Not really. The whole point of ssr alongside react 19/rsc is exactly abstracting the idea of "sending data between two places". You're sending html and removing waterfalls by moving data fetches to be as early as possible
If you don't want an interactive website, sure, just do everything on the server. That's a fine decision. Most of us work on apps where interactivity is a must
Real question: Does modern Gmail use a web framework, like React? My assumption: Gmail has been reimplemented multiple times over the years to adapt to web app changes, but the end user feels very little difference (except speed?).
And Gmail is still absolutely dog shit at performing basic features that have been table stakes for email clients since the 1990s. Specifically mass moving/deleting/filtering emails.
Every company I work at that uses G-Suite has me begging for Outlook even though I haven't worked with Windows professionally in over 15 years.
That's really the distinction the whole "just use HTML + serverside" crowd glosses over.
As soon as you have the need for complex UI interfaces (anything beyond a multi-select box and modals) in the browser, which almost every serious SaaS app requires at some point, you're going to need complex JS components.
I still think its crazy to use React/Vue beyond very isolated components of functionality and 100% simple server side should be the default unless absolutely necessary. But that's why the frontend industry is already moving to 'islands' of complex JS that is SSR by default.
That said, there still seems to be a high burden of adoption of SSR "islands", where you have these complex frameworks like Rewind/Next that still assume React/Vue as the composition of server side views instead of just pieces of the page.
Which is probably why so many sites end up with a TON of JS views that are unneeded. Because frontend devs are in their own world/dev enviornment. We really need React/Vue SRR+hydration that blends well into Rails/Python/etc frameworks without needing to commit heavily.
End users don't want complex UI interfaces, they want to use your product to find value as quickly as possible. You can have a crayon drawing interface as long as things make sense and there isn't friction from using the product.
Some UI gets this but often I find that most does not and that's the most common complaint that I hear from company to company..."you have the most advanced product but I need to take a two month course to figure out how to use it".
Customers really just want to buy your product, do nothing and get money and the closer you can get to delivering on that experience, the better.
You will always get more value from building APIs and integrations with other products than you will from putting options in the hands of users, but the big players in industry know this and build big moats intended to keep you out rather than improve everyone's products and their customers happiness. The problem is as workers in this industry we've taken the money and been good soldiers rather than demand and enforce open standards that would benefit our day-to-day and society at large.
I haven't even started in on the darker side of UI/UX like dark patterns and "engagement". It's not like "Sam's Pizza Shop" or any other small (or even medium) business needs some super complicated UI/UX and building that out for them would leave them worse off. Complicated JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers and even then you have the problems from the last paragraph. IMO if you choose to work on frontend and perpetuate all this behavior, you're part of the problem.
For ex our company routes phone calls and needed routing system that had 3 layers deep of hierarchical organization, reordering, sorting, weighting, grouping etc.
You could have done all of those with a new page load every time, or spread out into individual static pages, but that'd take 10x longer for the user. I built something that did all of that in a box that fit into one screen and one page load, and only 1 ajax request for autocomplete search box.
Some things just demand 'desktop style' complex browser UIs that server side simply can't provide...
Which is why every serious company that makes $$ uses it. Backend devs like to pretend they can throw the baby out with the bath water and call it day, then deliver poor UX because they limit themselves artificially, just because some people abuse JS.
None of what you did requires vite or nextjs and all of the tooling that comes with all of that.
And then in three years when the undermaintained bit of software needs to be updated the entire landscape has changed in the JavaScript world 4x over already and the tooling needs to be entirely redone along with the desired change.
Again, nobody is saying "you don't need JavaScript". We're saying that the way you folks are going about it is Hell's Treadmill.
At least if I have a languishing, old, unrebuildable bit of code on the server side, I can find some exploit to make it run my code changes without modifying any of the original code :D
> JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers
Definitely not. All it takes is a few comboboxes, date/time pickers, or literally anything wanting client state, to deliver a FAR better UX using js than pure html. If you tried building the kind of experience expected by today's consumers without js, you would know. People have very little patience for mediocrity on the web
And every single fancy UX JS tooling to provide those features utterly fails to do so in a way that's compatible with screen readers to be usable by people with visual impairments. Things like fly-out menus can be completely unusable by people with tremors.
ADA lawsuits against websites are massively on the rise (I worked in the early stages of WCAG compliance and helping people seek to bring such lawsuits).
You don't need all that fancy shit to deliver something that works and every time you go overboard with it you're alienating someone...
Edit: Also, wth? Every browser supports showPicker() and you can control and style the crap out of that without pulling components and frameworks into the mix. Nobody's saying don't use JS at all here. You don't need teams of engineers, components and a whole frontend build toolchain to put forms on a basic website. THAT is the complaint here. Not "caveman think JavaScript bad".
There are excellent options for building accesible stuff in the frontend world nowadays. If somebody is building something that is not accessible, the issue is not with the tooling
If you don't want an interactive website, sure, just do everything on the server. That's a fine decision. Most of us work on apps where interactivity is a must