Esbuild: [Question] about HMR support with Livereload
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!
akaibukai
>All comments
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.
evanw
on 9 May 2020
Related issues
qnp
路
4Comments
a7ul
路
3Comments
aelbore
路
3Comments
wcastand
路
4Comments
egoist
路
3Comments
Most helpful comment
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.