Every Framework Sucks Now
VloĆŸit
- Äas pĆidĂĄn 29. 06. 2024
- 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 đ - VÄda a technologie
![The moment we stopped understanding AI [AlexNet]](/img/n.gif)
You either die a well-loved framework, or live long enough to get to the left side
Russian bots
In the game of drones, there is no middleground :)
You wanna know how my framework got these scars?
:v sound about right
To alleviate this issue we should make a new framework that....
Itâs a never ending cycle, isnât it! đ
LTS version for frameworks would be great
Lemme know when itâs ready for me to fork it and add more bloat
xkcd 927. I didn't even have to look it up.
Wut da heeeeeee
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.
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 :)
React switching its paradigm like 5 times in the last decade is also a good reason to not like it anymore.
@@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
react was never simple, it was all a lie
@@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?
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.
Yeah, good point. As cool as features like RSC etc are, I'm definitely less productive than I was years ago.
God damn right đą
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.
@@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.
@@shapelessed Funny, all the frameworks and metaframeworks are sold with DX in mind.
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.
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.
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.
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.
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
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...
Exactly !
Litterally the opposite. Frameworks just add unecessary complexity to projects that 90% of the time, prolly dont even need it.
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.
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.
@@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
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.
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.
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.
Backend frameworks last for years, decades. Why can't frontend be the same? Fucking soydevs.
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.
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.
The Unix Philosophy did not ask to be involved /s
everything is getting so f** complex for no reason
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.
I don't think you know which is a valid reason versus not.
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
exactly what i came down here to say
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.
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.
ONG BRO. Seriously its rdiiculous how bloated overcomplex, and midwit-ey that javascript soyslop has become.
I just use basic react.
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.
your company fired people and your blaming the tools?
Vue is 10yo and it's still in v3. I don't think it is a rapid changing pace.
@@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.
â@@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.
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.
HTMX ftw
htmx mentioned!
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 đ
Golang and htmxđ
@@bensavage6389 only for simple case, it's not simpler for more advanced ui. spa with quasar is just simpler
@@hipertracker you can even build games with htmx, ffs
Another problem is that most fe frameworks feel the need to evolve away from the reason most people initially used them.
Abandoning webpack and embracing next js as replacement ?
Why not talking about vite ..
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
I hate next with all my strength, from the soles of my feet to the last strand of hair on my head
vike (formerly vite plugin ssr) is an up and comer here!
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.
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)
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.
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.
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.
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.
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.
I like C# over java litterally only cus it looks cooler. Java also is kinda old, so I have a bias against it.
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
I'm so sick of how complicated things keep getting. I loved webdev back in like 2008. Its become progressively more obnoxious since then.
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
@@kabukitheater9046 tsoding gang!
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.
â@@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
Complex for no reason at all anymore.
complexity.
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...
â@@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
@@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)
â@@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.
Yeah. And worse - undocumented or poorly documented complexity.
Everything is getting more complex and we're quickly becoming redundant and obsolete. Yeah of course we're fucking miserable.
Nuxt still my nr1. Over last two years, things they improved made my life easier so itâs quite nice.
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
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.
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.
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.
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.
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
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
Bruh im a backend engineer like Databases, Business Logic, APIs and im still watching this
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.
Yea I like stuff like tauri just cus making UI's in react seems common sense. But backends in rust is so much nicer than in java.
I don't know who thought we need some FE JavaScript code to do BE,
WE DON'T NEED THAT.
Server side JS is the biggest accident that happened to the web development industry.
@@test-rj2vl facts
@@test-rj2vl exactly
@@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.
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.
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.
Just gonna switch to Laravel so I can sleep better at night and buy a Lambo đ
Laravel mogs 99% of use cases of Javascript.
maybe it's because they change every damn second, the thing I learn today becomes irrelevant tomorrow and it's exhausting man
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
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.
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.
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.
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)?"
Nothing is changing, its all the same bullshit from the 60s. Were not using new math or anything here.
All the actual work is done by the hardware guys and actual engineers.
For us software cucks, the only things that even remotely count as engineering was cryptography and AI/Data science.
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?
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)
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.
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.
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
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.
Astro is still going strong.
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.
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
What about devs who chose their stack in 2015 at an enterprise company and now feel stuck with it 9 years later???
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
@@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.
@@drevan1138 You could try a "smooth transition" library like Preact perhaps?
@@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.
@@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
So happy I didn't go deeper into Web development 10 years ago. What a mess.
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.
Then, why not Astro?
@@tomfancode no one use it. thats the reality
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
@@tomfancode i already know next and donât want to spend time learning another framework that does the same thing.
@@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.
Making things easier drives abstraction up, and we end up not understanding how things work which leads to copy paste programming.
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.
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...
â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.
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.
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
Many front-end frameworks are becoming increasingly complex to learn, especially those involving server components or server actions.
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.
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âŠ
How much is early enthusiasm and then noticing the downsides of that specific framework later?
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.
Hopefully we all just move to Phoenix Liveview one day and live in peace
Yeah, Elixir with Phoenix is great. Also Gleam.
Same sentiment, sucks that its not picked up by companies to give better job opportunities
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.
Frontend overall sucks because the whole ecosystem is driven by people who don't know what they are doing.
One of the first of Theo's videos I saw (only recently became aware of this channel) was about js devs arguing about const vs let. He even showed tweets from purportedly the js language designers, and even they were bumbling around the point of const.
And most of the confusion seems to be from people assuming it means, in C-style pointer lingo, "const TYPE*" when it actually means "TYPE* const" - or in other words, the value being const vs the pointer being const. This is one of the reasons I think more people should learn C... hiding the idea of pointers and pretending they don't exist in the language, but then having everything silently just being pointers anyway, is a huge disservice to people trying to learn programming with languages like Java, Javascript, C#, etc.
That's one of the reasons why I like java. It's so consistent in everything and (except for some deprecated APIs still in there for backwards compatiblity) almost everything has a reason.
They are experimenting with the population
ââ@@nikomitk8091similar feelings. Java has remained (kind of) the same for a lot of years now with very little new crap. It just works and unlike the front end market, the industry neither adopts nor expects you to constantly know shiny new things for a "better" dev ex.
I agree. Next is the proof, the front end dev is almost a cheer leader of next while the devops is trying to deploy a """"front-end"""" app... The devops in my company got stuck trying to understand why he had to deploy next like a server while the app didnt need SSR components.
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!
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.
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.
I completely agree. And we're still in the process of migrating from Vue 2 in 2024.
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.
front end frameworks should have nothing to do with the server
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
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.
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.
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.
Because it should have been just jQuery in the first place
555+
I was porting a feature set from an old Ruby project that uses jQuery on the front and I honestly have no idea why it is so hated, everything needed was there and vanilla js never really caught up to the richness jQuery provided.
I think you hit the nail on the head with the job security part
@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.
The most obvious culprit for everything shifting left to me is SSR.
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.
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.
I wonder if this is just a phase or if we will shift back to more based frameworks / more vanilla type of code writing
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
lol, someone needs to fix how the mouse over works in that opinion/popularity scatter-line plot
Hey Theo, I have a small Library (angular :P) which aims to make multi-threading simpler using angular signals, its not public right now i just want to ask where a good place would be to ask for input , ( i think its far from production ready but i also can`t find many ressources about this)
Which means im not sure if i am on the right track or shoot myself already in the foot (it works in my own benchmarks exactly as expected).
So do you know a good place to ask for input? (planning to make it open-source till the weekend)
Edit: sorry for my bad english and greetings from germany :).
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.
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.
the paradox of choice, why more is less, good book, recommend
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.
Totally agree. Frontend developers are turning into holligans.
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.
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.
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
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 đđ
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
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
They should have had another metric about people flatly giving up Node. I mean I can't since I still have to work in it, but the experience of, for example, doing Golang + helpers (PicoCSS HTMX Surreal) has been very positive. It'll get even easier to stick to plain HTML/JS/CSS if tc39 ever enters the browser as well. It's back to basics.
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.
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).
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!
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.
Could you link to that vue code diagram? Or that Interview guide?
RSC is a mistake. if server was the goal all along we might as well not left rails in the first place
It's not a mistake it's just half baked. We are now in the PHP4 days of this, no frameworks to automate the useless boring stuff, no patterns, no nothing. The issue is that it is shoved down peoples throats because some IPOs are probably coming up :/.
I agree, hope some day react dies, and Vercel stop buying everyone's opinion about next and that shit dies too. We need a framework that does what is says and just it, and in my opinion, solid is going to create the next gen, but will be stand for a really long time. Solid is what React seemed to be a few years ago, but just when u understand how solid works u get why react is just a worst version of what solid is, but in order to understand the past, we need the after to come, and I put my money on solid. If I want a monolith, I prefer the Laravel + Inertia solution that vanishes the SSR front end solutions
The central goal of a library, is to take a piece of complexity of the language or its environment and build a more accessable wrapper over it. Broadening this to a framework, it's trying to be a collection of these that fundementally improve the experience of writing in a programming language. I think the problem JS frameworks are facing, is that it's really hard to be a good framework for JS in the browser, and server side JS at the same time, but server side js is not mature enough to have its own frameworks yet. Personally i'm from the java world and we've seen several waves of frameworks. As the core domain shifts new priorities take center stage. I think part of the problem is the complexity added by one framework for trying to run browser and server, instead of two separate but connected frameworks
I just wanted to mention the amount of good content on this channel is crazy, u got all my support â€
Astro made all the other tools shift left in my head
Speaking for myself, I'm just over the complexity of these huge frameworks and I'm more exited about using a nice backend in a language I actually really enjoy and pairing it with some simple templating engine and htmx if I need reactivity.
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.
Why did I watch this when I don't use any framework when writing HTML, CSS, & JS?
IMHO the average developer is willing to learn 1.5 - 2 frameworks. Regardless if it is frontend or backend. Many even stick to their core language and neglect the ecosystem around them. Which is a pity. Looking outsite the bubble helps to create far more better applications and contributes to the overall understanding. I started as a fullstack developer 2 decades ago and be happy that I knew about certain quirks and issues to look out for in various areas. So in my current position as a backend developer I'm aware of the frontend and its needs, although looking at some projects and code regardless of backend or frontend I feel a big pain. Its like those old jQuery2 modules that are still alive with wasteful calls and convoluted logic/libs just because someone thought it would be great to move everything to one platform ... hopefully the whole framework landscape will help and improve the web in the next years. The time of SPA's is over. Having mixed content of static HTML and dynamic DOM elements served by any reactive framework or even server-side backend is the key in my opinion.
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.
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.
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
Honestly everytime I see a react code or even configuration files on frontend it makes me wanna do other stuffs.
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.
just use htmx if that's the case
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...
21:30 Here you are also reaching a bit. Have you considered that maybe, just maybe, we are all not very happy with the general state of the webdev? The fact that we moved from pure server-side solutions to Next, Nuxt, and other "meta" solutions, hybrids of front and backend code? That we are basically forced to do fullstack job, but also not really? Or that a lot of frameworks start to feel the same (Signals happened, and suddenly everyone wanted them. Before that hooks happened, with the same conclusion), to the point that it seems like there is very little reason to go outside your framework of choice?
Yes, job market status is important, but come on, there are a lot more things happening on the web and with the frameworks, that are contributing to the overall mental state of the devs.
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
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