3 ms·
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
by willsmith72 2y ago
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
- craftkiller 2y ago> If you don't want an interactive website This is a false dichotomy. Gmail launched in 2004, React launched in 2013. Clearly interactive websites are possible without React.
- willsmith72 2y agoDifferent definitions of interactive
- dmix 2y agoThat'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.
- busterarm 2y agoEnd 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.
- willsmith72 2y ago> End users don't want complex UI Agreed, simplicity can be part of a great UX > 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 Simple tech does not mean simple UX
- busterarm 2y agoAnd 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".
- throwaway2037 2y agoReal 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?).
- busterarm 2y agoAnd 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.