Is this basically the same idea that react native works? by sending and receiving JSON into the JS thread? but instead of a thread you just use a server, right?
If a component conforms both to the rules for server components (no interactivity) and to the rules for client components (no direct access to backend resources), then it can be used both as a server component and as a client component. This is useful for many purposes. But it is not true of server components in general.
It's funny how computers have become massively powerful with multiple cores and oodles of RAM , but still struggle with rendering html interfaces on the client. My machine can render Call of Duty at 60fps but will sometimes struggle to do that with websites.
The technical reasonings don't matter. It is a reflection of the failure on the part of software engineers, product managers and standards bodies.
We are using a document markup language to create interactive UIs. Which, for some crazy reason, has taken over the rest of the industry as well. I have a TV with a React UI, which takes around a second to respond to actions on my remote control. Decades ago, TVs were responsive, even though they had a minuscule amount of processing power compared to modern ones.
You'd think that people would recognize that the web was not meant for what it is used today and would standardize on an alternative with similar benefits (easy debugging, quick feedback cycle, modern tooling) that would actually allow us to build proper interactive UIs, but apparently it is impossible to develop new software. Please, someone, kill HTML.
> The technical reasonings don't matter. It is a reflection of the failure on the part of software engineers, product managers and standards bodies.
Your personal assertion makes no sense. This is a purely technical problem, not a project management one. If you need to load a page and load a script and load data, and each load takes you around 100ms, then you don't change any of that with project management changes.
Technical problems are addressed with technical solutions, and this article shows you one: prerender the content on the server-side to avoid having to wait for data fetches to get the initial page load to finish.
> We are using a document markup language to create interactive UIs.
Your remark makes absolutely no sense and has no bearing with either the problem domain or the discussion. The markup side of things is not a problem. Parsing and rendering HTML is not a problem. HTML does not even feature in this discussion at all.
Please bear in mind that you are posting comments on a discussion on, to put it clearly to you, procedurally generated websites. This is about a server-side rendering technique for React applications. In case you are unaware, React is a javascript frameworks that is used to generate and manage the DOM. The "markup language" side of things barely even registers as boilerplate to specify the entry point. It's the javascript script that you run after the HTML is loaded that assembles the document tree.
> You'd think that people would recognize that the web was not meant for what it is used today
Your comment makes zero sense, and reads like a non-sequitur rant.
To clarify: I am emphasizing the fact that HTML is not suitable for what we are using it for today. It is used in applications that don't have anything to do with the web, but is taken into use purely because it has good tooling around it and practically every developer knows it. This often happens because there are deadlines, developers need to push out products, and nobody has time to actually work on a better fundamental technology. So, the common denominator ends up being chosen. I am not talking about whatever tehnical issue you believe exists. If the standards bodies took their legs out of their asses, they would have come up with a better standard. Instead, we are stuck on HTML/CSS/JS.
> Parsing and rendering HTML is not a problem. HTML does not even feature in this discussion at all.
If you actually read the comment tree, you'd realize that the whole discussion starts with an anecdote about how slow rendering HTML is even on a beefy machine.
Having worked with React since 2015 practically daily, I can say with confidence that the only reason it exists is to enable interactive UIs on top of a document markup language (HTML). Rendering HTML is exactly the problem, React's (initial) purpose was to make rendering (or rather, producing or manipulating) HTML easier.
> Your comment makes zero sense, and reads like a non-sequitur rant.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it."
> To clarify: I am emphasizing the fact that HTML is not suitable for what we are using it for today.
As I've said, that personal assertion makes no sense. HTML is not a bottleneck. Your claim was, and I repeat, "We are using a document markup language to create interactive UIs." The only part that HTML handles is define the DOM's initial state. It makes absolutely no difference whether you use HTML, XAML, QML, or whatever other technology you pick. The problem doesn't lie in the initial DOM setup. You're trying to criticize a data format while failing to understand you're criticizing the need to build up a hierarchical tree comprised of "windows".
And to make matters worse, you're complaining about HTML in a discussion on a problem where HTML plays absolutely no role at all. If you read the discussion you'll notice that the performance issue is tied to the need to fetch data required to generate the page. This has zero to do with HTML. In this discussion, HTML is used to point to the javascript that needs to be downloaded to generate and manage the page, and provide a root element for the javascript to manage. The most computationally demanding role of HTML is to show a single line of text showing an error in case the javascript fails to run.
> If you actually read the comment tree, you'd realize that the whole discussion starts with an anecdote about how slow rendering HTML is even on a beefy machine.
You're the only person who, for some reason, is discussing HTML in a discussion were HTML has zero relevance.
To make matters worse, the performance challenges showed in this discussion are related with the need to perform additional HTTP calls to fetch data, not rendering.
And please try to understand the fundamental lack of understanding that's needed to conflate the problem of rendering a document layout and a document format used to provide the initial configuration of a document tree.
And please try to understand that this discussion is about javascript generated pages. Think about it: HTML in this context is only used for two things: point to where to load the javascript that generates the page, and provide a root element that the script overwrites and manages.
Your messages show a fundamental lack of understanding regarding basic concepts and the problem domain, and you can't progress from a point where all your assumptions have no bearing with reality.
I have not claimed that HTML is the bottleneck. I have claimed that we are using it for things it was not meant for, creating major inefficiencies.
Can we agree that modern web-based UIs can often be slow or just CPU-intensive? If so, then why is that?
Your claim is effectively that HTML has no impact on the problem. Purely perfomance-wise, yes, modern browsers are plenty capable of doing DOM mutations super fast. No problem there. But since we are using an ecosystem that wasn't meant for interactive UIs, we need to create inefficient layers on top of it. Why do we need to create those layers? Because the underlying abstractions (HTML/CSS/JS) are not suitable.
I am not sure how else to make you understand. How come in 2021 there is no easy way to build a performant interactive UI on the web? If the ecosystem were suitable for it, surely we would have a reasonable solution by now. Considering how DOM changes are done plenty fast, JS is plenty fast and that we have major tech companies (Google, Microsoft, Facebook, Apple) working on the web, we should not have any issues.
In any case, it seems we are not going to be able to convince eachother. I am a believer in fundamentals. Get them right, and the rest follows. HTML was and is great for documents, but for interactive UIs, we can do better.
Games, particularly ones written with engines like Unity, actually look a lot like websites in this respect. You have a core engine written in C++ that runs the event loop and draws things on the screen and stuff, but all the actual game logic is written in an interpreted language.
> but all the actual game logic is written in an interpreted language.
I was listening to a talk by Jonathan Blow the other day where he was saying using interpreted languages (like lua) inside a game engine isn't considered good practice anymore. And indeed, in unity most games write all their logic in C# - which unity somehow compiles down to native code.
Unity specifically uses C# as the language for your logic, but it gets compiled to auto generated C++ code when you export (if you export to iOS you can take a look at the generated source). Of course games do sometimes make use of languages like Lua for scripting behaviour, I’m not sure if these usually remain interpreted or get compiled.
Yeah I never really understood this. Another example, my PS4 Pro can render the most beautiful games smoothly but the main interface with just a few icons is laggy as hell. Whats up with that?
Technologies that are fast to develop in but comprised of heaps of inefficient layers upon inefficient layers are possible in the first place because computers are powerful and have oodles of RAM. There’s so little punishment in the marketplace for websites for (ab)using system resources that it is the opportunity cost of failing to do so that dominates.
> but still struggle with rendering html interfaces on the client.
This assertion completely ignores the performance problems that are involved in "rendering html interfaces on the client".
The main difference between rendering "Call of Duty at 60fps" and rendering a SPA in React is where you decided to start counting. While your Call of Duty example presumes the app already in the post-init in-game state, your "rendering html interfaces on the client" only covers the app load and init state.
This means you are comparing a state where all data to output the first render is already fetched and available with a state where even the code that builds the app is not fetched yet and therefore at least a sizable HTTP request needs to be completed, followed by other sizable and non-pipelinable HTTP requests which are needed to fetch the data used to build up content and state.
Call of Duty does not need to perform and wait for at least two sequential HTTP requests to finish to be able to render a scene. Each HTTP request adds something between 50 to 100ms to the page load time. The topic of this discussion is a technique used to avoid having to wait for subsequent requests after the initial HTML+Javascript requests by simply prefetching and prerendering the content on the server. Consequently this approach avoids the need to make critical HTTP requests in the client-side by simply supplying the HTML and javascript with the client's intended state and content, thus potentially shaving over 50-100ms from a page load time.
Well, that's because there's different targets for these things.
When your paying engineers 6-figures and can achieve target performance simply by buying more cores, it's often a good trade off.
When you're selling a game to the general public, hardware is relatively fixed.
----
Big companies spend a lot of time on performance, because it matters. When you're running with millions of dollars of compute costs, it actually meaningful to optimize the code to save cores.
My pet theory is that this happens because a lot of top web developers don't really know how slow and stuttering their websites are in most machines not like their own (last-year top-of-the-line Mac models connected through perfect Wi-Fi/5G). And then it trickles down to the rest of the industry.
HTML tech was never designed to run applications. It's for hypertext documents and nothing else.
But one can pervert any tech to do any kind of stuff. So people started to build "HTML apps".
Using inappropriate tools results in abysmal results. Simple like that.
If you use the right tool you can render GUI components even with microcontrollers. Have a look at Qt for example.
One could have of course all the nice things about "HTML apps", even if the GUI tech would be purposely build and separated from the rest of the stack.
It's just the "Web Platform" that's a completely inadequate base for app development. But nobody cares as "it works fine". The mantra is even: Oh, we have so much compute power and RAM! It would be a pity if we wouldn't use it to the limit of what's available. The idea behind: If your "app" doesn't use all the available resources "it wastes resources, as unused resources are wasted resources".
I for my part just can't put in words how completely nuts this line of reasoning appears to me!
Especially as on the other side of the fence people complaining about the massive waste of resources by "web tech"...
The solution is of course also simple: Just don't use the wrong tool for the job!
If you're not writing hypertext documents, but want to build an application, just use technology that was purposely build to support efficient (along all kind of axis) application development. With "native" tech there's no problem to render some GUI components. That worked flawless even back than on i486 PCs. The stuff in the past even felt much more responsive than todays web-tech GUIs.
But of course Google & Co. will tell you that you should build apps for their "operating system" (the "Web Platform"), or else...
(There is even a broader parallel to be drawn to the satiation in the 90'ies: Just think for a moment about Kubernetes and PWAs, about Google and MS Windows ;-) But this rant is already too long. I'm sure the people here are able to see that parallels without further explanation).
Sounds like what 37signals/basecamp has been pushing for as a model for a decade now.
It took some time and flailing about in the community. But fortunately there was a relatively quick and massive structural change to programming large web front ends with compontent-based JS over the years.
Much like Rails, the problem wasn't the language per-se, but a broad consensus regarding the best approach and having structure community wide helps solve a lot of problems.
Now we finally have reached a pretty close consensus on the 'framework' side. Plus I'm also excited on the build systems side - as they are getting closer to just 'importing' other JS files instead of the endless magic of Webpack processors and similar hackery.
So with that area finally quieting down, performance optimization around SSR and pushing as much to the server-side in general is also finally reaching maturity. This is a critical piece of the puzzle. And probably the last major hurdle for serious performant JS-heavy frontends.
Heavily interactive web UIs are not going away no matter how many minimalist or anti-frontend-JS articles get posted on HN and elsewhere.
Countless SaaS products depend heavily on stuff we've had on desktop for ages (most legit critiques apply to miss-use-cases, not inherent issues). And their potential for serious interfaces with well managed client-side state, consistent abstraction layers with components, clean UI logic, etc, instead of ungodly spaghetti messes that were difficult for dev teams to manage - ones that would changed dramatically every time a new dev/manager was hired - or simply trying to hack full-on Rails style MVC but purely client-side (see: backbone.js), is finally coming to and end.
I'm personally a Vue, not React guy, but there's no question most advancements and experimentations happen in React's community first. Which a fine by me, as the good pieces always filter down to Vue quite quickly. SSR and deeper server integrations are clearly the way to go for any serious web app. The only downsides I've seen are they mostly JS server frameworks.
I think one missing piece that’s far from mature is data fetching. It’s really hard to get something working well at scale:
- REST is simple, but you end up with serial waterfalls for complex fetches.
- GraphQL avoids these waterfalls and lets you collocate declarative data with your components. This is great if your server layer supports it well.
- You also need a way to fetch all descendants’ data high up the tree (to avoid serial fetches). Relay does this with a compilation step, and requires passing pointers back down the tree for runtime use.
- Updating data (POST, PUT, Mutations) is super tricky to do in a way that keeps data consistent, avoids over-fetching, handles exceptions and idempotence and retries right, etc.
I wish there was a standard here, but I think we’re still pretty far from it.
I also feel like this really is one of the biggest pain points when writing single page apps. There is no good standard and everybody is promoting his/her way to do it that works well in a TODO app example but kinda fails in a big production application.
28 comments
[ 4.8 ms ] story [ 71.9 ms ] threadThis is blatantly wrong. The RFC (and Dan Abramov’s video) make it clear that server components can only be run on the server: https://github.com/josephsavona/rfcs/blob/server-components/...
I guess you can have components and hooks to share stuff between server and client?
We are using a document markup language to create interactive UIs. Which, for some crazy reason, has taken over the rest of the industry as well. I have a TV with a React UI, which takes around a second to respond to actions on my remote control. Decades ago, TVs were responsive, even though they had a minuscule amount of processing power compared to modern ones.
You'd think that people would recognize that the web was not meant for what it is used today and would standardize on an alternative with similar benefits (easy debugging, quick feedback cycle, modern tooling) that would actually allow us to build proper interactive UIs, but apparently it is impossible to develop new software. Please, someone, kill HTML.
Your personal assertion makes no sense. This is a purely technical problem, not a project management one. If you need to load a page and load a script and load data, and each load takes you around 100ms, then you don't change any of that with project management changes.
Technical problems are addressed with technical solutions, and this article shows you one: prerender the content on the server-side to avoid having to wait for data fetches to get the initial page load to finish.
> We are using a document markup language to create interactive UIs.
Your remark makes absolutely no sense and has no bearing with either the problem domain or the discussion. The markup side of things is not a problem. Parsing and rendering HTML is not a problem. HTML does not even feature in this discussion at all.
Please bear in mind that you are posting comments on a discussion on, to put it clearly to you, procedurally generated websites. This is about a server-side rendering technique for React applications. In case you are unaware, React is a javascript frameworks that is used to generate and manage the DOM. The "markup language" side of things barely even registers as boilerplate to specify the entry point. It's the javascript script that you run after the HTML is loaded that assembles the document tree.
> You'd think that people would recognize that the web was not meant for what it is used today
Your comment makes zero sense, and reads like a non-sequitur rant.
> Parsing and rendering HTML is not a problem. HTML does not even feature in this discussion at all.
If you actually read the comment tree, you'd realize that the whole discussion starts with an anecdote about how slow rendering HTML is even on a beefy machine.
Having worked with React since 2015 practically daily, I can say with confidence that the only reason it exists is to enable interactive UIs on top of a document markup language (HTML). Rendering HTML is exactly the problem, React's (initial) purpose was to make rendering (or rather, producing or manipulating) HTML easier.
> Your comment makes zero sense, and reads like a non-sequitur rant.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it."
As I've said, that personal assertion makes no sense. HTML is not a bottleneck. Your claim was, and I repeat, "We are using a document markup language to create interactive UIs." The only part that HTML handles is define the DOM's initial state. It makes absolutely no difference whether you use HTML, XAML, QML, or whatever other technology you pick. The problem doesn't lie in the initial DOM setup. You're trying to criticize a data format while failing to understand you're criticizing the need to build up a hierarchical tree comprised of "windows".
And to make matters worse, you're complaining about HTML in a discussion on a problem where HTML plays absolutely no role at all. If you read the discussion you'll notice that the performance issue is tied to the need to fetch data required to generate the page. This has zero to do with HTML. In this discussion, HTML is used to point to the javascript that needs to be downloaded to generate and manage the page, and provide a root element for the javascript to manage. The most computationally demanding role of HTML is to show a single line of text showing an error in case the javascript fails to run.
> If you actually read the comment tree, you'd realize that the whole discussion starts with an anecdote about how slow rendering HTML is even on a beefy machine.
You're the only person who, for some reason, is discussing HTML in a discussion were HTML has zero relevance.
To make matters worse, the performance challenges showed in this discussion are related with the need to perform additional HTTP calls to fetch data, not rendering.
And please try to understand the fundamental lack of understanding that's needed to conflate the problem of rendering a document layout and a document format used to provide the initial configuration of a document tree.
And please try to understand that this discussion is about javascript generated pages. Think about it: HTML in this context is only used for two things: point to where to load the javascript that generates the page, and provide a root element that the script overwrites and manages.
Your messages show a fundamental lack of understanding regarding basic concepts and the problem domain, and you can't progress from a point where all your assumptions have no bearing with reality.
Can we agree that modern web-based UIs can often be slow or just CPU-intensive? If so, then why is that?
Your claim is effectively that HTML has no impact on the problem. Purely perfomance-wise, yes, modern browsers are plenty capable of doing DOM mutations super fast. No problem there. But since we are using an ecosystem that wasn't meant for interactive UIs, we need to create inefficient layers on top of it. Why do we need to create those layers? Because the underlying abstractions (HTML/CSS/JS) are not suitable.
I am not sure how else to make you understand. How come in 2021 there is no easy way to build a performant interactive UI on the web? If the ecosystem were suitable for it, surely we would have a reasonable solution by now. Considering how DOM changes are done plenty fast, JS is plenty fast and that we have major tech companies (Google, Microsoft, Facebook, Apple) working on the web, we should not have any issues.
In any case, it seems we are not going to be able to convince eachother. I am a believer in fundamentals. Get them right, and the rest follows. HTML was and is great for documents, but for interactive UIs, we can do better.
I was listening to a talk by Jonathan Blow the other day where he was saying using interpreted languages (like lua) inside a game engine isn't considered good practice anymore. And indeed, in unity most games write all their logic in C# - which unity somehow compiles down to native code.
Technologies that are fast to develop in but comprised of heaps of inefficient layers upon inefficient layers are possible in the first place because computers are powerful and have oodles of RAM. There’s so little punishment in the marketplace for websites for (ab)using system resources that it is the opportunity cost of failing to do so that dominates.
This assertion completely ignores the performance problems that are involved in "rendering html interfaces on the client".
The main difference between rendering "Call of Duty at 60fps" and rendering a SPA in React is where you decided to start counting. While your Call of Duty example presumes the app already in the post-init in-game state, your "rendering html interfaces on the client" only covers the app load and init state.
This means you are comparing a state where all data to output the first render is already fetched and available with a state where even the code that builds the app is not fetched yet and therefore at least a sizable HTTP request needs to be completed, followed by other sizable and non-pipelinable HTTP requests which are needed to fetch the data used to build up content and state.
Call of Duty does not need to perform and wait for at least two sequential HTTP requests to finish to be able to render a scene. Each HTTP request adds something between 50 to 100ms to the page load time. The topic of this discussion is a technique used to avoid having to wait for subsequent requests after the initial HTML+Javascript requests by simply prefetching and prerendering the content on the server. Consequently this approach avoids the need to make critical HTTP requests in the client-side by simply supplying the HTML and javascript with the client's intended state and content, thus potentially shaving over 50-100ms from a page load time.
When your paying engineers 6-figures and can achieve target performance simply by buying more cores, it's often a good trade off.
When you're selling a game to the general public, hardware is relatively fixed.
----
Big companies spend a lot of time on performance, because it matters. When you're running with millions of dollars of compute costs, it actually meaningful to optimize the code to save cores.
HTML tech was never designed to run applications. It's for hypertext documents and nothing else.
But one can pervert any tech to do any kind of stuff. So people started to build "HTML apps".
Using inappropriate tools results in abysmal results. Simple like that.
If you use the right tool you can render GUI components even with microcontrollers. Have a look at Qt for example.
One could have of course all the nice things about "HTML apps", even if the GUI tech would be purposely build and separated from the rest of the stack.
It's just the "Web Platform" that's a completely inadequate base for app development. But nobody cares as "it works fine". The mantra is even: Oh, we have so much compute power and RAM! It would be a pity if we wouldn't use it to the limit of what's available. The idea behind: If your "app" doesn't use all the available resources "it wastes resources, as unused resources are wasted resources".
I for my part just can't put in words how completely nuts this line of reasoning appears to me!
Especially as on the other side of the fence people complaining about the massive waste of resources by "web tech"...
The solution is of course also simple: Just don't use the wrong tool for the job!
If you're not writing hypertext documents, but want to build an application, just use technology that was purposely build to support efficient (along all kind of axis) application development. With "native" tech there's no problem to render some GUI components. That worked flawless even back than on i486 PCs. The stuff in the past even felt much more responsive than todays web-tech GUIs.
But of course Google & Co. will tell you that you should build apps for their "operating system" (the "Web Platform"), or else...
(There is even a broader parallel to be drawn to the satiation in the 90'ies: Just think for a moment about Kubernetes and PWAs, about Google and MS Windows ;-) But this rant is already too long. I'm sure the people here are able to see that parallels without further explanation).
It took some time and flailing about in the community. But fortunately there was a relatively quick and massive structural change to programming large web front ends with compontent-based JS over the years.
Much like Rails, the problem wasn't the language per-se, but a broad consensus regarding the best approach and having structure community wide helps solve a lot of problems.
Now we finally have reached a pretty close consensus on the 'framework' side. Plus I'm also excited on the build systems side - as they are getting closer to just 'importing' other JS files instead of the endless magic of Webpack processors and similar hackery.
So with that area finally quieting down, performance optimization around SSR and pushing as much to the server-side in general is also finally reaching maturity. This is a critical piece of the puzzle. And probably the last major hurdle for serious performant JS-heavy frontends.
Heavily interactive web UIs are not going away no matter how many minimalist or anti-frontend-JS articles get posted on HN and elsewhere.
Countless SaaS products depend heavily on stuff we've had on desktop for ages (most legit critiques apply to miss-use-cases, not inherent issues). And their potential for serious interfaces with well managed client-side state, consistent abstraction layers with components, clean UI logic, etc, instead of ungodly spaghetti messes that were difficult for dev teams to manage - ones that would changed dramatically every time a new dev/manager was hired - or simply trying to hack full-on Rails style MVC but purely client-side (see: backbone.js), is finally coming to and end.
I'm personally a Vue, not React guy, but there's no question most advancements and experimentations happen in React's community first. Which a fine by me, as the good pieces always filter down to Vue quite quickly. SSR and deeper server integrations are clearly the way to go for any serious web app. The only downsides I've seen are they mostly JS server frameworks.
I think one missing piece that’s far from mature is data fetching. It’s really hard to get something working well at scale:
- REST is simple, but you end up with serial waterfalls for complex fetches.
- GraphQL avoids these waterfalls and lets you collocate declarative data with your components. This is great if your server layer supports it well.
- You also need a way to fetch all descendants’ data high up the tree (to avoid serial fetches). Relay does this with a compilation step, and requires passing pointers back down the tree for runtime use.
- Updating data (POST, PUT, Mutations) is super tricky to do in a way that keeps data consistent, avoids over-fetching, handles exceptions and idempotence and retries right, etc.
I wish there was a standard here, but I think we’re still pretty far from it.