I'm here from 2026. We decided SSR wasn't the move and went for something else. Also, the JS Framework Wars escalated to real life active combat, with people pledging to newly formed nation states, such as Svelteland and Reactania. I just returned from my second deployment. It's gotten ugly. War refugees have mostly fled to the combined haven of Larastro, a new state birthed from the joining of the Astro and Laravel Nations. Rumor has it they have solved hunger, poverty, and the problems of resource allocation inherent to market economies. My partner continues to beg that we flee there, but my ego simply won't allow that to happen. Tomorrow I redeploy to the front lines. Make better choices than we did. I beg of you all.
When Vercel sells all its servers, we might see something new. Vercel sells servers, Tailwind sell components, and TanStack sell courses - that’s all you need to know about modern technologies. In reality, we aren’t inventing new technologies; we’re finding more sophisticated ways to make money
But they are free to use man. What are you complaining about? If not tanstack query/table what will you do for those use cases? You'll write your own? And how are they supposed to make money if they give away their work for free? They are more than welcome to sell their courses or anything they like
I am baffled by the "you need some JavaScript on the server". It's not a language that provides any real benefit over the numerous other options on the server side and has very notable limitations there (events, threading, managing OS resources and so on). Sure, Node mitigates some of that, but it's nothing compared to languages that have explicit support for those features. I can't see going to anybody that is using Java, C# and so on and saying "Oh, you need JS to make a good web site" when they have been doing that for a very long time.
If anybody is using Java or C# for their server then I cry for them. Spring and .NET are vicious cycles that give developers Stockholm syndrome. Rust or Go may be better options, but JS is still better than either Java or C#, I'll give away the performance gains just to not have to deal with the nonsense that Java/Spring requires you to do.
Yes, the BFF take is by far the most stupid take I've seen Theo take. Trading 1% more user QOL in exchange of having to add a (not thin at all) layer of slow JS, complicating your deployment and basically multiplying your bills by 2x. Not to mention the mental anguish using JS causes, it should be a humans right violation...
13:39 "If you don't use JavaScript on the server _some_ amount, you are almost certainly making a bad website." Too hot. Way too hot of a take. Data streaming is a fun UX win, but sites without it are not "bad"
It's not just too hot of a take, my issue is that this is a statement that should add "as of this time" or "as I'm pushing this video" to be fully correct. Don't get me wrong, Theo is killing it here but is still going a tiny bit too far on the "need" to have some JS server-side. I'm not against it, and yes, as of BFF advantages, having some JS is the way to go, as of today. But in regards to HTMX hoping to be W3C standard and such, we don't know if in the near future JS won't have a proper alternative serving HTML fragments through a BFF that is NOT JS based. This could be possible given the evolution of (backend/BFF) web stacks.
@@mrbubbls8065 What exactly does it mean to have "some js for server"? I'm new to web dev but curious to know more. What real benefits will it bring over a backend written in go or rust?
@@silicon4636 you'll need to get to know about NodeJS and maybe Express or Koa when we talk about server-side JS APIs. But JS server-side could nowadays also be React's Server Components, for instance, which could also mean "some JS on a server" 😉 A lot more experience with all those things, including Go/Rust/PHP/etc. is needed to really grasp the benefits. This would be a long answer that is mainly already given, almost in full by Theo's video here and those related that he's talking about.... follow his schemas I might say 😁
@@mrbubbls8065 I have experience with using express and using js on server. I've also used rsc primarily through nextjs. What I was trying to ask was why is it essential to include js on server side? Is it about server-side rendering?
@@silicon4636 the point Theo is trying to make is that those backends can't do SSR specifically for compiled web frameworks, whose compilers are written in typescript usually. He's suggesting we slow down our web servers to a crawl by having a middle step (next js, sveltekit etc) that does SSR or SBR in some form of JS runtime. It's an absurd, stupid take. Instead, those devs should focus in writing standalone compilers and adapters that make it possible to do these things in a non JS backend.
I've personally worked at multiple agencies using NextJS where "senior" front end engineers just slap "use client" almost everywhere... The once senior React engineer is effectively a 0.1x developer in a server first world.
Yeah, I’ve used to love nextjs before app router and all other changes afterwards. I was a junior back then and I had a hard time grasping their changes and still do. It’s confusing and messy imo. I don’t even know now what framework I’d go with if I had to build a full stack app solo. Probably angular and some BaaS as I’ve been working with it for past 4 years and I love it.
That's quite an extreme statement. I'd agree react is getting complex nowadays with the mixture of server and client. The Dev experience in Next is pretty confusing when things crash but they will get better eventually. Vue and svelte are not that different tbh
To everyone confused about the BFF server: It's purpose is to act as a middleware between backend API servers and the browser. The benefits are: - easy to bring in performance optimisations for the UI like combining multiple API calls into one - data manipulations can be done without touching the backend. Far easier to change and deploy JS code - reduced JS bundle size shipped to client since only the required UI can be shipped - reduce the number of APIs exposed to the browser. We have a BFF server in our main product and have realised these benefits for a long time. It's pretty good and the UI team gets a lot of control to maintain quality
This is funny how big tech pushed us to use React to run away from Jquery, and from that born Vue and Svelte. But at the end, everyone noticed that React and other SPA js framework make the dev flow more and more complex. So Htmx came out and every one liked it. In my opinion Htmx is just an evolution of Jquery and It should have be that way since the begining. Instead of that, we divided programmers into categories (Front/Backend), and making Frontend dev super ego programmers because they knew React and Typescript. In some way, return to basics is always a good thing.
I like working on backend stuff, I like working on frontend stuff, but the communication between is hell. I just hope I can continue to work on projects where SPAs are good enough. If you use a decently fast framework the overhead of transforming JS+JSON into DOM should not be too much over transforming HTML into DOM. That is of course assuming, you don't really need SEO, work with weird browsers and you build you frontend with performance in mind. I.e. be careful with what packages you bundle and how you write your code.
40:48 something very similar happened yesterday with svelte 5. I made a sudoku game and wanted to reset the game when you change the size value on the parent. This change triggers infinite recalls as the prop is a signal and changing the signal retriggered the $effect rendering and filling up the memory limit of the browser tab. I ended up having another gameSize state and have to check inside the $effect if size !== gameSize then allow new render. It took me 2 hours to figure that out and it sucks. It felt really backwards to not able to use the prop as a signal and still need to have it's internal state like it's an angular app lol.
Regarding the length of videos, they're onto something. I used to be able to listen to your videos while walking my dog. Now I'm done walking half way through the video and I finish before you get to the juice.
One thing react compiler might make devs forget would be to move their state at the right places. Your example isn't suffering from not enough useMemos but because of highly dynamic states are at the root of the app. With enough memos we can patch it away, which is what the compiler ultimately is trying to do, but if we evangelize moving the state down and re ordering component hierarchy by using children, not only the code matches the intent much more, it gets performant without any optimization techniques. Alternate solution for your code here*. I am not saying the react compiler is bad (it's the best thing at its job), rather that it can lead us to forget some of the best practices that react compiler wouldn't perform (like moving state down or changing props of components). Alternate solution 1* Make Counter and ColorPicker separate components (as intended visually), just like SlowComponent. Move count state to counter and color state to color picker Now Counter wouldn't know when Color Picker's state changes, and SlowComponent wouldn't know when Color Picker's state changes. This small diff (which matches our intention) is enough to prevent re-renders. This is not what react-compiler would do, but it would definitely give us same results (or even better), without us having to worry about it, which is both a great thing and a concerning thing (in the sense of knowledge lost). But Divjot, what if I want to use the color and count in both ColorPicker and Counter (but not in SlowComponent)? You could pass SlowComponent as children to DemoComponent Alternate Solution 2* const App = () => Now again, SlowComponent wouldn't re-render since nothing in App is changing, the state lives "inside" DemoComponent, which SlowComponent can't know about. This is even neater diff (replace with props.children), but again it isn't something react-compiler would dare to attempt on your codebase. Of course this approach has its limitations, but I do think this knowledge is useful.
Great video btw. So if my code is hyper-optimized with Memos that explicitly say which dependencies to re-render on (super-fine-tuned), it might be faster than compiler react but it is also way more complex. Also have always been more of a SPA fan since I usually build Web Apps that I want to have a native feel, why is Next.JS so hesitant to support this as an option?
hey theo, awesome video you did here! i was wondering if you could do like a complete WebDev / Build your own Stuff in 2025 Video that covers all the basics one should know like the main tech steck you should use, tools to integrate like supabase/resend/..., best practices for deploying (with v0, netflify etc..), how to approach backend and frontend just like a 101 to catch people like me, that use the possibilites of AI to build their own business/product but dont really understand much of the technology behind it in detail would be so awesome!
Prisma DB looks really cool and I'd like to build something with it, but the fact that the product has no pricing worries the hell out of me. Though, it's cool and you can use their ORM for free so I'll keep it in my back pocket.
you never *need* js on the server, but in a full stack framework, js is usually your only option, because it’s the only thing that runs on the client, which is most of what theo’s talking about. some js on your server means your backend is purpose-built for your website and can harness these emerging features that allow for better routing and data hydration for users. these features do exist in some other frameworks in other languages, but they aren’t full-stack, or they provide client-side libraries to facilitate those features.
@@zaccanoy And by "full stack" I assume you mean "i want my client and server to be in the same language?". Like, I can send html, json or even js in whatever lang.
no, like i said, a full stack framework either is JS on the backend because that is the only language that can run on the client, or it provides a library for you to consume in JS on the client in order to facilitate the routing and hydration features present in frameworks like Next (JS) or Inertia (PHP). you can’t get these functionalities without sending the JS necessary and specific to your application to make it happen, so your framework at least has to interact with JS. A framework that’s hands-off about the browser side would be a backend framework, given it does nothing but supply mostly-static code/markup at the client side. full-stack means it facilitates the client and the server, not just one.
Hey man, you can't use vite or webpack compiler magic for type/javascript, and then shit on graphql codegen shenanigans. I mean you can, but would be good to recognize the double standard. From what I can tell so far, your trpc vs gql argument is like debating vanilla js vs any framework using webpack or vite
I'm a Vue dev (so i don't understand a lot of deep "react" stuff) but so much become clear with reactivity when you understand that ({same: false} == { same: false}) == 0
27:38 from the start of typescript, will from the start of async/await i always have the feeling this should be a complier step, we don't know need to know if a function is async or not, it should return the value or throw a error.
One horrible thing that happened to me when using a BfF is that it caused horrible race conditions in combination with (session) cookies. Also, having the BFF without a locking mechanism or sensible way of serializing operations with a remote service (especially when having to use refresh tokens and the remote server invalidates them once used) is a problem. Modeling that in BEAM processes seems one of the only nice ways to handle that. Sadly, in the project we had that problem, we used python, and collapsing the stack into a monolith was easier.
You can do backend for frontend in any language. There is nothing special about using JS for this. Traditional servers that took post form submission and create HTML were explicitly back for frontend
13:24 To some amount I disagree with that statement, you can have a descent user experience having no BFF. On the other hand the complexity it brings is tedious, for it you need to review, build, test, deploy, cache strategies, metrics, analytics, and lets not forget that in every 300 lines of code there is a bug.
I always wanted to learn the memoization, useCallbacks etc but I didn't. Now, with this compiler into the picture, i may never have the need to and hence the motivation to do as well. Yeah I am lazy. It sucks, I am aware. I wonder if I will regret? But atleast when or if I learn, I will learn in peace.
Lit doesn't get enough love, maybe because of its somewhat more targeted uses. But I've loved working with it for our main front-end library the past couple years.
I work with Graphql all day everyday, and I like it. Can't understand someone not say `resolver` when working with graphql lol. I do want to learn tRPC though, it's on my to-do list
BFF is really useful. In complex applications, it lets you aggregate data from multiple apis, have a platform agnostic business logic and even enable things like server driven ui. Depending on the use cases, more features can be added to the BFF layer (cache control, streaming of widgets in sdui, priority of widgets/api calls) etc and make the application standardized across all platforms
I am from 2030. All js-frameworks are dead. AI generate minified js files that works better then vanilla js. No one knows what code inside these files, but no one cares, it just works.
I've been developing stuff with no build system, no frameworks, minimal libraries, etc. - it's very productive and refreshing. Web components + semantic HTML5 elements make a great combination, especially with all of the JS and CSS features adopted by browsers in the past few years. IMO this is the way forward for web development, at least for high-performance web applications. Edit: for some reason I can't reply to this thread with more information :/
Have you been able to find a way to get data streaming to work? I have been using Go + Templ + Alpine-ajax and I can confirm it's very productive, but data streaming remains elusive.
It’s quite close minded and inaccurate to think that your vanilla stack is the way forward for high performance applications. When people say stuff like you they usually have no experience building complex apps, or are just averse to learning new things. You vanilla stack is client sided only, you’re definitely going to be limited by not embracing some sort of server architecture. If your argument is it feels good to develop in, sure thats subjective. But if your argument is that’s the way forward for high performance apps, you’re just completely wrong.
@@_y7ya try it - I think you'll like it :-) I am saying it's hard to build efficient applications when you have to deal with all of the baggage, abstractions, and mental overhead that comes with general purpose frameworks. In the case of the software I'm working on, there are interesting performance challenges with loading and interactively exploring 1 million business objects from an ensemble of different servers and services... Having direct control over everything reduces unnecessary complexity, and we can develop an application that exactly fits the problems we are solving.
@@_y7ya maybe we have different definitions of high performance. The software I am working on has challenging requirements for both memory and CPU usage due to the size of datasets users need to work with interactively, and a significant amount of the functionality is implemented through an in-house webassembly-based 3D engine. Retaining good control over allocations and total memory usage, as well as what computations run when, is inherently harder when using general-purpose frameworks like React (not to mention the overhead and abstractions from the framework which cause their own performance issues). What I am saying is: while the "status quo" (frameworks, libraries, build system, etc.) for web development is good, the functionality that's now available in a vanilla stack lets you productively build web applications without any external dependencies and a greater deal of control over performance-critical stuff, while staying simpler overall. (writing reply again, seems my first one disappeared)
@@_y7ya I think each web application has its own needs. Frameworks can be wonderful for some things, vanilla can be wonderful for some things. That's the great thing about the web - you can use the tools best suited to the problem at hand!
A big reason why I personally am reaching for other frameworks like Svelte or Vue are critical syntax differences. In my opinion, components being functions restricts code organization too much.
i beg to differ, vue and svelte templating is literally hindering my productivity right now. the biggest upside of functions as components is how much of it is just javascript/typescript in the end, so you get the whole power of type safety. i am out here relying on a vue ts linter, and its not even working that reliably. i just want the thing to get done man, dont give me the goddamn mental overhead and give me the types already.
If you like next's DX/router etc and dont want server side stuff you can just not use the server side stuff and do a static export. If you don't, then idk what the question is. Or what Next has to do with a CDN - a static spa is a static spa whatever you use to make it.
@@vikramkr382 Why use an entire bloated framework? I can simply use react-router and make a SPA using Vite, the generated files(CSS,JS,HTML) I can host ANYWHERE I want, no need for Vercel bullshit
Single FLIGHT is not new. Any REST api written in 2001 did this. In fact if you’re using a normal backend like Django you would need to do extra work if you wanted to remove this default behaviour! How broken is JS server dev if this is a new development now!
His diagrams prove the point that Js has become way too complicated... Think about the front-end and how simple and well engineered SwiftUI is for the desktop and mobile. Javascript needs to die it's a terrible language riddled with congenital defects and its further proliferation is a cancer that is sucking the life out of a new generation of developers. You can't engineer your way out of bad design. A language created in a week or weekend is inadequate to run the web for the next 20 years. We need new solutions! You can keep slathering new coats of paint on the same piece of garbage but it doesn't change the fact that its a effing piece of garbage. Web3 is the only hope to turn shit around and hopefully move to a more decentralized language stack let us not forget that Js is still mostly controlled by big tech.
I'm here from 2026. We decided SSR wasn't the move and went for something else. Also, the JS Framework Wars escalated to real life active combat, with people pledging to newly formed nation states, such as Svelteland and Reactania. I just returned from my second deployment. It's gotten ugly.
War refugees have mostly fled to the combined haven of Larastro, a new state birthed from the joining of the Astro and Laravel Nations. Rumor has it they have solved hunger, poverty, and the problems of resource allocation inherent to market economies. My partner continues to beg that we flee there, but my ego simply won't allow that to happen. Tomorrow I redeploy to the front lines. Make better choices than we did. I beg of you all.
Come over to Nuxtonia, we have cookies and peace
This deserves more likes 👏
@@MatthewSparks Hi, What your method in 2026? What Framework do you use?
you lost me at SSR
All hail the glorious motherland, HTMXSSR
You guys are not using jQuery? 😮
i use it. 6 years ago
What's that
Around 9 years ago😅
Its History now 😅
*crying in legacy code*
When Vercel sells all its servers, we might see something new.
Vercel sells servers, Tailwind sell components, and TanStack sell courses - that’s all you need to know about modern technologies. In reality, we aren’t inventing new technologies; we’re finding more sophisticated ways to make money
You have a point
But they are free to use man. What are you complaining about? If not tanstack query/table what will you do for those use cases? You'll write your own?
And how are they supposed to make money if they give away their work for free? They are more than welcome to sell their courses or anything they like
I am baffled by the "you need some JavaScript on the server". It's not a language that provides any real benefit over the numerous other options on the server side and has very notable limitations there (events, threading, managing OS resources and so on). Sure, Node mitigates some of that, but it's nothing compared to languages that have explicit support for those features.
I can't see going to anybody that is using Java, C# and so on and saying "Oh, you need JS to make a good web site" when they have been doing that for a very long time.
If anybody is using Java or C# for their server then I cry for them. Spring and .NET are vicious cycles that give developers Stockholm syndrome. Rust or Go may be better options, but JS is still better than either Java or C#, I'll give away the performance gains just to not have to deal with the nonsense that Java/Spring requires you to do.
Yes, the BFF take is by far the most stupid take I've seen Theo take. Trading 1% more user QOL in exchange of having to add a (not thin at all) layer of slow JS, complicating your deployment and basically multiplying your bills by 2x. Not to mention the mental anguish using JS causes, it should be a humans right violation...
@@C4CH3S it's not 2x its like 10x more
@@kevin.maloneAnything is better than JS, even Java
@@kevin.malone I enjoy reading bad opinions on the internet. Thank you.
13:39 "If you don't use JavaScript on the server _some_ amount, you are almost certainly making a bad website."
Too hot. Way too hot of a take. Data streaming is a fun UX win, but sites without it are not "bad"
It's not just too hot of a take, my issue is that this is a statement that should add "as of this time" or "as I'm pushing this video" to be fully correct.
Don't get me wrong, Theo is killing it here but is still going a tiny bit too far on the "need" to have some JS server-side. I'm not against it, and yes, as of BFF advantages, having some JS is the way to go, as of today.
But in regards to HTMX hoping to be W3C standard and such, we don't know if in the near future JS won't have a proper alternative serving HTML fragments through a BFF that is NOT JS based. This could be possible given the evolution of (backend/BFF) web stacks.
@@mrbubbls8065 What exactly does it mean to have "some js for server"? I'm new to web dev but curious to know more. What real benefits will it bring over a backend written in go or rust?
@@silicon4636 you'll need to get to know about NodeJS and maybe Express or Koa when we talk about server-side JS APIs. But JS server-side could nowadays also be React's Server Components, for instance, which could also mean "some JS on a server" 😉
A lot more experience with all those things, including Go/Rust/PHP/etc. is needed to really grasp the benefits. This would be a long answer that is mainly already given, almost in full by Theo's video here and those related that he's talking about.... follow his schemas I might say 😁
@@mrbubbls8065 I have experience with using express and using js on server. I've also used rsc primarily through nextjs. What I was trying to ask was why is it essential to include js on server side? Is it about server-side rendering?
@@silicon4636 the point Theo is trying to make is that those backends can't do SSR specifically for compiled web frameworks, whose compilers are written in typescript usually. He's suggesting we slow down our web servers to a crawl by having a middle step (next js, sveltekit etc) that does SSR or SBR in some form of JS runtime.
It's an absurd, stupid take. Instead, those devs should focus in writing standalone compilers and adapters that make it possible to do these things in a non JS backend.
11:58 BFF is pretty awesome in a lot of cases. Great being able to tailor things to what the client needs.
I've personally worked at multiple agencies using NextJS where "senior" front end engineers just slap "use client" almost everywhere... The once senior React engineer is effectively a 0.1x developer in a server first world.
Yeah, I’ve used to love nextjs before app router and all other changes afterwards. I was a junior back then and I had a hard time grasping their changes and still do. It’s confusing and messy imo. I don’t even know now what framework I’d go with if I had to build a full stack app solo. Probably angular and some BaaS as I’ve been working with it for past 4 years and I love it.
Corporate stack is still 10 years behind
$.cry();
Too accurate lmao. Typical time to update your stack is 2-3 years AFTER it is no longer receiving any security updates
React is the definition of a foot gun for me. I don't really get why anyone would use it instead of vue, svelte or even lit.
That's quite an extreme statement. I'd agree react is getting complex nowadays with the mixture of server and client. The Dev experience in Next is pretty confusing when things crash but they will get better eventually. Vue and svelte are not that different tbh
@@StingSting844 Teaching someone Vue is way easier that teaching someone React
Vue vapour, knocking the door.
Vue Vapor github repo has been abondoned for several months
Do you have any info about when Vue vapor mode will release?
It's 2029 and we are all using zigscript but fighting the transpiler
Theo, build something with Angular 19 and review the experience!
Man your diagrams are something else.
? They look like diagrams to me
@@Efecretion It was a compliment
@ Oh, a figure of speech. I get it
Reminder to come back in 2028 to watch this video again.
To everyone confused about the BFF server:
It's purpose is to act as a middleware between backend API servers and the browser.
The benefits are:
- easy to bring in performance optimisations for the UI like combining multiple API calls into one
- data manipulations can be done without touching the backend. Far easier to change and deploy JS code
- reduced JS bundle size shipped to client since only the required UI can be shipped
- reduce the number of APIs exposed to the browser.
We have a BFF server in our main product and have realised these benefits for a long time. It's pretty good and the UI team gets a lot of control to maintain quality
If there are examples out there, I would be curious to see them. This isn't meant as a gotcha, but the more information, the better.
This is funny how big tech pushed us to use React to run away from Jquery, and from that born Vue and Svelte. But at the end, everyone noticed that React and other SPA js framework make the dev flow more and more complex. So Htmx came out and every one liked it. In my opinion Htmx is just an evolution of Jquery and It should have be that way since the begining. Instead of that, we divided programmers into categories (Front/Backend), and making Frontend dev super ego programmers because they knew React and Typescript. In some way, return to basics is always a good thing.
Deno Fresh 2.0 incoming.
3:48 doesn’t Rust for a REST API get you like double the RPS of Go though?
I like working on backend stuff, I like working on frontend stuff, but the communication between is hell.
I just hope I can continue to work on projects where SPAs are good enough.
If you use a decently fast framework the overhead of transforming JS+JSON into DOM should not be too much over transforming HTML into DOM.
That is of course assuming, you don't really need SEO, work with weird browsers and you build you frontend with performance in mind. I.e. be careful with what packages you bundle and how you write your code.
the people who works with projects that does not need SEO doesn't really work in/for business and for profit stuff
@ except any b2b software
@@UnknownPerson-wg1hw b2b, internal tooling sites, b2e, tons of places make money without the need of SEO
40:48 something very similar happened yesterday with svelte 5. I made a sudoku game and wanted to reset the game when you change the size value on the parent. This change triggers infinite recalls as the prop is a signal and changing the signal retriggered the $effect rendering and filling up the memory limit of the browser tab. I ended up having another gameSize state and have to check inside the $effect if size !== gameSize then allow new render. It took me 2 hours to figure that out and it sucks. It felt really backwards to not able to use the prop as a signal and still need to have it's internal state like it's an angular app lol.
Regarding the length of videos, they're onto something. I used to be able to listen to your videos while walking my dog. Now I'm done walking half way through the video and I finish before you get to the juice.
Theo! It's a second video in a row that I wanna watch from start to finish!😃👍
I think Local First is gonna be fun to toy around with in 2025 (Dexie, Zero) and possibly bring back a new an improved Metoer.js experience.
One thing react compiler might make devs forget would be to move their state at the right places. Your example isn't suffering from not enough useMemos but because of highly dynamic states are at the root of the app. With enough memos we can patch it away, which is what the compiler ultimately is trying to do, but if we evangelize moving the state down and re ordering component hierarchy by using children, not only the code matches the intent much more, it gets performant without any optimization techniques. Alternate solution for your code here*.
I am not saying the react compiler is bad (it's the best thing at its job), rather that it can lead us to forget some of the best practices that react compiler wouldn't perform (like moving state down or changing props of components).
Alternate solution 1*
Make Counter and ColorPicker separate components (as intended visually), just like SlowComponent.
Move count state to counter and color state to color picker
Now Counter wouldn't know when Color Picker's state changes, and SlowComponent wouldn't know when Color Picker's state changes. This small diff (which matches our intention) is enough to prevent re-renders. This is not what react-compiler would do, but it would definitely give us same results (or even better), without us having to worry about it, which is both a great thing and a concerning thing (in the sense of knowledge lost).
But Divjot, what if I want to use the color and count in both ColorPicker and Counter (but not in SlowComponent)? You could pass SlowComponent as children to DemoComponent
Alternate Solution 2*
const App = () =>
Now again, SlowComponent wouldn't re-render since nothing in App is changing, the state lives "inside" DemoComponent, which SlowComponent can't know about. This is even neater diff (replace with props.children), but again it isn't something react-compiler would dare to attempt on your codebase.
Of course this approach has its limitations, but I do think this knowledge is useful.
Great video btw.
So if my code is hyper-optimized with Memos that explicitly say which dependencies to re-render on (super-fine-tuned), it might be faster than compiler react but it is also way more complex.
Also have always been more of a SPA fan since I usually build Web Apps that I want to have a native feel, why is Next.JS so hesitant to support this as an option?
Honestly, embedding a SPA into one of my MPA because I don't want to deploy a other proyect is something that I've done several times
What is that browser name I didn't remember((
And what about the diagram app I spent some time with miro and that is no so satisfying
hey theo, awesome video you did here!
i was wondering if you could do like a complete WebDev / Build your own Stuff in 2025 Video that covers all the basics one should know
like the main tech steck you should use, tools to integrate like supabase/resend/..., best practices for deploying (with v0, netflify etc..), how to approach backend and frontend
just like a 101 to catch people like me, that use the possibilites of AI to build their own business/product but dont really understand much of the technology behind it in detail
would be so awesome!
Nuxt has made web dev much simpler and easier
Prisma DB looks really cool and I'd like to build something with it, but the fact that the product has no pricing worries the hell out of me. Though, it's cool and you can use their ORM for free so I'll keep it in my back pocket.
What are you using for the diagrams in this video?
Why is this video so long. What's the summary here?
The last video really was fire 🔥
Pre-watched
on stream :p
What is the difference between tanstack query and trpc?
nuxt not mentioned smh
yes it was mentioned
Why do you need "some js on the server"? What's the benefit over other languages?
you never *need* js on the server, but in a full stack framework, js is usually your only option, because it’s the only thing that runs on the client, which is most of what theo’s talking about. some js on your server means your backend is purpose-built for your website and can harness these emerging features that allow for better routing and data hydration for users. these features do exist in some other frameworks in other languages, but they aren’t full-stack, or they provide client-side libraries to facilitate those features.
@@zaccanoy And by "full stack" I assume you mean "i want my client and server to be in the same language?". Like, I can send html, json or even js in whatever lang.
no, like i said, a full stack framework either is JS on the backend because that is the only language that can run on the client, or it provides a library for you to consume in JS on the client in order to facilitate the routing and hydration features present in frameworks like Next (JS) or Inertia (PHP). you can’t get these functionalities without sending the JS necessary and specific to your application to make it happen, so your framework at least has to interact with JS. A framework that’s hands-off about the browser side would be a backend framework, given it does nothing but supply mostly-static code/markup at the client side. full-stack means it facilitates the client and the server, not just one.
80% of frontend developers only use 20% of the JS framework they are working with.
and 99% of gamblers quit just before they're about to hit it big
Can’t wait to get to the point where I can go back to these videos And have them re wire my brain too
Hey man, you can't use vite or webpack compiler magic for type/javascript, and then shit on graphql codegen shenanigans. I mean you can, but would be good to recognize the double standard. From what I can tell so far, your trpc vs gql argument is like debating vanilla js vs any framework using webpack or vite
I'm a Vue dev (so i don't understand a lot of deep "react" stuff) but so much become clear with reactivity when you understand that
({same: false} == { same: false}) == 0
You and Primagen are becoming my favorite channels on TH-cam.
what is out of order streaming?
Hey Google set reminder to watch this video in 3 years
21:20 is so so so true, I hope every dev understood that 😔
Svelte for 2025 🎉
You're an awesome teacher 💪
whats app he using for diagrams?
Excalidraw
27:38 from the start of typescript, will from the start of async/await i always have the feeling this should be a complier step, we don't know need to know if a function is async or not, it should return the value or throw a error.
Nuxt ❤
One horrible thing that happened to me when using a BfF is that it caused horrible race conditions in combination with (session) cookies.
Also, having the BFF without a locking mechanism or sensible way of serializing operations with a remote service (especially when having to use refresh tokens and the remote server invalidates them once used) is a problem. Modeling that in BEAM processes seems one of the only nice ways to handle that.
Sadly, in the project we had that problem, we used python, and collapsing the stack into a monolith was easier.
You can do backend for frontend in any language. There is nothing special about using JS for this. Traditional servers that took post form submission and create HTML were explicitly back for frontend
13:24 To some amount I disagree with that statement, you can have a descent user experience having no BFF. On the other hand the complexity it brings is tedious, for it you need to review, build, test, deploy, cache strategies, metrics, analytics, and lets not forget that in every 300 lines of code there is a bug.
36:56 is just not true, I reach to other frameworks (Svelte) because I absolutely hate the HTML-in-JS (JSX) syntax
There should be a framework to help you choose a framework at this point
I always wanted to learn the memoization, useCallbacks etc but I didn't. Now, with this compiler into the picture, i may never have the need to and hence the motivation to do as well. Yeah I am lazy. It sucks, I am aware. I wonder if I will regret? But atleast when or if I learn, I will learn in peace.
You guys are not using Remix? 😮
Lit doesn't get enough love, maybe because of its somewhat more targeted uses. But I've loved working with it for our main front-end library the past couple years.
Where is angular??
I'm going back to jquery
I work with Graphql all day everyday, and I like it. Can't understand someone not say `resolver` when working with graphql lol. I do want to learn tRPC though, it's on my to-do list
Saving for later but leaving comment for auto. Sending love and respect Theo and Theo fans
Tank you man.
bro, 1hr???
thanks
SolidJS... "drops mic"
I was looking for this
So now we don't want something or saying that it's not good because AI gonna have to "learn" it??
Basically yes
You don’t have to use this face with everything, it dosnt suit this topic , please make new ones
This is why I love this channel. Every year he kills it and provides more value. Thanks! I'm going to be an op dev when I graduate!
SRR is a mistake. They just want you to pay for cloud rendering when your users can do it 😊🤑
Creating problems to solve them. React.
Meanwhile jquery devs with lamborghini:
prisma back?
React was too busy making your website slower in 2024.
It actually causes more problems than its solves and I'm not even exaggerating.
I travelled back in time from 2027 to make this comment. AI took all the jobs there is only a few of us left stop copy pasting please.
BFF is really useful. In complex applications, it lets you aggregate data from multiple apis, have a platform agnostic business logic and even enable things like server driven ui. Depending on the use cases, more features can be added to the BFF layer (cache control, streaming of widgets in sdui, priority of widgets/api calls) etc and make the application standardized across all platforms
Lmao dude try his best to not put Angular inside his thumbnails when videos have to do with JS frameworks.
Speaking from 2027, I'm here researching what you barbarians were up to in the past.
I am from 2030. All js-frameworks are dead. AI generate minified js files that works better then vanilla js. No one knows what code inside these files, but no one cares, it just works.
Devin was a fake, from the ground.
This guy 54 mins?
I've been developing stuff with no build system, no frameworks, minimal libraries, etc. - it's very productive and refreshing.
Web components + semantic HTML5 elements make a great combination, especially with all of the JS and CSS features adopted by browsers in the past few years.
IMO this is the way forward for web development, at least for high-performance web applications.
Edit: for some reason I can't reply to this thread with more information :/
Have you been able to find a way to get data streaming to work? I have been using Go + Templ + Alpine-ajax and I can confirm it's very productive, but data streaming remains elusive.
It’s quite close minded and inaccurate to think that your vanilla stack is the way forward for high performance applications. When people say stuff like you they usually have no experience building complex apps, or are just averse to learning new things. You vanilla stack is client sided only, you’re definitely going to be limited by not embracing some sort of server architecture. If your argument is it feels good to develop in, sure thats subjective. But if your argument is that’s the way forward for high performance apps, you’re just completely wrong.
@@_y7ya try it - I think you'll like it :-) I am saying it's hard to build efficient applications when you have to deal with all of the baggage, abstractions, and mental overhead that comes with general purpose frameworks. In the case of the software I'm working on, there are interesting performance challenges with loading and interactively exploring 1 million business objects from an ensemble of different servers and services... Having direct control over everything reduces unnecessary complexity, and we can develop an application that exactly fits the problems we are solving.
@@_y7ya maybe we have different definitions of high performance. The software I am working on has challenging requirements for both memory and CPU usage due to the size of datasets users need to work with interactively, and a significant amount of the functionality is implemented through an in-house webassembly-based 3D engine.
Retaining good control over allocations and total memory usage, as well as what computations run when, is inherently harder when using general-purpose frameworks like React (not to mention the overhead and abstractions from the framework which cause their own performance issues).
What I am saying is: while the "status quo" (frameworks, libraries, build system, etc.) for web development is good, the functionality that's now available in a vanilla stack lets you productively build web applications without any external dependencies and a greater deal of control over performance-critical stuff, while staying simpler overall.
(writing reply again, seems my first one disappeared)
@@_y7ya I think each web application has its own needs. Frameworks can be wonderful for some things, vanilla can be wonderful for some things. That's the great thing about the web - you can use the tools best suited to the problem at hand!
A big reason why I personally am reaching for other frameworks like Svelte or Vue are critical syntax differences. In my opinion, components being functions restricts code organization too much.
i beg to differ, vue and svelte templating is literally hindering my productivity right now. the biggest upside of functions as components is how much of it is just javascript/typescript in the end, so you get the whole power of type safety. i am out here relying on a vue ts linter, and its not even working that reliably. i just want the thing to get done man, dont give me the goddamn mental overhead and give me the types already.
@@UnknownPerson-wg1hw Did you try Svelte? In my experience, types work great there: I will admit that Vue + Typescript is still clunky
@@UnknownPerson-wg1hw Did you try Svelte? In my experience, types work effortlessly there. I admit that Vue + Typescript is still clunky.
one of the first comments, theo pls reply to this im a big fan
The biggest question I would have is why, WHY I would use Next to build a simple SPA lol, host the thing in a CDN and its done
If you like next's DX/router etc and dont want server side stuff you can just not use the server side stuff and do a static export. If you don't, then idk what the question is. Or what Next has to do with a CDN - a static spa is a static spa whatever you use to make it.
@@vikramkr382 Why use an entire bloated framework? I can simply use react-router and make a SPA using Vite, the generated files(CSS,JS,HTML) I can host ANYWHERE I want, no need for Vercel bullshit
I miss when your videos were 10 min long
My average video length is around 30 minutes long lol. It's rare I do short ones
@@t3dotgg I know... was just playing the role of the "worst commenter" @6:29
@@miro-hristov oh my god I forgot that was in there 🤣🤣 you got me
1h
th-cam.com/video/TKcetuFoYU0/w-d-xo.html
I have seen this in CakePHP awhile ago XD
Wait js frameworks are just react wrappers
definitely next js
Honestly feels like JS devs are re-discovering traditional apps again and realizing they've been needlessly suffering all this time.
I hate web dev frameworks 😅
Single FLIGHT is not new. Any REST api written in 2001 did this. In fact if you’re using a normal backend like Django you would need to do extra work if you wanted to remove this default behaviour! How broken is JS server dev if this is a new development now!
The guy is 🤡
His diagrams prove the point that Js has become way too complicated... Think about the front-end and how simple and well engineered SwiftUI is for the desktop and mobile. Javascript needs to die it's a terrible language riddled with congenital defects and its further proliferation is a cancer that is sucking the life out of a new generation of developers. You can't engineer your way out of bad design. A language created in a week or weekend is inadequate to run the web for the next 20 years. We need new solutions! You can keep slathering new coats of paint on the same piece of garbage but it doesn't change the fact that its a effing piece of garbage. Web3 is the only hope to turn shit around and hopefully move to a more decentralized language stack let us not forget that Js is still mostly controlled by big tech.
so many words for nothing, web3 my ass
@@UnknownPerson-wg1hw hawk tuah spit on web3
first
Yo why is there no Angular in your thumbnail.. is he not gonna talk about Angular?
My framework is better than all of this
I read the article, i watched Ryan read it on his stream. I watched Theo read it on his stream. Why am i watching the recording now? 🫣