Fortunately in 2022 they added new prefixes 😂 I don't know if I like the sound of "rontomatch" and "quectomatch" that much though.

The thing to understand is that this stuff is just not well optimized 🤣

On the other hand regexes in my experience have been a rare glimmer of beauty in the programming world. A pleasure to work with, expressive, powerful, compact, predictable execution, predictable-enough performance, and a correct implementation (as far as I've seen at least), which is huge.

CSS itself is messy, there's no visible link between how "contain: paint" and "position: absolute" interact, you just need to know, and there are thousands of possible interactions like that to consider. A ton of new (buggy!) features have been added. The tooling was never there. Perf is a gamble.

That's not accurate for me: the DOM barely changed for me in the past 10 years and its understandable (but ugly), I don't care for the Shadow DOM, I use my own framework with a lot of nonsense deleted (imo, of course) that other "modern" approaches bet on, I don't use stuff that abstracts CSS etc.

That said I haven't seen something as expressive and easy to use as CSS, a ton of very nice features got implemented for it in recent times, and fundamentally it seems to be tackling a much harder problem than a regex engine is, so I'll cut it some slack.

Also there is a lack of tooling for understanding what work CSS is actually causing, or why that needs to happen, its performance is much less predictable than the performance of a regex engine, and CSS work can happen for ~any reason, it's not like a regex that _you_ explicitly execute somewhere.

CSS on the other hand is a mess of hundreds of properties, potentially all interacting with each other in very non obvious ways. Last week I reported 2 Chrome bugs about some CSS features messing things up when used together, I've never seen anything like that for regexes, that would be insane.

There's a huge difference here though: the people that don't like CSS are right 🤣

One can run most regexes in their head, sometimes with some effort, and when that's not possible tools exist to step through the execution and stuff like that, the understandability of regexes is a solved problem.

Very similar for visual stuff: for apps the UI doesn't want to attract attention away from the usefulness, for art the UI wants to attract the attention and there's no "usefulness".

At least you got a good number, it might have been annoying if you had gotten -73

Download images: 3831ms
Download webfonts: 1912ms
JS execution: 34ms
DOM reflows: 1109ms
Ad loading: 2019ms

Someone who can write a JS-to-native transpiler please help, my webpage performance is dying

In general Meta seems to give employees kind of a lot of freedom, like if you have the time you can submit PRs for ~anything. You can have even more freedom if you don't care too much if you get fired because what you didn't wasn't valued enough 🤣

I joined a team that was meant to work on this kind of stuff, unfortunately there has been an internal reorg and we are supposed to be doing something else now. I'm ~finishing up some past work at the moment, will see how it goes after that 🤷‍♂️

Needless to say that that I have zero selectors matching on the value of that style attribute. And actually that kind of thing may be a huge area to explore for optimizations: what if there was a way to attach styles and ~classes that can't be targeted by anything else?

Did you consider porting tsc from typescript to javascript?? The port could have been fully automated, which would have been a huge advantage compared to porting to go.

I'd love to eventually ditch inputs for a use case of mine in order to make them little 1-line editors, with support for multiple cursors and other editor stuff.

GraphQL+Relay? Or was it a partial downgrade?