[izelnakri]

I'm actually very happy that esbuild doesnt have HMR by default. Despite the fact that most frontend devs loving/hyping HMR, I prefer live-reloads more because it refetches data/makes network calls and run my route hooks without any additional step. This is particularly important when you run your application tests in the browser(thats better than running app tests in CI btw) and change these test files constantly. The fact that most frontend devs favor HMR over live-reload signals something that I really dislike.

[nperez]

I’ve been a f/e dev for around a decade and I don’t trust HMR. I end up refreshing manually anyway just so I know I’m not seeing issues that don’t exist due to event bindings not refreshing properly, or app state getting messed up between loads. It’s fine for styling, but worries me when there’s too much complexity involved

[jakub_g]

IIRC, HMR in webpack has an issue when you add/remove/possibly reorder imports in JS; the imports are cached in memory by their index (or something like this), so when you remove a fifth import, suddenly the previously-sixth import statement will refer to the wrong module after HMR.

Took me a good while to understand the issue is with HMR and not my code. I restart the dev server many times a day just to be sure or when things inevitably explode.

[AltruisticGapHN]

That and the fact that unless you have two monitors often as you save the refresh happens out of view, when you’re not seeing the page, so you lose the immediate visual feedback of what actually changes. When you make minute touches to a design it’s annoying. When I hit F5 myself I can look at exactly what I’m interested and see if it shifted some pixels, if the font size is a bit better or worse...

[dota_fanatic]

> unless you have two monitors

Or have your editor and browser window tiled next to each other? Given how often FE development dabbles with design, using at least one decently sized monitor seems requisite.

And aren't FEers generally tweaking design in the DOM via a browser's developer tools when they're not sure what they want yet, copying back over into source once the design is finalized? Seems downright unpleasant to modify styling in the way you've described, and odd given there's a fantastic IDE in every major browser for styling exploration.

[RussianCow]

It's often much faster to make the change in the code directly than in the dev tools. For instance, I can very quickly apply a LESS mixin to an element, which would require knowing and making those specific changes to the raw CSS via the browser. The same goes for pretty much anything that's more than a one-value change.

[dota_fanatic]

Yes, I agree for what you’re describing, but that’s not the scenario I was referring to: the one where you don’t know how far over, how tall, how opaque, etc something should be and there’s no existing pattern to reach for off-the-shelf, like a mixin. Iterative exploration of design space.

[wishinghand]

You bring up a good point. Wondering if there can be some way to have both side by side. When I’m working on markup or css I definitely want HMR. But when I’m in the script section I’ve run into issues where I needed to reload the page.

[capableweb]

> some way to have both side by side

Yes, just hook up to the reloading event of HMR on the client-side and call `window.location.reload()` when that happens, now you have traditional "live reload".

[AltruisticGapHN]

Agree I hope Vite has a way to easily turn it off. Never understood the appeal. Way more fun to "see" what you’re going for in your mind and write more at once and see what happens, then react compulsively to a tight feedback loop. I think these features sometimes don’t make us better developers. I’m sure it has some good uses, personally never needed it.