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.
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.
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.
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.
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.
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
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'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.
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.
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.
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.
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.
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.
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.
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.
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
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"
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
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.
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've been bouncing around complete stacks for a while. I feel like react is the best way to build user interfaces but meta-frameworks like nextjs are so unreasonably complicated. On the other hand, a simple express api server is easy to configure but now your api lacks typesaftey. Right now I am using a bun monorepo with a trpc backend and a react router frontend. I use drizzle for my ORM and I can directly pass types to the frontend while I have a clear abstraction of server and client. I don't use things like server actions or streaming, just react query and ssr when I need. Would love to hear others thoughts
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 😅
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.
It's 2029 and we are all using zigscript but fighting the transpiler
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.
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.
Corporate stack is still 10 years behind
Deno Fresh 2.0 incoming.
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.
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
11:58 BFF is pretty awesome in a lot of cases. Great being able to tailor things to what the client needs.
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
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'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.
Hey Google set reminder to watch this video in 3 years
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.
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.
The last video really was fire 🔥
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.
Can’t wait to get to the point where I can go back to these videos And have them re wire my brain too
21:20 is so so so true, I hope every dev understood that 😔
Pre-watched
on stream :p
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.
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
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.
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.
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.
Vue vapour, knocking the door.
Vue Vapor github repo has been abondoned for several months
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.
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.
SolidJS... "drops mic"
Theo! It's a second video in a row that I wanna watch from start to finish!😃👍
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
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!
Theo, build something with Angular 19 and review the experience!
nuxt not mentioned smh
yes it was mentioned
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"
Where is angular??
What is the difference between tanstack query and trpc?
bro, 1hr???
whats app he using for diagrams?
Excalidraw
prisma back?
Svelte for 2025 🎉
You're an awesome teacher 💪
I was looking for this
I'm going back to jquery
Saving for later but leaving comment for auto. Sending love and respect Theo and Theo fans
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
Tank you man.
Meanwhile jquery devs with lamborghini:
Speaking from 2027, I'm here researching what you barbarians were up to in the past.
This guy 54 mins?
SRR is a mistake. They just want you to pay for cloud rendering when your users can do it 😊🤑
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.
React was too busy making your website slower in 2024.
It actually causes more problems than its solves and I'm not even exaggerating.
You don’t have to use this face with everything, it dosnt suit this topic , please make new ones
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.
This video is so damn long!!
lol joking trolling
I've been bouncing around complete stacks for a while. I feel like react is the best way to build user interfaces but meta-frameworks like nextjs are so unreasonably complicated. On the other hand, a simple express api server is easy to configure but now your api lacks typesaftey. Right now I am using a bun monorepo with a trpc backend and a react router frontend. I use drizzle for my ORM and I can directly pass types to the frontend while I have a clear abstraction of server and client. I don't use things like server actions or streaming, just react query and ssr when I need.
Would love to hear others thoughts
one of the first comments, theo pls reply to this im a big fan
Wait js frameworks are just react wrappers
definitely next js
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
first
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
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? 🫣