https://futureofcoding.org/ logo
Join Slack
Powered by
Webpack's Hot Module Replacement is exactly the ty...
# thinking-together
r
Webpack's Hot Module Replacement is exactly the type of solution that the "Worse is Better" story tells us to avoid. True or false? Why? Why not? http://dreamsongs.com/RiseOfWorseIsBetter.html
m
webpack was a solution for a problem that no longer exists, ES modules exist in all evergreen browsers natively and there are tools to compile them away for old browsers
if the oldest browser is edge classic then you don't need to compile them away
r
That's a fascinating thread to explore, e.g., isn't Webpack still the industry standard way to compile SASS for example?
But I think that's tangential to the question about hot reloading. I wasn't commenting on Webpack itself, just the hot reloading implementation, which as far as I know is state of the art, and isn't supported by any browsers natively (I don't even think that's possible).
I don't see how hot reloading as a concept can ever be made to work reliably for exactly the reasons worse is better warns us about (e.g., there's no way to "back out" of state changes, that a correct hot reloading implementation would require). But I'm no expert in these things, so I was curious what folks around here think.
m
it requires some cooperation from the application, you can only reload stateless code without having to handle some part in your code
it's usually used to apply changes in style and layout (render functions) without reloading and having to navigate to the same place every time. For more complex changes the simplest solution is to reload the page
r
That makes sense, i.e., it's only useful in small cases sometimes. But that seems funny to me given the absolutely massive amount of engineering behind hot reload. Seemingly it's where the majority of JavaScript development resources are going these days, at least in the React community. That's a gigantic amount of engineering to put towards a solution that is only really going to be helpful for making small UI tweaks?
E.g., it seems like it's the banner feature of Gatsby, React Native, and Expo
Also this is the first time I've heard the state-conflicting limitations of hot reloading discussed. It seems like more people should be talking about how it's not a good fit for use cases that involve a lot of state?
s
Because at least in the react world a lot of people use redux and there are sufficient solutions to keep a redux store intact after a hot reload.
m
yes, as long as your source of truth is data and not object instances and you don't change the shape of the data too much it can be handled, that's what I meant with the application collaborating with hot code reloading
s
Agreed
Back to the original point I would say, that hot reloading does not aim to be the "right thing". It rather is the result of a longer path of optimizations, that actually started with just hitting F5. So it actually is the New Jersey method.
r
Interesting, ok to restate: The redux approach to managing state makes hot reloading less problematic.
That makes sense
Wouldn’t the New Jersey method be to still keep hitting F5? Hot reloading seems to be trying to replace that with MIT?
s
In the article you mentioned, it says the worse-is-better approach starts at 50% (F5) and then gets optimized to around 90%: hot reloading.
m
I used to implement hot reloading on my apps, in the last one I implemented a way to display each component in isolation at any starting state I want with all its behavior. Reloading is instant and it always takes me to the state I want, so I never implemented hot reloading for this one
r
LiveReload is the 90% optimization of F5 http://livereload.com/ Hot reloading is a ground up re-imagining of the concept of refresh that is entirely different, and vastly more complicated. It still seems firmly MIT to me.
This description of "the right way" even specifically highlights the problems of trying to reverse state that hot reloading seems to have (that's mediated by using redux): "The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine."
s
Unfortunately I cannot find a good history of hot reloading, but I am pretty sure, it wasn't designed and implemented in its current form initially and surely the additional solutions around state management, css, assets and so on were not designed in the same run, but came later on. So, I still think, for hot reloading, there wasn't a group of people going at the problem in the way of "how can we do this absolutely correct, complete, with a simple interface" and so on. But again, unfortunately I cannot prove it.
r
Got it, yeah I understand that perspective. You're saying that hot reloading isn't MIT because it was designed incrementally. I can definitely see that perspective, that definitely is one of the lessons from the story.
But I still see so much similarity between just using F5 and worse-is-better: "the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action". And the aforementioned state resolution issues with hot reloading. I.e., "the New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex."
s
Yeah, it sure does sound similar.
2 Views
Open in Slack
PreviousNext
Powered by