4 ms·
> 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. HTM
by 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 agoI 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.