Skip to content
New issue

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

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

Already on GitHub? Sign in 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

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

No branches or pull requests

2 participants