5 ms·

Yes we have, and while the various new JS frameworks may be a bit more complicated they are also vastly more productive environments. For example webpack's deve

Yes we have, and while the various new JS frameworks may be a bit more complicated they are also vastly more productive environments. For example webpack's development server let you develop your app with real time updates with hot reload. The productivity benefits from just that are worth more than a few days of setting up webpack. And that's just one thing webpack provides

yoavm 9y ago
How is the productivity benefits from not having to press F5 after I'm updating the code is worth a few days of setting up Webpack? If I sum the time it took me to refresh pages since I started using the internet it doesn't get to a few days.
- boubiyeah 9y ago
  Plus, it uses a lot of CPU/battery everytime you save in your IDE whether you're going to actually check the result or not.
  - greenhatman 9y ago
    If either of those are actually problems for you then your dev environment leaves a lot to be desired. You can't be wasting cognitive load on that.
- JasonSage 9y ago
  This actually sounds hyperbolic to me. Are you sure that's the case?
  - yoavm 9y ago
    I'm not sure. But since the average time for a webpage to load is about 3 seconds[0], I would need to press F5 17,280 times to be refreshing for a whole day. I don't think I have, and even I did, quite a few of these had nothing to do with me developing anything, so hot-reload wouldn't help here. [0] https://www.semrush.com/blog/how-fast-is-fast-enough-page-load-time-and-your-bottom-line/ https://www.semrush.com/blog/how-fast-is-fast-enough-page-lo...
  - Can_Not 9y ago
    It's probably completely hyperbolic. No way it should take days unless you're trying to retrofit a legacy project and learn it at the same time.
- jwdunne 9y ago
  You're not counting the fact that a refresh may require developers to get back to the app state right before refresh.
  - yoavm 9y ago
    Yeah, maybe. But I'm also not counting the times I worked on a hot reload enabled project and I wasn't sure if it actually reloaded or maybe there was an error somewhere that made the whole thing stop working, and so I just manually refreshed. It's just not that amazing, and it certainly not worth a few days of setting up. Would someone really start a project from scratch and then spend days on getting hot reload to work? I'd never want to hire that person honestly, nor to develop in such a fragile platform. Hot reload is nice, but there's nothing revolutionary about it that justifies more than an hour of getting things to work.
    - jwdunne 9y ago
      Oh no I agree. It's far more painful than it needs to be. I've found productivity boosts in shortening the feedback loop. A tighter feedback loop makes it easier to get into flow. But days of effort to get a simple thing working defeats the purpose. My worst days are when I look over the day and I've spent it fixing a build process - there's no flow in that. I could just bite the bullet and still get into flow albeit less smoothly but still. That's how I worked for years. I just wanted to point out it isn't as simple as eliminating a refresh. There is a gain behind that.
- seanwilson 9y ago
  > How is the productivity benefits from not having to press F5 after I'm updating the code is worth a few days of setting up Webpack? It doesn't take a few days, it's more like a few hours, and it's completely worth it. It makes development much less frustrating, it reduces cognitive load (no switching back and fourth between windows) and it's faster (includes not having to get the app back into the state it was in before with hot reloading). When compiling and reloading is something you're doing hundreds of times a week, a seemingly small improvement makes a huge difference to how enjoyable it is to work on a codebase which makes you more productive. I'd say the same thing about reducing a test suite run from 10 seconds to 1 second; it might only be saving you a few seconds each time but it makes you more productive because tightening the feedback loop reduces frustration which increases productivity. There's nothing worse than attempting a fix, waiting 60 seconds in anticipation it worked, seeing the same error message as last time and then having to try again for instance.
  - greenhatman 9y ago
    Besides that, you don't even have to set up Webpack yourself if you're using the vue-cli app to create your boilerplate. I've never set up Webpack myself, but I'm getting all the benefits.
- Tehnix 9y ago
  Unless you have you entire state stored persistently across refreshes, then hot loading takes care of getting into the exact state you were in again. Make a small change -> immediately visible in the UI. Before hot reloading, make small changes -> (automatically) refresh page -> navigate to where you were, and set up the state again you were in. Hot reloading saves so much time, and means you'll check for smaller increments, because it's painless.
- Can_Not 9y ago
  Webpack takes zero time to setup if you use any of the popular boilerplates or standard generators.
Confusion 9y ago
Real time updates and hot reload are almost completely independent of js and webpack. E.g. Middleman has that via the ‘livereload’ feature.
interfixus 9y ago
Eh ... right this moment, I'm watching Firefox auto-reload the stuff I'm working on, by the sheer magic of me saving files in my editor. This is pug, scss, assorted js, svg, you name it. Am I missing out on man-years of productivity for never really having taken to the brontosaurus model?
- bitexploder 9y ago
  Nah, I think the trend of the commentary was just that the tooling is hard to learn how to set up. I think it is probably worth setting up and learning the tooling if frontend work is a non trivial part of your life. But as someone who just wants to put a toe in and feel productive it can be rough to find easy to use front end frameworks.
- pixelbash 9y ago
  Haven't we had auto reload since long before webpack? Or am I missing something.
0x0 9y ago
I dislike hot reload for a few reasons. One, it makes it difficult to keep two tabs open to compare the "before" and "after" of a change, because both tabs reload the "after" instantly. Two, you can get into an "impossible" state where you've navigated into a section of the site and get to see an "after" state that turns out to be unreachable because the change affected earlier navigation. Three, it is often unclear if everything reloaded properly during a hot reload, especially if you have also fiddled around with stylesheets etc in the chrome developer console. To each his own, though! :)
WD-42 9y ago
Hot Reload is not unique to webpack. Hugo for example, provides hot reload. At the same time it's an insanely fast static site generator, which you install by simply downloading a binary. No tools, no dependencies, no hundreds of thousands of node modules.
andrei_says_ 9y ago
Hot reload is not unique to webpack. The multi-day setup or the multi-day attempts to set it up followed by giving up, are. I very much would like to use a simple, sturdy, predictable environment and trying to work with webpack has brought me only frustration. Things that should get chained together and just work, don’t. To fix them I needed to understand obscure bugs in infinite npm dependencies. I’m not that good at JavaScript and honestly don’t want to be. I would gladly pay $50-100 per set up if this service existed.

yoavm 9y ago

How is the productivity benefits from not having to press F5 after I'm updating the code is worth a few days of setting up Webpack? If I sum the time it took me to refresh pages since I started using the internet it doesn't get to a few days.

boubiyeah 9y ago
Plus, it uses a lot of CPU/battery everytime you save in your IDE whether you're going to actually check the result or not.
- greenhatman 9y ago
  If either of those are actually problems for you then your dev environment leaves a lot to be desired. You can't be wasting cognitive load on that.
JasonSage 9y ago
This actually sounds hyperbolic to me. Are you sure that's the case?
- yoavm 9y ago
  I'm not sure. But since the average time for a webpage to load is about 3 seconds[0], I would need to press F5 17,280 times to be refreshing for a whole day. I don't think I have, and even I did, quite a few of these had nothing to do with me developing anything, so hot-reload wouldn't help here. [0] https://www.semrush.com/blog/how-fast-is-fast-enough-page-load-time-and-your-bottom-line/ https://www.semrush.com/blog/how-fast-is-fast-enough-page-lo...
- Can_Not 9y ago
  It's probably completely hyperbolic. No way it should take days unless you're trying to retrofit a legacy project and learn it at the same time.
jwdunne 9y ago
You're not counting the fact that a refresh may require developers to get back to the app state right before refresh.
- yoavm 9y ago
  Yeah, maybe. But I'm also not counting the times I worked on a hot reload enabled project and I wasn't sure if it actually reloaded or maybe there was an error somewhere that made the whole thing stop working, and so I just manually refreshed. It's just not that amazing, and it certainly not worth a few days of setting up. Would someone really start a project from scratch and then spend days on getting hot reload to work? I'd never want to hire that person honestly, nor to develop in such a fragile platform. Hot reload is nice, but there's nothing revolutionary about it that justifies more than an hour of getting things to work.
  - jwdunne 9y ago
    Oh no I agree. It's far more painful than it needs to be. I've found productivity boosts in shortening the feedback loop. A tighter feedback loop makes it easier to get into flow. But days of effort to get a simple thing working defeats the purpose. My worst days are when I look over the day and I've spent it fixing a build process - there's no flow in that. I could just bite the bullet and still get into flow albeit less smoothly but still. That's how I worked for years. I just wanted to point out it isn't as simple as eliminating a refresh. There is a gain behind that.
seanwilson 9y ago
> How is the productivity benefits from not having to press F5 after I'm updating the code is worth a few days of setting up Webpack? It doesn't take a few days, it's more like a few hours, and it's completely worth it. It makes development much less frustrating, it reduces cognitive load (no switching back and fourth between windows) and it's faster (includes not having to get the app back into the state it was in before with hot reloading). When compiling and reloading is something you're doing hundreds of times a week, a seemingly small improvement makes a huge difference to how enjoyable it is to work on a codebase which makes you more productive. I'd say the same thing about reducing a test suite run from 10 seconds to 1 second; it might only be saving you a few seconds each time but it makes you more productive because tightening the feedback loop reduces frustration which increases productivity. There's nothing worse than attempting a fix, waiting 60 seconds in anticipation it worked, seeing the same error message as last time and then having to try again for instance.
- greenhatman 9y ago
  Besides that, you don't even have to set up Webpack yourself if you're using the vue-cli app to create your boilerplate. I've never set up Webpack myself, but I'm getting all the benefits.
Tehnix 9y ago
Unless you have you entire state stored persistently across refreshes, then hot loading takes care of getting into the exact state you were in again. Make a small change -> immediately visible in the UI. Before hot reloading, make small changes -> (automatically) refresh page -> navigate to where you were, and set up the state again you were in. Hot reloading saves so much time, and means you'll check for smaller increments, because it's painless.
Can_Not 9y ago
Webpack takes zero time to setup if you use any of the popular boilerplates or standard generators.

Confusion 9y ago

Real time updates and hot reload are almost completely independent of js and webpack. E.g. Middleman has that via the ‘livereload’ feature.

interfixus 9y ago

Eh ... right this moment, I'm watching Firefox auto-reload the stuff I'm working on, by the sheer magic of me saving files in my editor. This is pug, scss, assorted js, svg, you name it. Am I missing out on man-years of productivity for never really having taken to the brontosaurus model?

bitexploder 9y ago
Nah, I think the trend of the commentary was just that the tooling is hard to learn how to set up. I think it is probably worth setting up and learning the tooling if frontend work is a non trivial part of your life. But as someone who just wants to put a toe in and feel productive it can be rough to find easy to use front end frameworks.
pixelbash 9y ago
Haven't we had auto reload since long before webpack? Or am I missing something.

0x0 9y ago

I dislike hot reload for a few reasons. One, it makes it difficult to keep two tabs open to compare the "before" and "after" of a change, because both tabs reload the "after" instantly. Two, you can get into an "impossible" state where you've navigated into a section of the site and get to see an "after" state that turns out to be unreachable because the change affected earlier navigation. Three, it is often unclear if everything reloaded properly during a hot reload, especially if you have also fiddled around with stylesheets etc in the chrome developer console. To each his own, though! :)

WD-42 9y ago

Hot Reload is not unique to webpack. Hugo for example, provides hot reload. At the same time it's an insanely fast static site generator, which you install by simply downloading a binary. No tools, no dependencies, no hundreds of thousands of node modules.

andrei_says_ 9y ago

Hot reload is not unique to webpack. The multi-day setup or the multi-day attempts to set it up followed by giving up, are. I very much would like to use a simple, sturdy, predictable environment and trying to work with webpack has brought me only frustration. Things that should get chained together and just work, don’t. To fix them I needed to understand obscure bugs in infinite npm dependencies. I’m not that good at JavaScript and honestly don’t want to be. I would gladly pay $50-100 per set up if this service existed.