4 ms·

As soon as esbuild gets react hot reloading capabilities I’m jumping ship. Although that might be out of scope and there is Vite. I’m hoping to avoid vite and g

As soon as esbuild gets react hot reloading capabilities I’m jumping ship. Although that might be out of scope and there is Vite. I’m hoping to avoid vite and go pure esbuild. Fantastic tool. It will make JavaScript distribution a much more pleasant experience across the board when it gets wider adoption.

ccmcarey 6y ago
Think that's out of scope - doesn't snowpack (which uses esbuild) cover this though? https://www.snowpack.dev/ https://www.snowpack.dev/
- keraf 6y ago
  Snowpack uses ESM for development which allows really fast HMR. And ESBuild is used for production builds. Best of both worlds.
lhorie 6y ago
He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97 https://github.com/evanw/esbuild/issues/97
- parhamn 6y ago
  Makes logical sense from a library/unixy perspective. They offered similar reasoning for not including a file watcher at first but they eventually added that. HMR is pretty much the last missing piece to make this the only JS bundling and dev tool you need. It would be a bad decision to omit it.
  - qbasic_forever 6y ago
    Check out tools like vite or snowpack, which use esbuild internally. They're the HMR developer experience you're looking for.
- izelnakri 6y ago
  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 6y ago
    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
    - AltruisticGapHN 6y ago
      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 6y ago
        > 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.

ccmcarey 6y ago

Think that's out of scope - doesn't snowpack (which uses esbuild) cover this though? https://www.snowpack.dev/ https://www.snowpack.dev/

keraf 6y ago
Snowpack uses ESM for development which allows really fast HMR. And ESBuild is used for production builds. Best of both worlds.

lhorie 6y ago

He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97 https://github.com/evanw/esbuild/issues/97

parhamn 6y ago
Makes logical sense from a library/unixy perspective. They offered similar reasoning for not including a file watcher at first but they eventually added that. HMR is pretty much the last missing piece to make this the only JS bundling and dev tool you need. It would be a bad decision to omit it.
- qbasic_forever 6y ago
  Check out tools like vite or snowpack, which use esbuild internally. They're the HMR developer experience you're looking for.
izelnakri 6y ago
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 6y ago
  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
  - AltruisticGapHN 6y ago
    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 6y ago
      > 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.