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

@AbstruseJoker

Күн бұрын

Russian bots

@codeChuck

Күн бұрын

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

@kosmonautofficial296

Күн бұрын

You wanna know how my framework got these scars?

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

@badhreeshmrao609

Күн бұрын

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

@ea_naseer

Күн бұрын

LTS version for frameworks would be great

@EightNineOne

Күн бұрын

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

@vytah

Күн бұрын

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

@go_better

Күн бұрын

Wut da heeeeeee

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

@fischi9129

2 күн бұрын

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

@Salantor

2 күн бұрын

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

@fischi9129

2 күн бұрын

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

@yojou3695

Күн бұрын

react was never simple, it was all a lie

@fischi9129

Күн бұрын

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

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

@Fiercesoulking

2 күн бұрын

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

@hellowill

Күн бұрын

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

@Dipj01

Күн бұрын

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

@ljc6141

Күн бұрын

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

@dorktales254

Күн бұрын

The Unix Philosophy did not ask to be involved /s

everything is getting so f** complex for no reason

@Saviliana

2 күн бұрын

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

@diadetediotedio6918

2 күн бұрын

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

@perc-ai

2 күн бұрын

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

@thegoose2071

Күн бұрын

exactly what i came down here to say

@aayush_dutt

Күн бұрын

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

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

@KingBobXVI

Күн бұрын

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

@gruntaxeman3740

Күн бұрын

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

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

@rijkvanwel

Күн бұрын

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

@jpffinc

Күн бұрын

God damn right 😢

@Salantor

Күн бұрын

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

@shapelessed

22 сағат бұрын

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

@Salantor

22 сағат бұрын

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

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

@joaofrancisco5781

Күн бұрын

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

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

@JonMcLaren

Күн бұрын

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

@ecodes8498

Күн бұрын

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

@michaeljmeyer3

Күн бұрын

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

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

@nwylynko

Күн бұрын

your company fired people and your blaming the tools?

@ojvribeiro

Күн бұрын

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

@Kaihlik

Күн бұрын

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

@peterixxx

Күн бұрын

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

@peterixxx

Күн бұрын

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

HTMX ftw

@xprowler404x

2 күн бұрын

htmx mentioned!

@reverse4646

Күн бұрын

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

@bensavage6389

Күн бұрын

Golang and htmx🎉

@hipertracker

Күн бұрын

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

@betoharres

Күн бұрын

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

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

@andrere__

Күн бұрын

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

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

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

@joaofrancisco5781

Күн бұрын

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

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.

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

@kabukitheater9046

2 күн бұрын

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

@levyroth

Күн бұрын

@@kabukitheater9046 tsoding gang!

@TheOne11111

Күн бұрын

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

@neoqueto

Күн бұрын

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

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

@nwylynko

Күн бұрын

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

@Drayken

Күн бұрын

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

@McTOTHTOMI

Күн бұрын

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

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.

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.

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

@creazy2312

Күн бұрын

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

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

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

@joaofrancisco5781

Күн бұрын

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

complexity.

@fischi9129

2 күн бұрын

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

@dfuzerz

Күн бұрын

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

@fischi9129

Күн бұрын

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

@Dipj01

Күн бұрын

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

@go_better

Күн бұрын

Yeah. And worse - undocumented or poorly documented complexity.

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.

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

@advertslaxxor

Күн бұрын

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

@shapelessed

Күн бұрын

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

@-Gnarlemagne

Күн бұрын

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

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)?"

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.

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

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

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

@tomfancode

Күн бұрын

Then, why not Astro?

@JhonQuenano

Күн бұрын

@@tomfancode no one use it. thats the reality

@bohdanvinter6929

Күн бұрын

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

@user-qq7yc1qp8z

Күн бұрын

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

@user-qq7yc1qp8z

Күн бұрын

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

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

@test-rj2vl

Күн бұрын

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

@diamondkingdiamond6289

Күн бұрын

@@test-rj2vl facts

@carlosabreu5012

Күн бұрын

@@test-rj2vl exactly

@gruntaxeman3740

Күн бұрын

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

@peterixxx

Күн бұрын

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

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

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

@smoked-old-fashioned-hh7lo

Күн бұрын

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

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

@JoRyGu

Күн бұрын

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

@hejloldetermig3850

Күн бұрын

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

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

@noobgamer7034

Күн бұрын

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

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

@infantfrontender6131

Күн бұрын

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

@smoked-old-fashioned-hh7lo

Күн бұрын

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

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.

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

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.

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

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

@msmeraglia

Күн бұрын

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

@drevan1138

Күн бұрын

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

@orderfromchaos663

21 сағат бұрын

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

@msmeraglia

16 сағат бұрын

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

@msmeraglia

15 сағат бұрын

@@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

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

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

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.

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.

Astro is still going strong.

@gabrielkime6597

Күн бұрын

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

@EightNineOne

Күн бұрын

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

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.

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.

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.

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!

Because it should have been just jQuery in the first place

@porrapatcpe20

Күн бұрын

555+

@Kwazzaaap

Күн бұрын

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

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.

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.

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

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...

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

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

@infantfrontender6131

Күн бұрын

Yeah, Elixir with Phoenix is great. Also Gleam.

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.

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.

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

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

Frontend overall sucks because the whole ecosystem is driven by people who don't know what they are doing.

@KingBobXVI

Күн бұрын

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.

@nikomitk8091

Күн бұрын

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.

@ea_naseer

Күн бұрын

They are experimenting with the population

@Dipj01

Күн бұрын

​​@@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.

@joaofrancisco5781

Күн бұрын

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 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.

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.

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

really cool interview process

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

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.

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 💀💀

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.

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

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.

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.

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

@SilvestreVivo

16 сағат бұрын

Totally agree. Frontend developers are turning into holligans.

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

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

@Kwazzaaap

Күн бұрын

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

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

@uiuxaidesign

Күн бұрын

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

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.

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

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

@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.

I made the right move sticking to angular, it sucked for ages but it’s actually pretty decent right now. I still hate frontend, but I don’t hate the framework anymore lol

Great differentiation between different types of devs. If you can work in a framework that you didn't choose, you are more likely to be able to work in a framework you can choose, even if that choice changes. The more adaptable you are, ironically by abstracting waway from frameworks that abstract away from low level, the more likely you are to have a good career.

I guess im just imune to the "outside of my interest scope" issue since im just interested in learning new stuff. I feel like the only thing i really enjoy is seeing my improvement or being competent with the thing im working on. So the only time when im not enjoying my work is when im working on an ancient project that is infested with complexity for no reason.

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.

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

Your channel is a great source to watch to actually get a better dev.

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

@Pandazaar

Күн бұрын

just use htmx if that's the case

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.

RSC is a mistake. if server was the goal all along we might as well not left rails in the first place

@Tackgnol

Күн бұрын

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 :/.

@joaofrancisco5781

Күн бұрын

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

Its because developers have worked with the "new" technologies now for a few years. The hype and new car smell wears off, end of the day its all just tools and its all just for a job

front end frameworks should have nothing to do with the server

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

Great analysis, thanks.

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

Guys what's that diagramming tool he's using? I absolutely love how simple and streamlined that looks and wanna try it myself

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

Spot on. And finding work right now is so hard... it sucks

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.