[rtpg]

It's actually not how things worked just a few years ago.

How things worked a few years ago: you wrote SSR pages with one set of tools (like Django Template Language), then hooked into it with another set of tools. If your pages are complex enough, you end up with weird brittleness because the "initial page load" is not handled the same way as modifications of that page.

Now it's much closer to using the same set for the initial load and subsequent edits. This is a net win for people working on the frontend, in theory.

The more nuanced thing is that frontend tooling is so lacking in terms of performance, despite being something that theoretically should work very fast. In particular, having a bunch of language tooling written in Javascript is the JS ecosystem's billion dollar mistake IMO.

[manigandham]

Why do you need all that client-side interactivity in the first place? Most interactions can easily be handled with a full refresh, as proven by the very site you're reading this on (hackernews).

Server-side web frameworks even have modern component-based UI templating now, and features like maps can be layered on top as progressive enhancement without this bloated frontend mess.

[mahesh-hegde]

Something like a collaborative document editor or forms with non-trivial logic.

Also, the interface of HN works because of its demographic.

[the_gastropod]

Yep. I think these examples are probably fine for the SPA style approach. What gets me is the other 98% of web apps out there, that are not collaborative document editors, calendars, or the handful of other use-cases where this approach can make some sense. It feels like a lot of complexity that has been cargo-culted into the mainstream.

Much of the "progress" in web development in the past decade feels like it's just fixing problems that only exist because we're building web applications this way. React, Redux, Typescript, Server Side Rendering.. these are solutions to problems we created for ourselves by using an architecture with a dubious value proposition in most of our use-cases.

[DerArzt]

Yeah, anything like what you described are going to be web apps and need all that logic. That being said for the majority of the web (news sites, simple message boards, shopping sites, etc) couldn't they all be rendered on the server?

I have to wonder how much of the client-side rendering framework use is mainly from people forming a cargo-cult around "it's what Facebook does" when at the end of the day what Facebook does is way different from your use case.

By strictly numbers, most engineers don't work at one of those tech giants, but at small firms making CRUD apps that don't really need all that responsiveness.

[rtpg]

"Majority of the web" is _not_ news sites and message boards and shopping sites. It's bank websites, ERP software, various CRMs (granted, like news sites...), time tracking, logistics sofware....

And, importantly, a lot of those websites have complex admin-side backends to deal with a lot of things as well! Of course in those cases you might say that the UX requirements are lower (true), but when you are basically serving as a DB frontend, you want to be able to do things quickly, even on a really bad connection.

There's a lot of cool work into partials for SSR, but React and friends are also very nice because you can build out complex UIs that operate through an API, without having to figure out a bunch of workarounds for stateless HTTP/HTML (form wizards anyone?)

[dgb23]

All those sites have content, which require elaborate, interactive, collaborative editing and reasonably complex, flexible data models. Meaning you’re going to want to re-use much of the work you did for the editing/publishing part and you want those things to be integrated to such a degree that changing and extending things is reasonably ergonomic.

[pjmlp]

That is why for 20 years SSR frameworks have supported components.

[manigandham]

Collaborative editors are the 1% of sites that are actually applications and need a SPA.

But Yelp is nothing like that. What part of the interface is so advanced? It's just a few links and buttons to navigate to pages and submit reviews. A few JS event handlers can handle AJAX/partial updates without an entire React frontend.

There's even stuff like https://alpinejs.dev/ and https://htmx.org/ to make this incredibly easy now.

[rtpg]

Personally I think htmx is an interesting strategy because it unifies the rendering tech on the server (you still gotta be careful to properly scope your incremental changes).

"Advanced forms" come up all the time, and are usually when you have even a bit of non-trivial business logic. For example "if people pick this set of options, show this other option" (but you want to avoid having a form wizard, cuz then you're having to track state across multiple page loads). There's also stuff like in business applications, previewing calculations and the like.

"A few JS event handlers" can handle a lot of tiny things, but many B2B SaaS have a handful of pages with a loooot of these things, and at the end of the day you could have your hacks, or you could try to be principled about loading it.

Though it's also about just finding the right mix, there are people who can architecture their stuff "correctly", completely SSR + some JS flavoring. But it requires having people who are really good at backend and frontend figuring out the right pieces and putting it together. That diligence is hard!

[jaywalk]

More than a few years ago, but ASP.NET WebForms with the AJAX Control Toolkit did this. It was terrible for many reasons, but it did allow you to use one set of tools for everything.

[manigandham]

I started my career with .NET and used/abused the AJAX controls too. Some of those sites are still running today, and still remain fast and responsive and simple to maintain.

The new cutting edge with Blazor is even more impressive and a serious contender for non-JS frontends. Similar advancements with Elixir/Liveview and Ruby/Hotwire

[pjmlp]

Just like JSF frameworks, with Prime being the best one.