4 ms·

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) framewor

Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks! Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness. Or go best-of-all-worlds if you happen to know Elixir/Phoenix. But don’t continue the descent into RSCs, now matter how many people tweet about it. These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! Stay sane instead, ship actual products quickly, and earn that lambo!

ramesh31 3y ago
>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is always there, but if that's your concern just build a traditional server templated site. The vast majority of SPAs have zero need for SSR and the complexity that it introduces.
- rattlyy 3y ago
  "very, very good reasons" bullshit, you do not need to turn landing pages into 30MB react bundles with 20 morbillion node modules
  - CuriouslyC 3y ago
    That's more an indictment of node's ecosystem and package management than anything else. Having helper libs for almost everything along with multiple versions of the same modules bundled is just a bit ridiculous. With functional deduplication across versions and a more robust standard library so people didn't need to add 50 NPM modules to do anything that would drop by an order of magnitude. Beyond that, bundle splitting with lazy loading is very helpful, but it requires knowing that you can do it and some additional work on top of baseline bundling. Then you're nearly at parity with static sites in terms of individual page download requirements for the first view (assuming react/etc are cached CDN libs rather than bundled) but each subsequent view of that page is much smaller, faster and more responsive than static html.
  - billythemaniam 3y ago
    There are definitely use cases where you want a render loop in web, pioneered by React, instead of traditional approaches for a web application. I think the pendulum swung too far and too many sites are being built as a SPA, but there are absolutely some "very good reasons" to build a SPA with React. As always, it depends on the use case.
- sodapopcan 3y ago
  The flip side is that most sites, and even "apps", don't need to be SPAs.
- the_gipsy 3y ago
  > We moved away from server rendered UI for very, very good reasons. In some cases, it's clear that it's a webapp and a SPA is warranted. In some cases, it should just have been a website, but yet there were organizational reasons to use react - producing technologically bad results in detriment of the users.
  - CuriouslyC 3y ago
    You can have a "static" site that renders react components to non-root nodes in order to provide interactivity if needed.
    - satvikpendem 3y ago
      That is literally what RSCs are, so unlike most of this thread, I am glad to start using them instead of using some template language like in PHP or Python.
- CuriouslyC 3y ago
  Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.
  - Draiken 3y ago
    Citation needed. 99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat. No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.
    - CuriouslyC 3y ago
      I didn't make any statement about what an application is, or isn't, or what percentage of the internet is in fact applications. That being said, things like Figma exist and wouldn't if the web was only static pages, so there's a compelling argument to be made for the existence of SPAs.
    - billythemaniam 3y ago
      > 99% of apps are basic CRUD apps Citation needed.
    - Ambolia 3y ago
      >99% of apps are basic CRUD apps You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.
      - Draiken 3y ago
        So because a few forms need validations you turn your whole application into a JS hellhole? That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app. Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowned upon that practice because it meant a ton of requests for the client, so we bundled everything. Now, new JS frameworks send small JS bundles as you open each page, lol. Why not have micro React (or whatever framework makes sense) pieces in pages that need it for the interaction? Plus, server-side form validation is extremely easy to do and also removes duplication. Its been a solved problem for over a decade. I'd even argue back-then it was harder since browsers were much worse and basic elements were lacking. Today you add a `required` attribute in an input and it simply works. I stand by it. Aside from a few exceptions, most apps have no business being SPAs. They go on to emulate a subpar version of a MPA, and people have to resort to absurdities like these server components to achieve the same experience we've had for 20+ years with server-side rendering.
- damethos 3y ago
  > We moved away from server rendered UI for very, very good reasons Can you please list your reasons?
cultofmetatron 3y ago
> Or go best-of-all-worlds if you happen to know Elixir/Phoenix. THIS... unless you're building something that absolutely requires a full blown progressive rich frontend app, (95% of you don't), liveview will do all the thins using serverside components with minimal jaavscript. Not just that, you'll have a serverside thread dedicated to that user which allows you to actively push changes to the user's frontend without you having to write explicit javascript handlers.
hathawsh 3y ago
Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never really caught on. (Hint: hidden component boundaries mean hidden complexity!) Meanwhile, the "server-rendered HTML" and "client-rendered HTML" camps are both doing quite well. I consider myself quite lucky to have both options at my disposal for every web project. I hope the work on RSC doesn't muddy React's support for pure client-rendered apps. 1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
- Steltek 3y ago
  CORBA is one of the few technologies purposefully designed to violate both the entirety of the Fallacies of Distributed Computing and the CAP theorem. It's a case study in awful ideas, week long troubleshooting nightmares, and angry customers. You don't hear about it for the same reason it's impolite to talk about your top 10 favorite snuff films with customers. There is no situation where it's appropriate and anyone flirting with the notion needs to be dismissed before they doom your company. CORBA is pure evil and you should not speak its name so lightly.
  - sonofhans 3y ago
    Preach it.
- marcosdumay 3y ago
  > So why doesn't everyone use it? Not to detract from your point, but nobody uses it because when network administrators everywhere started closing all the ports except for 80 (for "security!"), everybody moved to SOAP, that uses the port 80. And then, since the SOAP consortium doesn't have enough competency to create a full data transfer format, starting from XML and contained in a couple thousands pages of docs, in about a decade people said "enough!" and moved into what is commonly called REST. The problem with component boundaries is there, but it's not really what CORBA did.
mmcclure 3y ago
> Or go best-of-all-worlds if you happen to know Elixir/Phoenix. Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dashboard, that latter situation quickly became basically our entire dashboard and it simply made sense to move to a full SPA taking advantage of the API we were exposing to customers anyway. This was 2016, so LiveView didn't exist at the time, but I'm still not sure I'd make a different decision for that product today. The blog post is talking about the application that powers our public marketing site, which has a pretty different set of needs, but figured I'd throw it out there that we use and love Elixir/Phoenix! :)
- anonyfox 3y ago
  Thanks for sharing the Elixir love! More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!
  - satvikpendem 3y ago
    It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.
    - melx 3y ago
      You forgot to also say Rust is faster.. if all languages were very similar there's not much point in having those.
      - satvikpendem 3y ago
        That's fine, that's why I continue to use Rust and not Elixir.
    - jpbastyr 3y ago

ramesh31 3y ago

>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is always there, but if that's your concern just build a traditional server templated site. The vast majority of SPAs have zero need for SSR and the complexity that it introduces.

rattlyy 3y ago
"very, very good reasons" bullshit, you do not need to turn landing pages into 30MB react bundles with 20 morbillion node modules
- CuriouslyC 3y ago
  That's more an indictment of node's ecosystem and package management than anything else. Having helper libs for almost everything along with multiple versions of the same modules bundled is just a bit ridiculous. With functional deduplication across versions and a more robust standard library so people didn't need to add 50 NPM modules to do anything that would drop by an order of magnitude. Beyond that, bundle splitting with lazy loading is very helpful, but it requires knowing that you can do it and some additional work on top of baseline bundling. Then you're nearly at parity with static sites in terms of individual page download requirements for the first view (assuming react/etc are cached CDN libs rather than bundled) but each subsequent view of that page is much smaller, faster and more responsive than static html.
- billythemaniam 3y ago
  There are definitely use cases where you want a render loop in web, pioneered by React, instead of traditional approaches for a web application. I think the pendulum swung too far and too many sites are being built as a SPA, but there are absolutely some "very good reasons" to build a SPA with React. As always, it depends on the use case.
sodapopcan 3y ago
The flip side is that most sites, and even "apps", don't need to be SPAs.
the_gipsy 3y ago
> We moved away from server rendered UI for very, very good reasons. In some cases, it's clear that it's a webapp and a SPA is warranted. In some cases, it should just have been a website, but yet there were organizational reasons to use react - producing technologically bad results in detriment of the users.
- CuriouslyC 3y ago
  You can have a "static" site that renders react components to non-root nodes in order to provide interactivity if needed.
  - satvikpendem 3y ago
    That is literally what RSCs are, so unlike most of this thread, I am glad to start using them instead of using some template language like in PHP or Python.
CuriouslyC 3y ago
Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.
- Draiken 3y ago
  Citation needed. 99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat. No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.
  - CuriouslyC 3y ago
    I didn't make any statement about what an application is, or isn't, or what percentage of the internet is in fact applications. That being said, things like Figma exist and wouldn't if the web was only static pages, so there's a compelling argument to be made for the existence of SPAs.
  - billythemaniam 3y ago
    > 99% of apps are basic CRUD apps Citation needed.
  - Ambolia 3y ago
    >99% of apps are basic CRUD apps You run into the edges of pure HTML forms on day 1 of the project if you have to listen to any feedback or requests from the users.
    - Draiken 3y ago
      So because a few forms need validations you turn your whole application into a JS hellhole? That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app. Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowned upon that practice because it meant a ton of requests for the client, so we bundled everything. Now, new JS frameworks send small JS bundles as you open each page, lol. Why not have micro React (or whatever framework makes sense) pieces in pages that need it for the interaction? Plus, server-side form validation is extremely easy to do and also removes duplication. Its been a solved problem for over a decade. I'd even argue back-then it was harder since browsers were much worse and basic elements were lacking. Today you add a `required` attribute in an input and it simply works. I stand by it. Aside from a few exceptions, most apps have no business being SPAs. They go on to emulate a subpar version of a MPA, and people have to resort to absurdities like these server components to achieve the same experience we've had for 20+ years with server-side rendering.
damethos 3y ago
> We moved away from server rendered UI for very, very good reasons Can you please list your reasons?

cultofmetatron 3y ago

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix. THIS... unless you're building something that absolutely requires a full blown progressive rich frontend app, (95% of you don't), liveview will do all the thins using serverside components with minimal jaavscript. Not just that, you'll have a serverside thread dedicated to that user which allows you to actively push changes to the user's frontend without you having to write explicit javascript handlers.

hathawsh 3y ago

Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never really caught on. (Hint: hidden component boundaries mean hidden complexity!) Meanwhile, the "server-rendered HTML" and "client-rendered HTML" camps are both doing quite well. I consider myself quite lucky to have both options at my disposal for every web project. I hope the work on RSC doesn't muddy React's support for pure client-rendered apps. 1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

Steltek 3y ago
CORBA is one of the few technologies purposefully designed to violate both the entirety of the Fallacies of Distributed Computing and the CAP theorem. It's a case study in awful ideas, week long troubleshooting nightmares, and angry customers. You don't hear about it for the same reason it's impolite to talk about your top 10 favorite snuff films with customers. There is no situation where it's appropriate and anyone flirting with the notion needs to be dismissed before they doom your company. CORBA is pure evil and you should not speak its name so lightly.
- sonofhans 3y ago
  Preach it.
marcosdumay 3y ago
> So why doesn't everyone use it? Not to detract from your point, but nobody uses it because when network administrators everywhere started closing all the ports except for 80 (for "security!"), everybody moved to SOAP, that uses the port 80. And then, since the SOAP consortium doesn't have enough competency to create a full data transfer format, starting from XML and contained in a couple thousands pages of docs, in about a decade people said "enough!" and moved into what is commonly called REST. The problem with component boundaries is there, but it's not really what CORBA did.

mmcclure 3y ago

> Or go best-of-all-worlds if you happen to know Elixir/Phoenix. Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dashboard, that latter situation quickly became basically our entire dashboard and it simply made sense to move to a full SPA taking advantage of the API we were exposing to customers anyway. This was 2016, so LiveView didn't exist at the time, but I'm still not sure I'd make a different decision for that product today. The blog post is talking about the application that powers our public marketing site, which has a pretty different set of needs, but figured I'd throw it out there that we use and love Elixir/Phoenix! :)

anonyfox 3y ago
Thanks for sharing the Elixir love! More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!
- satvikpendem 3y ago
  It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.
  - melx 3y ago
    You forgot to also say Rust is faster.. if all languages were very similar there's not much point in having those.
    - satvikpendem 3y ago
      That's fine, that's why I continue to use Rust and not Elixir.
  - jpbastyr 3y ago