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 ?
Rails gets it right with a Hotwire IMO.
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.
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.
The frontend is just HTML/CSS and there are many templating languages that can be used. Any competent front-end dev should be able to handle this.
> "reality shows"
What reality exactly?
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.
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.
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.
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.
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.
If you step out of the JS ecosystem (especially as it relates to server-side code), you'll still find a _lot_ of SSR.
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.
There is no reason any of that should be the case for a client side rendered app these days if good people build it.
But getting good people in any trade is a perennial problem.
lots of things to do when your data is a js object.
