Who here wants to work on a minimally-maintained PHP project from 2011?
Nobody?
In 10 years from now, this JavaScript crap will be just like that PHP project is perceived today. Except it will be much worse, because the PHP project didn’t have dependency hell like this. At least the PHP project wasn’t also your phone app.
I like to work on old legacy systems from the 00s. They are all relatively simple without too many dependancies. Code is often spaghetti, but its often also not having 20 layers of abstraction. Nowadays code is so damn abstract with layers of enheritance, delegates, messaging etc. Very difficult to understand apart from the makers.
Give me old code. I like it.
The future is already here. As a tech lead, consulting for one of my clients, I have to oversee the maintenance of three JS-heavy projects (backend too) that are imploding under their own weight of technical debt. And a good part of that are dependencies.
Those are actually easy. The ones using the first versions of React with custom state management and weird conventions however, are a different story.
Those, and debugging jQuery UI problems.
I digress but in my career of using every technology possible, the pain I had debugging a huge (HUGE) jQuery UI project could perhaps only be matched by trying to make NHibernate (Hibernate ORM but for .NET) behave in some complicated (but CRUD after all) data-heavy projects.
Yes. Perhaps not in the public web but there are so many internal tools using it. It has a lot of issues but the average jQuery UI project is so old that some users will actually complain if you fix bugs because it breaks their workflow (speaking from personal experience)(there was an xkcd for this I think).
NHibernate, the codebase must have been ancient. What is surprising it is still actively being maintained but the documentation examples look just as old and alien.
For a long time I worked at a client driven development shop, and we picked up lots of codebases from other developers. There were apps in PHP, Java, .NET. All of them were buried in technical debt. You can take any programming language and build a project buried in technical debt.
What is the alternative to dependencies if you are making a highly interactive web app? Large/old apps being a pain to maintain isn't something unique to javascript.
The same as in other languages. Avoid dependencies whenever you can, and only add them when really needed. And only if you are fairly certain that the dependency a) will still be there in a few years time and b) developers take backwards compatibility seriously.
> Who here wants to work on a minimally-maintained PHP project from 2011?
In a more serious note: I don't think the language matters that much when working in legacy codebases. What matters the most is the (usually undocumented) business logic that one needs to decipher based on the code. I'll take any day of the week a documented PHP project from 2011 than any Go/Rust/TS/Kotlin undocumented project of 2024.
I couldn’t make it through. It’s funny but also stressed me out.
I feel like the front end web dev community is going through its equivalent of the microservices/kubernetes madness that overtook the server devs in the past few years and they’re making everything 10x more complex than it needs to be.
Like, server side React frameworks like Nextjs solve a problem that never should have existed in the first place — that people were using React to build websites, when React wasn’t designed for that problem. It was designed for SPAs. And so with server components and Nextjs they’ve reinvented PHP. It’s like, we could have skipped a five year step and used PHP/Rails/whatever.
>And so with server components and Nextjs they’ve reinvented PHP.
Except worse. There will be PHP-7 monoliths out there running on Apache until the heat death of the universe. Try updating a Node project that hasn't been touched in two years.
To be fair, a lot of those PHP monoliths aren't even using Composer, and regardless updating them would probably be painful as well.
That being said, just installing old Node.js projects can be painful, unfortunately. It's got a lot better with newer NPM versions that use lock files by default, but it still leaves a lot to be desired. Often updating the Node project is the only way to get it running, because somewhere in the stack someone broke semver, or your OS is newer and some native extension does not compile on the new version, or you need to use an ancient Node.js to run it because it depended on some behavior that was deprecated and removed in the 5 Node.js versions released since the project was written.
A particularly notable thing recently is that newer Node.js doesn't support older crypto types, breaking most dev servers built for older Node versions. This has been a pain lately.
The joke is just that JavaScript is silly and over-complicated and build on a billion different libraries that update every 30 seconds, right? IMO it would be funnier if it were about half as long.
The weird cuts are part of the gimmick. I think part of the joke is how stressful it is to listen to.
>that people were using React to build websites, when React wasn’t designed for that problem. It was designed for SPAs.
React generated HTML on the server from the very start with Node.js. You always had some form of hydration, even before there was an explicit API and process for it.
It was built by Facebook... to build a highly utilized and extremely popular website. React had pretty popular examples and integration with RoR and Python, and of course PHP.
Why are you just making up history to fit preconceived notions?
Idk if this is charitable. To gp's point: isn't the website of Facebook a SPA? The overall point isn't that React et al have no place, its just that they became so prominent from the changing face and market of the web itself, that somewhere a long the way we forgot it could be any way else. To the point that it is now molding js development in general.
If Facebook’s website can be characterized as a SPA then wouldn’t most websites fit the definition of a SPA? Except the most static of websites like blogs.
It’s not making up history. There is a documentary[0] on the history of React where the people involved in its creation and use at Facebook described it this way:
> Bolt [a predecessor of React] was basically more or less Facebook's implementation of a client-side MVC. [It was] not a tool belt, it was truly an application development framework. Something designed and meant to build complicated interactive rich apps and was being used to build pretty complicated very real products at Facebook at the time. […] As the product itself got more complex and as we added more engineers to the team, we didn't hit a wall but it started to get really, really hard to make changes. And that was around the time that Jordan [Walke, creator of React] was on the ads team and he's like ‘I wonder, there's got to be a better way’. […] Jordan was a product engineer at the time, working on ads, and ads has one of the most complicated pieces of UI across all of Facebook at the moment. On the ads team they were hitting the limits of what you can do without React complexity wise. […] Jordan had a lot of very interesting ideas around how you could take what we had done in Bolt and make it easier for it to scale with people's ability to understand large applications.
As the GP said, React was explicitly designed to solve the problem of having many engineers writing large, complex, client-side applications. It was not designed for building simple web sites.
There is no need to imbue meaning into quotes or history when there is a clear, well defined timeline with striking examples of how React was used to generate static website all the way from its initial release.
And the complaints hold less and less water each year.
In 2015, people were still complaining about trying to build stable layouts using CSS. Congratulations, we now have Grid and Flexbox (and subgrids just stabilized!) but they still complain. They complain about having to write custom Javascript (which is slow and has to be maintained) so functionality gets pushed into CSS and they complain that CSS is getting too complicated.
There were people complaining about the "Javascript framework of the week". Then React took over the space, and now they complain about how everything's written for React and we should just use htmx and Svelte. I thought we didn't want something new every week!
There were people complaining that Webpack was slow and required too much up-front configuration. Then Vite came out (which is fast and only requires minimal configuration) and they went back to complaining about having to learn new things.
The best explanation I can come up with is that most organizations must just treat FE as an afterthought and assign people to do that work who have no experience or interest in it.
From my point of view, a lot of trouble could be saved if it were a priority in browser development to reduce the number of libraries and layers necessary to build things like SPAs.
There’s been a lot of movement in this direction for CSS which is great, but it needs to happen in HTML and JavaScript too. Just a few cycles of implementing popular libraries as base browser functionality and adding better widget primitives would do wonders to reduce complexity and bloat.
Agreed. I’ll take a more controversial stance that I’ve said here before: CSS/HTML are part of the problem and the community should have invested in proper UI/rendering frameworks a long time ago that weren’t designed around the quirks of HTML and CSS. Building an accessible canvas-based UI with a React-like API would make a lot more sense for SPAs, and maybe other types of websites too.
Not really. These APIs are useful, but they’re still too primitive to make a dent in library usage. To do that you need things like highly capable “batteries included” (yet easily customizable) widgets and the more generally applicable parts of React (or similar) implemented as browser APIs, so for the majority use case few or no third party libraries or layers are necessary.
The end goal here would be to have a basic reactive UI development toolkit complete with a full spread of ready to use widgets with nothing but a plain text editor and a browser.
That won’t meet everybody’s needs of course, but even those still using third party libs would benefit since things like React could be lightweight “sugar” libraries built on the browser APIs instead of hulking behemoths with a fractal spiral of dependencies.
> if it were a priority in browser development to reduce the number of libraries and layers necessary to build things like SPAs.
But this is the antithesis of FE culture. When FE culture spun up there was a lot of mocking of javascript devs as not "real" devs. I think they felt the need to reinvent CS so that they could show they were legitimate. They never really recovered from that.
It’s not the same as the microservicesageddon (and yeah we were part of that too).
What I’ve been noticing is backend becoming incredibly slow and kludgy and there’s a want for FE for work around it. Since you can’t bleed a rock, we’re creating these incredible and evil machinations across everything but the server->db layer in order to get the page to load as quickly and efficiently as possible.
Frankly, we should just dump the servers and let the FE query the db directly. We’d probably do it fucking better anyway.
Frontend only devs who know the first thing about efficient queries are exceedingly rare.
Solutions like Firebase that do exactly what you are describing are extremely expensive and just as limited in terms of functionality, and properly designing security for them is quite difficult. For quite awhile I was on that train until I just couldn't justify the price and limitations, and my frontend stack to deal with those problems became excessively complex.
If you could pre-sign the queries to prevent abuse (user edits to queries making them potentially slow) then IMHO it would be a nice idea in a load of cases. Datasette actually does this, though that’s aimed at a very specific subset of cases.
Even if react is made for SPAs (which is a murky definition anyway) there are many parts of react that make general website development better. For example dependency management is way easier and maintainable with npm/react than manually importing scripts in the right order the traditional way. Achieving high levels of interactivity is also much easier for the same reason.
Just because react was built for one things doesn't inherently mean its wrong to use it for other things.
React wasn’t designed for SPAs. It was, in fact, originally derived from server-side technology. And whatever criticism is due both Next and RSC, solving “React for websites” isn’t one of them. Both are targeting highly dynamic web applications in which both the server and the client are implicated in that dynamism—and in which a high degree of sharing between them is beneficial.
You might also object to that being a problem which should exist, but it’s a distinctly different problem to discuss. And in discussing it, the “React to build websites”criticism is mostly meaningless.
I’m amused trying to guess whether this was downvoted because someone disagrees with the factual claim about React’s origins, or with the point that criticism shouldn’t be based on falsehoods about the object of that criticism.
I had an epiphany the other day experimenting with react-spring making some animations - Flash was much simpler, easier, and more performant in doing the exact same thing 30 years ago. The inevitable solution to the JS framework wars is the return of Flash.
I do trunk based development. i have a script named "c" that does `git add --all && git commit -m "progress" && git push` and another one named "p" that does `git push prod`. apart from that i use effect-ts and express with kita.js and a few small libs and do persistence with pg. the rest is written by me and somehow i don't feel the need to add anything to it. not everybody needs k8s, microservices, and all that crap that will fail at the worst possible moment.
This was really fun. I dunno if t3/t4 are based in anything specific but most of this is surprisingly sharp, while also being ridiculous.
What surprises me most is that we have tried so many things, except most apps are a handful of bundles, and even more wildly, almost all work happens on the main thread still! React's vdom has given us a very nice & performant Immediate Rendering (vs Retained Rendering) view, and we've dabbled with unidirectional data flow, signals, whatever graphql is, and other abstractions, but the core "where and how does work happen" model hasn't been much iterated on.
Now we are very busy figuring out React Server Components and doing other page rehydration works, which indeed can shift much of the work out of main thread. But the client has been somewhat stuck, somewhat patterned into monolithic main thread patterns forever, and few have tried to push beyond that. Even with wasm happening, it still seems like few are using web workers to divide up where the work happens, which feels like it could be such a giant win for keeping the page crisp & responsive, for thickening the client effectively.
I thought he was making stuff up - "t3 stack vs t4 stack". But about 2 minutes in, I realized that I'd heard of a few things that he's talking about so I looked it up and they're real!
I think it's possible everything he's saying is true, more or less. LOL
74 comments
[ 5.0 ms ] story [ 143 ms ] threadhttps://www.youtube.com/watch?v=6KefznccsY0&t=87s
Nobody?
In 10 years from now, this JavaScript crap will be just like that PHP project is perceived today. Except it will be much worse, because the PHP project didn’t have dependency hell like this. At least the PHP project wasn’t also your phone app.
Those, and debugging jQuery UI problems.
I digress but in my career of using every technology possible, the pain I had debugging a huge (HUGE) jQuery UI project could perhaps only be matched by trying to make NHibernate (Hibernate ORM but for .NET) behave in some complicated (but CRUD after all) data-heavy projects.
In a more serious note: I don't think the language matters that much when working in legacy codebases. What matters the most is the (usually undocumented) business logic that one needs to decipher based on the code. I'll take any day of the week a documented PHP project from 2011 than any Go/Rust/TS/Kotlin undocumented project of 2024.
Similar video. I've seen their channel described as "the best workplace videos I can never show my coworkers."
I feel like the front end web dev community is going through its equivalent of the microservices/kubernetes madness that overtook the server devs in the past few years and they’re making everything 10x more complex than it needs to be.
Like, server side React frameworks like Nextjs solve a problem that never should have existed in the first place — that people were using React to build websites, when React wasn’t designed for that problem. It was designed for SPAs. And so with server components and Nextjs they’ve reinvented PHP. It’s like, we could have skipped a five year step and used PHP/Rails/whatever.
Except worse. There will be PHP-7 monoliths out there running on Apache until the heat death of the universe. Try updating a Node project that hasn't been touched in two years.
That being said, just installing old Node.js projects can be painful, unfortunately. It's got a lot better with newer NPM versions that use lock files by default, but it still leaves a lot to be desired. Often updating the Node project is the only way to get it running, because somewhere in the stack someone broke semver, or your OS is newer and some native extension does not compile on the new version, or you need to use an ancient Node.js to run it because it depended on some behavior that was deprecated and removed in the 5 Node.js versions released since the project was written.
A particularly notable thing recently is that newer Node.js doesn't support older crypto types, breaking most dev servers built for older Node versions. This has been a pain lately.
The weird cuts are part of the gimmick. I think part of the joke is how stressful it is to listen to.
React generated HTML on the server from the very start with Node.js. You always had some form of hydration, even before there was an explicit API and process for it.
It was built by Facebook... to build a highly utilized and extremely popular website. React had pretty popular examples and integration with RoR and Python, and of course PHP.
Why are you just making up history to fit preconceived notions?
It's responding concisely to the point OP was trying to make. Their "point" or perspective is not accurate and it's certainly disingenuous.
>To the point that it is now molding js development in general.
I'm not following this statement. Can you expound on this?
> Bolt [a predecessor of React] was basically more or less Facebook's implementation of a client-side MVC. [It was] not a tool belt, it was truly an application development framework. Something designed and meant to build complicated interactive rich apps and was being used to build pretty complicated very real products at Facebook at the time. […] As the product itself got more complex and as we added more engineers to the team, we didn't hit a wall but it started to get really, really hard to make changes. And that was around the time that Jordan [Walke, creator of React] was on the ads team and he's like ‘I wonder, there's got to be a better way’. […] Jordan was a product engineer at the time, working on ads, and ads has one of the most complicated pieces of UI across all of Facebook at the moment. On the ads team they were hitting the limits of what you can do without React complexity wise. […] Jordan had a lot of very interesting ideas around how you could take what we had done in Bolt and make it easier for it to scale with people's ability to understand large applications.
As the GP said, React was explicitly designed to solve the problem of having many engineers writing large, complex, client-side applications. It was not designed for building simple web sites.
[0] https://www.youtube.com/watch?v=8pDqJVdNa44
Here's Pete Hunt talking about static webpages with React, in a best practices talk from 2013: https://youtu.be/x7cQ3mrcKaY?t=1528
There is no need to imbue meaning into quotes or history when there is a clear, well defined timeline with striking examples of how React was used to generate static website all the way from its initial release.
In 2015, people were still complaining about trying to build stable layouts using CSS. Congratulations, we now have Grid and Flexbox (and subgrids just stabilized!) but they still complain. They complain about having to write custom Javascript (which is slow and has to be maintained) so functionality gets pushed into CSS and they complain that CSS is getting too complicated.
There were people complaining about the "Javascript framework of the week". Then React took over the space, and now they complain about how everything's written for React and we should just use htmx and Svelte. I thought we didn't want something new every week!
There were people complaining that Webpack was slow and required too much up-front configuration. Then Vite came out (which is fast and only requires minimal configuration) and they went back to complaining about having to learn new things.
The best explanation I can come up with is that most organizations must just treat FE as an afterthought and assign people to do that work who have no experience or interest in it.
There’s been a lot of movement in this direction for CSS which is great, but it needs to happen in HTML and JavaScript too. Just a few cycles of implementing popular libraries as base browser functionality and adding better widget primitives would do wonders to reduce complexity and bloat.
https://github.com/Flipboard/react-canvas
React is the Simpsons of web tech (Referring to the "Simpsons did it meme" if that wasn't clear).
There are a lot of interesting renderers for react, some of them are even maintained: https://github.com/chentsulin/awesome-react-renderer
The end goal here would be to have a basic reactive UI development toolkit complete with a full spread of ready to use widgets with nothing but a plain text editor and a browser.
That won’t meet everybody’s needs of course, but even those still using third party libs would benefit since things like React could be lightweight “sugar” libraries built on the browser APIs instead of hulking behemoths with a fractal spiral of dependencies.
But this is the antithesis of FE culture. When FE culture spun up there was a lot of mocking of javascript devs as not "real" devs. I think they felt the need to reinvent CS so that they could show they were legitimate. They never really recovered from that.
What I’ve been noticing is backend becoming incredibly slow and kludgy and there’s a want for FE for work around it. Since you can’t bleed a rock, we’re creating these incredible and evil machinations across everything but the server->db layer in order to get the page to load as quickly and efficiently as possible.
Frankly, we should just dump the servers and let the FE query the db directly. We’d probably do it fucking better anyway.
Solutions like Firebase that do exactly what you are describing are extremely expensive and just as limited in terms of functionality, and properly designing security for them is quite difficult. For quite awhile I was on that train until I just couldn't justify the price and limitations, and my frontend stack to deal with those problems became excessively complex.
Just because react was built for one things doesn't inherently mean its wrong to use it for other things.
You might also object to that being a problem which should exist, but it’s a distinctly different problem to discuss. And in discussing it, the “React to build websites”criticism is mostly meaningless.
turned out to be prophetically true in many many ways.
It's actually valibot. Unwatchable.
is a great line
What surprises me most is that we have tried so many things, except most apps are a handful of bundles, and even more wildly, almost all work happens on the main thread still! React's vdom has given us a very nice & performant Immediate Rendering (vs Retained Rendering) view, and we've dabbled with unidirectional data flow, signals, whatever graphql is, and other abstractions, but the core "where and how does work happen" model hasn't been much iterated on.
Now we are very busy figuring out React Server Components and doing other page rehydration works, which indeed can shift much of the work out of main thread. But the client has been somewhat stuck, somewhat patterned into monolithic main thread patterns forever, and few have tried to push beyond that. Even with wasm happening, it still seems like few are using web workers to divide up where the work happens, which feels like it could be such a giant win for keeping the page crisp & responsive, for thickening the client effectively.
I think it's possible everything he's saying is true, more or less. LOL
t3: https://create.t3.gg
t4: https://t4stack.com
must have missed that joke