If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well.

There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is out of date now due to improvements in Browser engines, the fundamental ideas are still the same.

https://www.youtube.com/watch?v=mHtdZgou0qU

If you skip to the 35 minute mark he speaks about reflow specifically. Generally I still use many of these techniques when writing vanilla JS (which is unfortunately rare these days). There are other talks where he talks about many other performance specific topics.

Obviously none of this is as good as real world experience of dealing with a thorny issue.

No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"

Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc."

Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but will only consume 6% if you go out of your way to make it 'performant'"?

These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook"

How is 2D graphics programming helping there?

The article goes on to describe, correctly, layout properties ("The W3C spec is full of these!"), paint properties ("this tiny "bikeshed" SVG which you can find on lots of W3C spec pages. It costs ~30% CPU!") and composite properties.

These are not specific examples. These are literally footguns upon footguns that literally have no corresponding counterpart anywhere.

> That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.

Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.

No we are not. Someone asked about how one learns some techniques that the OP mentioned (that were simpler than the ones given in the article). I gave some general advice on how one should think about what is happening and some general advice about how to think about performance.

Then you are pretending that none of this is relevant because you are concentrating on the hyper specific stuff in the article (which we are no longer talking about).

I also disagree that this cannot be reasoned about by learning a bit about how graphics works, Cartesian coordinate system and literally turning on the paint flashing tool that is in dev tools. It is literally obvious what is happening when you see it.

> Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.

In fact it was very helpful to help me to understand what was happening. I literally said to myself "wait a minute, that is kinda like this thing I did in SDL 1.2 in university". You are literally telling me, that something I know to be useful isn't, because you say so. That is unreasonable.

Yes. Yes we are literally discussing this under an article whose introduction literally says what I quoted.

> Someone asked about how one learns some techniques that the OP mentioned

Yes, and the techniques OP mentioned literally cannot be learned from 2D graphics because nowhere in 2D graphics are you going "ah yes, to fix 60% CPU utilization for a primitive animation, you need to apply this awkward workaround that will tell the browser not to reflow the page".

Edit: and this particular technique is only applicable to this specific property for reasons that do not exist anywhere else, except in the browsers.

> wait a minute, that is kinda like this thing I did in SDL 1.2 in university

Well, it's not. Just because it kinda somewhat looks like something different doesn't make it so. Hence my question in this comment: https://news.ycombinator.com/item?id=44658482

Because those are not hyper specific, no matter how much you pretend they are

Experience is the best teacher.

the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.

my criticism is reserved for the concept of "first principles", as if there should be a cohesive and simple set of rules that you can build up all the knowledge you need from. that's just not really how any complicated system works: building a comprehensive understanding of a complicated system takes a lot of work and a lot of time.

Have you never resized a window on a desktop OS?

So the you need to fix that height /remove resize, then google on which technique to use?

The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.

Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.

How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case.

The acceptable range would be something like 0 - 1% when no interactions are taking place.

I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there.

Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).

they need to understand and believe that their wishes are not everyone's wishes, and that they alone are the cause of their own problems. Everyone else works hard to give them the creative freedom they demand, but for multiple decades now they have demonstrated over and over how they love shooting themselves in the foot at every opportunity.

> consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor. How is that considered acceptable?

It's not acceptable, unless you are a front-end web developer. If you are a front-end web developer, you don't consider this a problem in any way because the page looks as it is intended to look.

It's frustrating how just changing a filtering option will reload the entire web page on most websites.

Changing height typically only shifts elements, and browser engines typically wont relayout them due to position changes.

"overflow: clip" is also much more lightweight than "overflow: hidden"

Yes, looks like this property isn't just a hack, but was designed with exactly the performance considerations laid out in the article in mind. Animating height is only expensive when the element’s height affects layout, which it doesn't have to!

  > Just wrap it in a container with fixed height and "overflow: hidden".

Like the example from the linked article, there's one animation involved essentially and if the browser does the hard work for the entire length of one animation cycle and no layout ever changes, just assume it never will? It would have to have a bunch of edge cases to handle correctly I'm sure though.

But Google having more people working on Chrome than on Android I would say all the low-hanging optimizations have already been optimized, and all that's left is pretty complex even for teams of thousands.