4

Forgive me if the question is too subjective.

I do understand what it is. No need to explain that, please.

I just don't get why people find it useful. Same for live reload. The act of pressing CMD+R isn't something that takes time. If the actual refresh takes significant time, seems like one should just fix their dev environment.

I have a trust problem with such things. Seems too likely that they'll end up causing bugs. I fear that I'd spend an hour tracking down a bug only to find it was hot-module-reloading's fault. Or that everything is working in dev, but breaks in prod because prod isn't using hot-module-reloading and dev is. Perhaps this fear is misplaced.

I also find it tricky to know when the changes have taken effect. Seems simpler to just know that once you press CMR+R, your changes are there.

tybro0103
  • 48,327
  • 33
  • 144
  • 170
  • 1
    it's a tool, like a left-handed can opener: some will find it useful, some won't. – dandavis Dec 23 '15 at 16:26
  • sometimes i have the browser on a different monitor than the editor. being a heavy keyboard user, it's a lot quicker to press ctrl+s than ctrl+s,alt+tab,ctrl+f5,alt+tab... for CSS, it's can't fail, for JS, it depends. – dandavis Dec 23 '15 at 16:28

3 Answers3

4

It's an efficiency thing. No matter how fast your dev environment is, when you press Refresh, it's going to take a second or two, since by definition things won't be coming from cache, and we're talking dev so there could be a bunch of HTTP requests that would be consolidated into a just a couple of HTTP requests in production. So if your workflow is save, switch to browser, hit refresh, you're sitting there for a couple of seconds. Every time.

With live-reload, hit save in your editor, and by the time you've switched over to your browser, the refresh is already completed or at least underway.

I was skeptical about the value of it until I started using it. Definitely noticed cycles were a little bit faster, sometimes markedly faster depending on what I changed and whether I flipped to the browser right away or not.

I haven't had trouble with it causing bugs. YMMV.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • Fair enough. What about knowing when it has taken effect? Does that ever get weird for you? – tybro0103 Dec 23 '15 at 16:24
  • @tybro0103: It hasn't so far. If I think for some reason it's failed, I just (drum roll please) hit refresh. :-) I'm not entirely sure it _has_ actually ever failed, but presumably so, nothing's perfect. – T.J. Crowder Dec 23 '15 at 16:26
  • Ditto...and the *older* I get (I'm sure I meant to say the *more experienced* I get), the nicer it is to have **effect** closer to **cause**. :-) – markE Dec 23 '15 at 23:20
3

HMR relies on the maintaining of state. For a simple web app the reload may only take seconds. For a complex web app the steps required to get to a state may be long and complex, open to mistakes along the way. So you do your long list of steps, get to the bit you are testing and smack, a silly typo means you have to start over again. All that unnecessary repetitive work can be avoided, changing a job from hours to tens of minutes by using HMR. I have no problems trusting it for what it is designed to do.

You would never release without testing, and you would never test with HMR. HMR is for development, you only need to trust it to maintain a state while work through a module.

tybro0103
  • 48,327
  • 33
  • 144
  • 170
Blindman67
  • 51,134
  • 11
  • 73
  • 136
  • 1
    Losing trust has nothing to do with not understanding. Are you more likely to trust a simple solution or a complex solution? Promises are a good example of a complex solution to a simple problem, that "promised" a lot to devs, and now it's starting to become a problem because of the way errors are handled. – trvsdnn Dec 23 '15 at 18:27
  • LOL promises were designed to simplify the event driven nature of Javascript applications. They are not faulty, nor is the old callback/event model faulty. It is the basic lack of understanding of what is going on under the hood that is the cause of problems. – Blindman67 Dec 23 '15 at 18:41
  • @Blindman67 "basic" lack of understanding... yeah. I didn't say they are faulty, I said it's a complex solution that a lot of people are using for a simple problem that callbacks can solve, and because of that complex solution they're getting bugs they wouldn't have otherwise. See https://github.com/mjackson/npm-http-server/pull/17/files#r48298501 and http://jlongster.com/Stop-Trying-to-Catch-Me – trvsdnn Dec 23 '15 at 19:46
  • @blahed If everyone had 35 years of programing experience there would be a lot less bugs. – Blindman67 Dec 23 '15 at 19:57
  • 1
    @Blindman67 I'll leave it at this: You made a good point about the benefits of reloading. I think the way you went about making your point actually hurt your point. – trvsdnn Dec 23 '15 at 20:15
  • @blahed I will stick to what I said. Knowing and trusting the tools you use is very important in any industry. Not trusting new technology because of a vague feeling is not going to do anyone any favours. It's a general statement not directed at anyone. – Blindman67 Dec 23 '15 at 20:27
  • TL;DR: Hot Module Reloading can save one significant time in the scenario where a manual process (following refresh) is involved to get to the desired state in which one is testing. – tybro0103 Dec 23 '15 at 20:29
1

It scares me too... if I can't trust it 100% of the time (and I can't get away from refreshing 100% of the time), why worry with the extra complication of it?

It's refreshing to refresh. That's my new saying.

trvsdnn
  • 146
  • 2