Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

New LiveReload Backend #194

Closed
mattdesl opened this issue Jan 4, 2017 · 4 comments
Closed

New LiveReload Backend #194

mattdesl opened this issue Jan 4, 2017 · 4 comments

Comments

@mattdesl
Copy link
Owner

mattdesl commented Jan 4, 2017

I've been thinking about switching out tiny-lr for a more custom solution that uses uws in the server and plain old WebSocket on the client.

This might allow for:

  • Cleaner dependency tree and smaller footprint (tiny-lr has been a bit sketchy to depend on...)
  • The LiveReload stuff can run on the same port/server as budo
  • Better error handling and messaging; i.e. faster and more reliable LiveReload reconnections, better handling of IP changes, etc.
  • More control over LiveReload; potentially opening the door to features like [Idea] changes to <style> injected without page reload #104

Downsides:

  • Since budo's HTTP server will provide the LiveReload client script, we have to name it something obscure to avoid a conflict with an actual user script
  • We lose some features of LiveReload like legacy browser support and image reloading (is anyone using that?)
@mattdesl
Copy link
Owner Author

mattdesl commented Jan 6, 2017

Some progress this week — you can test like so:

npm install mattdesl/budo#feature/livereload-rework -g

@mattdesl
Copy link
Owner Author

mattdesl commented Jan 9, 2017

More progress in the same branch.

  • CSS reloading is more robust in my tests across latest versions of: FF/Chrome/Safari and iOS Safari/Android Chrome. Things like deeply nested style sheets (due to imports), reloading <style> tags, etc works more reliably and without any flashing of unstyled content.
  • Things seem perceptually faster but I should do some benchmarks to be sure.
  • Much cleaner error handling when clients disconnect or IP changes, it will generally reconnect smoothly
  • All runs on the same server as budo so no need for a second port or second server
  • Allows some new and interesting APIs/features

There are various open questions like: how should the LiveReload client be bundled and served to the user? How many times should budo try to re-connect to the LiveReload server? Should we expose the LiveReload client (send / receive events from budo's WebSocketServer) to the user, or force them to write their own client-side WebSocket handling if they want that sort of thing?

You can see some experimental LiveReload extensions but I'm still not 100% sure that will make it into budo.

@mattdesl
Copy link
Owner Author

BOOM

done. mostly.

@tintenfrei
Copy link

Got this on my terminal when running canvas-sketch: can you give me a hint of how to solve it?

NOTE: The bundled LiveReload client could not be found, so budo will
generate this on the fly.
This is most likely because you are using a git cloned version of budo
instead of installing it from npm.
You can run this from your cloned budo folder to create a build:
npm run bundle-live-client

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants