6 ms·

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.

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.

paulryanrogers 6y ago
How much of CODs code is interpreted in real time? Because for the web it's usually 100% interpreted.
- emerongi 6y ago
  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.
  - rualca 6y ago
    > 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.
    - emerongi 6y ago
      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."
      - rualca 6y ago
        > 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.
- csande17 6y ago
  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.
  - josephg 6y ago
    > 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.
  - tomduncalf 6y ago
    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.
cipher_system 6y ago
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?
ameliaquining 6y ago
The developers of Call of Duty put huge numbers of engineer-hours into making it highly performant. The developers of most websites do not do this.
elgenie 6y ago
The causality goes the other way. 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.
rualca 6y ago
> 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.
- the_gipsy 6y ago
  I think here on HN everybody knows that there are HTTP request, but we are talking about UI stuttering and generao slowness NOT from the network.
SkyPuncher 6y ago
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.
doliveira 6y ago
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.
still_grokking 6y ago
Well, there's nothing to wonder in my opinion. 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).

paulryanrogers 6y ago

How much of CODs code is interpreted in real time? Because for the web it's usually 100% interpreted.

emerongi 6y ago
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.
- rualca 6y ago
  > 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.
  - emerongi 6y ago
    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."
    - rualca 6y ago
      > 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.
csande17 6y ago
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.
- josephg 6y ago
  > 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.
- tomduncalf 6y ago
  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.

cipher_system 6y ago

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?

ameliaquining 6y ago

The developers of Call of Duty put huge numbers of engineer-hours into making it highly performant. The developers of most websites do not do this.

elgenie 6y ago

The causality goes the other way. 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.

rualca 6y ago

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

the_gipsy 6y ago
I think here on HN everybody knows that there are HTTP request, but we are talking about UI stuttering and generao slowness NOT from the network.

SkyPuncher 6y ago

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.

doliveira 6y ago

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.

still_grokking 6y ago

Well, there's nothing to wonder in my opinion. 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).