Every Framework Sucks Now

The latest State of Javascript survey revealed some...concerning trends. I wanted to talk about them, and why I'm still hopeful for the future of javascript frameworks, despite the happiness and sentiment going down.
SOURCE
2023.stateofjs.com/en-US
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@ristopaasivirta9770]

To alleviate this issue we should make a new framework that....

[@badhreeshmrao609]

It’s a never ending cycle, isn’t it! 🙈

[@ea_naseer]

LTS version for frameworks would be great

[@EightNineOne]

Lemme know when it’s ready for me to fork it and add more bloat

[@vytah]

xkcd 927. I didn't even have to look it up.

[@go_better]

Wut da heeeeeee

[@dj_256]

You either die a well-loved framework, or live long enough to get to the left side

[@AbstruseJoker]

Russian bots

[@codeChuck]

In the game of drones, there is no middleground :)

[@kosmonautofficial296]

You wanna know how my framework got these scars?

[@chonkyboy3597]

:v sound about right

[@SteveBoyer10]

While your point about forced use is a good one, I’m convinced our collective frustration is more due to the complexity all these frameworks are introducing. React used to be simple: “change state, component re-renders. Go have fun.” Now there is SO much more to think about. It’s just not fun anymore.

[@fischi9129]

I think the complexity mostly arises because people don't wanna learn/keep up to date... in both cases I would highly suggest to change induatry, learning is kind of an intrinsic skill that goes hand in hand with Programming. People who don't are people on the road of senior junior/professional juniors, which I despise with a passion because they hate complex stuff and like simple stuff and end up making everything 4 times more complex for everybody, since they pretty much recreate what frameworks and libs do, but worse, less efficient and with less documentation.... and normally a non consistent API :)

[@Salantor]

React switching its paradigm like 5 times in the last decade is also a good reason to not like it anymore.

[@fischi9129]

@@Salantor where did it switch it's paradigm over 5 times? Now I'm not a react enjoyer myself, but I only see 1 paradigm shift... kinda... like we went from OOP components to functional components... only paradigm shift I saw ngl

[@yojou3695]

react was never simple, it was all a lie

[@fischi9129]

@@yojou3695 So, you want a variable that updates the ui whenever it changes so that you update the variable... that's 2 lines, 3 including the function declaration, idk, u want the app to code itself? like what are your expectations?

[@shapelessed]

I feel like the answer is much more simple than what is being talked about here. It's the sheer fatigue and pressure caused by the frameworks that want to compete with each other on how many features they have and how much market they can fit in. The amount of information an average dev has to handle these days is 2-3 times more than just 5 years earlier. Everybody is just god damn tired.

[@rijkvanwel]

Yeah, good point. As cool as features like RSC etc are, I'm definitely less productive than I was years ago.

[@jpffinc]

God damn right 😢

[@Salantor]

Remember that famous blog post about how complicated it was to create a simple webpage around 2000 and 2015 or something? Today it would be twice as long.

[@shapelessed]

@@Salantor It was complicated back there because of spotty support and no real standard. Today we have strong standards, and spotty DX, because everybody is trying to do things differently despite the standards.

[@Salantor]

@@shapelessed Funny, all the frameworks and metaframeworks are sold with DX in mind.

[@Strammeiche]

Was mostly backend and infrastructure before. Dabbeled a bit in frontend this year. Everything I heared is true, frontend is madness. The dependencies, the rate of breaking changes, the massive Overkill and Performance waste.

[@KingBobXVI]

Was it by choice or just circumstance? For me, despite my resume saying C/C++, C#, Ruby, etc, all my previous positions I was hired for were roles listed as backend programming, but then after joining ended up being mostly frontend. And man, do I not like the frontend ecosystem.

[@gruntaxeman3740]

No need to. It is just sign of junior developers messing around. I just wrote SPA application with 4 production time dependencies. Those projects with tons of dependencies is that there are developers who install new dependency every simple thing that can be made with less than 100 lines of code.

[@CottidaeSEA]

I think the answer is quite easy. Devs just want to write their code and have it work. That is getting harder to do, more configuration bullshit, more framework changes, split between server components and client components that isn't clearly explained, etc. People just want a no bullshit solution.

[@icusmilingAZ]

I would like to see an interview where the prospective employee and the lead would sit side by side and look at PR's. The potential employee can see what a shitshow the codebase is, and the employer can see how well the dev can understand the shit codebase, and what things they would flag if they were doing the PR.

[@JonMcLaren]

While i like the concept. The challenge is that in really big companies you tend to have abstractions on abstractions to the point that if you haven't seen what's going on under the hood it's difficult to actually determine if the choices made by the dev were good or not. May be doable in smaller projects though.

[@ecodes8498]

@@JonMcLaren Exactly. Also how would you evaluate a good codebase when you do not know the business side of things? There is a reason onboarding can take months and you cannot replicate that in an interview enviroment

[@michaeljmeyer3]

I tend to code with the candidate. I lead with them, following and giving feedback. I work with them for half an hour, after spending 15 minutes describing the more significant problem and how my small contribution will affect it. Ideally, I then create a PR and flag it as being from a candidate. The team comments, and we meet to discuss the candidate if needed. I really want to hear them think through the process. I want them to be comfortable, not distracted by abstractions, and to have to problem-solve on their own. I hope they are saying the right buzzwords that pique my interest. This also shows them what to expect when pairing with me and working on my team. This approach works well for me. It lets me assess their current state, potential for coaching, and interpersonal style. I have had people really enjoy the process, even if they are not chosen. It gives them a good feeling and gives them value. It's not just a 'woo' me test; it is a conversation with a deliverable.

[@inexistente]

everything is getting so f** complex for no reason

[@Saviliana]

Mostly those old gang problem, they always want to make things as complex as it could to protect their own job titles, instead of allowing things to be simplify and have better GUI and explaining during use.

[@diadetediotedio6918]

I don't think you know which is a valid reason versus not.

[@perc-ai]

just use rust brother. javascript is not the future trust me. Learning rust now will be one of the best decisions in your career especially if you yourself still workin in 20 years

[@thegoose2071]

exactly what i came down here to say

[@aayush_dutt]

No. React code from 2015 still runs good. Stuff that was already very complex just got less complex, at the expense of making the defaults a little more complex. You can still opt out.

[@rookandpawn]

i was friends with the inventor of browserify who told me frameworks are meant to die. like writing them is basically waiting for them to expire. hence, small tools, reliable, composed, piped, and focused. unix philosophy.

[@Fiercesoulking]

This the mindset of webdevs. Software devs are the only engineers who reinvent the wheel from time to time. Webdevs doing it constantly which is absurd.

[@hellowill]

Backend frameworks last for years, decades. Why can't frontend be the same? Fucking soydevs.

[@Dipj01]

There are certain frameworks like gtk and qt that have been here forever and will continue to do so. Even backend frameworks like Spring. Js frameworks on the other hand, yeah absolutely.

[@ljc6141]

Javascript, fundamentally, is not very good for dom manipulation. That's why frameworks are made. Frameworks "die" when some other new framework has a better method for dom manipulation. It's really not that deep.

[@dorktales254]

The Unix Philosophy did not ask to be involved /s

[@AllemandInstable]

TLDR; two major factors : - as time goes on, the people joining a framework ecosystem are no longer the enthusiast but rather people forced to learn the framework - as time goes on, projects get more complex, performance matter more and more, the tools (frameworks) adapt to those needs, and get closer to backend knowledge, which frontend people don't like

[@joaofrancisco5781]

And the worst part is that front end devs dont think a lot outside their problems, like security, deploy and so on. And use Next because is removes the network latency but it is giant piece of shit that is support by Vercel wich was the main thing used to deploy simple front end apps easily and for free. Now they built their kingdom and built the idea that every fucking LP needs a nextjs solution for the company, and the dev has to use it or the they is the one the brought the shit idea...

[@___Kevin]

Exactly !

[@saltylelele]

I've recently committed to building a project in completely vanilla JS, only using TS with bun as ebserver. I've enjoyed building it a 100x more then using any framework for this. Everything is just simpler, and it just works.

[@bigyikes7354]

All of the frameworks update too quickly. My company let go half of the web engineers and now we have more codebases than _engineers_ to maintain. I don't care about new features when I just want to keep the lights on and avoid having to deal with security vulnerabilities. Engineering _real products_ is complicated enough without your dependencies changing how they work every 1.5-2y.

[@nwylynko]

your company fired people and your blaming the tools?

[@ojvribeiro]

Vue is 10yo and it's still in v3. I don't think it is a rapid changing pace.

[@Kaihlik]

@@nwylynkothat happens all the time, it’s a reality that people have to deal with, sometimes you are losing market share but still have customers to service or you run out of investor funding and have to cut back. Web tools that just make life difficult to maintain existing code bases by not maintaining backwards compatibility are annoying because you might not have anyone available any more who can even do the upgrades. That’s just the real world.

[@peterixxx]

​@@nwylynkoI would too. I can still compile my old c++ code just fine. My python scripts work and have been reliably in production for 10 years straight. The insane update treadmill is not necessary.

[@peterixxx]

The worst example of this I've seen was salt stack. It broke all of the supposedly 'infrastructure as code' configuration I was maintaining in every update. It didn't save me any time. It would have been easier to run things on bare metal configured by hand than to use salt stack. It was a complete failure.

[@azixy_web]

Abandoning webpack and embracing next js as replacement ? Why not talking about vite ..

[@joaofrancisco5781]

Exacly. Next is trash just as react. Everyone knows, but the popularity grows as people buy the idea that they need Nextjs to make a LP

[@TheJunioGG]

I hate next with all my strength, from the soles of my feet to the last strand of hair on my head

[@OwnnOfficial]

HTMX ftw

[@xprowler404x]

htmx mentioned!

[@reverse4646]

I recently discovered there is also a valid parody of htmx named htmz. For simple cases it does the same as htmx without the attribut madness just with a simple one line onload inline script 😅

[@bensavage6389]

Golang and htmx🎉

[@hipertracker]

@@bensavage6389 only for simple case, it's not simpler for more advanced ui. spa with quasar is just simpler

[@betoharres]

@@hipertracker you can even build games with htmx, ffs

[@Fiercesoulking]

I think one of the main problems changes which force you to rewrite your code. In big project this becomes almost impossible the problem with this is then you are stuck sooner or later with an unsafe version. The other is the average age of developer gets older because early 2000s people were the first so most were in their early 20s like 95% . Now the average is in the mid to late 30 and this is just the average means learning a new framework every other week became impossible . The last point is the dependency hell of JS

[@JoelBrage]

I believe you are missing two reasons. 1. Maintenance overhead as the nice structure falls apart over time combined with vue3-ish incompatible migrations. 2. As a framework is adopted more ppl who are just doing a job and less greenfielding new tech adopters are using it.

[@andrere__]

Vue 3 migration really was a mess, basically broke my project. Had to rewrite almost everything, now it's working but I still would need to rewrite even more (basically everything)

[@T33K3SS3LCH3N]

I've been using Vue for a while now and I love having both APIs. Especially because they're well documented and Vue itself is so simple, so the switch to Composition really isn't that hard. I started off extending an old project at work with Vue where I couldn't change the build process, which can only be done with Options API. I love that this is even possible. And when I started a bigger new project, I went with the Vue/Quasar/Vite bundle (adding basic UI components and simple dev server/build tooling) and the Composition API which is just awesome to work with.

[@deado7282]

Another problem is that most fe frameworks feel the need to evolve away from the reason most people initially used them.

[@LongJourneys]

I'm so sick of how complicated things keep getting. I loved webdev back in like 2008. Its become progressively more obnoxious since then.

[@kabukitheater9046]

as tsoding put it, "the best code is the one you can copy paste". you can't even paste code nowadays coz most of it are sitting on a mountain of dependencies

[@levyroth]

@@kabukitheater9046 tsoding gang!

[@TheOne11111]

100% True. I don't enjoy Web Dev anymore. No standard and doing the same thing over and over again instead of creating the better thing.

[@neoqueto]

​@@kabukitheater9046 Everything needs npm and thus Node.js, you can't develop frontent without a server anymore, everything is transpiled, preprocessed, blegh. I still rawdogg stuff whenever I can and that usually results in more readable code and 5x less wasted time

[@NizzyABI]

Complex for no reason at all anymore.

[@sarthikg]

Issue with Theo's perspective is that he feels that frameworks are moving towards left because people are not interested in the "server stuff", but apparently he never considered the fact that people might not have liked the "server stuff". As much as I was interested in server capabilities being a possibility in the frontend codebases, the actual implementation is not only complicated, but also a mess to deploy. Having a dedicated backend never caused me to think, why is there a white screen for so long when i visit my website, ohh, it' the cold start. The benefits of having a server components based app ties very strongly to how good the infrastructure is, atleast in-terms of cols starts, which is not the case when u throw the static file even on a server (not even cdn). I think the perspective needs to be broadened up a bit, its not people's fault that they don't want to learn, but even people who were interested have kind of not liked the experience.

[@smoked-old-fashioned-hh7lo]

most people that are interested in the server would not even consider node an interest. many backend engineers openly mock node. this video is basically maximum copium to avoid harsh truths.

[@marcelo-ramos]

It's not not wanting to learn, it's having to relearn so much to accomplish the same. I learned backend 20 years ago, and since then I had to learn very little every year to stay current. In the other hand, just for React (as an example), I have had to relearn pretty much the whole thing at least 3 times. It's ridiculous.

[@hellowill]

I can't keep up with this shit. JS/FE is making a mockery of software "engineering". I was using create-react-app just fine... then decided to update my project and it's deprecated? Really? Then there's no clear alternative, the React docs have NextJS listed first, which doesn't seem like a direct replacement, and is tied to another company. Then people recommended I use Vite, which React docs have no mention of at all, lol. Comparatively, it took less than an hour to upgrade my (Java/Springboot) backend. No idea why Java gets so much shit when it's ideal for large/long-running (AKA real) projects I think the people talking shit never worked on a real project. Or they focus on the wrong things, such as language syntax, over stability and ecosystem.

[@nwylynko]

Bro, CRA is just a build tool, Vite is just a better build tool. Just use Vite. Your talking like Java isn't insanely tied to Oracle.

[@Drayken]

Vite is the alternative to post-CRA. Basically nothing changes for you, just create a vite app and everything else functions the same for the dev.

[@McTOTHTOMI]

I love Spring for backend. I forever hated meta frameworks. Just isolate the backend and frontend for the language it has been designed to. Why I hate Javascript is because it just feels soo glued together with random stuff. Some array operations are not even natively supported. Meanwhile Spring is so complex, yet so much faster and secure. You don't have big supply chain attacks there because there you don't really have 10 line Java code (not saying it couldn't happen). And the fact that large companies (Netflix, Government, etc.) are still using Spring as backend tells a lot. I get that people like the typesafe and close integration with meta frameworks, but if you spend time on proper documentation via OpenAPI or GraphQL you can have tools that generate typescript types anyway. Also if you have your full stack in one codebase, it's larger and harder to manage, not to mention for example a junior frontend dev and designer could easily write backend and modify it, which you can yes filter in a PR, but wouldn't it be simple to have them totally separate, then people who have no business in backend cannot even attempt to modify it. All together, for small projects these frameworks are easier to manage by a small team, but if you plan to get large just write these apps the proper, already proven way. And meanwhile you could also learn Docker and Kubernetes for deployment, because they are also not that complicated, people just make them look like they are. I'm a full stack developer managing Spring, Svelte stack in a startup (currently in dev) l. the whole k8s cluster is also managed by me.

[@shadeblackwolf1508]

I'm a java developer with a web app on top of my APIs. The web app is in react, but largely an obligation no one in the team cares about. The exciting stuff is all on the server. The web app is just to give non-tech people in the company access to what we've developed in a nice view.

[@maccsguitar]

Backend does well with their basic standard libs for ages and the maintenance cost for old stuff is minimal. Frontend frameworks break down to 1000 dependencies each and there are breaking changes every half a year in most of the libraries in use, no wonder newcomers find it ridiculous. At the same time we have legislation tightening on secure software development practises. Absolute madness.

[@joaofrancisco5781]

Thats why Solid has a high retention, simples, but not a spaghetti, dependencies but primitives that are supported by the framework team, not people that are working above the framework and that will create standars for a non opinative framework like React. Solid has opnions, and in my opinion that's great

[@lessquo]

Recently, I dabbled in Rust a bit. I tried to run a simple hello_triangle app with wgpu and winit. I chose winit because it was the most downloaded windowing library and the official wgpu document used it. Unfortunately, the latest winit (0.30.*) introduced a breaking change, resulting every example on the documentation and online tutorials didn't work. I'm so tired even in Rust

[@keepfeatherinitbrothaaaa]

Everything is getting more complex and we're quickly becoming redundant and obsolete. Yeah of course we're fucking miserable.

[@lronmate]

complexity.

[@fischi9129]

then either don't make your app as complex or change industry... Idk if most people realize this, but if you write the same react you wrote in 2019... it still works.... you can choose not to implement server components, you can choose to use document.querySelector. All the simple? apis you used to be able to use are still there, and for the most part they are still the same.... so where is the problem? I think most people just wanna make the old raw html,css,js files and then they realize, shut is worse over there if you go higher than exactly 3 pages...

[@dfuzerz]

​@@fischi9129 i know a few people who build big projects solo with old technologies that they didn't want to give up, and it works great. the problem isn't that the technologies have an expiry date, forcing everyone to change technologies (even though most frameworks aren't LTS, which means that if a security vulnerability is found you are forced to update), but that the market demand changes, which means you are forced to use the popular frameworks with the newest versions if you want to be part of (or create) a team of developers

[@fischi9129]

@@dfuzerz so, hello, I'm that guy who works with outdated stuff. When I walked in my job 3 months ago there was no compression of network traffic, auth cookies were not httponly, script tags got loaded in the middle of the file having some pages with 20 second loadtimes.... most of the fixes I did since were pretty much getting to know how they built your tools around it, and then inject fixes and manipulations that should not affect the functionality but fixes a lot of this shit(not fun). About the forcing... nobody is forcing you to use new shit to get a team of devs together, a competent dev is fairly technology independent (e.g. language, framework etc)

[@Dipj01]

​@@fischi9129it doesn't work like that. Even if the old code works, employees are still pressured to know the latest stuff to remain employable. And more and more latest stuff increases cognitive load giving a feeling of complexity, which the op meant. Don't feel offended when someone refers to complexity as complexity.

[@go_better]

Yeah. And worse - undocumented or poorly documented complexity.

[@hanes2]

Nuxt still my nr1. Over last two years, things they improved made my life easier so it’s quite nice.

[@creazy2312]

exactly! Nuxt is just love.. but I feel so much behind sometimes because "all the cool stuff" is coming out react first.. at least it feels like it does

[@ericsexton3539]

Im an engineer who was using Vue in real projects up until last year. Vue 3 is amazing. I love it. But, when it came out, the state of 3rd party libraries and frameworks was rough. A lot of them were not updating or coming out with update that was just filled with bugs. We were also teaching some people Vue at the time and it was so confusing because they don’t know the difference between vue2 and vue3 so they might try to some code that they saw online and realize it just doesn’t work anymore. It also felt like this period went one a lot longer than other technologies’ “upgrade cycles”. Vue 3 is still great and still valid points about not wanting change. But i think there were also the engineers who chose vue and were disappointed by how the vue3 release was handled. It

[@kolklik]

Agreed. Used vue2 in some real projects, vue3 came out, and honestly... It was a clusterfuck to upgrade. So many things broken left and right, and the promises made before hand was retracted and we were left with a lot of loose ends. In the end, we actually ditched the vue3 upgrade as it wasn't worth the pain, and have instead moved towards completely getting rid of vue.

[@FireDragon91245]

Bruh im a backend engineer like Databases, Business Logic, APIs and im still watching this

[@badhreeshmrao609]

I’m a backend dev, but i still like to keep tabs on how frontend is doing. With all this rising complexity of frameworks, do you think ppl will eventually go to using only vanilla JS for future projects? How would you guide someone who wants to learn frontend nowadays?

[@infantfrontender6131]

In the end, with vanilla JS you will create your own framework, probably without docs and tests. I have seen it in many companies. Just give a try to all frontend frameworks (React, Vue, Svelte, Solid, Angular), maybe 1 week for each one if you have time. And choose those, that you understand better. Also, check meta frameworks (React -> Next, Remix, Vue -> Nuxt, Svelte -> SvelteKit, Solid -> SolidStart and framework agnostic Astro)

[@smoked-old-fashioned-hh7lo]

htmx, tailwind, and any language with a server framework. if you wanted something a bit better you could build your own tiny islands architecture and then for state management you could install 'signals' from the preact repo. all of that is significantly easier than using a modern framework.

[@mementomori8856]

maybe it's because they change every damn second, the thing I learn today becomes irrelevant tomorrow and it's exhausting man

[@wilmerwalton5089]

I've listened to a number of associates howl about the rate of change in software development, and the need to learn new things. I don't think it'll set-off an Internet war to observe that the JavaScript ecology has one of the more egregious rates of change. We're headed into a period where rates of change are accelerating at a breakneck rate, in software methodology. "Thank you sir, may I please have another (change)?"

[@solii01]

I am not sure I agree with your take on choice vs. forced. I find myself being more and more dissatisfied with languages and frameworks I work with privately, always thinking "I should have chosen XYZ instead.", at work I do not get those thoughts, because I know we are (for now) stuck with what we have.

[@markuseberlein3394]

How much is early enthusiasm and then noticing the downsides of that specific framework later?

[@rohan1765]

I don't know who thought we need some FE JavaScript code to do BE, WE DON'T NEED THAT.

[@test-rj2vl]

Server side JS is the biggest accident that happened to the web development industry.

[@diamondkingdiamond6289]

@@test-rj2vl facts

[@carlosabreu5012]

@@test-rj2vl exactly

[@gruntaxeman3740]

@@test-rj2vl I often wrote Typescript to backend using NestJS framework because my sidekick developer is frontend only guy and he can do some fixes if I'm not available. Typescript on good structure isn't bad.

[@peterixxx]

The history of the whole industry is littered with zombified remains of things some guy thought was a great idea and released it into the world like the contents of Pandora's box. In nature, old things die. In the digital world, they never really go away.

[@relaxationtube2388]

Just gonna switch to Laravel so I can sleep better at night and buy a Lambo 😅

[@naughtiousmaximus7853]

Laravel mogs 99% of use cases of Javascript.

[@noobgamer7034]

The real problem is when the companies do not consider upgrading the project. For example if the project is in vue 2.6. And after a year client comes back and wants to add new features, but due to the old code base, we cannot move forward as much. At this point management does not care about whether it was built with Vue 2, they just want the changes to be implemented as soon as possible.

[@noobgamer7034]

Also because of poor practices, like not spending enough time jn writing test cases to define behaviour. This thing mostly occurs in service based sectors

[@levyroth]

At the moment I'm contemplating getting back into PHP or start fresh with Vue. Everything else seems to be imploding. The job market is a joke at least here in the UK. It's simply not worth knowing so much fluff for a 30-40K per year job.

[@jimmy21584]

After coming to frontend web dev relatively late, I find the infrastructure gross compared to anything else, ie Qt or SwiftUI. I find the frameworks bloated and overengineered. Just my personal impression. Hopefully webassembly and tighter standards will give us beautiful things in the future.

[@drevan1138]

What about devs who chose their stack in 2015 at an enterprise company and now feel stuck with it 9 years later???

[@msmeraglia]

Find a way to get buy in from leads to allow a migration to another better platform? Not the easiest depending on your experience/role but that’s common at every company I’ve been at, you get to a point where things are too much of a pain to maintain you start to migrate things out to better tech

[@drevan1138]

@@msmeraglia Thanks, but it’s hard at a company of 27,000. I’m the lead in my area and got us on React way back when. We have to integrate with the rest of the company and each area’s code is expected to easily run as a composable component in every other area. Our design system is obviously in React as well. Nothing is impossible to get off, but it would take a huge effort and a lot of convincing.

[@orderfromchaos663]

@@drevan1138 You could try a "smooth transition" library like Preact perhaps?

[@msmeraglia]

@@drevan1138 well if you find the time or the right project to be the prototype, you can control your own teams env, R & D some new tech, or replace some chunk of code you own with a new language/framework and show the rest of the company why its worth moving over. If its not, then figure out how to clean up what you have to make it less painful to use. You kind of just have to make something first and get people excited about it, otherwise no one is going to change. Just my two cents from what's worked for me.

[@msmeraglia]

@@drevan1138 otherwise sadly, it takes moving to a company that will ALLOW you to use what you want. That was my most recent experience, previous company wouldn't adopt Rust, moved companies and we are now migrating all of our services TO Rust after I wrote 3 or 4 different services to show them benchmarks and got enough people excited, showed the money saving potential in AWS, and the scaling possibilities

[@daSenfgurke]

I think a big point is that in actual real world applications and teams there is little to no time to redo or refactor old code. So if a framework introduces a lot of changes too quickly, people will get fatigued and overwhelmed because they feel obligated to adopt all these new features.

[@Aleks-fp1kq]

Making things easier drives abstraction up, and we end up not understanding how things work which leads to copy paste programming.

[@advertslaxxor]

And copy paste programming leads to more copy paste programming. I don't really do UI stuff, but I've been trying to pick up React and it really feels like the only way to deal with it is to copy paste.

[@shapelessed]

Too many people want to solve too many issues with too few tools. You end up with tools the size of ffmpeg with APIs so large you'll never learn it all. Recently I worked on a project that required TS, nodemon and Vite to run alongside, just wanted to have some tool to configure them in some JSON file, spawn them all with a single command and pipe their output to a single terminal to see everything in a single space. I wasted like 3 hours searching for a tool that would do this only to find some overengineered junk that attempted to do everything it could while making their APIs so convoluted and complicated I just gave up...

[@-Gnarlemagne]

​Whenever someone talks about ffmpeg in a context like this I immediately feel a sense of kindredship lmao. We've seen hell and made it back out alive.

[@user-qq7yc1qp8z]

I would use next when: - I need ssr for content website - It's simple app without other clients like mobile, without complex backend logic and without high load. Otherwise, I think just React with Vite + separate backed is better approach.

[@tomfancode]

Then, why not Astro?

[@JhonQuenano]

@@tomfancode no one use it. thats the reality

[@bohdanvinter6929]

why not use next with a separate backend? you could still opt out of all the super bananas RSC stuff whenever you need with "use client", while having (arguably) more convenient ways of doing things with nextjs features

[@user-qq7yc1qp8z]

@@tomfancode i already know next and don’t want to spend time learning another framework that does the same thing.

[@user-qq7yc1qp8z]

@@bohdanvinter6929 or this option. The issue is next gets slow in terms of updating and navigating between pages when working locally, it’s better now, but when app router was released it was unbearable, like 2 sec to open a new page.

[@GnomeEU]

So happy I didn't go deeper into Web development 10 years ago. What a mess.

[@dazraf]

For nearly most things you don't need a full-loaded-and-bloated framework. You need a set of small carefully chosen libraries that help with small discrete tasks.

[@tarasturchenko4528]

Vue shifted left not because of new api but because of migration complexity to v3. On my work project it took 1 year of migrations and making changes

[@mchisolm0]

Hmm…concerned we are trying to get more students into tech right now like we pushed people to go to college. I think without reimagining the relationship between classrooms like mine and the industry, we might end up with a problem in 10 years.

[@Murmeltier]

I have a specific project (Vite + Vue) running since 2021 and every time I have to do a "npm install" some packages will have a problem. Be it being discontinued, no longer working with another packages version, etc. Often combined with some sort of a vulnerability introduced as well - so you can't ignore and force it.

[@antsmasherjack]

Astro is still going strong.

[@gabrielkime6597]

Astro is a joy to work with. I absolutely love how closely it mimics vanilla html and js, while enhancing it with genuine qol improvements like file based routing and reusable components. And letting you choose which framework to use inside an island when you need more clientside responsiveness is such a good call… ive been thinking and I feel like it’s a fantastic adaptation to ballooning complexity. keep things simple by default and let the developer choose a tool they’re comfortable with when they need something more powerful.

[@EightNineOne]

I also love Astro. And I honestly think the whole ecosystem/JS fatigue thing is a big driver. Astro does so much with so little and has excellent support for basically any framework you’d want to use with it. It’s kind of the dream. The simplicity of the 2010s but the DX wins made since then

[@k22kk22k]

I always have wanted a framework that KEEPS the way things work. The code may get old-fashioned as time goes on, but it should keep working, stable and secure. It’s okay to pursue a new way, but that should be another framework. Don’t break or constantly obsoleting what is currently working fine and paying the bill for just an update. Should I still stick to PHP?😔 Very few in JS ecosystem seem to keep value delivering and learning cost in mind seriously…

[@kasper_573]

I very much agree with negative experiences being tied to the maturity of software projects. At the end of the day you need to write and maintain good software. While your tools do matter and have an impact, the biggest impact by far is your skill. No matter what tools you’re using, once your project reaches a certain scale you will have to fall back on computer science and architectural principles. While our frameworks provide solutions in some scaling issues, they only give you a foundation. For the vast majority of problems you’re left to your own devices and this is where you must rely on your own skill and organize your codebase and architecture wisely. I believe therein lies the problem, that people blame the framework when their own skill is lacking.

[@TsillALevi]

Many front-end frameworks are becoming increasingly complex to learn, especially those involving server components or server actions.

[@Salantor]

12:00 I feel like you are reaching a bit here. The problem is not that Vue 2 was closer to just writing HTML + CSS or whatever, but the shift between versions was pretty radical. On top of that, we got a more complicated reactivity system, years of waiting for some of the biggest libraries to migrate, and a bit of a feeling that Vue might be repeating React's mistakes by switching its paradigm every few years. Vue 2 components are basically classes, and Vue 3 components are a bunch of functions. You need time to switch your mental model with such changes.

[@JoRyGu]

The Vue negativity was 100% on the breaking of the ecosystem between Vue 2 and Vue 3. Tons of very, very popular libraries were broken for months/years. Maybe there are people that didn't like Vue 3 for what Theo is talking about here but I'd bet they're in the very small minority.

[@hejloldetermig3850]

I completely agree. And we're still in the process of migrating from Vue 2 in 2024.

[@MrHirenP]

lol, someone needs to fix how the mouse over works in that opinion/popularity scatter-line plot

[@thegoose2071]

writing anything related to the web feels less like a fun project and more like a chore. i could suck at web dev but it feels like even a brand new project is a complete mess right from the get go. everything is too complex, nothing is scalable.

[@brennan123]

There's another possible theory for why things are shifting leftward. You briefly hinted at it. As frameworks grow and evolve over time they need to maintain backwards compatibility. "All large codebases suck" can be extended to frameworks as well. Each increment change often has its own quirks. It adds some benefits but also breaks a lot of things. We've seen this with hooks. While it has overall been an a welcome addition the fact that it breaks the traditional programming model means that you can't use hooks inside of useEffect, for loops, recursion, etc. An array specifying dependencies? That's not a normal programming concept. It's a hacky workaround to solve the useEffect architecture. It's as if there's Javascript / Typescript and then there's this other pseudo-language with its own quirks introduce that then need additional hooks to counteract the problems created by hooks in the first place. Why is my code running multiple times, why can't I just run this onMount or onDismount anymore? Why do I have to useState the same number of times and the exact same order? Why can I useState inside of an if statement or loop? I'm losing my reference to my callback because the code is running multiple times (well you have to useCallback now to fix the problem that never existed before). It seems like we need to take a step back, figure out what are a good set of primitives suited to the task of modern full stack development, and build up from there. Something that follows a traditional programming model or maybe an entirely new language with primitives built into the language itself rather than framework / library APIs needed to achieve it.

[@luizfcavalcanti]

@Theo, crazy idea... Why not ask the "why" in the next survey? IMHO it's not only the "you're being forced to use this", there's also the heavy handed influence companies are exerting in forcing certain paradigms and technologies that people are tired of working around those forced choices.

[@kevinweir2499]

When you build something on a shaky foundation and house of cards (JavaScript) are you really surprised? The ecosystem is a staggering mess of complexity.

[@NabekenProG87]

Some of these graphs only change by low single digits, they are flatlining, not declining. That could also happen because the userbase is saturated. You cant just always grow, at some point you have to take away "clients" from other frameworks that have a harder time switching

[@PP-ss3zf]

front end frameworks should have nothing to do with the server

[@austincodes]

I think you hit the nail on the head with the job security part

[@zBrain0]

Svelte in particular is shifting left because of the changes that they are making. People are making assumptions that are inaccurate. I just finished moving a significant code base to version 5 and it is so much easier to understand, so much more consistent, and to add to those wins the output is smaller and more efficient. But people don't like the fact that you have to type a few extra characters to make something reactive. It's just silly.

[@SilvestreVivo]

Totally agree. Frontend developers are turning into holligans.

[@naughtiousmaximus7853]

Its crazy because its not like its much more verbose. You are complaining over what, 17 more total characters you need to write? Come on, its pretty obvious these devs arent building anything outside of portfolio sites and blogs.

[@alvesvaren]

I am really excited about tanstack start, it is much more transparent with what it's doing, and things like next hide wayyy too much behind the scenes so you can often not really understand why something is happening.

[@jackevansevo]

The most obvious culprit for everything shifting left to me is SSR.

[@carlmeyer96]

This was such a great video. I love your breakdown and thoughts. I haven't read through the survey myself but watching this makes we want to go and take a deeper dive. Keep up making awesome vids!

[@Khari99]

Hopefully we all just move to Phoenix Liveview one day and live in peace

[@infantfrontender6131]

Yeah, Elixir with Phoenix is great. Also Gleam.

[@d06murd]

Same sentiment, sucks that its not picked up by companies to give better job opportunities

[@rijkvanwel]

Good subject, bad take. The growing complexity of JS frameworks that seems to serve marketing purposes more than actual UX/DX improvements is a genuine problem worth discussing IMO. I've been in web development since PHP/Mootools days but I don't feel we're more productive or building significantly better apps now, even though we've had 15 years of tech improvements since (and had to completely relearn how we build multiple times in the process).

[@Kwazzaaap]

Yes, when I look at old codebases every feature that's "brand new" is already there. Like these people just forget about 15 year old tech so they can invent it again!

[@SilvestreVivo]

The fact that people is less and less happy with React, doesn't mean we don't like to work with Vue or Svelte. Actually, we love them more and more every day.

[@lukasmolcic5143]

I think we are in a point of divergence, the industry feels like the solutions that we have are not doing it, every solution has its serious downsides, performance, the amount of complexity, maintainability or some limitation on what it can reasonably do, I would predict the dissatisfaction will just keep growing until we reach a new point of convergence and a new paradigm emerges

[@ws_stelzi79]

The thing with JS - a inherent client side THING - moving to the server certainly feels very wrong for every halfway decent JS dev! JS is for frontend and literally else is for backend. IMO THAT is a good thing and shows how crazy compared to other language ecosystems the JS ecosystem is.

[@capability-snob]

Great to see it's not just devops anymore - frontend devs are now taking shift-left seriously, too 🙃 Edit: also, that svelte take on reactivity is spot-on.

[@grink-ii]

The thing that has burned me out most is trust. I'll swallow the difficulty curve, but there are too many frameworks promising more than they can deliver.

[@Dmytro-Shcherbyna]

I'm rarely working on frontend. It's not in my sphere of interests. I'd prefer never touching it, tbh, as I find it really frustrating to come back after year or so and find out everything changed so much that it feels like different framework (React/Vue and bunch of smaller libs from my experience) that needs to be re-learnt, while I'm tight on time and need smth done fast. Then I find lots of HowTo's neither of which works, lack of documentation (or plain misleading one), conflicting versions of everything and everything being so unnecessary complicated that my brain melts (granted, I'm not the smartest person on Earth). I don't need it to be fancy, I need it to work and usually it just doesn't. It's same exp for some of my dev friends.

[@Pandazaar]

just use htmx if that's the case

[@anwiseru9064]

really cool interview process

[@frankymaca]

I just wanted to mention the amount of good content on this channel is crazy, u got all my support ❤

[@brennan123]

I love your interview process with the different options. Is that publicly available and do you have a link to it? Each engineer has a different background, interests, strengths and weaknesses. Allowing them to show you what they are capable of by catering to their natural way of working is brilliant.

[@luketurner314]

Why did I watch this when I don't use any framework when writing HTML, CSS, & JS?

[@fnfal113]

Honestly everytime I see a react code or even configuration files on frontend it makes me wanna do other stuffs.

[@xprowler404x]

hi theo, im a cybersec major and not a web dev by any means, hell my website is just regular js, css (no tailwind) and regular old html. but i still enjoy ur vids learning about crazy web innvomation when my knowledge is just php 💀💀

[@imaron]

I think one of the main aspects you missed, is maturity. In early webdev everything was miserable and people were willing to do anything to ease the pain. But now, I think, we've gotten to the point where most solutions are kinda "good enough". The opportunity cost of learning something new and switching to it has become really high, because the benifit isn't nearly as stark. And as you stick with the thing that you know and continue to use it, you start to see it's flaws. I think webdev just has gotten to the point where general software dev has been for a while. No longer, are we the cool, fast pace part of the industry. Tech stacks are settling in, nothing can be deprecated anymore out of fear for compatibility and progress is slowing. It's not all bad, but alas, it was fate.

[@kittycat794]

Agreed. I have npm burnout. Not allowed to upgrade anything because it will break enormous dependency trees, not allowed to move to a simpler solution and ditch the mountains of code that were written. I think a lot of devs are like me in that way. There is no budget for refactors and for simplification.

[@PieJee1]

Vue composition api was an improvement to me, but they did make non-intuitive changes. You would not be the first one to use useFetch in a callback method. A more constructive name that tells this is a declaration would have benefitted vue 3. It is similar with angular forcing rxjs on everything while most programmers still think in promises

[@NizzyABI]

I wonder if this is just a phase or if we will shift back to more based frameworks / more vanilla type of code writing

[@oivinf]

SSR is an unnecessary complication that doesn't solve any problems and makes control flow difficult and messy. And being constantly forced onto new versions of the frameworks that are less functioncal and less useful than the last iteration isn't helping

[@oivinf]

Example: the only way in Next App Router to make anything interactive and stateful is on the client side. The only way to make something depend on data is on the server side. So how do you create say, a search bar? Or a button that orders or filters a list? Well you have to refresh the page with that state in the query. But that means even the client side stuff isn't going to change state until the url query updates. Which only happens after a round trip to the server and full rerender. Because shallow routing isn't supported 🤪 what a mess

[@ignrey]

My guess is that launching RC updates results in every techfluencers talking about them, which results in more people feeling like they're getting behind somehow. All of this spiral into a lot of devs feeling the pressure and start to complain about it...

[@piff57paff]

Fun story: I recently tried to learn next.js and their tutorial points to a starter that NPM fails to resolve the dependencies for (as it's using some specific revision of next.js and react RCs). If already the tutorial is broken, you know the state of the ecosystem.

[@jordanbrennan1296]

That Vue Composition diagram is misleading at best. IF and only IF the developer thoughtfully organizes their code in logical chunks do you get that “better” diagram. And IF and only IF every developer who then touches that code takes extra time to fully grok how the previous developer organized all that logic AND also takes great care to add their code to the “correct” yet invisible sections will the code stay organized like the diagram. It’s a ridiculous claim and Vue should remove it. The Options API had a sensible organization that held true across every component (every app really!) and no developer could make a mess of it.

[@JozefKonradPlata]

This is a very accurate diagnosis, I can sign with both hands on that. I've started to learn few JS frameworks just to understand front-end better, and maybe build the front-end for my personal website. And somehow I got sucked into the things I'm not even interested in doing. But with the current job market there's not much I can pick from to escape that JS frameworks bs.

[@robkom]

Having more choices doesn't generally lead to happier outcomes; this is known as the paradox of choice and is somewhat similar to analysis paralysis. Being unhappy because someone else made the effort to make technology choices seems somewhat counterintuitive. I think it's less about not having the choice and more about the general lack of autonomy, as well as being misinformed or uninformed.

[@uiuxaidesign]

the paradox of choice, why more is less, good book, recommend

[@blinking_dodo]

Since you'd be switching frameworks and most of them seem to be in decline, perhaps you could consider using *no* framework at all? Just plain old HTML/CSS and JavaScript, back to the basics. There are features like custom HTML elements, DOM templates and module architecture you may or may not be aware of.

[@gersom3318]

Astro made all the other tools shift left in my head

[@LKTitan01]

Your thoughts about backend Node Spring boot ...

[@witchmorrow]

I agree that it is frustrating to continuously have to learn new paradigms and keep aware of what's going on in the industry, because there is just so much changing all the time, but on the flipside that is also why I like the frontend. I find it so exciting to learn about the new stuff and can't wait to use it

[@Norinot1]

Its so bizarre to see that many people dislike Angular and out of all the frameworks I've used before and know how to use I like that the most, idk why I just like using it. Ignorance is bliss I guess. But like, I love Go.... and others love that too. Hm.... mmaaaayybeee.....

[@vvvvvvvvvwv]

Are there other surveys that do similar sentiment question like this for other ecosystems? I'd like to see if this is just something in the JS ecosystem or something more industry wide

[@lukor-tech]

This part about the bubble not having too many intersections grows even larger when you think about the AI burst and the "vanitas" part of learning on new FE devs

[@Holobrine]

So…if retention is going down…where is everyone going?

[@gunnarthorburn1219]

Interesting analysis. My work, and passion, is about solving business problems. I am a full stack developer. Web frontends are just a tool to avoid some details of DOM-manipulation. I got on Angular.js in 2014. Angular 4 was not a realistic upgrade path, and Vue is quite similar to Angular.js, so I migrated from Angular.js to Vue, and later to Vue 3. So you are absolutely correct, I have no interest in the Composition API - because it solves no problem for me and just cause a hell of a lot of refactoring of working code. I don't need to a better web framework, I need to not waste time on rewriting code that works.

[@davidmuturi2078]

Interview guide link

[@darknezx9542]

I primarily used svelte from earlier this year and chose to start from 5. It makes a lot of sense to me and I prefer it to the svelte 4 way. I can agree with theo's argument.

[@sadkebab]

I personally think there is also some actual hysteria going on in most developers that participate in the discussions arount the current state of the frameworks. As someone who worked mostly in consultancy projects for 8 years or so and had to touch voluntarly or not most of these frameworks in different points of their evolution... I am very satistified with the direction they are taking. I have hit the limits of all these frameworks so many times in my past and I HATED the workarounds. I can understand that my subjective experience is different from the one that the average developer has, but it seems to me that the average developer doesn't want to aknowledge that the complexity is rising because more and more people are hitting the ceiling of what these frameworks can offer. Also there is so much misinformation everywhere about these tools nowadays. Since this industry should be about logic, we should ashamed on how much the talk degenarated because of the "vibe". Most of the takes I see online have blatant logical fallacies from the way the are built to the way they are discussed. We can do better.