React 19 - This Has To Stop!

A quick look at the upcoming React 19
💬 Topics:
- React Forget Compiler;
- React Actions;
- use server and use client directives;
- React Canary;
- React 19 updates;
- Is React still relevant?
- React alternatives
🥇 Become a Member - / @awesome-coding
✉️ Join the Newsletter - newsletter.awesome.club/
📖 Blog Article - www.awesome.club/blog/2024/re...

[@NoobaLV]

You said a whole bunch of nothing. You name complexity and don't give a single example of what is complex with React. Then you bring up React actions and that they started supporting server-side rendering but fail to mention why it is bad. I was actually interested in your takes but you have to be more specific.

[@kevinb1594]

I think he neglected to mention why moving to server side rendering is 'bad' because it should be obvious. A FRONT END FRAMEWORK that moves closer to the backend makes its existence less justifiable. If you need a server to render your UI library, why not just skip the library all together? As far as complexity, anyone who has used React as it has developed can attest to the fact that things have gotten more complex especially in the react ecosystem as a whole. Hooks, server side components, REDUX...

[@awesome-coding]

Hey! I'm sorry if I wasn't able to clearly present my ideas in the video - I'm usually trying to keep things short and concise, and some of the information is lost in translation. So here are the two main issues: ISSUE 1 React is adding in a compiler to address its main issue - a bad reactive model. Here is what the current alternative is: a) data is stored in a signal b) the signal value is changed c) effects associated with the signals are updating the DOM directly, with minimal effort. Here is what React is offering: a) data is stored in the state b) the state changes c) a process called rendering (which is NOT actually rendering but a phase where one ore more functions are rerun) is triggered c.1) when these functions are rerun, internal functions and other computations are triggered, which might cause more "rendering" c.2) to avoid unnecessary computations you have to add in your code things like: useCallbacks, useMemos, memos, dependency arrays d) The rendering process finally finishes, and the result is an abstraction of the real DOM called the vDOM e) the current vDOM tree is compared to a previous snapshot in a diffing process called reconciliation d) based on the reconciliation results, the real DOM is updated. Sure, you might not notice this complexity as a developer (even though you are forced to address the pitfalls when using memoization hooks or dependency arrays), but the complexity is there. Rendering and reconciliation takes way more CPU cycles than they need to, the vDOM is taking way more heap space (and associated GC) than it needs to. Granted, we don't really care about this kind of metrics for now, but we should aim to build robust software nevertheless. ISSUE 2 Server Actions, and mixing backend and frontend code. Now, the concept of isomorphic JavaScript is not novel, and I remember the early days of meteor when this was a big thing. However, THIS APPROACH IS AGAINST BASIC PROGRAMMING PRINCIPLES... It blows my mind that "separation of concerns" ,a core concept in maintaining good software, is thrown out the window, and very few people seem to care. How is it a good idea to mix together server code with frontend code just to get a slight DX advantage and nothing more. What happens if you have a "use client" component in a "use server" component in another "use client" component. I know what will happen, but why do have to add this complex process in our dev processes? What happens when inexperienced developers will inadvertently expose API keys and other sensitive information from the backend in their client code? React has a major problem - bloat (from the vdom, from the reactivity model, and from other places as well). Instead of addressing it, they just do the easiest patch - SSR everything and then hydrate the sh*t out of your app. I like how people say that they don't care about performance, because the browser can take it, but then, after years of pushing CSR to the community they figure out all of a sudden that the Server can do it better. It's not that the server can do it better, it's just your framework being heavy and inefficient that the browser can't handle it anymore. Hopefully you'll see why this rant was not present in the video 😅

[@NoobaLV]

@@kevinb1594 You don't need a server to render the UI library, it was added as an OPTION. The core functionality is still there. No one is forcing you to opt-in into server-side rendering. You name three things for you second point, the usage of hooks, server-side components and redux as features that are increasing complexity of React in a negative way. The only feature out of those that you will use is hooks and I don't even know how you can use React without hooks. I'll reiterate, SSR is not A MUST, same goes for Redux, you don't need to use Redux, which is a separate library btw, in order to use React.

[@user-fr2fm3ri3w]

@@kevinb1594”server bad” yeah avg js dev

[@hydranooni]

​​​@@awesome-coding I know you make short videos and usually I really like them, even if they are against React. But I'm tired of people who shit on React without reasoning or knowing whats happening in React. You are obviously very much in the React space, so I would have wished that you got into it further with reasoning so that other people who know nothing dont think React is shit or that React v19 is shit. Anyways, love your videos

[@user-xj5gz7ln3q]

I love the complexity of React; it's a guarantee of job security. Not even AI will be able to understand, let alone code it. Yeah, keep going React guys.

[@awesome-coding]

I'm right behind you. I'll not use it in my projects, but I'll invoice the hell out the customers who will :))

[@3pm479]

[@TayambaMwanza]

Funny thing is Angular is switching to signals for Reactivity, also most other frameworks are doing so and React doesn't want signals, interesting plot twist, Angular is following the trend now and React is not.

[@awesome-coding]

Yep... crazy... Angular seems more reasonable and lighter than React these days. Angular is actually considering removing Zone JS from their dependencies at some point in the future so you CAN update your reactivity model.

[@awesome-coding]

@@silaspy-ff2ne So we should just use Solid then :)

[@neociber24]

The compiler may improve a lot of things, but I think the focus on signals people have is incorrect. Focusing on performance when they are not rendering millions of elements, and for sure the end user will notice your 0.005ms improvement.

[@_timestamp]

​@@silaspy-ff2ne vue had signals before solidjs, and I'm sure vue copied it from older frameworks (knockoutjs?). Btw at the end signals are nothing special, just a Proxy in vanillajs es6+

[@LarsRyeJeppesen]

Yep, I am already running zoneless in our internal apps. There are some issues with 3rd party libraries (even material) but from V18 it will be game over for zones, and hello Signal components, hello localized change detection on div level@@awesome-coding

[@rawallon]

I don't think its competing with other frameworks, I think the Meta team is doing the same thing they were always doing: implementing things that make easier for them to make their job

[@awesome-coding]

💯💯💯 Yep - exactly that!

[@starvin-arvin]

Vercel has a big influence on the direction of React right now and it's not really Meta's baby anymore. I think it is definitely competing with the other frameworks at this point.

[@untlsn]

React is corp library/framework for corp Server first and heavy back compatibility And now compiler that clear some performance issues not recreating underlying system like Vue3 + vapor

[@rawallon]

@@starvin-arvin Eh, kindof, I think next team do push react to be in a certain way, but there's a reason some ppl decided to leave React's team to work on Next, and not other way arround

[@wlockuz4467]

Remember how Google killed AngularJS to build Angular 2 which is now known as just Angular, besides the confusing naming, I think it was the right choice because they realized their framework had huge problems. I wish React would do something similar, not kill the current React, that would be extremely stupid, but instead create a new non-backwards compatible fork of React that doesn't have a decades worth of band aid fixes, and is not based on virtual DOM (which seems like the root of half the problems with React). They're not short on talent, neither short on research, there are already frameworks that do what React does but 10x better, they just don't get any traction because of a lack of thriving ecosystem, talking of course about Solid. So I am not really sure what would hold them off if not corporate politics or some other bs. But who am I kidding, this is React, I can't wait to be on my death bed reading about React 69 release where they optimized their optimization that wasn't optimizing what it was supposed to be optimizing.

[@LarsRyeJeppesen]

Angular is insanely good now from v 17 and forward... impressive what they have done tbh

[@moritzschuessler]

I even think that react without the vDOM would make stuff that makes react great wouldn’t be possible. The vDOM enables react to have easily different rendering results. Like what other framework can be used to render mails, DOM and other fancy stuff with the same syntax?

[@edhahaz]

Remember when google killed something? Yes, everyday

[@jwoods9659]

That is called Solid js

[@untlsn]

I think you don't understand how no-vdom framework works For example solid just compile lower case elements to performant template creation But upper case components are complied to function execution, so you can create mails, mobile components ect. inside this components and return it Only in some cases you need to tweak TypeScript

[@grenadier4702]

Can someone explain it to me: why does one need server actions? I mean you just send rest-request to your normal server made with GO, Java, C# and etc , get a response and proceed.

[@illustris.]

DX and pretty much nothing else. It honestly feels like a gimmick to make React "full-stack".

[@Bozo---]

Maybe for speed of building a non rest app

[@timgerk3262]

Localizing business rules in a single source file has value. "Just one place" logic overriding separation of model/controller/view.

[@grenadier4702]

@@timgerk3262 I can't understand what you are trying to convey. What is "business rules"? You can use domain folder structure and create "order" folder and place api.ts there containing "function makeOrder" which calls external api (i.e GO server for example)

[@untlsn]

Codeing speed You just create action next to component, TypeScript auto complete go brr, HMR go brr and done

[@alexandrodisla6285]

Svelte is a compiler Now react is a compiler

[@grinsk3ks]

We are finally getting a clearer VUE of what the future holds ...

[@awesome-coding]

Nice! I missed the opportunity of a good pun 😅

[@StefanoV827]

Instead of building something like RTK Query internally they are pushing for server actions so you are forced to use node for the backend and a monolith solution ... I don't get it

[@philipp9220]

Just don’t use them

[@untlsn]

I suggest to use node for small endpoint and real backend for rest

[@StefanoV827]

@@untlsn what does it mean REAL backend? 😅 I use node only for websocket and TCP servers. Also I prefer using microservices not a full stack app like using nextjs ... I want my frontend and my backend scalable separately

[@untlsn]

@@StefanoV827 real backend so connection to outside services, to database ect

[@midophriya3657]

I like react v19. No more useMemo. I really don’t care on nodejs server part(nextjs). My server and client is always split anyway. Make react just frontend. It will benefit react native as well

[@awesome-coding]

Fair! I can get onboard the idea of keeping React only on the frontend!

[@hodev632]

Reactjs is like jquery.we all say it's hard to use, but the ecosystem around is so good that we are all going to use it anyway. I hope this comment doesn't get rendered 4 times

[@rockNbrain]

Lol

[@awesome-coding]

😅

[@VuTuanIT]

Jquery projects are still working well after 10 years. React projects will be obsolete and not even able to run in dev environment or build production in around 2 years 😢

[@emgodas]

​@@VuTuanITcan you explain why react apps wont run after 2 years? I'm believing because of updates but the updates have their own positive things like security or simplicity which makes the app faster etc. I'm new to React so if I said something wrong I apologize

[@IStMl]

YT runs on Angular not React, no worries

[@MaPhongBa129]

The complex of React in the future is not for normal or app, web developers, its for libraries author and build tools. As the normal developers like me, we need to learn how to use 1st, and after that, we can think about the deep dive

[@hawrezangana8240]

That's why I am learning Phoenix (Elixir)

[@CIBI]

Simple question i am newbie i want learn frontend for job and experience? Which are those you people will suggest

[@user-xj5gz7ln3q]

JavaScript, HTML and CSS.

[@awesome-coding]

Yep - start with the basics. HTML & CSS should be pretty easy to pick up. Then Vanilla JS, Some Typescript and maybe Solid JS as your first framework.

[@markoffden]

And then learn React if you want to get an actual job instead of ranting on KZbin video comments about millisecond performance gains 😂

[@everythingisfine9988]

JavaScript, HTML and CSS. Learn the basics of type script, no need to be a master. Learn a common SQL language and set up a local server with Node. For front end frameworks. Do a search in "indeed" for jobs. Select the top three frameworks with the most jobs. Test all three out, and pick the one you're most comfortable with. And you should be good

[@saadhabashneh5587]

Right now it seems that the vue team and the svelte team are making the best decisions

[@LarsRyeJeppesen]

Meanwhile Angular is getting insanely good.. when we can remove change detection from v18, it will be so so powerful . But I like both tbh. Signals rule

[@techislife6765]

What competition? I have yet to see anything truly challenge React. Sure there are a few that have promise, but they are years away from ready for the scale that react is at.

[@awesome-coding]

Angular is in direct competition with React, and is actually preferred in some industries. Vue is mature and reliable with an ecosystem compeeting with React. Svelte does not have a wide adoption yet, but it is moving very fast, so it has the momentum to be a real player in a couple of years.

[@rand0mtv660]

@@awesome-coding Not hating on Svelte because I think it's amazing, but people have been saying Svelte is going to be the next big thing ever since Svelte 3 was released roughly 5 years ago. Let's just accept React won for the foreseeable future and is the most popular and other solutions are just one level below fighting with each other. I'm not saying React is the best, but it does some thing better than others and others do some things better than React, that's it. Use what you like and stop worrying about others.

[@user-kk5cv1rs5r]

Larger user base of React is just because it was just earlier in the market. If it would have come after Vue. Good luck....

[@Kaczucha888]

You took the words right out of my mouth. Waiting for SolidStart stable release so much

[@Richard-cl6kt]

Why even consider and wait for it when you can have SvelteKit?

[@browntigerus]

My bet with React compiler things are going to shake up a bit. May be they will do the signals without doing the signals, or even replace the entire DOM under it.

[@vladlazar94]

React seems to move in a direction along which, further along, awaits htmx. It seems to me that the easiest way to reach the goals of React is to drop React altogether.

[@jomoc6112]

whats seems to be the main problem? svelte is only .005secs faster than react why bother transfering?

[@mrgalaxy396]

React is becoming the Java of frontend. On paper, it looks like an elegant solution to tackle complexity and if you do things really right it indeed is a good solution. The gold standard of the industry if you will. However, in practice it has shown to be an overengineered solution that's easy to make a mess out of unless you're really careful and more modern approaches have realized there are easier and better ways to handle some of the complexity React tackles, leading to leaner and easier to manage solutions.

[@awesome-coding]

Well said!

[@davixx1995]

Angular looked more like java to me with all the boilerplate, react makes me think more of c++ (powerful, but requires you to lose a lot of time to fix performance issues or bugs)

[@philipp9220]

React can also render other things than HTML. Without a VDOM React Native, React-PDF and other renderers would not be possible.

[@incarnateTheGreat]

I think Meta and the React team really took their feet off the gas pedal. Thankfully, it allowed for others to create ideal solutions that will eventually put React out to pasture. I will still use React, but I'm anticipating Solid potentially replacing it. If the main issue isn't the compiler but the bloated react-dom, then there really isn't a positive future for React.

[@untlsn]

There are too many long live project writen in React And when JQuery you can incrementally replace with vanilla JS You can't replace react with something else, because current style of react is all or nothing

[@dripcaraybbx]

The problem is when product-building methodologies become products themselves

[@awesome-coding]

THIS.

[@oumardicko5593]

I only use React, vue or angular for SPA. Personally, i feel like if you ever feel the need to use nextjs or these weird metaframeworks, check if php, java... wouldn't do a better job

[@ruaidhrilumsden]

Personally I wouldn't want to touch PHP or Java with a 40ft barge pole. Presumably if you're using one of those for the backend then you're not using a frontend framework, so you'd then also be sacrificing UX, as you'd be stuck with full-page reloads?

[@oumardicko5593]

@@ruaidhrilumsden pho and java are just examples. At the end of the day, you need two things: make money and give the best UX possible. My opinion might be biased but if i ever feel the need to use a meta framework like nextjs, i’ll just check if i cannot use other programming languages. Go has a template language called templ, it’s pretty good, with kotlin, you have dsl and probably the best DX in my opinion.

[@AspirinC]

I would love to hear your opinion on HTMX … from reading your comments it sounds like something you would appreciate?

[@awesome-coding]

Hey! I think it is great for some use cases. I actually explored it in detail in some of my videos (like this one - kzbin.info/www/bejne/mKXMXpWkfMesl80)

[@anasouardini]

Great video.

[@awesome-coding]

Thank you!

[@brianm.9451]

If React had planned on integrating signals I might have given React 19 a look but they disnt and I don’t know why.

[@awesome-coding]

They went the compiler way probably because they are so tied in to the vdom...

[@TechBuddy_]

I will stick with sveltekit and astro

[@awesome-coding]

Glad to see you! :))

[@ruaidhrilumsden]

Remix and Astro for me currently!

[@TechBuddy_]

@@awesome-coding glad to see me ?

[@TechBuddy_]

@@ruaidhrilumsden I was a remix fan for a long time!! Remix is very good too

[@armantgoldswain3951]

Whats good about Remix? Isnt that still react?

[@mohamaddelkhah]

Wasm-gasm.

[@roccociccone597]

HTMX is a god send for a guy like me who doesn't particularly like JS. And if I ever have to use a "real" frontend framework, I'd just use svelte. It's fast and so much nicer than react.

[@wij8044]

Why is it better?

[@lipepaniguel]

amen

[@roccociccone597]

@@wij8044 well what are you referring to?

[@zlackbiro]

Why you involving Next examples in React? There is no similarities in this two how they work, except JSX, state, props...

[@awesome-coding]

The React docs: "We advise you always use React with a framework like Next" The Next docs: We are "the React framework" The React & Next teams: "We are working together to better integrate Next and React via Server components"; Your comment: "There are no similarities between the two!?" Cool cool cool 👍

[@Barnardrab]

I took a look at the boiler plate code for setting up React. It feels like it's easier to just write in vanilla JavaScript.

[@awesome-coding]

😅 What do you mean?! People in the comments say that React is not bloated at all...

[@kkebo]

Good luck building native js web app thats scalable and maintanable

[@Barnardrab]

Skill issue. Vanilla JavaScript has been sufficient for everything I've built so far, although I also use template engines like Handlebars and TypeScript.

[@TheRickmint]

I completely agree with @NoobaLV comment; this video is overly generic and riddled with unsubstantiated statements lacking both sources and explanations, rendering it highly subjective. When you claim, 'React is built on top of a bloated and underperforming reactivity model,' could you elaborate on what exactly you mean? It's crucial for content creators to exercise caution when sharing videos, as they can inadvertently spread misinformation and cause confusion

[@awesome-coding]

Did you read my reply to that comment? You should start by doing that, since I believe it explains in detail the main issues. 1. The fact that "React is built on top of a bloated and underperforming reactivity model" is not something novel or subjective... Virtual DOM, Rendering and Reconciliation are processes not needed in other frameworks, but they are a must in React. Would you call a framework that needs extra steps to perform a task bloated? 2. The fact that Million JS gained some traction and attention because one guy simply optimised React's reconciliation step to make components up to 70% faster. Would you call a process that can be optimised to almost double the performance underperforming? 3. In React you have to "fine tune" reactivity with dependency arrays, use callbacks and memoization. Would you call it bad dev experience when a framework leaks its reactivity implementation to the user, and relies on the user to "fix it"? This video is a quick overview of what React 19 is offering, not a deep dive into the framework. This video assumes you have some prior knowledge of React, so you know about vDOM, you know why frameworks like Preact have a lighter vDOM implementation or why frameworks like Solid don't need a vDOM at all. Stating facts that you are not aware of or you don't agree with does not equal misinformation. I'm sorry I'm not hyping React 19 for the sake of views or likes on KZbin. This is because I actually work with React on a daily basis and I know both it's strengths as well as its many flaws.

[@adeleke5140]

@@awesome-coding 1. Just because React needs to render and reconcile to update the state of the DOM, that doesn't mean it's bloated. 2. MillionJS is cool, React can always be better, not sure how that is a good argument against react. 3. Isn't that what the compiler is supposed to solve? Making sure Devs don't have to manually memoize components The issue I have with SolidJS is that they don't admit that Solid also has it's quirks and pitfalls. React is succeeding not only because of the Job market and ecosystem but because they got something with reactivity right.

[@x0z59]

Many have moved now to Angular. See React is getting weird.

[@awesome-coding]

I think this is actually true... weird times. I remember I picked up React exactly because Angular seemed like too complicated for no reason.

[@x0z59]

Seems complicated if the basis is just the first view (verbosity, many files ) but once you are used to it, those quirks will seem be invisible and unnoticeable. The "separation of concern" is what makes real-world projects easy to maintain which Angular shines in. Plus, it's typed.@@awesome-coding

[@awesome-coding]

@@x0z59 I agree - Angular felt verbose compared to React's function component approach. What I disliked the most about Angular was the heavy use of RxJS in scenarios you didn't really need it. This is not enforced by the framework, but I saw many projects where a plain fetch call to bring some data from the server was enough, but people did operators, subscriptions, switch mapping and piping instead. I'm too old for that.. :))

[@x0z59]

Signals has just arrived to Angular and it will eventually let people get rid of RxJS overdose. And Signals adoption is stabilizing now.@@awesome-coding

[@maneshwar3468]

Move from Angular to Vue. It's a hybrid of Angular & React. Angular is great but Vue looks better than Angular.

[@neociber24]

I don't agree with the complexity thing. Svelte is also compiled, all those framework have a ton lf complexity that is hidden away. My only problem with React is that they don't want to commit to fullstack and want you to use a framework but aren't giving you the tools to run React as fullstack.

[@ruaidhrilumsden]

Fair point. All the frameworks abstract away a ton of magic. I suppose the counter point to the fullstack argument could be that they should continue focusing on what they've been doing - and that there's still lots of work to do on the client side. I'm sure if they did commit to developing a fullstack solution there would be plenty in the community complaining about that too. I'm on the fence TBH - Remix is my favoured option these days - it feels essentially like what a "vanilla" fullstack React solution would be anyway, especially when they get round to implementing RSC.

[@CoolestPossibleName]

Svelte is actually simple to use, has no virtual dom, and is more efficient.

[@neociber24]

​@@CoolestPossibleName I argue React is also simple to use, complexity will always exists on complex apps.

[@awesome-coding]

@neociber24 My counterpoint to this is Solid. UI libraries don't have to be that complex anymore in my opinion, and libraries like Van JS take this concept to an extreme. (Sure, van is not really an option for large projects, but it shows that you can do 80% of what react does in just a few lines of code). If you consider signals as the source or reactivity, the following concepts in React are obsolete: vDOM, Rendering, Reconciliation, dependency arrays, use callback, use memo. Svelte has kind of the same issue. It turns out their "magic" reactivity approach where you would "write plain JS" and it simply works in the DOM is not the best idea. They are back pedalling now, and Svelte 5 introduces "runes" which are simply signals :) Angular - the same story. They have Zone JS which is kind of hit and miss, hence you'll see "ChangeDetectorRef.detectChanges()" used in various places. They have the same approach now: they introduced Signals recently, and they are hinting they might remove Zone JS at some point in the future (of course, this is going to be very tough without breaking backwards compatibility). So my take is that we were fooled to believe this is difficult, when it actually isn't.

[@awesome-coding]

@neociber24 Thanks for your input by the way. I really appreciate it!

[@botondvasvari5758]

simple clean ????? XDDDDDDDDDDDDDDDDDDDD omg

[@Woeden]

They're finally learning that those abstractions are bad for DX

[@awesome-coding]

Are they learning though? :))

[@netssrmrz]

Good video. I agree with your views on SSR. Besides what you have mentioned, devs should consider that splitting your UI onto a server also increases costs, reduces server performance as the app scales, and strongly couples your server functionality so that it is less reusable.This generally makes SSR a bad choice for enterprise web apps so unless you're building toy sites or want to improve your CV, personally, I don't see SSR being relevant. It's been tried before (late 90s) and we moved on for a reason.

[@awesome-coding]

Well said!

[@vigneshwarrv]

but Future doesn't about the Past. I completely agree with your point though

[@terasoft-official]

Nobody speaks about blazor

[@awesome-coding]

It is tied to the .NET platform, so there is a lot of knowledge you need to unpack there.

[@xtraszone]

I prefer vue 3

[@frankdearr2772]

great thanks 👍

[@edhahaz]

React forget is better than signals

[@awesome-coding]

How would you know? React forget is not even open sourced or available to the public yet... You either worked on it directly, in which case you would be biased, or you have no idea what you are talking about. And since the react compiler will handle mostly memoization for an exiting dirty checking based reactivity system, while signals are the building block for a different reactivity system I'm gonna guess you have no idea what you are talking about. I love the confidence though 👍

[@edhahaz]

​@@awesome-coding While I can't personally verify the claims about React Forget, I'm willing to trust that it will achieve it's goals. Meaning it will simplify things without requiring a change to the mental model to fit to a new paradigm like signals. That's why it's better.

[@claushellsing]

NEVER EVER use React in server

[@darah.k3221]

Respect yourself and use other frameworks

[@awesome-coding]

😅✌️

[@bear458ziif-s]

the react fanboys that defend everything react does is the worst part of the community. they act like they're being held at gunpoint to say good things about it.

[@awesome-coding]

I think that's true for most ecosystems, and this is why I believe being locked in into one programming language or framework is a pretty bad idea. You are getting into an echo chamber where any competing idea is immediately dismissed.

[@adeleke5140]

hating react shouldn't be a personality trait.

[@QueeeeenZ]

Vue killed React back in 2014 and it's still dead.

[@wielomarian]

AMEN MY BROTHER.

[@awesome-coding]

I can always count on you for the mandatory Vue comment on my videos 😅✌️