3 ms·

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

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.

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.