Every Framework Sucks Now

128,650
60
Published 2024-06-30
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 🙏

All Comments (21)
  • @dj_256
    You either die a well-loved framework, or live long enough to get to the left side
  • @SteveBoyer10
    While your point about forced use is a good one, I’m convinced our collective frustration is more due to the complexity all these frameworks are introducing. React used to be simple: “change state, component re-renders. Go have fun.” Now there is SO much more to think about. It’s just not fun anymore.
  • @shapelessed
    I feel like the answer is much more simple than what is being talked about here. It's the sheer fatigue and pressure caused by the frameworks that want to compete with each other on how many features they have and how much market they can fit in. The amount of information an average dev has to handle these days is 2-3 times more than just 5 years earlier. Everybody is just god damn tired.
  • @Strammeiche
    Was mostly backend and infrastructure before. Dabbeled a bit in frontend this year. Everything I heared is true, frontend is madness. The dependencies, the rate of breaking changes, the massive Overkill and Performance waste.
  • @inexistente
    everything is getting so f** complex for no reason
  • @icusmilingAZ
    I would like to see an interview where the prospective employee and the lead would sit side by side and look at PR's. The potential employee can see what a shitshow the codebase is, and the employer can see how well the dev can understand the shit codebase, and what things they would flag if they were doing the PR.
  • @rookandpawn
    i was friends with the inventor of browserify who told me frameworks are meant to die. like writing them is basically waiting for them to expire. hence, small tools, reliable, composed, piped, and focused. unix philosophy.
  • @piff57paff
    Fun story: I recently tried to learn next.js and their tutorial points to a starter that NPM fails to resolve the dependencies for (as it's using some specific revision of next.js and react RCs). If already the tutorial is broken, you know the state of the ecosystem.
  • @saltylelele
    I've recently committed to building a project in completely vanilla JS, only using TS with bun as ebserver. I've enjoyed building it a 100x more then using any framework for this. Everything is just simpler, and it just works.
  • @noobgamer7034
    The real problem is when the companies do not consider upgrading the project. For example if the project is in vue 2.6. And after a year client comes back and wants to add new features, but due to the old code base, we cannot move forward as much. At this point management does not care about whether it was built with Vue 2, they just want the changes to be implemented as soon as possible.
  • @FireDragon91245
    Bruh im a backend engineer like Databases, Business Logic, APIs and im still watching this
  • @bigyikes7354
    All of the frameworks update too quickly. My company let go half of the web engineers and now we have more codebases than engineers to maintain. I don't care about new features when I just want to keep the lights on and avoid having to deal with security vulnerabilities. Engineering real products is complicated enough without your dependencies changing how they work every 1.5-2y.
  • @mementomori8856
    maybe it's because they change every damn second, the thing I learn today becomes irrelevant tomorrow and it's exhausting man
  • @davidl.e5203
    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.
  • @CottidaeSEA
    I think the answer is quite easy. Devs just want to write their code and have it work. That is getting harder to do, more configuration bullshit, more framework changes, split between server components and client components that isn't clearly explained, etc. People just want a no bullshit solution.
  • @maccsguitar
    Backend does well with their basic standard libs for ages and the maintenance cost for old stuff is minimal. Frontend frameworks break down to 1000 dependencies each and there are breaking changes every half a year in most of the libraries in use, no wonder newcomers find it ridiculous. At the same time we have legislation tightening on secure software development practises. Absolute madness.
  • @azixy_web
    Abandoning webpack and embracing next js as replacement ? Why not talking about vite ..
  • @T33K3SS3LCH3N
    I've been using Vue for a while now and I love having both APIs. Especially because they're well documented and Vue itself is so simple, so the switch to Composition really isn't that hard. I started off extending an old project at work with Vue where I couldn't change the build process, which can only be done with Options API. I love that this is even possible. And when I started a bigger new project, I went with the Vue/Quasar/Vite bundle (adding basic UI components and simple dev server/build tooling) and the Composition API which is just awesome to work with.
  • @LongJourneys
    I'm so sick of how complicated things keep getting. I loved webdev back in like 2008. Its become progressively more obnoxious since then.