To alleviate this issue we should make a new framework that....
@badhreeshmrao6095 ай бұрын
It’s a never ending cycle, isn’t it! 🙈
@ea_naseer5 ай бұрын
LTS version for frameworks would be great
@EightNineOne5 ай бұрын
Lemme know when it’s ready for me to fork it and add more bloat
@vytah5 ай бұрын
xkcd 927. I didn't even have to look it up.
@go_better5 ай бұрын
Wut da heeeeeee
@dj_2565 ай бұрын
You either die a well-loved framework, or live long enough to get to the left side
@AbstruseJoker5 ай бұрын
Russian bots
@codeChuck5 ай бұрын
In the game of drones, there is no middleground :)
@kosmonautofficial2965 ай бұрын
You wanna know how my framework got these scars?
@chonkyboy35975 ай бұрын
:v sound about right
@SteveBoyer105 ай бұрын
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.
@fischi91295 ай бұрын
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 :)
@Salantor5 ай бұрын
React switching its paradigm like 5 times in the last decade is also a good reason to not like it anymore.
@fischi91295 ай бұрын
@@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
@yojou36955 ай бұрын
react was never simple, it was all a lie
@fischi91295 ай бұрын
@@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?
@shapelessed5 ай бұрын
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.
@rijkvanwel5 ай бұрын
Yeah, good point. As cool as features like RSC etc are, I'm definitely less productive than I was years ago.
@jpffinc5 ай бұрын
God damn right 😢
@Salantor5 ай бұрын
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.
@shapelessed5 ай бұрын
@@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.
@Salantor5 ай бұрын
@@shapelessed Funny, all the frameworks and metaframeworks are sold with DX in mind.
@Strammeiche5 ай бұрын
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.
@KingBobXVI5 ай бұрын
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.
@gruntaxeman37405 ай бұрын
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.
@enkiimuto10415 ай бұрын
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.
@JohnSmith-op7ls5 ай бұрын
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.
@saltylelele5 ай бұрын
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.
@honkhonk80095 ай бұрын
ONG BRO. Seriously its rdiiculous how bloated overcomplex, and midwit-ey that javascript soyslop has become. I just use basic react.
@eleinaedelweiss62155 ай бұрын
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.
@abduladilsunnat24895 ай бұрын
@@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 :)
@gerardonavarro34003 ай бұрын
@@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
@rookandpawn5 ай бұрын
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.
@Fiercesoulking5 ай бұрын
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.
@hellowill5 ай бұрын
Backend frameworks last for years, decades. Why can't frontend be the same? Fucking soydevs.
@Dipj015 ай бұрын
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.
@ljc61415 ай бұрын
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.
@dorktales2545 ай бұрын
The Unix Philosophy did not ask to be involved /s
@piff57paff5 ай бұрын
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.
@inexistente5 ай бұрын
everything is getting so f** complex for no reason
@Saviliana5 ай бұрын
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.
@diadetediotedio69185 ай бұрын
I don't think you know which is a valid reason versus not.
@perc-ai5 ай бұрын
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
@thegoose20715 ай бұрын
exactly what i came down here to say
@aayush_dutt5 ай бұрын
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.
@bigyikes73545 ай бұрын
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.
@nwylynko5 ай бұрын
your company fired people and your blaming the tools?
@ojvribeiro5 ай бұрын
Vue is 10yo and it's still in v3. I don't think it is a rapid changing pace.
@Kaihlik5 ай бұрын
@@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.
@peterixxx5 ай бұрын
@@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.
@peterixxx5 ай бұрын
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.
@icusmilingAZ5 ай бұрын
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.
@JonMcLaren5 ай бұрын
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.
@ecodes84985 ай бұрын
@@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
@michaeljmeyer35 ай бұрын
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.
@tarquin1612344 ай бұрын
@@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.
@noobgamer70345 ай бұрын
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.
@noobgamer70345 ай бұрын
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
@CottidaeSEA5 ай бұрын
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.
@ThePizzabrothersGaming5 ай бұрын
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
@CottidaeSEA5 ай бұрын
@@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.
@LongJourneys5 ай бұрын
I'm so sick of how complicated things keep getting. I loved webdev back in like 2008. Its become progressively more obnoxious since then.
@kabukitheater90465 ай бұрын
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
@levyroth5 ай бұрын
@@kabukitheater9046 tsoding gang!
@w1-w2-w35 ай бұрын
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.
@neoqueto5 ай бұрын
@@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
@NizzyABI5 ай бұрын
Complex for no reason at all anymore.
@maccsguitar5 ай бұрын
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.
@onça_pintuda9995 ай бұрын
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
@lessquo5 ай бұрын
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
@PeterSahanaya3 ай бұрын
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
@mementomori88565 ай бұрын
maybe it's because they change every damn second, the thing I learn today becomes irrelevant tomorrow and it's exhausting man
@JoelBrage5 ай бұрын
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.
@andrere25 ай бұрын
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)
@T33K3SS3LCH3N5 ай бұрын
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.
@sarthikg5 ай бұрын
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-hh7lo5 ай бұрын
most people that are interested in the server would not even consider node an interest. many backend engineers openly mock node. this video is basically maximum copium to avoid harsh truths.
@marcelo-ramos5 ай бұрын
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.
@CulturalArcher5 ай бұрын
@@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
@smoked-old-fashioned-hh7lo5 ай бұрын
@@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.
@azixy_web5 ай бұрын
Abandoning webpack and embracing next js as replacement ? Why not talking about vite ..
@onça_pintuda9995 ай бұрын
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
@TheJunioGG5 ай бұрын
I hate next with all my strength, from the soles of my feet to the last strand of hair on my head
@rikkischulte85705 ай бұрын
vike (formerly vite plugin ssr) is an up and comer here!
@FireDragon912455 ай бұрын
Bruh im a backend engineer like Databases, Business Logic, APIs and im still watching this
@AllemandInstable5 ай бұрын
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
@onça_pintuda9995 ай бұрын
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...
@___Kevin5 ай бұрын
Exactly !
@honkhonk80095 ай бұрын
Litterally the opposite. Frameworks just add unecessary complexity to projects that 90% of the time, prolly dont even need it.
@positiveslip5 ай бұрын
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.
@insiderich73724 ай бұрын
@@positiveslipAny Linux command line user would know, less has always been better than more :)
@badhreeshmrao6095 ай бұрын
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?
@infantfrontender61315 ай бұрын
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-hh7lo5 ай бұрын
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.
@deado72825 ай бұрын
Another problem is that most fe frameworks feel the need to evolve away from the reason most people initially used them.
@Fiercesoulking5 ай бұрын
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
@shadeblackwolf15085 ай бұрын
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.
@honkhonk80095 ай бұрын
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.
@keepfeatherinitbrothaaaa5 ай бұрын
Everything is getting more complex and we're quickly becoming redundant and obsolete. Yeah of course we're fucking miserable.
@hellowill5 ай бұрын
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.
@nwylynko5 ай бұрын
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.
@Drayken5 ай бұрын
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.
@TOTHT0MI575 ай бұрын
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.
@honkhonk80095 ай бұрын
I like C# over java litterally only cus it looks cooler. Java also is kinda old, so I have a bias against it.
@ballerina34832 ай бұрын
I am thinking about switching to backend with java as my main language tbh . Mentally fatigued by this constant unstability on Frontend
@hanes25 ай бұрын
Nuxt still my nr1. Over last two years, things they improved made my life easier so it’s quite nice.
@creazy23125 ай бұрын
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
@lronmate5 ай бұрын
complexity.
@fischi91295 ай бұрын
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...
@dfuzerz5 ай бұрын
@@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
@fischi91295 ай бұрын
@@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)
@Dipj015 ай бұрын
@@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_better5 ай бұрын
Yeah. And worse - undocumented or poorly documented complexity.
@brennan1235 ай бұрын
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.
@OwnnOfficial5 ай бұрын
HTMX ftw
@xprowler404x5 ай бұрын
htmx mentioned!
@reverse46465 ай бұрын
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 😅
@bensavage63895 ай бұрын
Golang and htmx🎉
@hipertracker5 ай бұрын
@@bensavage6389 only for simple case, it's not simpler for more advanced ui. spa with quasar is just simpler
@betoharres5 ай бұрын
@@hipertracker you can even build games with htmx, ffs
@jimmy215845 ай бұрын
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.
@wilmerwalton50895 ай бұрын
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)?"
@honkhonk80095 ай бұрын
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.
@solii015 ай бұрын
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.
@dazraf5 ай бұрын
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.
@daSenfgurke5 ай бұрын
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.
@ericsexton35395 ай бұрын
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
@kolklik5 ай бұрын
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.
@javier.alvarez7645 ай бұрын
@@kolklik what framework you are using now?
@kolklik5 ай бұрын
we've moved to svelte ✌️
@user-qq7yc1qp8z5 ай бұрын
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.
@tomfancode5 ай бұрын
Then, why not Astro?
@JhonQuenano5 ай бұрын
@@tomfancode no one use it. thats the reality
@bohdanvinter69295 ай бұрын
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-qq7yc1qp8z5 ай бұрын
@@tomfancode i already know next and don’t want to spend time learning another framework that does the same thing.
@user-qq7yc1qp8z5 ай бұрын
@@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.
@Murmeltier5 ай бұрын
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.
@tarasturchenko45285 ай бұрын
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
@Salantor5 ай бұрын
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.
@rohan17655 ай бұрын
I don't know who thought we need some FE JavaScript code to do BE, WE DON'T NEED THAT.
@test-rj2vl5 ай бұрын
Server side JS is the biggest accident that happened to the web development industry.
@diamondkingdiamond62895 ай бұрын
@@test-rj2vl facts
@carlosabreu50125 ай бұрын
@@test-rj2vl exactly
@gruntaxeman37405 ай бұрын
@@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.
@peterixxx5 ай бұрын
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.
@levyroth5 ай бұрын
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.
@ballerina34832 ай бұрын
Same thinking about changing my language JS is exhausting
@Salantor5 ай бұрын
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.
@JoRyGu5 ай бұрын
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.
@hejloldetermig38505 ай бұрын
I completely agree. And we're still in the process of migrating from Vue 2 in 2024.
@relaxationtube23885 ай бұрын
Just gonna switch to Laravel so I can sleep better at night and buy a Lambo 😅
@naughtiousmaximus78535 ай бұрын
Laravel mogs 99% of use cases of Javascript.
@theilluminatimember88965 ай бұрын
Adonis.js 🤫
@TesterAnimal15 ай бұрын
@@naughtiousmaximus7853mogs?
@Aleks-fp1kq5 ай бұрын
Making things easier drives abstraction up, and we end up not understanding how things work which leads to copy paste programming.
@advertslaxxor5 ай бұрын
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.
@shapelessed5 ай бұрын
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...
@-Gnarlemagne5 ай бұрын
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.
@mchisolm05 ай бұрын
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.
@OldKing111005 ай бұрын
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.
@lukasmolcic51435 ай бұрын
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
@kittycat7945 ай бұрын
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.
@austincodes5 ай бұрын
I think you hit the nail on the head with the job security part
@NabekenProG875 ай бұрын
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
@drevan11385 ай бұрын
What about devs who chose their stack in 2015 at an enterprise company and now feel stuck with it 9 years later???
@msmeraglia5 ай бұрын
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
@drevan11385 ай бұрын
@@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.
@orderfromchaos6635 ай бұрын
@@drevan1138 You could try a "smooth transition" library like Preact perhaps?
@msmeraglia5 ай бұрын
@@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.
@msmeraglia5 ай бұрын
@@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
@zBrain05 ай бұрын
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.
@SilvestreVivo5 ай бұрын
Totally agree. Frontend developers are turning into holligans.
@naughtiousmaximus78535 ай бұрын
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.
@Khari995 ай бұрын
Hopefully we all just move to Phoenix Liveview one day and live in peace
@infantfrontender61315 ай бұрын
Yeah, Elixir with Phoenix is great. Also Gleam.
@d06murd5 ай бұрын
Same sentiment, sucks that its not picked up by companies to give better job opportunities
@imaron5 ай бұрын
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.
@LionKimbro4 ай бұрын
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.
@rikschaaf27 күн бұрын
13:14 in the .svelte file, instead of going from `let count = 0` to `let count = $state(0)`, couldn't they have gone to `state count = 0` with `state` being a new keyword for .svelte files? I feel that that syntax would clearly specify that you're talking about a reactive state there, instead of a normal variable, without having to wrap all your values in a `$state()` call.
@kabukitheater90465 ай бұрын
RSC is a mistake. if server was the goal all along we might as well not left rails in the first place
@Tackgnol5 ай бұрын
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 :/.
@onça_pintuda9995 ай бұрын
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
@kasper_5735 ай бұрын
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.
@MuhammadFahreza4 ай бұрын
17:26 remix is not existant anymore? why? I thoght shopify bought is some time ago right?
@dotnetapp5 ай бұрын
Hey Theo, I have a small Library (angular :P) which aims to make multi-threading simpler using angular signals, its not public right now i just want to ask where a good place would be to ask for input , ( i think its far from production ready but i also can`t find many ressources about this) Which means im not sure if i am on the right track or shoot myself already in the foot (it works in my own benchmarks exactly as expected). So do you know a good place to ask for input? (planning to make it open-source till the weekend) Edit: sorry for my bad english and greetings from germany :).
@markuseberlein33945 ай бұрын
How much is early enthusiasm and then noticing the downsides of that specific framework later?
@davidl.e52035 ай бұрын
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.
@luizfcavalcanti5 ай бұрын
@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.
@NizzyABI5 ай бұрын
I wonder if this is just a phase or if we will shift back to more based frameworks / more vanilla type of code writing
@alvesvaren5 ай бұрын
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.
@robkom5 ай бұрын
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.
@thegoose20715 ай бұрын
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.
@grink-ii5 ай бұрын
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.
@ws_stelzi795 ай бұрын
The thing with JS - a inherent client side THING - moving to the server certainly feels very wrong for every halfway decent JS dev! JS is for frontend and literally else is for backend. IMO THAT is a good thing and shows how crazy compared to other language ecosystems the JS ecosystem is.
@MrHirenP5 ай бұрын
lol, someone needs to fix how the mouse over works in that opinion/popularity scatter-line plot
@antsmasherjack5 ай бұрын
Astro is still going strong.
@gabrielkime65975 ай бұрын
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.
@EightNineOne5 ай бұрын
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
@PieJee15 ай бұрын
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
@ExtremeTeddy5 ай бұрын
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.
@fueledbycoffee5835 ай бұрын
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
@ecodes84985 ай бұрын
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
@fueledbycoffee5835 ай бұрын
@@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"
@Eevee88585 ай бұрын
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
@fueledbycoffee5835 ай бұрын
@@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
@capability-snob5 ай бұрын
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.
@vvvvvvvvvwv5 ай бұрын
Are there other surveys that do similar sentiment question like this for other ecosystems? I'd like to see if this is just something in the JS ecosystem or something more industry wide
@ignrey5 ай бұрын
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...
@darknezx95425 ай бұрын
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.
@brennan1235 ай бұрын
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.
@TsillALevi5 ай бұрын
Many front-end frameworks are becoming increasingly complex to learn, especially those involving server components or server actions.
@mickomagallanes11855 ай бұрын
It is complex because the paradigm is new, just how jQuery developers are confused when the new JS and SPAs are introduced
@xprowler404x5 ай бұрын
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 💀💀
@lukor-tech5 ай бұрын
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
@Daniel15au5 ай бұрын
tbh I like the idea of moving stuff to the server side where possible, and using htmx. Server side frameworks are much more mature and don't change as quickly.
@ErickRodrCodes5 ай бұрын
My understanding is people learn frameworks rather than foundational knowledge of JS that can help them to avoid this kind of situation. Boot camps focus on framework rather than JS, and this has caused this trend where devs are unable to adapt properly to other frameworks and understand what is happening on the codebase
@shabbirhossain7765 ай бұрын
Why did he mention that "Remix does not exists anymore"? Do anyone have the context? Please share any article or reference for me to look into. Thanks.
@Naton5 ай бұрын
this is such a good take, the diagram Theo drawn was so relatable
@TightyWhities945 ай бұрын
Frontend overall sucks because the whole ecosystem is driven by people who don't know what they are doing.
@KingBobXVI5 ай бұрын
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.
@nikomitk80915 ай бұрын
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_naseer5 ай бұрын
They are experimenting with the population
@Dipj015 ай бұрын
@@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.
@onça_pintuda9995 ай бұрын
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.
@JohnSmith-op7ls5 ай бұрын
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.
@Dmytro-Shcherbyna5 ай бұрын
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.
@Pandazaar5 ай бұрын
just use htmx if that's the case
@shadeblackwolf15085 ай бұрын
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
@JozefKonradPlata5 ай бұрын
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.
@l3lackoutsMedia5 ай бұрын
My first interview that landed me a job was from the perspective of a specialist actually funnily enough but a specialist on something i wrote during education.
@carlmeyer965 ай бұрын
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!
@witchmorrow5 ай бұрын
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
@rikkischulte85705 ай бұрын
the line people have about vue 2 being the peak is very similar to those who pined for angular 2.x versions when react took the stage, and were overwhelmed by angular 3 which also introduced many to early typescript which was much more complex when it first came out. and vue2 is like a simpler angular 2, with how presentational logic and attaching event handlers worked for example
@erickoehli5 ай бұрын
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.
@Norinot15 ай бұрын
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.....