Add Live Reload using WebSockets

[wh1le]

Adds WebSocket-based live reload support (edited, deleted, created)

What's included

• LiveReload server - uses listen gem to watch and faye-websocket to push changes
• Rack middleware intercepts WebSocket upgrade requests at/_live_reload
• Frontend JS - connects via WebSocket, fetches fresh HTML on change, swaps .main content and nav sidebar
• Config - live_reload: true by default, disable with --no-live-reload or live_reload: false in .madness.yml

[DannyBen]

Thanks. There are issues with this PR that need addressing before I can decide if I want to merge it.

1. It seems to originate from an outdated commit (62 commits behind).
2. I prefer to avoid negative flags. No --no*.
3. Live reload, if added, should be off by default.
4. Live reload should work out of the box for non evented file systems (use polling only or by default).
5. Tests should at least pass, and at most provide 100% coverage.

Even if all these are fixed, I am still not sure I want to merge - there is more overhead than I am comfortable with, but if the above is fixed, I can at least start to evaluate.

[wh1le]

Hey thanks for feedback! I use it mainly for live preview and editing. I love go-grip but it misses file tree navigation. The test fix should be an easy one. If you are not comfortable maintain WS part, we can close it I can maintain fork for myself because it solves my problem. Let me know your thoughts

[DannyBen]

Thanks for being cool and understanding about it.

My TLDR reply to this would be: Yes, I would feel more comfortable avoiding live reload in madness.

The longer rationale is this:

1. Contrary to a "web development server" where you almost always "edit", madness is a "viewer first" - so I assume most people, most of the time do not need the auto reload.
2. Another point to support this - is that madness uses standard markdown, so there is no constant need to do "trial and error" to see if what you edited looks good.
3. Because of these two points, I am in a position where I would love to have auto reload, but not at any cost. Only if it is "cheap".
4. While your implementation seems correct, it is definitely not cheap. Some reasons:
   • The listen gem is causing issues with system rubies (require English/english naming issues)
   • The web socket gem is a heavy-duty dependency - also brings its own baggage and increases the surface for potential problems
   • The file watching defaults to evented, which means it does not work on several file system configurations (like VMs) - changing it to polling only, means less ideal solution for users who can use evented, and adding a configuration option to choose between evented/polling, yet again increases the surface for issues and the maintenance burden.

So to sum it up - I would love to have this feature, but not at its current cost.

In any event, do not close this PR - as I or someone else may find the motivation to try and reduce its cost.

[wh1le]

Thanks for the thoughtful breakdown, makes total sense.

I think this can be addressed with polling and or SSE and listen with simple File.mtime polling in a thread.

Rack supports SSE streaming natively. One-directional push is all live reload requires. Polling with Dir.glob + File.mtime in a background thread. Works on every filesystem (VMs, Docker, NFS) without platform-specific watchers.

Also it can be off by default and enabled with --live-reload or live_reload: true in .madness.yml

[DannyBen]

Polling with Dir.glob + File.mtime

Will this help? https://github.com/DannyBen/watchly
It is a gem I made as a replacement to Filewatcher - it is a lightweight, polling only file watcher.

If we can mitigate some of the issues, than having live reload becomes much more attractive.