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.
I took it upon myself to contact few software solution companies to rewrite the tool in a modern language and add few features.
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.
After proceeding with one of the companies, the end result was slow, very hard to maintain and every new feature was very highly priced.
We're in a worse situation than we were.
Was is a bad selection of technology for the specific use case ?
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...
With server side rendering you have to reload the whole page everytime
Someone must have lied to you or forgot to explain WebSockets.
Before WebSockets existed, some of us would use a hidden background frame to load server rendered code with a simple "onload" script to move it to the forground replacing only the portion that needed updating.
Maybe someone lied to you... With websockets you have to keep the connection open, so it would be great to build a chat but not so much for a rich web application...
I've wanted to try this, but that connection drop issue sounds like a deal killer when serving page data when compared with ajax polling. How does it handle connection failure? I've worked on event based software for desktop/mobile where the best case was to detect the connection drop on the client side then show a "reconnecting" message while it tries to regain it's websocket.
It usually sounds easy to implement, but comes with more edge cases than you'd expect.
Connection drops have not been as big a deal as I would have expected. But Blazor takes care of that for client side detection, automatic reconnecting, and providing hooks for showing a basic "connecting" UI. There's not a lot you have to implement yourself - the websocket transport is largely abstracted away (unless you specifically want to dig around in there).
That said, I've polished off some of the rough edges with some additional handling. For example, if the user is not directly interacting with the app right at that second of a connection drop, I won't immediately show a loading indicator, so there is no visible difference in the app UI (it just looks like everything is still fine). If the connection reconnects before they interact with it again, they'd never even know it dropped, if it doesn't I then show the loading indicator (which appears after a second or two in any case if the connection is taking longer to reconnect).
If you can cope with the slightly different paradigm of an always connected socket, there are huge upsides to using this framework, and the dev loop can be very fast with hot reloading etc.
Blazor is the UI framework, the underlying connection is actually handled by SignalR which uses several transports from WebSockets (by default) to server-sent events and long-polling.
The Blazor server framework and JS already handle connection drops automatically but you can also add your own logic (like forcing a page refresh if it takes too long).
You certainly do not need to build out an entire SPA or use React to reload part of a page just to swap in some HTML or load something asynchronously in the background.
"That is not only slower but it also feels slower to the user"
Not always the case and in many cases, server side rendering is totally fine and has been for decades. We need to stop suggesting that only 1 solution is correct. SPAs have a place but plenty of use cases can do fine with old school server side renders.
I think SPA were cool and with all the frameworks, it became even cooler to just do more client side work BUT don't forget that there are plenty of studies now that have shown that SPAs are not always the correct and magical answer and in many cases they are actually slower.
Phoenix Liveview and the many other copied featuresets in other web frameworks are sending dom diffs over a websocket connection where a tool like morphdom will render only the necessary changes to the page.
This sort of architecture for static rendering is a big deal because it gives live page updates in a way that is SEO friendly and significantly less complex for development than SPAs are.
Node/React/VueJS SSR apps are a benefit to the user and do no such thing. SSR for React uses your heavyweight servers to pre-render the initial HTML. Thereon it's an SPA again, it's just seeded with the SSR results. In-fact, if the client determines the seed data for state/html can't be used it will be abandoned and the client will render by itself. This can happen when your state model isn't intact or if you have differing versions of client and server. You can have certain modules entirely render on the backend by choice but it's not mandatory.
> 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.
this is not true, and if the collective "full stack" community believes this, I feel like I suddenly have a very good understanding of why websites, and more generally the web tech stack itself, sucks so much these days.
HackerNews, the site you're reading right now, uses server-side rendering. Even for voting. And yet it's incredibly fast and more usable than most SPAs. I'm sure you've also used StackOverflow at some point, which is another incredibly fast and responsive SSR site.
There are also many "partial" update mechanisms from XHR/fetch + innerHTML to slim frameworks like AlpineJS/HTMX to newer SSR live rendering like Blazor/LiveView/Hotwire.
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.
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.
At risk of being that guy on HN, this looks like the kind of thing that you would run and generate a static html and always use the same css.
If you're not happy with the perl tool, I'd run it to get all the HTML, then build a new tool in your favorite language that reads through the same source material and generates similar HTML (you can fix stuff you don't like as you go along, but don't change too much if the goal is to just get it done). I'd give an experienced developer about a week, or an average intern a month or three, assuming there's some hidden complexity, but not too much.
I'm not surprised software solutions companies aren't going to bid on a project that's 40 hours of work. And that you got someone to build a monstronsity instead.
Definitely feels that way. I would choose Rails today because its an older technology with a proven track record.
Companies tend to go with hype technologies because thats what developers want to learn and so there are more hiring possibilities, I suppose.
I'm not sure this personal assertion holds any water. Think about it for a second. You need to have a front-end, and you have to pick your tech stack. You know all you need is to render a nice page with some user interaction support and some automation. You have a small team of front-end developers to pull that off.
What are you going to pick?
Is it a good idea to force upon your team a full stack tech stack which forces front-end developers to develop and deploy backend code just to see a basic html+JavaScript page load?
Do you need to bother about Java/python/ruby/PHP/whatever just to have a button showing up in a browser?
Or is it simpler to just let your frontend team deploy their html+JavaScript resources in a file server and just get rid of any server development from their equation?
> 99% of web applications don’t need to be SPA.
Meanwhile, reality shows that close to 100% of web applications don't need to be dynamic HTML/server-side rendered colossal apps, and are better off as SPAs.
You mention "frontend team", "server development", "backend code"... But it's all just programming, we are all just programmers (or problem solvers). We can use HTML today, Python tomorrow, and SQL on Fridays. You can learn K8s during spring, and focus on Go during winter time. On summer better to improve your Pinia skills, while on autumn one should read SICP. Christmas time is for bash, though.
Unfortunately, "modern" IT companies do make the distinction between "frontend" programmers, "backend" programmers, etc. They do this not because it's better for us (the programmers), but because it's cheaper for them. If you care about your career, do not specialize. On the other hand, if you only care about your job, then sure go ahead and become a "frontend" (or "backend") master.
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.
If you step out of the JS ecosystem (especially as it relates to server-side code), you'll still find a _lot_ of SSR.
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.
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.
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.
I took it upon myself to contact few software solution companies to rewrite the tool in a modern language and add few features.
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.
After proceeding with one of the companies, the end result was slow, very hard to maintain and every new feature was very highly priced.
We're in a worse situation than we were.
Was is a bad selection of technology for the specific use case ?