5 ms·

As a former fullstack developer who has been fulltime on infrastructure for a decade now and reading these comments, not only can I barely follow half of the co

As a former fullstack developer who has been fulltime on infrastructure for a decade now and reading these comments, not only can I barely follow half of the conversations but they're so far removed from the fundamentals of sending data between two places over the wire that I'm extremely satisfied with the career choices I've made. Y'all are inventing your own problems to solve.

downrightmike 2y ago
#BillableHours
- busterarm 2y ago
  To a certain degree that is true, but they're also much more replaceable. Not only have I seen multiple organizations lay off entire frontend groups, but as time goes on I work with more and more people who specialize in only this end of the stack and need people like me to wade in and solve actual problems for them. Under the hood I know how things actually work and I can quickly get up to speed on their issues, whereas it's not always so easy going the other way. Also if I had a dollar for every time I had to help web engineers "figure out" why the Sentry p95s are so high when sending large binary blobs on multiple round trips between Eastern US and Japan, I'd be a rich man.
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 ago
    Different definitions of interactive
    - dmix 2y ago
      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.
      - busterarm 2y ago
        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.
deleted 2y ago
[deleted]

downrightmike 2y ago

#BillableHours

busterarm 2y ago
To a certain degree that is true, but they're also much more replaceable. Not only have I seen multiple organizations lay off entire frontend groups, but as time goes on I work with more and more people who specialize in only this end of the stack and need people like me to wade in and solve actual problems for them. Under the hood I know how things actually work and I can quickly get up to speed on their issues, whereas it's not always so easy going the other way. Also if I had a dollar for every time I had to help web engineers "figure out" why the Sentry p95s are so high when sending large binary blobs on multiple round trips between Eastern US and Japan, I'd be a rich man.

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 ago
  Different definitions of interactive
  - dmix 2y ago
    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.
    - busterarm 2y ago
      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.

deleted 2y ago

[deleted]