LIVERELOAD ATOM FULL
LIVERELOAD ATOM CODE

I'm using v14, since I can't live without optional chaining Node.js for running the development server.

ws for setting up server-side websockets.

nodemon for detecting file changes and rebooting the server as a consequence.

Sure, script tags should all be within the tags, but if they aren't the browser will run them anyway. This works because HTML parsers are so loosey-goosey.

LIVERELOAD ATOM CODE

Note that while 'injection' sounds like something fancy, here it's nothing more than wrapping the 'injected' code in tags and appending that to the end of the HTML documents when the server sends them to the browser. Upon breaking those connections, the pages immediately reload and end up establishing a new connection to the newly-rebooted server. Have that script reload the page when the connection closes.Ĭollectively, this makes it so that any change to a source file causes the server to reboot and therefore break the websocket connection to any pages loaded in the browser. Inject a script into served HTML files that opens a websocket client.Run the dev server with nodemon so that it will be rebooted whenever any source file changes.Run a websocket server alongside the development HTTP server.Here's the simple approach I'm starting with: Eventually it might be useful to know what has changed, but to start we just need to know that anything has changed and reload the site as a consequence.

Websockets are more fun and will give a lot of flexibility in the future (in case you want to turn this live-reloader into something hotter), so let's go that route. That way there's no lag between a change and that change becoming visible on the site. We could set up a 2-way websocket so that the server can push information to the browser. We could set plain old vanilla HTTP route that the site pings every 100 milliseconds (or so) to ask if something has changed. There are two reasonable choices for how the server would inform the browser to trigger a reload: We'll make a simple, live-reload development server that refreshes your browser whenever you change a source file. But it's a fun exercise to make your own, and remove some of the mystery in the process. You should definitely get an off-the-shelf, hot-reload server for serious development work. If not, a bit of googling will get you to some open source projects that will do the trick to some degree or another. Which pre-existing solution you use depends on your project, but if you're doing modern webdev there's a good chance you're using a framework or a module bundler (like Webpack) that provides a hot/live-reload server out of the box. This is amazing because the rest of your website's state (form content, open/closed state of widgets, etc) stays intact while only the stuff you've changed gets changed on the page.įortunately, very smart people have solved the hot-reload problem for you. The goal of hot reloading is to refresh the minimum possible portion of content on the page when something changes, instead of the entire page. Modern frameworks like Vue and React have what they call 'hot' reloading, which is a huge improvement to 'live' reloading.

LIVERELOAD ATOM FULL

It's already helpful if the page simply does a full reload whenever any source file changes. In short, it's having a development server watch for changes to your code, then telling your browser to refresh itself so that the rendered page stays in sync with your code. If you're currently making webpages without automatic reloading, drop everything and get that hooked up now! I didn't even know that was a thing, but now I can never go back. I didn't realize just how annoying this was until I started using modern frameworks (Vue and React), which come out of the box with 'hot reloading'. I spent my first few years of web development alt-tabbing over to my browser to manually refresh the page every time I made a change to the code.

Livereload atom