Wouldn't it have been wiser to restrict CSS to document-oriented use cases, accepting that for apps you need Javascript anyway, and then just measure and position elements programmatically? The problem with the discussed solutions in TFA (which is great btw) is the lack of discoverability, and CSS generally solving for the wrong 20% of use cases, bringing unsustainable technical debt for displaying our docs going forward for generations to come. I really would appreciate an attempt to specify CSS behavior, even a subset of it, as a constraint-based formulation or other formal spec; easier said than done, though.
Wouldn't it have been wiser to restrict CSS to document-oriented use cases, accepting that for apps you need Javascript anyway, and then just measure and position elements programmatically?
Measuring DOM elements and moving them around in JS is quite slow. Transforms are fast, but understanding where things are after they've been transformed is hard. JS layout is also somewhat prone to problems with things like browser zoom level, OS display scaling (although I've not seen that be an issue in a couple of years), differences between browsers and browser versions, and so on. Layouts with CSS, so long as you're being reasonably conservative, do work quite well in 2020.
I agree that there's lot of benefits and certain elegancy by sticking with CSS layouts.
CSS transforms are really just an visual effect, not affecting the layout. That's why they are super fast (typically HW accelerated by GPU), but not suitable for defining the layout.
Managing the DOM in JS may be order of magnitude slower but is still fast enough, actually surprisingly fast. It's common to implement 60 FPS animations e.g. in React. Of course the performance heavily depends whether the manipulation causes a layout reflow etc, but generally speaking, DOM is pretty fast nowadays, and most sites/apps are not _that_ performance critical (such as games). Yes, it's not uncommon either that a complex JS app becomes slow, but that's mostly because of inefficient programming / generally bloated app, not because the layout is done by JS instead of pure CSS.
Browsers already have "alternative" APIs to make totally non-DOM interfaces, such as canvas (2D) and WebGL (3d). Nothing prevents to come up with alternative layout/UI libraries written on top of them. I'm sure such a libraries exist. Why it's really rare to utilize non-DOM UIs is probably due to many reasons, i.e. compatibility issues with exotic/older user-agents, devs being more familiar with DOM based solutions, etc.
After all, I think DOM works pretty well even for app-style UIs. Actually, many "native" technologies don't offer as easy responsive layouts, user-settable font-size, etc, which comes almost for free with DOM. There's lof of beauty in the DOM, despite its document-oriented origins.
(Oh, I just typed out some mind flow of mine, maybe a bit off-topic.)
> Browsers already have "alternative" APIs to make totally non-DOM interfaces, such as canvas (2D) and WebGL (3d). Nothing prevents to come up with alternative layout/UI libraries written on top of them. I'm sure such a libraries exist.
>Measuring DOM elements and moving them around in JS is quite slow.
It is not an inherent property of js-controlled positioning. Browsers don’t have direct measuring methods and require stupid workarounds, that’s it. Measuring text layout (most complex thing) in wfh/hfw in js is as fast as in css, because it is just el.getSizeForW(w) and then c++ does the thing as usual. There is no black magic in calculating layouts, it is arithmetic.
>JS layout is also somewhat prone to problems with things like browser zoom level, OS display scaling (although I've not seen that be an issue in a couple of years),
It’s not a property of js either. If a browser provides a stupid internal api that requires manual accounting to zooms and dpi, then css implementation is also prone to that.
>differences between browsers and browser versions, and so on. Layouts with CSS, so long as you're being reasonably conservative, do work quite well in 2020.
The problem is that apps are not conservative, apps want innovation instead of a text layout that spends 20 years to learn a proper vertical alignment.
> Browsers don’t have direct measuring methods and require stupid workarounds, that’s it.
Oh? There are the old-school e.offset{Top,Right,Bottom,Left} etc methods for measuring the DOM stuff, and there's Visual Viewport API (experimental) for more advanced use cases:
It doesn’t work correctly until you root your element into the document under a proper div hierarchy (to simulate all selectors) and wait for it to half-render, and then you remove it, which causes entire document to reflow twice, which is a “stupid workaround” part. With this API you cannot “measure” anything, you can only check what was the result of an already computed and pre-heated flow.
Soo my styling would be split 37% / 63% between my business logic and CSS files, with one million Medium posts telling me how to hack that weird combination from hell into specific looks? That sounds truly horrifying!
