Hacker News Reader

Comment by zogrodea | Hacker News Reader

Unrelated, but I'm impressed by how fast browsers can be in some cases.

I once created a HTML file with just a start/end HTML tag and 50k (unstyled) button elements in between, curious to see how it performs. I tried the same in Flutter on a release build (using Material widgets so they are styled) and the HTML was much faster.

I was able to tab through (changing focus by holding tab) the buttons in both Chrome and Firefox at a consistent frame rate with no signs of any lag, while FLutter struggled and lagged quite a bit with the same.

Would anyone know why that is? Are web browsers hyper-optimised for static documents (beating a "native" GUI toolkit for static documents)? Is Flutter just comparatively slow compared to Qt, GTK and so on? Does the styling have that much of an impact on performance?

I am aware that updating DOM elements is uniquely slow for browsers but this experiment was a surprise for me and I'm curious for an explanation.

View on HN

> Are web browsers hyper-optimised for static documents (beating a "native" GUI toolkit for static documents)?

Yes. The browser is the world's most widely deployed and used runtime. I would assume Blink, WebKit and Gecko are the three most carefully optimised pieces of software ever.

If you want performant styling stick to CSS.

CSS can certainly be performant but you need to be aware of what can trigger reflows, which will absolutely destroy your performance. Cascading reflows are horrible.

Can you share your code?

I will in a bit hopefully. It was a few months ago and I don't have Flutter installed on this computer but I'm doing it now.

Edit: I was coding it up now, but my storage is full (having trouble copying text to my clipboard and unable to save files) so I don't think I will be able to deliver on what I intended. Sorry about that.

On the HTML side, I had a code generator (in Javascript) that output `<html> <button /> <15000 more buttons.../> </html>` and wrote it to a file.

On the Flutter side, I used the default Flutter sample app (`flutter create .`) and I just used a similar code generator to put 15000 buttons in a Column widget.

I don't think I'll be able to do much else to help with reproducibility sadly.

If others try the same, I would be interested in if their results are any better than mine (with Chrome/Firefox being faster).

I think if you use ListView.builder() in Flutter instead of a Column you will see much better results - it ensures that Flutter does not have to layout 15k buttons all the time, just those that are visible.

Of course, it's unfair to allow Flutter to have optimizations but not the raw HTML, but disallowing well-known, real-world optimizations is also an unfair test IMO.

https://api.flutter.dev/flutter/widgets/ListView-class.html

Desktop toolkits expose list/scroll virtualization to apps natively and expect you to use it, so they aren't optimized for the case of a giant single vertical layout. HTML doesn't so devs are forced to just throw piles of markup at the browser which has to digest it all.

But, that's a very web-specific UI design idiom that you just don't find in typical native apps. If you change your test to use desktop UI as it's intended to be used, and then stick say a few tens of millions of buttons in it, then the browser will find it much harder and the desktop toolkit won't break a sweat.

Reply on news.ycombinator.com