4 ms·

> but comes with the most powerful layouting system and rendering engine If that would be the case there wouldn't be the flurry of JS frameworks which try to "

> but comes with the most powerful layouting system and rendering engine If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM. The DOM was originally created to render static text-heavy documents, baking such a limited document-layout system into browsers was a mistake in hindsight. These days, the DOM should be "just another" on-demand loaded Javascript UI framework sitting on top of a handful lower level rendering APIs.

immibis 3y ago
I thought flexbox solved this.
diggan 3y ago
> If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore). The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state. People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases. Well, except when it's chosen by cargocult, which is probably most of the cases.
- troupo 3y ago
  Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation. And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?
  - diggan 3y ago
    Which popular frontend framework advertise their DOM mutation speed on their frontpage exactly? Most frontend frameworks I come across nowadays advertise their developer experience and their features, not their DOM mutation speed. And when I say state manipulation I'm not talking about performance, I'm talking about the architecture and people working with the codebase. No one cares about state manipulation performance because as you said, it's a solved problem.
    - troupo 3y ago
      What do you think words like "performant framework for building web user interfaces" (Vue), "rendering is blazing fast, because Lit touches only the dynamic parts of your UI" (lit) and similar mean? No, they don't mean "our architecture and state manipulation". > No one cares about state manipulation performance because as you said, it's a solved problem. Indeed. That's way in any modern all modern frameworks, without an exception, the main focus is how to touch the DOM as little as possible because it's slow as molasses.
      - diggan 3y ago
        From your own example, here is the text from https://vuejs.org/ https://vuejs.org/ as of today: > The Progressive JavaScript Framework > An approachable, performant and versatile framework for building web user interfaces. > Approachable - Builds on top of standard HTML, CSS and JavaScript with intuitive API and world-class documentation. > Performant - Truly reactive, compiler-optimized rendering system that rarely requires manual optimization. > Versatile - A rich, incrementally adoptable ecosystem that scales between a library and a full-featured framework. Yes, performance is mentioned. But it's hardly the main selling point, and they don't even mention DOM manipulation, they're talking about the rendering in general. Lit isn't even a framework, it's a "web components library". > all modern frameworks Yeah, "all modern frameworks" being one framework + one library?
        troupo 3y ago
        What do you think "performant UI" is in the context of the web? What do you think all frontend libraries have been optimizing for for the past decade? Why do you think they measure their performance by this benchmark: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...? Or, as most people in the frontend space [1], you only understand the absolute surface level of the technologies you use? And unless it's spelled out in the exact words you expect, you don't understand the concepts? [1] I'm a frontender myself, and the amount of people I meet who don't even have the most basic understanding of the tools and technologies they use is mind-boggling.
bobthepanda 3y ago
The issue most javascript frameworks try to fix with the DOM is the fact that it is not a language and does not have very good templating support. (Even web components in their plain form are pretty bad; no one wants to write document.appendChild everywhere) But no one has dethroned HTML and CSS as a fully baked cross platform engine, because it has been battle tested and optimized to death. And not really for lack of trying; UI is just actually very complicated.
- switchbak 3y ago
  "UI is just actually very complicated" ... yeah, it's not like we've been developing UIs for decades prior to creating them in web tech. I think it's unfortunate that there's a generation that just takes that statement as a given, without any deeper understanding of the tech that underlies such things. UIs can be simple, they can also be complicated. Much of that depends on the sophistication and flexibility of the layout approaches you provide. Building UIs on top of a DOM, especially with layout controlled by this CSS monster - well yes, THAT's bound to be complicated. Unfortunately it's in this awkward zone where the implementation is complex, but it doesn't provide the corresponding payoff for the developer experience.

immibis 3y ago

I thought flexbox solved this.

diggan 3y ago

> If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore). The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state. People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases. Well, except when it's chosen by cargocult, which is probably most of the cases.

troupo 3y ago
Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation. And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?
- diggan 3y ago
  Which popular frontend framework advertise their DOM mutation speed on their frontpage exactly? Most frontend frameworks I come across nowadays advertise their developer experience and their features, not their DOM mutation speed. And when I say state manipulation I'm not talking about performance, I'm talking about the architecture and people working with the codebase. No one cares about state manipulation performance because as you said, it's a solved problem.
  - troupo 3y ago
    What do you think words like "performant framework for building web user interfaces" (Vue), "rendering is blazing fast, because Lit touches only the dynamic parts of your UI" (lit) and similar mean? No, they don't mean "our architecture and state manipulation". > No one cares about state manipulation performance because as you said, it's a solved problem. Indeed. That's way in any modern all modern frameworks, without an exception, the main focus is how to touch the DOM as little as possible because it's slow as molasses.
    - diggan 3y ago
      From your own example, here is the text from https://vuejs.org/ https://vuejs.org/ as of today: > The Progressive JavaScript Framework > An approachable, performant and versatile framework for building web user interfaces. > Approachable - Builds on top of standard HTML, CSS and JavaScript with intuitive API and world-class documentation. > Performant - Truly reactive, compiler-optimized rendering system that rarely requires manual optimization. > Versatile - A rich, incrementally adoptable ecosystem that scales between a library and a full-featured framework. Yes, performance is mentioned. But it's hardly the main selling point, and they don't even mention DOM manipulation, they're talking about the rendering in general. Lit isn't even a framework, it's a "web components library". > all modern frameworks Yeah, "all modern frameworks" being one framework + one library?
      - troupo 3y ago
        What do you think "performant UI" is in the context of the web? What do you think all frontend libraries have been optimizing for for the past decade? Why do you think they measure their performance by this benchmark: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...? Or, as most people in the frontend space [1], you only understand the absolute surface level of the technologies you use? And unless it's spelled out in the exact words you expect, you don't understand the concepts? [1] I'm a frontender myself, and the amount of people I meet who don't even have the most basic understanding of the tools and technologies they use is mind-boggling.

bobthepanda 3y ago

The issue most javascript frameworks try to fix with the DOM is the fact that it is not a language and does not have very good templating support. (Even web components in their plain form are pretty bad; no one wants to write document.appendChild everywhere) But no one has dethroned HTML and CSS as a fully baked cross platform engine, because it has been battle tested and optimized to death. And not really for lack of trying; UI is just actually very complicated.

switchbak 3y ago
"UI is just actually very complicated" ... yeah, it's not like we've been developing UIs for decades prior to creating them in web tech. I think it's unfortunate that there's a generation that just takes that statement as a given, without any deeper understanding of the tech that underlies such things. UIs can be simple, they can also be complicated. Much of that depends on the sophistication and flexibility of the layout approaches you provide. Building UIs on top of a DOM, especially with layout controlled by this CSS monster - well yes, THAT's bound to be complicated. Unfortunately it's in this awkward zone where the implementation is complex, but it doesn't provide the corresponding payoff for the developer experience.