5 ms·

I’ve been developing for the web since, well not quite 30 years ago (PHP isn’t even 30!), but let’s say 25 years ago. I’ve used so much different tech in those

I’ve been developing for the web since, well not quite 30 years ago (PHP isn’t even 30!), but let’s say 25 years ago. I’ve used so much different tech in those years that I have a pretty good sense of it, and I even contributed to the development of both PHP and React. And you are totally off base. Modern frameworks are far superior for building modern web apps than older serverside tech. Demands have changed and so we need new tools to address this. Does this mean every single “new hotness” is truly a set change? No, of course not, a lot of things are just fads. Actually I would put SSR slightly in that camp, for while it’s certainly beneficial it’s not really a game changer. It’s just a modest performance optimisation (in some cases!).

ratww 4y ago
While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered. This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP used to do. I personally enjoy both the old and new techniques, and I think it's a natural progression to use those new frameworks for also rendering on the server. Not only because of code-sharing, but because I think they're better than old templating engines.
- tomnipotent 4y ago
  > argument is that the techniques themselves were "forgotten" and are now being rediscovered Which is a silly, lazy argument. > by people claiming that the term "Server Side Rendering" can't be retroactively applied Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR.
  - csmpltn 4y ago
    > "The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR." Can you provide even a single example for something we can do with JS running on both the client and the server, that was otherwise "impossible" (quoting you here), or very difficult, without this capability?
    - mypalmike 4y ago
      Single codebase for data object definitions, without an extra data definition language and code generation layer. Which leads to things like... data validation logic that is exactly the same on client and server. Same for serialization/ deserialization code.
    - chrischen 4y ago
      Doing "new" stuff and being more performant is really in the domain of the web browser, not in the javascript libraries that run on browser engines. Saying React doesn't enable "new" stuff in that regard isn't really fair because React isn't meant to do that. What React does do is allow for the development of maintainable complex applications such as most major web apps you use including Instagram, Facebook.com, Netflix.com, etc.
  - ratww 4y ago
    > Show me one such claim In this thread: https://news.ycombinator.com/item?id=31723357 https://news.ycombinator.com/item?id=31723357, https://news.ycombinator.com/item?id=31723746 https://news.ycombinator.com/item?id=31723746, https://news.ycombinator.com/item?id=31724418 https://news.ycombinator.com/item?id=31724418 > The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Sure it does, but this doesn't mean that PHP wasn't rendering on the server. The term still applies to what PHP was doing. > Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR. Pointing out those unique opportunities is not a problem, and I agree with you on that. But it has absolutely nothing to do with the usage of SSR or the term SSR. Also, using the same language on server and client is older than modern JS frameworks, which definitely counts as something being "rediscovered". And yes, is definitely a cool thing, nobody is claiming the contrary.
- chrischen 4y ago
  SSR isn’t a technique though. Functional UI composition is a technique, and SSR is an optimization being brought back to this technique.
  - ratww 4y ago
    Yes it is. It's a method of achieving something or carrying something out. But not only it doesn't matter, I don't think anyone else is interested in a stupid semantics discussion.
chrischen 4y ago
I agree with you SSR is an optimization but I wouldn’t call it a fad. Take a page that is static for 99% or even 100% of all users—it wouldn’t make sense to have distributed rendering at scale by each client. Instead SSR allows the server to render once and then just serve from the cache. Not only does it speed up the page for the user it saves energy. So I would classify it as a fundamental optimization here to stay.

ratww 4y ago

While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered. This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP used to do. I personally enjoy both the old and new techniques, and I think it's a natural progression to use those new frameworks for also rendering on the server. Not only because of code-sharing, but because I think they're better than old templating engines.

tomnipotent 4y ago
> argument is that the techniques themselves were "forgotten" and are now being rediscovered Which is a silly, lazy argument. > by people claiming that the term "Server Side Rendering" can't be retroactively applied Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR.
- csmpltn 4y ago
  > "The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR." Can you provide even a single example for something we can do with JS running on both the client and the server, that was otherwise "impossible" (quoting you here), or very difficult, without this capability?
  - mypalmike 4y ago
    Single codebase for data object definitions, without an extra data definition language and code generation layer. Which leads to things like... data validation logic that is exactly the same on client and server. Same for serialization/ deserialization code.
  - chrischen 4y ago
    Doing "new" stuff and being more performant is really in the domain of the web browser, not in the javascript libraries that run on browser engines. Saying React doesn't enable "new" stuff in that regard isn't really fair because React isn't meant to do that. What React does do is allow for the development of maintainable complex applications such as most major web apps you use including Instagram, Facebook.com, Netflix.com, etc.
- ratww 4y ago
  > Show me one such claim In this thread: https://news.ycombinator.com/item?id=31723357 https://news.ycombinator.com/item?id=31723357, https://news.ycombinator.com/item?id=31723746 https://news.ycombinator.com/item?id=31723746, https://news.ycombinator.com/item?id=31724418 https://news.ycombinator.com/item?id=31724418 > The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Sure it does, but this doesn't mean that PHP wasn't rendering on the server. The term still applies to what PHP was doing. > Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR. Pointing out those unique opportunities is not a problem, and I agree with you on that. But it has absolutely nothing to do with the usage of SSR or the term SSR. Also, using the same language on server and client is older than modern JS frameworks, which definitely counts as something being "rediscovered". And yes, is definitely a cool thing, nobody is claiming the contrary.
chrischen 4y ago
SSR isn’t a technique though. Functional UI composition is a technique, and SSR is an optimization being brought back to this technique.
- ratww 4y ago
  Yes it is. It's a method of achieving something or carrying something out. But not only it doesn't matter, I don't think anyone else is interested in a stupid semantics discussion.

chrischen 4y ago

I agree with you SSR is an optimization but I wouldn’t call it a fad. Take a page that is static for 99% or even 100% of all users—it wouldn’t make sense to have distributed rendering at scale by each client. Instead SSR allows the server to render once and then just serve from the cache. Not only does it speed up the page for the user it saves energy. So I would classify it as a fundamental optimization here to stay.