React Fast Refresh allows for refreshing only the components that were modified as well as maintaining things like state while refresh. This is excellent dev experience.
Very jealous of this kind of speed on refresh. The Fast Refresh React docs within the React Native docs give a bit more insight here: https://reactnative.dev/docs/fast-refresh
I don’t know, HMR has been a mixed bag in the projects I’ve used it on (it was so problematic on one webpack project, I disabled it, and am happier for it). Better to have it than not I suppose, but really, a fast full refresh is good enough - sometimes Meteor is that fast (like on a new project), but it doesn’t scale.
Totally understand about hmr, but if it’s a requirement for this kind of fast refresh, I think it’s worth it. I mean this in the most respectful way possible to meteor core devs, but Meteor currently is by far the slowest dev process I use in my projects. I think hmr and fast refresh can move us forward in that department.
Just to point out though - it’s WAY faster on Linux than Windows. This is way more apparent during deploy - the difference is 2 minutes on Linux vs 30 minutes on Windows!
I haven’t looked in depth into implementing HMR, but at a high level the build process would probably be something like:
Get a list of all files in the app that the app has compilers for
Compile the files
Find and resolve imports and lazily compile files that are imported
Link the files. During or after this step it would probably compare to the previous linker result to detect which files were modified, and prepare something to send to the client that can be used for HMR
After the client has received the changed files, the output can be written to disk. There are probably exceptions to when this could be delayed.
Most of this is the normal build process. The main difference to a normal rebuild is that step 5 could sometimes be delayed until after the refresh, and there would be more work done by either the linker or an additional step done afterwards. HMR could probably update the page faster than a full refresh, and save time from manually returning to the previous state, but it is unlikely to improve rebuild time itself.
I have had some challenges with getting HMR to work well in webpack, but once it does, it is worth the improvement in developer experience. This is a project I’ve been interested in.
This would be huge. I agree with @stolinski, Meteor currently has the slowest reloads compared to all modern react development setups. That’s not the good superlative to be in
I’m going to be diving deeper into the Vue + Meteor packages to more deeply understand & be able to support them better. One day I’ll probably be digging deeper into React too.
It would be nice to develop some common best practices / strategies to deploying the various front-ends with Meteor for consistent developer experiences.
Yeah, totally. SSR is not fast! I actually disable it when I’m working locally by commenting out the import statement in server/main.js (all the SSR stuff is in another file).
I wonder if any other platform has an SSR HMR solution. I haven’t heard of anything like that.
Totally, but slow reloads aren’t exclusive to SSR. We get full server restarts on React file changes even when those files aren’t referenced on the server. If we had client only reloads with the main Module option, that would go a long way.
That’s not happening anymore for me on Meteor 1.10.2 - if I disconnect SSR, I don’t get server rebuilds for files that are not connected to the server bundle (I just tested and got a client only refresh that took under 2 seconds!). Are you still seeing that in the latest versions?
That should not happen, perhaps there some dependency or import somewhere.
Same, I think this would be huge @zodern and I’m willing to bet that many folks would be willing to sponsor this work (myself included). I think HMR and tree-shaking are the two major items left on the Meteor build system to-do list and I think implementing those will anchor the Meteor server and build tool at the heart of the growing NodeJS ecosystem for years to come.
I’ve already reached out to Benjamin privately about this opportunity few months back (Sep, 2019) and here is what I wrote:
The react team is working on a better version of react-hot-loader and they’re are calling it Fast Refresh (to distance the brand from react-hot-loader). The previous version of react-hot-loader misses the refresh many times therefore many developers end up refreshing manually instead of gambling on the hot change to occur.
However the new version seem to be more reliable, and knowing the react team, there will be tons of hype once it’s released. I’m not sure about the implementation challenge of such a feature (exporting module change/accept APIs) but I think it’s great opportunity for Meteor to jump on that bandwagon if it is technically feasible. Either way, I think the industry is standardizing around this API and most front-end framework will end up supporting it (vue, svelte etc.) and it’ll also decrease the pressure on the build system to keep getting faster.
This is just a suggestion/opportunity pertaining to Meteor that came to my mind and I wanted to share with you.
Not only that, but Blaze had already HMR back in 2015 and it was working great! Meteor and Blaze were designed to work together and I wonder if this following the “market trend” with React (even if I understand the reasons why) has been the source of all the performance problems we’ve seen in recent years with Meteor…
This is exactly what I’m talking about. I was under the impression the mainModule was the way to go moving forward, but it has really ruined our build speeds.
Either way, getting client only rebuilds for mainModule would be great, but HMR with Fast Refresh are big improvements to dev experience and going to be a big deal for anyone considering Meteor over other platforms.
+ 
reactions)