Status/Roadmap of the project

[cristian-eriomenco]

First of all thank you @gaearon for this incredible and amazing initiative on creating the Hot Loader.

I've raised this ticket, in order to get a better understanding on whether the project is still going to be developed/finished. At the moment the project seems to feel, slap-my-face-now, abandoned? (just by looking at the stats, correct me if i'm wrong).

So instead of me moaning, it would be worthwile that we identify the remaining open features/tasks to be developed and have a better understanding whether it has any future or not.

IMHO understanding what is outstanding will also help the potential contributors and maybe attract more enthusiastic people to provide some help.

Thanks!

[gaearon]

This is probably better discussed in RHL repo.
Anyway, here’s my perspective.

RHL introduced a lot of mess into the ecosystem because people ran after shiny things without actively working on the underlying infrastructure. As a result we got 10,000 boilerplates with varying degrees of brokenness. Everybody wanted “hot reloading” but few knew how to configure it correctly, and many ended up with development code in production builds, spent days trying to get HMR to work, blamed Webpack and React, had broken dependency updates, etc.

It was partly my fault, and I wanted to fix it. For the past few months I’ve been working on Create React App which is my attempt to build a solid foundation for adding developer experience features without burdening app developers. Since the configuration is hidden, you can’t configure it incorrectly. Since dependencies are hidden, you don’t need to worry about updating them one by one and solving the resulting issues. Since it works on top of lower-level technologies, it can patch over their faults and deliver a better integrated experience.

I still care about hot reloading a lot. But I think I have been doing it in the wrong order all this time. I should have focused on stability first before the hype came in. I don’t think that continuing to work on React Hot Loader in its current form is the best use of my time right now, and I’m happy to hand over maintenance to other people (thanks @calesce for stepping up!) People still see hot reloading as something gimmicky, fragile, and flaky. It is not a good default yet. This is what I want to fix, but the way to fix it is by building trust in the tools. It doesn’t just need to work, it needs to work well in every case, or do full refresh when it can’t. There should never be a situation where you aren’t sure if it worked because this builds up the frustration.

Here is my current plan about adding hot reloading to React:

• Make Create React always refresh the page on change so people learn to trust it and stop pressing “refresh” themselves.
• Add syntax error overlay to Create React App so that people spend more time in the browser and aren’t afraid that making errors forces them to look at terminal or console.
• Add a “redbox” in Create React App on any JavaScript error in development. This helps ensure page never appears broken, and that people spend even less time in the DevTools console, and more time in the browser app section.
• Add the necessary hooks to React to avoid hacks like this, a top-level <AppContainer>, or module.hot.accept code. The user shouldn’t change their code in any way for hot reloading to work. Incidentally we need the same hooks for React DevTools so it aligns with React team plans.
• Enable a simple implementation of hot reloading that is guaranteed to work in 100% cases without any hacks like proxies and associated pitfalls. In practice this means that I’ll likely enable it only for stateless functional components defined in separate files. We recommend extracting markup-heavy code into separate components anyway so this encourages cleaner component structure.

At every point of time the goals are:

• It works 100% of the time.
• When it can’t hot reload, it refreshes 100% of the time.
• The page never ends up in a broken state due to hot reloading.
• Every error is reported clearly.
• People don‘t get confused “whether it worked or not”.
• Changes to React internals won’t suddenly break anything because we only use public APIs.

I am focusing on Create React App because I believe that hot reloading can only work truly well if it’s a part of an integrated experience we can fully control. Otherwise small incompatibility issues will keep it flaky. I also don’t necessarily want this to be branded as React Hot Loader. I want people to associate hot reloading with React itself, as an officially supported part of the default setup. We’ll see if we can make it work well enough to deserve this.

A project like React Hot Loader also has its place, as it attempts to solve many more use cases. But it has proven impossible for me to deliver the quality I want with it. I’m trying something different with the integrated approach now. I understand that not everybody may be onboard with my goals and methods, and that’s fine. I’d love to see people try different things as opposed to everyone relying on RHL, and I’d also love to see people keep improving RHL itself as it has slightly different goals.

I hope this clarifies it a little!

[cristian-eriomenco]

@gaearon Thank you for a detailed and comprehensive response. Respect. Closed

[jcreamer898]

@gaearon is my hero

[gaearon]

Next step: facebook/create-react-app#783.

[gaearon]

So, we finally released the error box in Create React App which means we can start experimenting with hot reloading in some ways in the future.

[gaearon]

facebook/create-react-app#2304

[gaearon]

I've previously archived this repo but I'm unarchiving it now just to comment that we did it.

https://reactnative.dev/blog/2019/09/18/version-0.61
https://nextjs.org/blog/next-9-4
https://github.com/facebook/create-react-app/releases/tag/v4.0.0

It just took a few more years than planned.