Every Framework Sucks Now
HTML-код
- Опубликовано: 1 окт 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...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
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
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
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 then 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.
My gf just started having tests on React on her job, she couldn't get to work because SOMETHING was deprecated and she couldn't spot where on her code or why, she was just terrified for it because she couldn't deliver the test functioning in time, and then everyone above her that checked her work was like "Yep, that seems about right"
And that was her introduction to dependency hell.
That’s what happens when you have an inept standards body that takes decades to roll out basic things.
Everyone scrambles to add those features their own way and you get a hundred competing options. And of most of those will reuse one of the hundred competing options for various lower level functionality and so on.
It’s why a hello world Vue app is what, over 1000 packages, all of which are going to be updated, abandoned, and wind up with security issues at random times.
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 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.
@@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."
I don't think this goes against the idea. It would be valid for a new dev to see these abstractions and rightly recoil in horror at the usual gross over-engineering intellectual-masturbation, suggest they employ KISS, and to then withdraw their job application.
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
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.
Im new to programming and i have a question why use javscript framework it seems like an overkill for everything. If i can use php and not js natives or framework. i only use js for interactivity mainly onclick and etc.
Im learning for backend and frontend is just a curiosity thing so i have not much of a clue on why is there so many js framework.
@@eleinaedelweiss6215 Frameworks were first introduced to make lives simpler and everyone jumped on the bandwagon. As time went on the frameworks kept adding more features, getting more complex and ultimately becoming a requirement to land a job and now everyone's forced to learn a never-update-ending framework :)
@@eleinaedelweiss6215Because JavaScript wasn't always this good, and each framework just tries to make creating UI/UX easier compares to doing it by hand, and believe me manual DOM manipulation gets annoying fast
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.
maybe it's because they change every damn second, the thing I learn today becomes irrelevant tomorrow and it's exhausting man
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.
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!
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
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 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.
I mean.. Starting a project and having it work has never been easier. The rest is just optimization if needed that wasn't even possible to do before
@@ThePizzabrothersGaming False. It has pretty much always been easier than now. You can get a lot more stuff in your new project these days mostly without any work. However, it also comes with a lot more knowledge requirements. There are many times when I've found that the defaults don't work out after a while. There are many times when I find out that we have some use-case where the solution does not actually work and there needs to be a bunch of hacks to make it work, or just a straight up replacement.
Those things have always happened, but I've never experienced it more than these days.
Just gonna switch to Laravel so I can sleep better at night and buy a Lambo 😅
Laravel mogs 99% of use cases of Javascript.
Adonis.js 🤫
@@naughtiousmaximus7853mogs?
Bruh im a backend engineer like Databases, Business Logic, APIs and im still watching this
Everything is getting more complex and we're quickly becoming redundant and obsolete. Yeah of course we're fucking miserable.
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.
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 am a mobile dev - the same shit show happening in mobile frameworks. It is not about frontend migrating to backend. It is more about multiple technologies in the same project, and guys who read a lot of books and really think that abstractions and new magic can fix everything. Nowadays I write 3 times more code for the same things I did in 2020. Each new lang and framework started as a simple and precise tool for the exact issues we had on hands, next a lot of people join the dev community and start pushing new shiny ideas. From that point tool or framework became a mess. Less is more in 2024.
@@positiveslipAny Linux command line user would know, less has always been better than more :)
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
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)
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
FRR, i just learn Go for like 3 weeks and coming from javascript land i can say go is really nice. i can do all things just with standart library and can focus more on the backend it self rather than focus on 3 party library i've to learn
Another problem is that most fe frameworks feel the need to evolve away from the reason most people initially used them.
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.
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.
@@smoked-old-fashioned-hh7lo why ? I work with node in intership and I would like to know why ? should I change ? or learn other things side by side
@@CulturalArcher if you have a job i would hold onto that. survival is more important than anything and it's difficult to get jobs right now. i don't remember what this video was about but my point seemed to be that most engineers typically have very little desire to use javascript on the server. frontend engineers that lack knowledge and experience with other languages and environments tend to have more interest in it because it's more convenient. as far as developer experience goes it's one of the worst in my opinion.
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 am thinking about switching to backend with java as my main language tbh . Mentally fatigued by this constant unstability on Frontend
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
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.
So happy I didn't go deeper into Web development 10 years ago. What a mess.
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.
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.
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
All Javascript frameworks are lipstick on a pig.
The foundations of html/css and javascript were badly designed and never intended for large complex applications
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.
@@infantfrontender6131 why do you need tests for the UI? thats some idiotic thought process.
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.
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
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.
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
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.
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.
Same thinking about changing my language JS is exhausting
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.
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.
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.
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
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.
lol, someone needs to fix how the mouse over works in that opinion/popularity scatter-line plot
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 worked on backend, on ML, on language processing, on ETL optimization, genomics, chemistry, geospatial, digital art, and digital music. Every single coding experience had a different learning curve, but I always ended up enjoying it.
Never, never, never never with frontend.
Inconsistent behavior with caching, state management, widget alignment, scrolling behavior, ugly CSS code, tons of dependency for any small requirement, concurrent states, extremely huge CSS or JS files for a single widget. Everything feels like a nightmare.
To this day, I still couldn't align a scrollable Datatable header and row content without debugging through 47 different files nested in between my static.
Svelte 5 is kinda sort of ruining Svelte so I understand why thats on the down trend.
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.
@@kolklik what framework you are using now?
we've moved to svelte ✌️
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.
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.
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
Why do you post so much Next.js cope and lies? Svelte, Nuxt, Docasaurus and Astro were all going up in this list. It's Next that's doing bad. People hate Next. It's a mess. Stop lying dude.
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
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.
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
I think you hit the nail on the head with the job security part
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.
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.
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 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.
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
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.
YO HTMX IS COMING !!!!!!!!!!!!!!!!!
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.
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.
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!
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.
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.
Bet on vanilla. Frameworks come and go, but if you’re staying solid on what browsers themselves can do, you’re probably going to stay excited.
Honestly I'm just tired of framework churn. Like could I have something with a consistent workflow for longer than a year.
I'm tired of all these non-problem solutions getting tacked on to the directions of frameworks and tools.
I am happy with my .NET full stack ;-)
Why did I watch this when I don't use any framework when writing HTML, CSS, & JS?
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
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.
Many front-end frameworks are becoming increasingly complex to learn, especially those involving server components or server actions.
It is complex because the paradigm is new, just how jQuery developers are confused when the new JS and SPAs are introduced
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.
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.
React is absolutely worse than Vue. No endless runtime allocations of arrays and callbacks on every component redraw, no manual dependency management (Vue it truly reactive), no CSS-in-JS/JSX bullshit, templates are in HTML, styles in CSS/SCSS, no attempt to pack everything in JS in cursed PHP-style and with callback hell. Logic (conditions, loops, etc) is way more readable as few easy to remember and understand directives, also optimized at compile time. Two-way binding. Great DX overall. Easiest store/routing solutions. React, on the other hand, is simply overhyped garbage, that only felt good and fresh after jQuery/Angular. So sad it's so wide-spread. And Vue isn't hard to learn and understand at all, even Composition API. BTW, Vue reactivity is stand-alone, diesn't have to be limited to Vue applications only
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.
A doctor of companies , a man who has been working in the IT sector for over forty years, said that when he does a reorganization of the companies of his clients, usually about seventy percent of their IT costs only money without it bringing money in, so he cuts away seventy percent of the IT. Most in general and overall in the IT sector, more than fifty percent is just hype and causes over-complexity in many ways. IT costs society hugely in various ways.
So, if you are developer with ever more headache and possibly burn-out on the long run, your toys are growing into vast over-complexity, becoming a burden, it is because nature aims at simplicity and efficiency.. Evolutionary we are at large scheduled to be deprecated.. to be discontinued, just like our toys, and so it is with much of the toy and hype technology of our societies.
Honestly everytime I see a react code or even configuration files on frontend it makes me wanna do other stuffs.
by the time you learn a new frame work its already trash
Most web apps don’t need a front end framework. Some libraries to make DOM access easier and handle UI stuff like modals snd tool tips if you really need them, sure, but a full on framework?
We wasted so much time and resources on this fat web client side quest only to end up going back to server side rendering. Funny but sad, and expected.
The problem is the churn and youre part of that problem by just constantly promoting huge churn in frameworks and not on longevity. Remember pushing Vercel Edge so hard only for it to be killed? and Next when it clearly has some of the highest churn of any framework weve seen.
You make massive jumps in conclusions here when theres no evidence present re: “theyre forced to use it”
We need a replacement to the web browser. The web browser was made for rendering documents and navigating between them. What we have on the client is a total mismatch between what's being done, and what it was intended to do.
I don't think that this will be as hard or impossible as people imagine. All you need is one good free client, and one compelling need that is provided only through that good client, and people will download it, opening a new door.
Think of how many video games people buy -- each their "own" client.
It's not crazy that people would download a new kind of general internet client.
Theo is spot on. I picked Vue because I didn't have to learn other things. After the change, HTMX + Golang/Templ feels like Vue2 but cleaner.
It's very nice.
FE is too complex and pays less than BE, no reason to be there unless you really love it or at junior level. nowadays devs gets disillusioned from all the new tech hype fast, since nothing ground breaking coming up, just new remixes of the same old messy trash, I came into conclusion that programming trends are more like fashion than science. it is not about productivity but about marketing. Anyways, programming in not enough to pay the bills in the last few years, so there is no reason to get too excited about anything related to it.
Thank God, it's starting to fall apart.
I didn't choose React, and could've probably end up disliking it. But it actually made me excited about programming again. Clean and easy to understand code, leaning towards functional paradigm. Mind you, it wasn't a startup. The project was pretty big with tons of legacy shit I still had to touch now and then. They nitpicked my first MR into rewriting my class component with hooks, and its was magical. I was already burned out after my previous job, but now I had something new and pleasant to look at. And loved it so much, I dove straight up into F# and Haskell, and now also learn Calculus.
You really hit the nail on its head about this two types of developers. My current colleagues don't seem to like React, because they weren't React devs before. They don't like Tailwind, because weren't doing utility classes or mixins before. They still lean towards variables instead of values. Shifting perspectives takes real effort and ain't often pleasant
Not Aurelia.. it is so simple, powerful and a joy to use. Try it if you don't believe me. Stable API since 2016. Aurelia V2 is in beta now.
The effect you talk about is real - but let me tell you the real differentiator of good and bad technologies is that with a good technology you start liking it when you do not choose it - so the graph does not turn left, or at least very minimally and very temporarily for like a month.
All this shows is that web dev as a whole basically is bad technology - but there are people who got used to it and those who for some reason were all shielded from it a bit and now not anymore.
as a vue developer i can speak about this. I am currently unhappy with the current state of vue. i started using vue with version 2.0 and the options API was perfect. but since v3 they hay move on into a more react hooks approach and i simply think it was done to attract the react crowd. yes. it did improved some areas where the options api lacks but 'reactifying' vue was not the answer
I believe that too. I was trying to convince our startup to use vue 2 instead of react but the devs before me were not interested to even try it out. Few months later of praising vue a few of the new devs gave it a try for a day and they were shocked how easy it was and straightforward. They were wondering how react became so popular when vue 2 has such smaller learning curve. I was a huge evangelist for Vue and Nuxt. Today I do not even bother mentioning the framework. Why should you make people learn a new framework that looks and thinks like react, instead of just using react? The trend of making every framework look like react killed their adoption rate in the end
@@ecodes8498 when i tried to picm my first ui framework i could not wrap my head around react; vue took me just a day to learn. And i agree with you. Frameworks are starting to converge into "just react in other color"
I thought it was just me xd 😂 nuxt still seems simple (even though it's gotten bulky (not in terms of size) compared to nuxt 2)) I think I will just stick to backend instead of full-stack saves me lot of headache
@@Eevee8858 i do full stack and started as a front end developer. i just save me a headache and do backend the old fashion way. a Good Ol' REST API is all i need. i usually use python or if i need the performance, golang
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.
People can't wrap their heads around signals and they are poorly explained and demonstrated (burn the counter example). Sveltekit is by far the easiest and most natural HTMLish framework, but it has taken way too long to transition to the childishly named and poorly documented "runes" (signals - svelte 5) and rich is making everything sound too complex. Getters and setters just don't jive with people. Everything react is just a dumpster fire, period.
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
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.