[Question] about HMR support with Livereload

[akaibukai]

Hello and thank you for this project!
Just heard of it and after reading the readme I couldn't agree more with the incentives behind this project..
I'm primarily interesting by this project for working with Svelte and CSS frameworks like Tailwind which also requires other tools like PurgeCSS, DropCSS, SASS, etc.)

Currently even Rollup and Svelte don't officially support HMR (however there are good results for example with this project https://github.com/rixo/rollup-plugin-svelte-hot)
And it's really a game changer to have HMR support with Livereload when working with frontends.
Anyway, keep up the great work!

[evanw]

I'm mainly focused on getting end-to-end builds up to the speed of HMR so I'm not going to be working on HMR, at least not in the short term. Ideally with esbuild you wouldn't need HMR to have good development iteration speed anymore. Short term I'm going to be more focused on features that are useful for production builds such as code splitting and tree shaking.

HMR can still be useful for live CSS changes and for retaining JS application state between reloads. But I think it's worth experimenting whether that can be solved at the framework level instead of the build system level (e.g. with swapping the CSS tag or storing JS state in sessionStorage). That also seems more sustainable for esbuild since frameworks will likely have custom requirements for HMR transforms and esbuild doesn't have plugin support since it's written in Go.

[anotherglitchinthematrix]

I think there is a simple solution, at least for front-end development, that we can easily assamble for any project, we can use Watchman to trigger the build on the source code changes and serve the output with the BrowserSync.

[natew]

HMR is more than just building faster, the state preservation part is absolutely key. Even doing a window reload can be many seconds of delay as it reloads and parses all JavaScript.

Esbuild is especially suited to support HMR as the value of HMR increases the faster the build goes. Being able to customize game logic while the game is running, or really fine tune design or interactive elements that are deeply nested, is such a big deal, it’s almost akin to a leap forward for development in general.

I see the plug-in system now exists somewhat, would be interested in discussion towards the next steps that would enable Fast Refresh to work. This would be one of the last big features esbuild would need in order to be a viable replacement for a large portion of app developers.

[zaydek]

I’d encourage anyone who is curious about hot-* capabilities to check out this comment: #21 (comment). I created a minimal reproducible repo for experimenting with esbuild + TypeScript + hot reloading.

It’s not HMR but I think it will give most of you what you need without burdening the implementation complexity of esbuild. I agree that if esbuild were to leverage hot reloading, it would force Evan to give something else up in terms of time or more relevant features.

I’d love to see HMR myself but not before esbuild is at least 1.0. This should help anyone curious with the process of implementing hot reloading capabilities without JavaScript fatigue.

[zaydek]

Follow-up: If you’re implementing esbuild in Go you may want to check out this project: https://github.com/osdevisnot/sorvor. The author implemented live-reload which is more reliable than typical techniques (e.g. chokidar, etc.). It’s very fast and I thought it was HMR at first.

Implementation is here: https://github.com/osdevisnot/sorvor/blob/main/pkg/livereload/livereload.go.

Edit: More follow-up: I implemented an incrementally recompiled HTTP server w/ server-sent events for live reload here: https://github.com/zaydek/esbuild-dev-server. This is like the previously linked repo but is implemented as simply as possible. Some contextual background here which may be useful: #645 (comment).

In short, I think what all of the HMR issues are talking about is a rapid development server that takes advantage of esbuild’s incremental recompilation capabilities. This can be implemented today without HMR by using file watchers and server-sent events, which are an HTML spec, for live reloading. Again, it’s not the same as HMR but it does solve for the same problem space and works today.

[zaydek]

Follow-up: I implemented an incrementally recompiled HTTP server w/ server-sent events for live reload here: https://github.com/zaydek/esbuild-dev-server. This is like the previously linked repo but is implemented as simply as possible. Some contextual background here which may be useful: #645 (comment).

In short, I think what all of the HMR issues are talking about is a rapid development server that takes advantage of esbuild’s incremental recompilation capabilities. This can be implemented today without HMR by using file watchers and server-sent events, which are an HTML spec, for live reloading. Again, it’s not the same as HMR but it does solve for the same problem space and works today.

[kim366]

This is a bit unfortunate. With live reload instead of HMR overall esbuild is slower than Parcel in reflecting changes in the browser

[tsugabloom]

@kim366 you're welcome to try vite 2.0 (supposedly framework agnostic) which uses esbuild with hmr. might be quicker than your parcel setup.

[evanw]

I have some updates: With esbuild version 0.17.0, you can now easily do live reloading without a lot of setup. You can also do hot reloading of CSS without much additional work. However, I still consider hot reloading of JavaScript to be out of scope. There are other tools such as Vite that can do this if you need it. I'm closing this issue because live reloading and hot reloading has now been implemented in esbuild to the intended extent.