4 ms·

The reason the web changes so fast, and there are so many rewrites, is the same reason a puzzle whose pieces don't fit together keeps getting shifted around and

The reason the web changes so fast, and there are so many rewrites, is the same reason a puzzle whose pieces don't fit together keeps getting shifted around and restarted. People are looking for a satisfying non-leaky abstraction to build upon and they don't find it with web technologies. They get close, but those last few pieces never quite fit, and we lack the power to reshape the pieces, so we tear out all the pieces and try again. Maybe this next time we'll find a better way to fit them together.

blacksmith_tb 1y ago
Developers certainly are prey to that impulse, but management tends to want ROI... Rewriting existing apps / services / etc. that work and have been refined over time is usually not a money-maker (unless they can't scale, say). But it is good for PMs and PdMs to say "my team built Z in just two months! (which does do exactly what Y did, but we lost the guy who wrote that...)"
- anon7000 1y ago
  And that’s why React is the dominant framework in companies, and frameworks are either passion projects from open source developers (like Svelte), or from big tech, which has the resources for it (FB & React, Google & Angular, MS & Blazor)
- array_key_first 1y ago
  Rewriting apps is a huge money maker. You need pretty much constant UI churn and product churn or consumers move on. This isn't the case necessarily with B2B, which is why we see a lot more "legacy" (aka stable) applications.
jchmbrln 1y ago
This is insightful. I remember thinking after the first generation of SPA frameworks like Backbone and Ember and—somewhat later—AngularJS that maybe the second generation (React, Vue, etc.) would get it all sorted out and we'd arrive at stability and consensus. But that hasn't happened. The next generation was better in some ways, worse in a few, and still not quite right in many others. Of course I hear plenty of people complaining that apps on top of hypertext is a fundamental mistake and so we can't expect it to ever really work, but the way you put it really made it click for me. The problem isn't that we haven't solved the puzzle, it's that the pieces don't actually fit together. Thank you.
- emseetech 1y ago
  Resolution is in design not engineering. Instead of trying to tireless work around the web as a sort of “broken mobile”, design with its strengths instead. The difficulty is finding designers who understand web fundamentals.
- switz 1y ago
  Frontend web development is effectively distributed systems built on top of markup languages and backwards compatible scripting languages. We are running code on servers and clients, communicating between the two (crossing the network boundary), while our code often runs on millions of distributed hostile clients that we don't control. It's inherently complex, and inherently hostile. From my view, RSC's are the first solution to acknowledge these complexities and redesign the paradigms closer to first principles. That comes with a tougher mental model, because the problem-space is inherently complex. Every prior or parallel solution attempts to paper over that complexity with an over-simplified abstraction. HTMX (and rails, php, etc.) leans too heavily on the server, client-only-libraries give you no accessibility to the server, and traditional JS SSR frameworks attempt to treat the server as just another client. Astro works because it drives you towards building largely static sites (leaning on build-time and server-side routing aggressively). RSCs balance most of these incentives, gives you the power to access each of them at build-time and at run-time (at the page level or even the component level!). It makes each environment fully powerful (server, client, and both). And manages to solve streaming (suspense and complex serialization) and diffing (navigating client-side and maintaining state or UI). But people would rather lean on lazy tropes as if they only exist to sell server-cycles or to further frontend complexity. No! They're just the first solution to accept that complexity and give developers the power to wield them. Long-term, I think people will come to learn their mental model and understand why they exist. As some react core team members have said, this is kind of the way we should have always built websites-once you return to first principles, you end up with something that looks similar to RSCs[0]. I think others will solve these problems with simpler mental models in the future, but it's a damn good start and doesn't deserve the vitriol it gets. [0] https://www.youtube.com/watch?v=ozI4V_29fj4 https://www.youtube.com/watch?v=ozI4V_29fj4
  - 1y ago
binary132 1y ago
Clearly what we need is more, faster automated code generation.
zenmac 1y ago
>People are looking for a satisfying non-leaky abstraction to build upon and they don't find it with web technologies. They get close, but those last few pieces never quite fit, and we lack the power to reshape the pieces, so we tear out all the pieces and try again. Maybe this next time we'll find a better way to fit them together. Also keep in mind the web standard puzzle is also changing all the time to try make the puzzle to fit better while developers are designing abstractions to catch up. That how you get XMLHttpRequest -> ajax -> axio -> fetch and history.replaceState situation. In general SPA has pushed web towards not so archiving friendly place. And PWA != SPA
- MrJohz 1y ago
  I think you're mixing some things up there. The history of making HTTP requests in the browser has only been two APIs: XMLHttpRequest -> fetch. Fetch is an upgraded version of XMLHttpRequest with a promise-based API and better async/streaming support. Ajax was a word used to describe the technique of making http requests in the browser, and axios is a third party library that wraps different APIs on different platforms to provide a unified interface. These were never separate browser APIs.
fouc 1y ago
You seem to be conflating javascript with web technologies. So many other web tech doesn't shift nearly as much as the javascript space does.

blacksmith_tb 1y ago

Developers certainly are prey to that impulse, but management tends to want ROI... Rewriting existing apps / services / etc. that work and have been refined over time is usually not a money-maker (unless they can't scale, say). But it is good for PMs and PdMs to say "my team built Z in just two months! (which does do exactly what Y did, but we lost the guy who wrote that...)"

anon7000 1y ago
And that’s why React is the dominant framework in companies, and frameworks are either passion projects from open source developers (like Svelte), or from big tech, which has the resources for it (FB & React, Google & Angular, MS & Blazor)
array_key_first 1y ago
Rewriting apps is a huge money maker. You need pretty much constant UI churn and product churn or consumers move on. This isn't the case necessarily with B2B, which is why we see a lot more "legacy" (aka stable) applications.

jchmbrln 1y ago

This is insightful. I remember thinking after the first generation of SPA frameworks like Backbone and Ember and—somewhat later—AngularJS that maybe the second generation (React, Vue, etc.) would get it all sorted out and we'd arrive at stability and consensus. But that hasn't happened. The next generation was better in some ways, worse in a few, and still not quite right in many others. Of course I hear plenty of people complaining that apps on top of hypertext is a fundamental mistake and so we can't expect it to ever really work, but the way you put it really made it click for me. The problem isn't that we haven't solved the puzzle, it's that the pieces don't actually fit together. Thank you.

emseetech 1y ago
Resolution is in design not engineering. Instead of trying to tireless work around the web as a sort of “broken mobile”, design with its strengths instead. The difficulty is finding designers who understand web fundamentals.
switz 1y ago
Frontend web development is effectively distributed systems built on top of markup languages and backwards compatible scripting languages. We are running code on servers and clients, communicating between the two (crossing the network boundary), while our code often runs on millions of distributed hostile clients that we don't control. It's inherently complex, and inherently hostile. From my view, RSC's are the first solution to acknowledge these complexities and redesign the paradigms closer to first principles. That comes with a tougher mental model, because the problem-space is inherently complex. Every prior or parallel solution attempts to paper over that complexity with an over-simplified abstraction. HTMX (and rails, php, etc.) leans too heavily on the server, client-only-libraries give you no accessibility to the server, and traditional JS SSR frameworks attempt to treat the server as just another client. Astro works because it drives you towards building largely static sites (leaning on build-time and server-side routing aggressively). RSCs balance most of these incentives, gives you the power to access each of them at build-time and at run-time (at the page level or even the component level!). It makes each environment fully powerful (server, client, and both). And manages to solve streaming (suspense and complex serialization) and diffing (navigating client-side and maintaining state or UI). But people would rather lean on lazy tropes as if they only exist to sell server-cycles or to further frontend complexity. No! They're just the first solution to accept that complexity and give developers the power to wield them. Long-term, I think people will come to learn their mental model and understand why they exist. As some react core team members have said, this is kind of the way we should have always built websites-once you return to first principles, you end up with something that looks similar to RSCs[0]. I think others will solve these problems with simpler mental models in the future, but it's a damn good start and doesn't deserve the vitriol it gets. [0] https://www.youtube.com/watch?v=ozI4V_29fj4 https://www.youtube.com/watch?v=ozI4V_29fj4
- 1y ago

binary132 1y ago

Clearly what we need is more, faster automated code generation.

zenmac 1y ago

>People are looking for a satisfying non-leaky abstraction to build upon and they don't find it with web technologies. They get close, but those last few pieces never quite fit, and we lack the power to reshape the pieces, so we tear out all the pieces and try again. Maybe this next time we'll find a better way to fit them together. Also keep in mind the web standard puzzle is also changing all the time to try make the puzzle to fit better while developers are designing abstractions to catch up. That how you get XMLHttpRequest -> ajax -> axio -> fetch and history.replaceState situation. In general SPA has pushed web towards not so archiving friendly place. And PWA != SPA

MrJohz 1y ago
I think you're mixing some things up there. The history of making HTTP requests in the browser has only been two APIs: XMLHttpRequest -> fetch. Fetch is an upgraded version of XMLHttpRequest with a promise-based API and better async/streaming support. Ajax was a word used to describe the technique of making http requests in the browser, and axios is a third party library that wraps different APIs on different platforms to provide a unified interface. These were never separate browser APIs.

fouc 1y ago

You seem to be conflating javascript with web technologies. So many other web tech doesn't shift nearly as much as the javascript space does.