esprehn

Also the specs are written to define observable behavior, and there's a fair bit of ambiguity that's UA defined, but to be actually compatible with the Web requires doing what Chrome does.

The good news is that you can look at the source of the 3 major engines (and Ladybird!) and your AI agent can do comparisons and figure out optimizations.

Comment · 1 month ago

Have you tried something like "Always consult the utils/ package before writing helper functions. When adding a new generic helper function justify it in your design or PR description."

I have better luck telling it positive things rather than lots of "never do X" style things.

Comment · 1 month ago

The implementation of the Web APIs look very broken and incomplete: https://github.com/h4ckf0r0day/obscura/blob/main/crates/obsc...

This might be faster in some benchmarks, but it's not really implementing the web.

I'm more optimistic about AI browsers based on Ladybird or Servo which are actually trying to pass WPTs.

Comment · 2 months ago

Larry designed the algorithm and Brin implemented it. Not so different than what we saw with transformers and LLMs. The people who came up wit the ideas and the algorithms were joined by others who implemented them. Together they made it all work.

Comment · 2 months ago

You can animate it now. There's no default though which is a bit annoying. I wish we had made it animate open/closed smoothly.

https://austingil.com/animating-details-element-with-only-cs...

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...

Comment · 2 months ago

Script attributes are very often disabled for security reasons.

The declarative actions API is currently only used for popover, but it's been discussed for over a decade to allow SSR of rich content that's interactive before script loading. See also https://developer.chrome.com/blog/command-and-commandfor

For a long time I also pushed back on these interactive APIs because script is a better primitive and every site seems to have quirky requirements. I've come around on it though because there's huge demand for SSR again and businesses are seeing the value in very fast TTI.

I do still think the date picker API is a disaster. Everyone actually needs something much richer than the system date picker. Travel websites want ranges. People want to put dots and day highlights. I wish they'd fix that next.

Comment · 2 months ago

As opposed to what? Not sure what the alternative you're picturing is.

Comment · 2 months ago

There were a lot of factors that led to the dart decision. It's also important to note that Flutter is very old, we were designing it in 2014.

- we wanted hot reload

- it was supposed to feel familiar to web developers and reasonable to native developers

- iOS needed AOT compilation for speed since we couldn't use a JIT

- TypeScript had literally just reached 1.0

- Swift looked promising, but the Oracle lawsuit made the idea of using it tenuous

- Kotlin was not even 1.0 yet, that wouldn't happen for 2 more years

- Go made huge binaries. The language was also lacking features like generics and Go was unwilling to add them (remember this is 2014).

- v8 was not interested in AOT, but Dart was willing to dramatically invest in flutter

There were probably other reasons too I'm forgetting.

Dart was a really pragmatic choice to ship quickly. I have mixed feels about how the decision has aged over time, and wish we had things like Hermes and WASM back then, and a willingness to build a TypeScript compiler like other native frameworks (ex. Valdi)... But for the time I think the choice was reasonable.