5 ms·

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 bett

by 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.

by ratww 4y ago

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.