If the React team was impacted, I imagine, given half of the core React team is already there, Vercel would scoop up the rest of the talent if they were interested in working at Vercel.
I don't think React is going anywhere given its bigger than Meta now.
That said, React Native seems like its the development framework for all Meta applications, I imagine its still core to their business as a result, but that may have changed, I am a few years out of date on this exactly
RN's not really core to Meta tbh. The most important surfaces are all built either natively or with NT / Blocks I think. Also ~19 months outdated though.
I was at Meta when this was tweeted and I think he must be referring to mostly internal apps. AFAIK the only part of the FB app that was heavily React Native was FB Marketplace.
By 2021 there were edicts in some departments that absolutely no new projects were to written with RN, with the emphasis moving towards their server-side rendering frameworks (Native Templates and Bloks.)
How does it work. In the sense that what does it provide the client side. Does the client get served pre-rendered interfaces of some sort?
Trying to figure it out as the Meta apps are very nice UX wise and maybe web technologies have come a long way to "feel native" hence i am in disbelief at the leaps and bounds being made.
Former long-time mobile eng at Meta here: RN is considered by most internally to be hot garbage and very unpleasant to work with.
They have 2 or 3 other React-like internal frameworks that most of the apps are made with. ComponentKit is the main one for the Blue App, and IIRC that's open source.
Layoffs or no layoffs it is extremely unlikely React will be used as much as it is now 5-10 years from now. It will probably be legacy no one wants to touch anymore. That's the nature of front end development unfortunately.
I hope to be proven wrong btw ...its about time we have a FE framework surviving more than 10 years.
React is already almost 10y old. Just check framework usage and downloads, stackoverflow survey etc. React just keep rising, exponentially. Vue had major growth couple of years ago, but it flatlined since then. TBH I don't see React going anywhere in the next 10y. It's like Java of frontened world. You think it's not there, but it's everywhere.
I'll say the death of JQuery rather than being replaced by React or Angular, was more a result of standardization of ECMAScript and the progress of native APIs in browsers.
Before JQuery creating your own JS for a weird IE6 bug was a nightmare; but with that problem solved in the modern web development, JQuery killer feature became a little redundant.
I seriously doubt "native web components" or something similar will catch in the same momentum to kill React.
The number of people who went from jQuery to native is much much lower than you mention. Most moved to angular/react/vue/some framework. People replaced jQuery to handle state easier not because of standardization..
React keeps evolving, following technological progress, inventing new approaches to make frontend development easier. As other comment pointed out, React today is not the same as React 5y ago and it will not be the same 5y from now. jQuery is the same as jQuery 5y ago. Java is not the same as Java 10y ago, it kept evolving. That's why is still strong and alive. That's why React is here. That's why jQuery is not.
And certainly in 2012, both Angular.js and Ember used jQuery as an integral part of their implementation and even exposed it directly to users in their directive/Ember.$ APIs, so the actual end of widespread jQuery in new projects was later than that.
It might be still called React but will be completely different. How similar are React + hooks + redux to React of 4 years ago? We call both React but it's hardly similar.
Fast forward 10 years from now...
True, however even redux is on its way out. Dan Abramov, the creator, doesn't particularly recommend it anymore. Now, you'll see more React-Query and into the future: use() hook and SSC (Server Side Components)
FWIW, my estimates show that Redux is still used by 35-40% of React apps [0]. That's definitely less than it was a couple years ago, but still the largest usage of any React-related state lib by far. (It's also worth noting that Dan stopped working on Redux in 2016 after one year and handed it over to Tim Dorr, myself, and now Lenz Weber, and has not been involved with Redux since then.)
On the flip side, usage of our modern Redux Toolkit package continues to go up fairly rapidly (to the point that RTK by itself is more widely used than other libs like Mobx or Zustand), and we get tons of positive feedback daily from folks who enjoy using it.
Also, Redux Toolkit's "RTK Query" data fetching and caching API also addresses the same use case as React Query, with some unique features and capabilities (OpenAPI/GraphQL codegen, streaming updates, cache lifecycles) [1].
So, while Redux will never be the "must-have" it was in 2016-17, it's still an excellent choice in many cases, and still very widely used.
Then they copied React and went with hooks and use this and use that and all that nonsense. One might argue they also copied angular 1 initially so they have no original ideas.
JSX style templates and components aren't going anywhere. A new framework that handles context and events better than React by default might ascend, but a good portion of FE dev work will look the same.
Point taken you are right. So I wanna see a mainstream FE framework make it to 10 without completely changing its API (Angular, React hooks) or its state management (Redux, Mobix..what is next?)
If you know Rails or Django fast forward 9 years.. you still know them. Can you say the same about React?
For the record: I maintain Redux, and it's never been an actual recommendation from the React team. In fact, Dan has publicly stated that "the only state management tool we recommend is React itself".
Redux is certainly the most widely _used_ state management lib in React apps, but that's a community-driven thing, not anything the React team has specifically suggested (in the same way that React Router is the most commonly used routing lib).
Oh no doubt. I am not blaming anyone specific here. I'm just calling it as it is - the way you write React apps now will be completely different 10 years from now.
I think just frontend is a more apples to apples comparison. In that scope, what >10 teams >1m ARR are using plain Rails/Django html templates with html button actions and such? If you shop around at Rails/Django jobs, they're almost all going to be using different frontends that you'd need to ramp up on: React, Vue, jQuery, Hotwire, Turbo, Stimulus, HTMX, Alpine.js, etc. You could also say "If you know jQuery fast forward 9 years ago... you still know it" and be right about keeping yourself to the limited opportunities to do it the old-fashioned way.
I think React has made a deep impression in the industry and wont disappear overnight. There is less of a 'brainer' these days if you want to choose the boring tech for SPA (or similar) apps, and that is React.
I am hoping vanilla JS will some day replace all the frameworks as the core features the frameworks have get absorbed into web standards natively, like what happened to jQuery. It's already perfectly possible to build a modern SPA UX without frameworks but a lot of devs don't generally prefer it. Yet?
There was never such a period. For the last few decades, it has been relatively easy (definitely a hassle that most people wouldn't want to do, but not especially complicated) to build a PC and run Linux on it. I did it as a child just following instructions online without understanding what I was doing.
And that PC's functionality is dependent upon code contributed by dozens of large technology companies. Even GCC and Clang work well because Intel and AMD contribute to them.
Heck, Firefox exists because Google keeps funding them.
It isn't 2002 anymore where Linux was some radical open source project with basement hackers making it all work.
> And that PC's functionality is dependent upon code contributed by dozens of large technology companies. Even GCC and Clang work well because Intel and AMD contribute to them.
That really doesn't seem like the same problem; there's a world of difference between being wholly at the mercy of one company (Facebook, Microsoft, Apple) vs "dozens of large technology companies". If tomorrow Microsoft disappeared or turned more evil, Windows users would have a problem. If tomorrow Redhat disappeared or turned more evil, Linux users at large would be totally fine, and even folks in the RH ecosystem would recover quickly enough (probably by rebasing Rocky directly from Fedora).
Instead, consider that you chose to leverage your web development work by taking what fb has jumpstarted with a lot of their cash. You can also think of it as second-hand-investment for your thing, and you don't have to sell any part of that to get the money/talent.
And yeah sure, that second-hand-investment money might dry up at some point, but you can still continue to use what you got when you decided to go that route (it's not like your react project is going to suddenly fail, why would it), and since it's a huge project and you are not the only one to have made that choice, you can likely still count on enough third-hand-investment for it to not be any problem in the future.
All in all, I would say that if this is your most worrisome dependency you are probably in pretty good shape.
React is used across the company. I see it kind of like an internal tooling team that just happened to open source the tool. I think it will continue to be maintained
Internally, definitely. But open sourcing things has a (dollars/time/opportunity) cost that Facebook may decide to no longer pay, or can no longer afford to with a smaller team.
I doubt it. React is a pretty simple library when it comes down to it, it's open source, it's fairly mature and built out as-is, and it's one of the largest contributions to the web that Facebook has ever made. It doesn't take a huge team to work on, and out of all the goings-on at facebook I would assume react is pretty high on the priority list.
I don't think it matters until/unless Meta completely goes bust.
Only time will tell if corporate subsidized open source projects like React will thrive if such an event occurs. There may or may not be enough of a strong and organized community to keep it going. I'd say odds look pretty good for React continuing to thrive though.
I've been waiting for this. I want it, everyone wants it. To be honest I think if the right people worked on it, you could code business rules with AI like this:
Users have access to their own posts.
Users are in groups.
Groups have an admin user.
The group admin can edit any post.
(probably a bit underspecified, but you get the point)
I can imagine a world where that could theoretically be converted into a domain model, rest endpoints, GQL service and an authentication system. I literally think the above is possible with today's AI capabilities, it's just no one has released a finished product.
Beyond that, I think AI for front-end is a lot harder, but could probably exist at some point.
My company's yesterday's internal discussion of impending layoffs immediately jumped to "hey, maybe we will get some really good React developers out of this".
That's not how open source works. Open source projects don't just float by themselves in the open source cosmos. There's still people behind them.
Maintainers and major contributors are from Facebook. You can't "just fork" the monstrosity that React is and magically keep it moving at the same pace.
React is small compared to some things that have been forked. WebKit, OpenOffice, and the BSD operating systems come to mind. And who says it has to be in constant development? Freeze it and fix it, then worry about new features.
It is both true that it not impossible that a fork of React could be succesful; and that there is a reason React "would be impacted" by layoffs.
For the second, the question "Why would React be impacted by layoffs if it's open source", the answer is obviously: It would be impacted if people who were getting paid to work on it have been laid off. Seems straightforward. Bigger impact depending on number and roles of such people.
WebKit was forked from KHTML by huge company that employed people to work on it. And was later forked again into Blink by another huge company that employs people to work on it.
I have come to prefer hooks, but I have never felt they're necessary. Class based React allowed for massive simplification of some setup/tear-down actions.
I have something that has a lifecycle and I don't want to initialize and destroy the state every time. I encapsulate that into a function, call it a hook, and go about my day knowing that I don't have to care about redoing the lifecycle every single time.
It's basically a class that has pre-written lifecycle functions.
Hook-using functions basically are classes, just with utterly bizarre method and property declaration syntax and some strange and unhelpful behaviors.
I mean, they ultimately associate lists of properties and functions (methods, if you like) with a component object instance (yes, object) down in the React internals. Sure, access to them is FIFO rather than a lookup table, but that still looks a whole lot like very-weird classes/objects being reimplemented in a language that already has decent-enough ones.
Now, the trouble was certain optimizations and features were probably going to be hard to impossible to achieve while supporting both functional- and class-based components more-or-less equally, and the easy path forward was to let class components become more powerful and functional components slip to second-class (haha), but instead they put object/class-like features in their functions so they could have functions (but very much stateful/side-effecty, so WTF is the point?) lead the way, for whatever reason.
Everything in hooks is explicit. Which is a blessing and a curse.
Classes were really easy to compose and automatically easily bring everything you needed into the class. This did lead to some situations where you could over-engineer and get yourself into a bind. You can technically do the same/similar thing with hooks, it just requires a bit more code. Lack of setup/tear down with hooks also means you need to rely on nonces more often.
In general, hooks have a bunch of small, reactive-programming tricks that you learn with experience.
i'm a react noob too, but my impression is mostly that hooks are nicer for smaller components with simpler states, and classes reduce some boilerplate if you have a lot of different state variables within one component.
> 'If React isn't good enough for you to use after 9 years, it'll never be good enough'
I'd argue the opposite - it has been good enough, but now the whole FB platform is old and stale and so is React. 10 years is a long lifetime in the tech world. It will be around for another decade but I'd argue is over the hill in most of its variants. Big next gen opportunities
Can you expand on why? I’m pretty satisfied with React in that it
1. doesn’t try to be a full framework
2. Is easy to explain (without hooks)
3. Has good inner-loop tooling with hot reload
4. Doesn’t have any insane transpiration requirements
Is that all still true with modern react? By the time you explain the rules of hooks, concurrent mode and its hooks, and RSC I think the only one that's true is (3).
@guhidalg there is nothing 'wrong' with React at all, it's mature and debugged. The issue is the platforms it serves are old and something newer is sure to replace it
Components based approach was pretty much wide spread because of React, we had shitty MVC stuff like angular before it. I wouldn’t call it fashion mind set.
It you think React is bloat I would recommend Preact
Yes, sometimes it takes a fresh set of eyes to point out the tune everyone is dancing to out of inertia. If it happens often that people point out this issue then i’d take it a hint and reflect on it. Maybe there is an opportunity for creating something better, radically different not just an iteration, and maybe now is the time for it. We in tech have the personality and culture to re-invent when times are hard.
It can be as you say sometimes, but most other times, it's akin to Chesterton's Fence or Gell-Mann Amnesia, talking about something without actually knowing anything about it. It's not only wrong, it's useless.
I do, and i have been writing spas since before this madness. It’s real utter shite. We need something better instead of religiously fixating on it. But i do appreciate you making personal assumptions instead if focusing on the core of what i said, and you seem to have confirmed that there is indeed backlash against this untamed beast.
You said "fresh set of eyes" so I assumed you don't use it, my apologies.
I was also speaking generally, not towards React itself. Some people do have some issues with it, but I don't think it should be discarded wholesale as you imply. By all means, use alternatives like Vue, Solid or Svelte, but React is in my opinion wholly superior, at least for someone functionally oriented like me, where f(State) = UI without reactive stream based side effects.
A fresh set of eyes in the sense of your observation that its usually new folks pointing out the many issues this framework is suffering from.
I use an array of frameworks. Anyway there is nothing intellectual in this debate as we are not conceptualising alternatives we are just considering existing tools, a bit like building workers considering different types of hammers. A common issue in the js world.
Isn't it borderline arrogance to ask this question? People are impacted and you care about your favorite tool? React will exist, and it open source, if you care, you have options do something about it.
I don’t think it’s arrogant to be concerned about such a tool especially considering that other peoples livelihood also depend on such important tools like react. It’s possible to be concerned about the people developing a tool AND the tool itself.
It really does lack empathy. It's disappointing. IDK why you're getting downvoted even though you have a point here. React is open source and it's an organization by itself. It will survive. Worst case scenario: one of the OSS leaders will fork it and get help from others. Easier said than done, but that's one of the options that ppen source provides you.
For the lack of a better example, when Bill and Melinda (Gates) got divorced, people were worried about the Gates foundation. They even posted about it in their official note of separation to the community. Now, that makes sense. Asking about an open source project that's already quite stable, right after Meta lays off employees is in poor taste.
Why would it be arrogant? If I'm using something that my business depends on, such as a library like React, you're damn right I want to know how it'll affect me. Now I can be concerned about the people who make the tool, but I can also be concerned about the tool itself.
The React Core team was 100% Meta up until earlier this year, when Seb Markbage switched to Vercel (and I believe Vercel is now also funding an additional full-time dev to contribute more React SSR / Server Components implementation). React Native work is also primarily Meta, although I think MS has a team that supports RN for Win/Mac.
There are certainly _contributions_ from the community, but in terms of core library vision and implementation work, it's all been the primary team (Seb, Andrew Clark, Dan Abramov, et al).
Dan recently commented and said that they'd certainly _like_ more actual outside contributors, but there's a big onboarding cliff that requires a lot of time investment:
I don't think React is going anywhere given its bigger than Meta now.
That said, React Native seems like its the development framework for all Meta applications, I imagine its still core to their business as a result, but that may have changed, I am a few years out of date on this exactly