A future without React



I would like to bring a concern regarding having a huge system that already uses React on everything in the frontend.

My concern is if someday React becomes obsolete or something better comes up after a couple of years. How can you build a codebase that can handle different front end libraries/frameworks?

Is AMD (requireJS) still something that may solve the problem? Can we still internally create different modules that can encapsulate the old and the new so that the system can scale together. That things can be rewritten easily because they are small and isolated?

I would love to read your thoughts about that. Please inform me if the question is not that clear. :slight_smile:


The answer to your question is simple: always use native web technologies.

You look at things far enough out into the future, everything will go away. React, Vue, Angular, etc. may be the extJS, mootools, and dojo of the past. If keeping your code as flexible as possible is the goal, using vanilla JS, HTML, and CSS is the way to go.

As for requireJS, you can look into native import functionality which is hitting most of the modern browsers right now. That’s one more library that you can check off your list as needing to rely on :stuck_out_tongue:


I totally agree with you on that.
The architecture is were I’m mostly thinking about. Would you simply separate modules and isolate general clean code outside and keep “view” models containing react separated and inject core modules inside react? or is there some other way of doing this? I’m trying to think of ways to keep the code as flexible as possible.


Using modules is a good idea in general. Thats core to any kind of large (or medium… or small) scale organization. AMD/require are already on their way out in favor of the newer import/export standards - though they were a necessity when those standards didn’t exist.

One thing to be mindful of when writing code is that, while using frameworks is OK - React exists because it solves a problem - know that there may be better solutions down the road. As such, you should write your code to be portable, decoupling functionality from the framework(s) you’re using as much as possible. For example, if you need a React component to show a user’s porn star name (apparently I’m “Shakin’ Thruster”), don’t put the code that has to make that translation in the react component itself. Keep it outside as a separate function that you could potentially move to any other codebase easily and use it with whatever framework it may be using.

This kind of approach to coding not only makes your code portable, but it also makes it easier to test and generally easier to debug. It can take some discipline to do (it’s a lot easier to just write working code all in the same place) but it usually pays off in the end, especially for larger projects.


My limited experience of React is when using it for a decent sized project, it’s best to bring in some other frameworks like Redux, reselect and things like that, each covering a different aspect. You’re right that things become irrelevant over time, but rarely does that happen to every aspect at once. So React would only cover the presentation aspect really, which is what it shines at.

For example, I hope someday there will be a state management library that doesn’t expect quite as much boilerplate as Redux, and if that happens then I just replace that part of my setup, with little impact on the React bit.


Can you guys see if this is something we should do?
I find this a good solution to what I’m talking about:


This doesn’t seem directly related to what you were talking about before. This looks like an abstraction around other frameworks/libraries that better helps you manage multiple instances of those within a single context. I wouldn’t see any use in using it if you’re currently only dealing with react, or ultimately some other future framework.


This will kind of build a code base that does not depend on redux and react. We can easily replace it. But I have a question regarding that framework I just shared. Can you and should you rather use node modules to separate your apps and join them in one unified module to deploy? Is that a practice used and recommended? I do not want to end up building a monolith of a front end app. I want to separate parts of it as isolated apps.


Dependency on react/redux is whether or not you use react/redux :wink: . If you don’t want to use it, then use something else. If you do use it, the dependency is there. Single-spa doesn’t change that. It adds an additional dependency that attempts to help coordinate individual components of a page. If you’re using a single framework, that framework will already provide that coordination.

Where single-spa might be helpful looking forward is providing a means for a staggered migration path where you would be able to more easily swap out old components with the new migrated versions with minimal impact. This would then let you run the application with both frameworks at once, react for the old stuff, and future-framework-x for the new stuff. While we’ve done this before - at a more granular level, and without single-spa - generally its not ideal because of the extra overhead of having both frameworks served to the user rather than just the one. It depends on how massive your SPA is though, and what your migration plan is.

We’re in the middle of a migration now (from backbone to react) and we’re not doing any kind of transitional release where both frameworks are running together - at least not for this particular component. The react version is being developed internally until complete, then will be released as a full replacement of the original.

As far as modules go, it’s up to you. You can deploy a single bundle with all of your modules combined into one file, or you can have that split up into smaller files which get loaded as needed. It takes a little more coordination to have split files, but if you’re experience issues with startup time because your all-in-one bundle is too big, then that’s something you’ll want to do. Webpack docs have info on this: https://webpack.js.org/guides/code-splitting/


This thread is a wonderful read and discussion. Not to sidetrack it, but somehow it reminds me of this recent video:

NSFW / Kids: ( some curse verbiage )

Concur, vanilla or bust. Can I use, oh crap …


That won’t always keep you safe :wink: . I saw one example when ES6 came out that had about 5 different things about it that was broken in ES6 but worked in older iterations of JS runtimes. It was horrible code, but it was interesting to see just how much broke (and I assume the example was manufactured for this purpose… though I’m not really sure…). I’ll post it if I can dig it up.


Please do sounds fun. We are getting closer though, … we hopes.


To conclude:
what I agree with is you should avoid a lot frameworks and stick with the standard stuff, when possible. Which means I should use Node Modules to isolate different apps than using the https://single-spa.js.org framework or others.


I’ve been spending a ridiculous amount of time working with Web Components recently. Once all the ideas from that become a reality, we will be a bit closer to avoiding relying on 3rd party libraries for some of the things we…kinda…need them for like building large-scale apps in a sane way.


Is There a tutorial on how to start using Web Components today on every browser until they become standard? If they become standard you simply remove the “helper” that helps you use Web Components. Just like how Babel is for instance.


I just saw theres something called polymer (https://www.polymer-project.org). Is this what you are referring to Kirupa? Kan we use that already today? I think you had a tutorial about this. I can´t remember.

<React.Format> error while studying Learning React Book