6 ms·

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 microservic

by dimal 2y ago

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.

k__ 2y ago
Yes, I also have the impression that the whole SSR story is a step backwards. Especially with the prevalence of CDNs nowadays.
ramesh31 2y ago
>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.
- rezonant 2y ago
  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.
triyambakam 2y ago
I think the editing style is stressful. It could be funnier if it were slower paced.
- dclowd9901 2y ago
  It actually reminded me a lot of Jonathan Krisel’s directorial/editing style (Portlandia). I think both this video and that show are hilarious.
- bee_rider 2y ago
  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.
whoknowsidont 2y ago
>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?
- beepbooptheory 2y ago
  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.
  - whoknowsidont 2y ago
    >Idk if this is charitable. 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?
  - jacobsimon 2y ago
    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.
- csnover 2y ago
  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. [0] https://www.youtube.com/watch?v=8pDqJVdNa44 https://www.youtube.com/watch?v=8pDqJVdNa44
dgellow 2y ago
People have been complaining about this since at least 2015
- mhink 2y ago
  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.
jwells89 2y ago
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.
- HumblyTossed 2y ago
  > 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.
- jacobsimon 2y ago
  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.
  - stevenpetryk 2y ago
    Canvas is a blank slate to screen readers though.
    - jacobsimon 2y ago
      Yeah that’s what I meant by accessible, agree it’s a problem today
  - egeozcan 2y ago
    > Building an accessible canvas-based UI with a React-like API would make a lot more sense for SPAs https://github.com/Flipboard/react-canvas 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).
belter 2y ago
Like a comment on YouTube says: "Don't write this down...It will change next week..."
dclowd9901 2y ago
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.
- rezonant 2y ago
  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.
- dunk010 2y ago
  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.
deleted 2y ago
[deleted]
Xeronate 2y ago
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.
eyelidlessness 2y ago
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.
- eyelidlessness 2y ago
  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.
beau_g 2y ago
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.

by dimal 2y ago

k__ 2y ago

Yes, I also have the impression that the whole SSR story is a step backwards. Especially with the prevalence of CDNs nowadays.

ramesh31 2y ago

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

rezonant 2y ago
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.

triyambakam 2y ago

I think the editing style is stressful. It could be funnier if it were slower paced.

dclowd9901 2y ago
It actually reminded me a lot of Jonathan Krisel’s directorial/editing style (Portlandia). I think both this video and that show are hilarious.
bee_rider 2y ago
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.

whoknowsidont 2y ago

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

beepbooptheory 2y ago
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.
- whoknowsidont 2y ago
  >Idk if this is charitable. 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?
- jacobsimon 2y ago
  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.
csnover 2y ago
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. [0] https://www.youtube.com/watch?v=8pDqJVdNa44 https://www.youtube.com/watch?v=8pDqJVdNa44

dgellow 2y ago

People have been complaining about this since at least 2015

mhink 2y ago
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.

jwells89 2y ago

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.

HumblyTossed 2y ago
> 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.
jacobsimon 2y ago
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.
- stevenpetryk 2y ago
  Canvas is a blank slate to screen readers though.
  - jacobsimon 2y ago
    Yeah that’s what I meant by accessible, agree it’s a problem today
- egeozcan 2y ago
  > Building an accessible canvas-based UI with a React-like API would make a lot more sense for SPAs https://github.com/Flipboard/react-canvas 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).

belter 2y ago

Like a comment on YouTube says: "Don't write this down...It will change next week..."

dclowd9901 2y ago

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.

rezonant 2y ago
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.
dunk010 2y ago
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.

deleted 2y ago

[deleted]

Xeronate 2y ago

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.

eyelidlessness 2y ago

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.

eyelidlessness 2y ago
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.

beau_g 2y ago

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.