5 ms·

I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be. I’m sure they’ll claim it’s differ

by Osiris 3y ago

I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be. I’m sure they’ll claim it’s different now because… hydration or something or another. As a former PHP developer who spent a lot of time both working on server rendered pages and converting server rendered pages to be API/JS (render the core in HTML+JS and use APIs with two way data binding to update the UI), I can’t believe we’re going back that way, but with wildly more complicated patterns than we had before.

sam0x17 3y ago
Yeah, I've witnessed the entire arc also as an ex-ex-ex PHP developer from the early 00s, and I literally recall the original justification for this whole exodus that lead to the creation of React and a slew of other things was "jquery bad". I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. Maybe I'd still be doing frontend stuff and not burying my head as far into backend as humanly possible while I wait for a workflow that doesn't require a package.json and a 3 GB node_modules folder so I can make the same frontend widget I could make with 50 lines of js in 2007.
- ytoawwhra92 3y ago
  > I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. We kind of did (well, 2013), but it just wasn't backed by a massive developer marketing effort.
quickthrower2 3y ago
SSR is different I think because it can perform better, but given the state of most sites on the internet I think 2003 style rails is sufficient for most sites. And I haven’t met a JS-ey UI I have enjoyed using as much as a vanilla HTML one for most online stuff (drawing, games, 3D etc. excepted).
- sam0x17 3y ago
  And turbolinks on modern rails apps literally feels like those fancy JS-ey UIs anyway in terms of responsiveness. Not to mention things like phoenix liveview..
- Osiris 3y ago
  The RSC stuff seems to just add a vast amount of complexity with little benefit. It feels like the end state here is going to be HTML+CSS with JS for interactivity using APIs, which is exactly what I was doing in 2006.
bluepuma77 3y ago
Did you have a look at SvelteKit? It does that "hydration" magic, first page loads completely from server, then it can work like a SPA, only fetching required data. It’s all JS, which we know from the frontend, all that "magic" is done by the framework in the background. You write it once, it works both ways automatically. We already build 3 webapps using SvelteKit, still happy for the ease of use, or great "DX" as some call it.
CipherThrowaway 3y ago
How much experience do you have with RSC and Next.js? I remember writing PHP and JSF back in the 90s and 00s, and the experience of both writing RSC and Next.js as well as using websites built with these technologies is simply not comparable.
- deleted 3y ago
  [deleted]
antoniuschan99 3y ago
I started in 2010 with Java and JSP and initially thought the same thing. But after reading more about it, I see it as like foldable phones. We’re back to using foldable phones, but it’s totally different than before. Also, I recall heavily using jQuery and Ajax to update parts of the page before Spa’s came along.
Scarblac 3y ago
> I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be. People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange. And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.
- tacker2000 3y ago
  Yea but why do I need to use React for that? Is it because these devs can only do React and nothing else, so we will shoehorn everything into it? I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer than learning and using normal, already available tools.
  - Scarblac 3y ago
    React and Server Components are also normal, available tools.
    - tacker2000 3y ago
      To clarify, I mean other server side tools that have been available a long time and had bugs ironed out. React Server stuff just came out recently, and still has a long way to go i guess.
  - pawelmurias 3y ago
    > I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer The server side components didn't seem to me at a glance significantly less convenient then say a normal PHP server stack.
  - deleted 3y ago
    [deleted]

by Osiris 3y ago

sam0x17 3y ago

Yeah, I've witnessed the entire arc also as an ex-ex-ex PHP developer from the early 00s, and I literally recall the original justification for this whole exodus that lead to the creation of React and a slew of other things was "jquery bad". I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. Maybe I'd still be doing frontend stuff and not burying my head as far into backend as humanly possible while I wait for a workflow that doesn't require a package.json and a 3 GB node_modules folder so I can make the same frontend widget I could make with 50 lines of js in 2007.

ytoawwhra92 3y ago
> I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. We kind of did (well, 2013), but it just wasn't backed by a massive developer marketing effort.

quickthrower2 3y ago

SSR is different I think because it can perform better, but given the state of most sites on the internet I think 2003 style rails is sufficient for most sites. And I haven’t met a JS-ey UI I have enjoyed using as much as a vanilla HTML one for most online stuff (drawing, games, 3D etc. excepted).

sam0x17 3y ago
And turbolinks on modern rails apps literally feels like those fancy JS-ey UIs anyway in terms of responsiveness. Not to mention things like phoenix liveview..
Osiris 3y ago
The RSC stuff seems to just add a vast amount of complexity with little benefit. It feels like the end state here is going to be HTML+CSS with JS for interactivity using APIs, which is exactly what I was doing in 2006.

bluepuma77 3y ago

Did you have a look at SvelteKit? It does that "hydration" magic, first page loads completely from server, then it can work like a SPA, only fetching required data. It’s all JS, which we know from the frontend, all that "magic" is done by the framework in the background. You write it once, it works both ways automatically. We already build 3 webapps using SvelteKit, still happy for the ease of use, or great "DX" as some call it.

CipherThrowaway 3y ago

How much experience do you have with RSC and Next.js? I remember writing PHP and JSF back in the 90s and 00s, and the experience of both writing RSC and Next.js as well as using websites built with these technologies is simply not comparable.

deleted 3y ago
[deleted]

antoniuschan99 3y ago

I started in 2010 with Java and JSP and initially thought the same thing. But after reading more about it, I see it as like foldable phones. We’re back to using foldable phones, but it’s totally different than before. Also, I recall heavily using jQuery and Ajax to update parts of the page before Spa’s came along.

Scarblac 3y ago

> I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be. People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange. And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.

tacker2000 3y ago
Yea but why do I need to use React for that? Is it because these devs can only do React and nothing else, so we will shoehorn everything into it? I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer than learning and using normal, already available tools.
- Scarblac 3y ago
  React and Server Components are also normal, available tools.
  - tacker2000 3y ago
    To clarify, I mean other server side tools that have been available a long time and had bugs ironed out. React Server stuff just came out recently, and still has a long way to go i guess.
- pawelmurias 3y ago
  > I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer The server side components didn't seem to me at a glance significantly less convenient then say a normal PHP server stack.
- deleted 3y ago
  [deleted]