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.

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.

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.

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.

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

Indeed. But it's kinda funny that it quite literally came full circle.

> 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

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.

For the vast majority of projects it certainly means faster development and far lower production cost.

I was mostly worries that not having different PL would allow people to forget abstract interfaces.

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/FastG...

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

Thank the gods.