Comment by ebiester | Hacker News Reader

Comment by ebiester | Hacker News Reader

Parent Full thread

This is where I think the confusion lies. When I think of the tools that my teams build, they effectively are internal and external tools that happen to use the browser as a platform because nobody was able to converge on a universally-installed tool like java web start. Web applications proliferate because it entirely circumvented the problems of installing software.

The places people are most enamored with SPAs are tools that effectively replace desktop applications. Consider Jira or Trello. These are effectively applications that happen to live in the browser. If you built progressive enhancement on trello, it would effectively mean building a parallel application.

Multiple page applications do not have the ecosystem to make these tools easier to build. I have built these applications before SPAs became the dominant modality and after. The MPA has a long way to go to make this a good experience.

Now I think it's great that content apps are moving away from SPAs. I think the only reason that people did this was to avoid the white flash, frankly, and I'm glad that chrome has solved this. I hope nobody is using react to build their content in 2022.

However, we have a long way to go before MPAs could replace SPAs in web applications. (And frankly, that time would have been better spent in building a tool that is truly fit for purpose rather than overloading the browser DOM, but I fear that ship has sailed.)

I think there is a mismatch between the types of web content that the general public most interacts with and the types of web content which tend to have lots of development resources devoted to them. The ratio of SWEs to users is much, much higher for niche (typically B2B or internal business line) applications, which often require a fair amount of interactivity and custom logic. Whereas the vast majority of random web content used by the general public probably can just be hosted as static sites or server-side rendered apps with better performance and lower cost. HN then just reflects the underlying demographics of the industry and has a disproportionate number of people who work on niche applications where SPAs are still the more appropriate tool.

Which makes sense given the economics. Consumer facing content is generally free to users and funded by ads so the dev costs need to be amortized across more content, which tends toward a lower touch, more scalable approach like static pages where there isn’t much if any custom logic on any given page of content. Businesses on the other hand are willing to fork over cash directly to solve their problems so you get higher touch, more custom solutions where SPAs are relatively more useful.

Also software engineering by its very nature automates routine tasks, reducing their costs and manual complexity dramatically over time to the point that a SWE isn’t needed to carry them out. So none of us work on static sites because at this point it doesn’t take a highly skilled engineer to set up, host, and scale one. One day SPAs and cloud native and k8s and all the latest fads may reach the same level of simplicity, and we will all be working on tuning hyper parameters on ML models or whatever else becomes the de facto cutting edge for the field.

> I hope nobody is using react to build their content in 2022.

Unfortunately they are. People are using React for things that aren't apps.

I mean why wouldn’t you? Degenerate React — a mostly static content “chrome” replacing the “layout.html.erb” and a component to render content from an API based entirely on the route replacing “article.html.erb” still is way faster than your average site. Slower then the equivalent SSR but ehh.

I can't even imagine a person being "enamored" by Jira.

Reply on news.ycombinator.com