4 ms·

> I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting syste

by troupo 3y ago

> I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great lengths to touch DOM as little as possible. A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s. It's a system designed to render a page of text with a couple of images in one rendering pass at the core, and no amount of hacks on top of it will make it a high-perfromant layout and rednering engine. > Aside from arithmetic JS is just as fast as Java now This has nothing to do with either layout or rendering > The two big limitations from a pure processing perspective are the garbage collector Has nothing to do with either layout or rendering > massive repaints of large data on large layouts. Where "large data" is measly thousands of elements. Massive repaints in DOM happen basiclly on any and all layouts and layout changes. And these changes are triggered by almost anything that happens in the DOM. There's a reason why any reasonable animation you can reliably do with DOM is to literally rip the element out of the layout context and render it independently because "the most powerful layout and re-rendering engine" cannot cope with re-calculating and re-rendering the layout for the entire page when you move elements around. Edit. Slightly more on this: - Rendering performance https://web.dev/articles/rendering-performance https://web.dev/articles/rendering-performance - Linked article, Stick to Compositor-Only Properties and Manage Layer Count https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count https://web.dev/articles/stick-to-compositor-only-properties... From the last article: there are only two properties that can be handled by the compositor alone, all others trigger either a re-flow+re-paint or a re-paint.

austin-cheney 3y ago
Please, don't guess at performance. My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders. The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
- troupo 3y ago
  > Please, don't guess at performance. I don't. > My biggest learning about performance is that developers don't know how to measure it. So have you measured it and compared it to anything else? Judging by the fact that you think that "JS is fast" has something to do with rendering and layout, my guess is that you haven't. > The DOM is an in-memory object accessed via a standard API. This has nothing to do with rendering, layout, and doesn't make it fast (compared to other ways of doing UIs) in the general case. > string parsing mechanisms, like query selectors, is several times faster than it used to be. Again. This has literally nothing to do with either layout or rendering. > To run your own tests see this micro-benchmark test: I said it: "A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s." > To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Oh wow, you can select elements quickly. What does this have to do with the actual performance of things that matter? Or with the rest of your claim about rendering and layout? It's funny that you claim something about people guessing, and then use and talk about things that are completely irrelevant to your claims.
d3w4s9 3y ago
You comment shows that you have no practical knowledge of the web ecosystem, and everything you know about it comes from all the blog articles that contributes nothing that's useful in real world use. The reality is that web is fast enough (even with all the tweaks and different approaches of frameworks, libraries etc), and it is the first choice for building a new cross-platform product and for migrating legacy projects. It makes all the business sense as well. Your pedantic arguments are not going to reverse that trend.
- troupo 3y ago
  > You comment shows that you have no practical knowledge of the web ecosystem You're talking to a person with 20 years of frontend development experience. But sure, do go on with your assumptions. Also, no idea what "web ecosystem" has to do with the patently false claim of " the most powerful layouting system and rendering engine.", but do go on > The reality is that web is fast enough I never claimed it wasn't. But, again, without clarification of what fast is, or what enough is, it's again nebulous, and wrong for a very wide variety of use cases. > it is the first choice for building a new cross-platform product and for migrating legacy projects. I have no idea what this has to do with any of the things in this discussion. > Your pedantic arguments are not going to reverse that trend. Java applets and ActiveX also where the bee's knees and the best thing since sliced bread, and drove businesses and brought in billions of dollars in revenue. All this has literally nothing to do with the technology and how bad or good it is.
  - austin-cheney 3y ago
    I have also been writing for the web for over 20 years. This doesn't really mean anything though. That is why measures are all that matters. Bad measures are still monumentally better than no measures at all. The sad reality is that most people writing for the web today cannot do so without a framework. They have no idea how the layers underneath actually work. If you want to understand performance you must measure for it in multiple different ways and have something meaningful to compare it to. All modern browsers provide fantastic performance measuring tools in their developer tools. Its how I got my OS GUI (in a browser) to execute as fast as within 60ms of page load.

by troupo 3y ago

austin-cheney 3y ago

Please, don't guess at performance. My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders. The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

troupo 3y ago
> Please, don't guess at performance. I don't. > My biggest learning about performance is that developers don't know how to measure it. So have you measured it and compared it to anything else? Judging by the fact that you think that "JS is fast" has something to do with rendering and layout, my guess is that you haven't. > The DOM is an in-memory object accessed via a standard API. This has nothing to do with rendering, layout, and doesn't make it fast (compared to other ways of doing UIs) in the general case. > string parsing mechanisms, like query selectors, is several times faster than it used to be. Again. This has literally nothing to do with either layout or rendering. > To run your own tests see this micro-benchmark test: I said it: "A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s." > To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Oh wow, you can select elements quickly. What does this have to do with the actual performance of things that matter? Or with the rest of your claim about rendering and layout? It's funny that you claim something about people guessing, and then use and talk about things that are completely irrelevant to your claims.

d3w4s9 3y ago

You comment shows that you have no practical knowledge of the web ecosystem, and everything you know about it comes from all the blog articles that contributes nothing that's useful in real world use. The reality is that web is fast enough (even with all the tweaks and different approaches of frameworks, libraries etc), and it is the first choice for building a new cross-platform product and for migrating legacy projects. It makes all the business sense as well. Your pedantic arguments are not going to reverse that trend.

troupo 3y ago
> You comment shows that you have no practical knowledge of the web ecosystem You're talking to a person with 20 years of frontend development experience. But sure, do go on with your assumptions. Also, no idea what "web ecosystem" has to do with the patently false claim of " the most powerful layouting system and rendering engine.", but do go on > The reality is that web is fast enough I never claimed it wasn't. But, again, without clarification of what fast is, or what enough is, it's again nebulous, and wrong for a very wide variety of use cases. > it is the first choice for building a new cross-platform product and for migrating legacy projects. I have no idea what this has to do with any of the things in this discussion. > Your pedantic arguments are not going to reverse that trend. Java applets and ActiveX also where the bee's knees and the best thing since sliced bread, and drove businesses and brought in billions of dollars in revenue. All this has literally nothing to do with the technology and how bad or good it is.
- austin-cheney 3y ago
  I have also been writing for the web for over 20 years. This doesn't really mean anything though. That is why measures are all that matters. Bad measures are still monumentally better than no measures at all. The sad reality is that most people writing for the web today cannot do so without a framework. They have no idea how the layers underneath actually work. If you want to understand performance you must measure for it in multiple different ways and have something meaningful to compare it to. All modern browsers provide fantastic performance measuring tools in their developer tools. Its how I got my OS GUI (in a browser) to execute as fast as within 60ms of page load.