For an internal tool at our company that served a website with register schema of SOC (derived from IPXact XML's) we used an old tool written in perl that was very hard to maintain.<p>I took it upon myself to contact few software solution companies to rewrite the tool in a modern language and add few features.<p>All the companies dissmised server side rendering and suggest a server - client scheme based on NodeJS on the server and React / Angular on the client.<p>After proceeding with one of the companies, the end result was slow, very hard to maintain and every new feature was very highly priced.<p>We're in a worse situation than we were.<p>Was is a bad selection of technology for the specific use case ?
Hype. That is why. 99% of web applications don’t need to be SPA. And the majority of the other 1% probably need just a fraction of their app as SPA.<p>Rails gets it right with a Hotwire IMO.
It is, now. NextJS, Gatsby, Remix, Astro, Deno's Fresh are all frameworks that prioritize server side rendering in the server-Javascript world, rather than client side single page apps from a few years ago.
There are great progressive server-side rendering libraries out there these days, but most companies are shoddy and have no reason to care about their craftsmanship. They make money either way, and lots of it. If you really care about quality you build it yourself, it's that simple.
With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data. That is not only slower but it also feels slower to the user. With SPAs you only reload the part of the page that has some data changing which loads asynchronously in the background, so it's not only faster, it also feels faster. If your new implementation is worse maybe the company you hired didn't do a great job...
Server side rendering is still used a _lot_. Wordpress, for instance, is a double digit percentage of the web. It's not the JS package du jour though, so it doesn't get as much hype.<p>If you step out of the JS ecosystem (especially as it relates to server-side code), you'll still find a _lot_ of SSR.
What are SOC applications like? Generally for rich web applications with a lot of interactivity, you want to do client side rendering. Interactive apps can be deceptively complex to build and you really want to hire the right people for it. The spectrum of web developers you can find in the market is very wide which doesn't make it easy to find the right people. It also doesn't help that consultancies generally want to stick with the hottest, bleeding edge tools to stay relevant in the market and to motivate developers to come work for them.
You certainly can write snappy ergonomic apps that do the SPA thing (the server/client scheme you mentioned). It is very popular for consumer facing apps. Unfortunately SPA's are a little bit more complicated, and it sounds like they made a mess of it. While I don't know the details, it very possible that your internal tool could have been a much more straightforward SSR app.
The slow, hard to maintain and high priced are the features of a terrible consultancy.<p>There is no reason any of that should be the case for a client side rendered app these days if good people build it.<p>But getting good people in any trade is a perennial problem.
Because people write code in terribly slow languages so they would have to have many more servers which is more expensive if they used server-side rendering.