3 ms·

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 wi

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.
- emerongi 6y ago
  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.

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.

emerongi 6y ago
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.