Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I suspect part of it might be interactive-ity with the event loop: let me explain.

I regularly have to use web browsers (I try and want to use Firefox, but Chrome is faster for me in this scenario) on an under-provisioned (yes I know, but I don't have any control over that!) VM which runs VDI sessions on both Linux and Windows (with VMWare on Windows).

On both Windows and Linux, Firefox's UI (in this CPU-constrained env - it fluctuates, and sometimes is okay, but often is slow) in terms of UI interaction is very notice-ably much slower than Chrome, especially when there's animated content in the document. It seems like Firefox prioritizes thread-wise the HTML/JS content at the expense of any UI signals/presses/drags or other interaction, and so sometimes clicking close tab does nothing for > 30 seconds, but animated content within the document keeps playing perfectly.

Chrome does none of this (on same VM machines) with same content: I click the close button, and instantly a tab closes, or I can drag a tab around instantly.



I think that Chromium’s UI stack is also just more solid, being closer to “native” and being drawn with Skia and such, as opposed to the Firefox approach (previously XUL, which was always slow and clunky and later switching to a web tech based UI).

There used to be Gecko based browsers that fixed this with alternative native UIs (Camino, K-Meleon, and Epiphany aka GNOME Web), but then Mozilla removed embedding support and ever since anybody wanting to use Gecko are stuck with the design decisions of the Firefox team whether they want to be or not.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: