Bundle size matters until it doesn't. Flutter is absolutely not suitable for web pages, but for web applications the situation is different. I was quite hesitant about Flutter web, up until around 3 years ago, the binary size being biggest concern. That was until I looked at Linear (which we used back then) and found out that the download is several times larger than whatever we were building with Flutter web, and nobody cared. I used to obsess about every kilobyte transferred, but I think at least when it comes to applications, that time might be over.

Technically, it’s not just about the download pipe. A 2MB+ WASM blob or JS bundle imposes a heavy CPU parse/compile tax. On mid-tier mobile devices, this results in main-thread jank and a 'Time to Interactive' (TTI) that kills user retention before the first frame even renders.

Beyond that, the 'Canvas-only' approach is computationally expensive. You are effectively re-implementing a rendering engine (layout, hit-testing, paint) on top of a rendering engine. While the browser's native DOM/CSS engine is a highly optimized, hardware-accelerated C++ powerhouse, a Canvas-only app has to manually calculate every pixel and handle every event in the WASM/JS loop. This drains battery faster and runs hotter than letting the browser do what it was built for.

It has been like that since the very beginning (sky engine).

That is absolutely not true. Elements with dirty layouts are tracked and layout is only recomputed up to the neearest layout boundary.

Weird, it looks like you're right but I recall their early marketing saying stuff like just rebuild the whole layout, it's cheap since it's compiled. They must have meant it's cheap to rebuild as needed haha

I'm looking at the code but I don't quite see that?

  auto start= result.indexOf("http://");
  ...
  auto end= result.indexOf("\r", start);
  ...
  m_describeUrl= result.sliced(start, end - start);

I don't think end can ever be < start (other than < 0 if not found, which is handled).

Because I'm dumb