6 ms·

Don't worry, we're slowly circling back to servers pushing out fully pre-rendered pages that don't require any scripts - or make it more convenient to create th

by krono 5y ago

Don't worry, we're slowly circling back to servers pushing out fully pre-rendered pages that don't require any scripts - or make it more convenient to create those, anyway. React's upcoming server-side components will likely be a very popular solution for achieving this. It's like PHP but this time in JavaScript.

netr0ute 5y ago
If I can't use an adblocker on it then count me out.
Dma54rhs 5y ago
The jsx soup already reminds me hacking php and html together with each other, truly back to the roots :)
- klabb3 5y ago
  Indeed. But it's kinda funny that it quite literally came full circle.
seumars 5y ago
It’s disappointing to see that the consensus among frontend devs is to just sit and wait for a new API from react to do all the work. Every framework out there has simple methods for rendering a component to string which can be returned to the client.
- tomphoolery 5y ago
  Trust me, no one who's actually working on this in the real world is banking on React's upcoming APIs for this at all. Suspense is still not done, and it's been over 4 years. Server components aren't happening anytime soon IMO. The only reason why I think this year is still tenable is because Vercel ate up all the React devs who can contribute to such a task. Most JS devs I've talked to or work with are writing code based on what we have now.
  - krono 5y ago
    To be fair, React's work is the most likely implementation of this concept for people to have heard about before. They've been talking about it for years, after all :) You're either vastly underestimating the number of developers at that skill level, or overestimating the number of those devs you or I might ever have even heard of.
datavirtue 5y ago
Thank the gods.
agumonkey 5y ago
> PHP but this time in JavaScript a sizeable improvement maybe, also does using the same language on both side a pro or a con ? real question
- krono 5y ago
  For the vast majority of projects it certainly means faster development and far lower production cost.
  - agumonkey 5y ago
    I was mostly worries that not having different PL would allow people to forget abstract interfaces.
    - krono 5y ago
      We already have cheap and fast. Can only pick two out of three[1], I'm afraid :) Jokes aside, theoretical knowledge is definitely lacking. There doesn't seem much interest either - that is, until you show how they could have saved days and get more reliable results more efficiently, if only they had known there's that 50+ year old algorithm they could have used. Experienced and knowledgable devs are still very important to have around. 1: https://paydirtapp.com/blog/wp-content/uploads/2012/11/FastGoodCheap.png https://paydirtapp.com/blog/wp-content/uploads/2012/11/FastG...
- grogenaut 5y ago
  Every time I've tried using typescript (sorry not using untyped JS) on the server and client, the mismatch between client and server libraries made it very hard to re-use the objects, frameworks or libraries. So much so that it felt like two different languages, or at least as different as writing react and writing CDK. I very quickly reached for any other server language and an IDL like GQL for the communications. This let me re-use code for the transport which was the max I was able to get from typescript/js only. The other big issue is the things I was working on actually needed high parallelism, and node really provides concurrency, so I quickly hit issues there as well. I'm currently working in a GQL based world and the golang based one we use is massively parallel and very performant, and I'd be worried about the speed loss writing in node. This makes me very sad because I really do like Typescript as a language, and writing everything in one language seems like it'd be great. But it's really brought down by all the typing issues with legacy javascript, node, and other tools. But then again, I'm not writing crud apps at work or for fun so your mileage may vary.
epistasis 5y ago
As a non-expert outsider, I thought that was the promise of React since the early days? Isn't there already server side rendering? What you describe, a PHP style server rendering of mostly static HTML, with small bits of JavaScript for interactivity, sounds great. But will that actually be possible? I'm really really sick of web apps and mobile apps that flash the "no content here" version of widgets while they wait for data to be loaded. It's the very very worst sort of user experience.

by krono 5y ago

netr0ute 5y ago

If I can't use an adblocker on it then count me out.

Dma54rhs 5y ago

The jsx soup already reminds me hacking php and html together with each other, truly back to the roots :)

klabb3 5y ago
Indeed. But it's kinda funny that it quite literally came full circle.

seumars 5y ago

It’s disappointing to see that the consensus among frontend devs is to just sit and wait for a new API from react to do all the work. Every framework out there has simple methods for rendering a component to string which can be returned to the client.

tomphoolery 5y ago
Trust me, no one who's actually working on this in the real world is banking on React's upcoming APIs for this at all. Suspense is still not done, and it's been over 4 years. Server components aren't happening anytime soon IMO. The only reason why I think this year is still tenable is because Vercel ate up all the React devs who can contribute to such a task. Most JS devs I've talked to or work with are writing code based on what we have now.
- krono 5y ago
  To be fair, React's work is the most likely implementation of this concept for people to have heard about before. They've been talking about it for years, after all :) You're either vastly underestimating the number of developers at that skill level, or overestimating the number of those devs you or I might ever have even heard of.

datavirtue 5y ago

Thank the gods.

agumonkey 5y ago

> PHP but this time in JavaScript a sizeable improvement maybe, also does using the same language on both side a pro or a con ? real question

krono 5y ago
For the vast majority of projects it certainly means faster development and far lower production cost.
- agumonkey 5y ago
  I was mostly worries that not having different PL would allow people to forget abstract interfaces.
  - krono 5y ago
    We already have cheap and fast. Can only pick two out of three[1], I'm afraid :) Jokes aside, theoretical knowledge is definitely lacking. There doesn't seem much interest either - that is, until you show how they could have saved days and get more reliable results more efficiently, if only they had known there's that 50+ year old algorithm they could have used. Experienced and knowledgable devs are still very important to have around. 1: https://paydirtapp.com/blog/wp-content/uploads/2012/11/FastGoodCheap.png https://paydirtapp.com/blog/wp-content/uploads/2012/11/FastG...
grogenaut 5y ago
Every time I've tried using typescript (sorry not using untyped JS) on the server and client, the mismatch between client and server libraries made it very hard to re-use the objects, frameworks or libraries. So much so that it felt like two different languages, or at least as different as writing react and writing CDK. I very quickly reached for any other server language and an IDL like GQL for the communications. This let me re-use code for the transport which was the max I was able to get from typescript/js only. The other big issue is the things I was working on actually needed high parallelism, and node really provides concurrency, so I quickly hit issues there as well. I'm currently working in a GQL based world and the golang based one we use is massively parallel and very performant, and I'd be worried about the speed loss writing in node. This makes me very sad because I really do like Typescript as a language, and writing everything in one language seems like it'd be great. But it's really brought down by all the typing issues with legacy javascript, node, and other tools. But then again, I'm not writing crud apps at work or for fun so your mileage may vary.

epistasis 5y ago

As a non-expert outsider, I thought that was the promise of React since the early days? Isn't there already server side rendering? What you describe, a PHP style server rendering of mostly static HTML, with small bits of JavaScript for interactivity, sounds great. But will that actually be possible? I'm really really sick of web apps and mobile apps that flash the "no content here" version of widgets while they wait for data to be loaded. It's the very very worst sort of user experience.