5 ms·

>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

>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?

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?