[inapis]

Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be handled by SSR. The real kicker happens when people start demanding the ability to generate their own reports by supplying their parameters. They want the ability to write their own queries. They want WYSIWYG building blocks. They want to define their own templates.

Very quickly we are in a territory well done with react than with Hugo.

Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.

[chipotle_coyote]

I would say rather that my argument hinges on the assumption that the majority of web sites in the world are not the primary products of the companies that produce them. I would argue, in fact, that you're looking at web sites from a very particular lens. An absolutely valid lens, to be sure, but a particular one. nonetheless.

If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?

Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.