Somebody in Chrome should probably look into optimizing ::highlight() selectors because that stuff should go at the speed of light (we know all the matches from the start because the user told us), but it doesn't seem to be, at all.

I don't get how capturing tracing information from a Chrome instance containing only one tab that is not even filling the screen with content and is using about 400 body elements could possibly take over a minute (I had to kill it). Did Chrome hire people trying to make things slower or something?

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

Very interesting how just changing an inline style on an element, which changes the "cursor" being rendered, triggers a style/layout/paint recalc for the entire page in Chrome 🙃 By far the biggest structural performance issue on the web is how rendering works, imo. What are we doing about that?

Borderline criminal the size of an avocado seed.

I wonder how much of a difference profit-wise would be for Tesco to use different baskets. The have ones that are very heavy (metal instead of plastic), oddly shaped (they could carry much more stuff without feeling bigger), and with unergonomic handles (thin metal ones that dig into your hands).

Is there any on-demand CI where you send them the commands to execute and they just run them and give you stdout/stderr back? I'd like to add support for executing my tests ~anywhere to my test runner, but I don't want a github-style CI thing, I just want an extra --flag and my existing workflows.

I touched moss, does it count?

Your outie hates each re-render equally

Some incentives are interestingly different with signals: if you make a component a controlled component or not then updating it costs the same, but with a VDOM if the state lives in the parent now updating it is potentially much more expensive, so you are kinda incentivized to do the wrong thing 🤔

New package, which is actually a benchmark: "json-simple-parser", the fastest pure-JS implementation I could come up with for a JSON parser. Somewhat useful for benchmarking parser generators, or perhaps JS itself, or different engines, or if you like really ugly code? github.com/fabiospampin...

I just asked chatGPT to clean up a truly awful JSON parser, and surprisingly the code it gave me still works. It converted it to (nicer?) OOP garbage and it's some 70% slower though. But then I asked it to not make it slower, and it still gave me OOP garbage that's only ~13% slower. Pretty cool.

Arrow functions seem special in that you can often easily detect when they don't use any of their arguments for sure, like this: ```ts let {toString} = Function.prototype; let isNullaryFunction = typeof fn === 'function' && fn.length === 0 && toString. call(fn).startsWith('() =>'); ```

Does anybody know what the fastest JSON parser written in JS is? I'd like to check how mine compares against it. github.com/fabiospampin... 👈