A point of reference
ben.bucksch at beonex.com
Wed Mar 7 21:15:49 UTC 2018
Joshua Cranmer 🐧 wrote on 07.03.18 21:11:
> For Atom, one thing they did call out was that the DOM and CSS
> performance was way too slow for their needs
I'm not surprised. Atom is an editor, and it works a lot with the DOM.
For every keypress, it modifies the DOM, which puts the engine under
stress. Atom probably wants to do syntax highlighting, or even
potentially more advanced things like incremental compiling in VS Code,
which happens in the backend. So, there are a lot of DOM modifications,
and a lot of ms-sensitive back and forth between the frontend, and the
backend. Some operations like a background compile result might change
the entire DOM of the window, to highlight errors, identifiers etc. So,
this is a challenging task.
However, DOM performance has nothing to do with JS performance. And a
C++ implementation of a backend module would not help with a bad DOM
Given what I read about Electron, it probably does a lot of data copying
in their frontend/backend data exchange and the marshalling. So, that's
something to have an eye out for.
In Thunderbird, probably the most time-sensitive operation in the UI
would be scrolling through a folder. Users expect millisecond-reaction
We also have an editor to write emails, but that's far less advanced
than Atom or VS Code. We only need HTML editing, which many other
projects already need and do. And Gmail already does that in a web UI.
>> Today, most webapps are incredibly slow. But they are slow, because
>> the developers are loading MB large JS libraries to do some
>> animations. Of course that has to be slow.
> So you're saying you've specifically measured the performance of these
> apps and found that the loading of the large JS libraries was the
> primary cause of the slowdown, and that you were able to eliminate the
> use of those libraries, not retard functionality, and achieve
> significantly better performance? Or are you just looking at the size
> of those libraries and saying "gee, that must be why you're slow" and
> moving on?
Case in point: I implemented the same app in Ext.js and then
reimplemented it in Angular, and found dramatic (around 10x, IIRC)
performance improvements. An implementation without any libraries was
> I do agree that you need to measure performance to understand what the
> issues are and how to improve it, but it is possible to make general
> comments about performance and have some idea about how things should
It's possible to say that callfunction("dosomething") is going to be
slower than dosomething().
Statements like "JS apps are too slow" are too generic to be useful.
Otherwise, Mozilla wouldn't exist in the first place. People said "JS
apps are too slow" back then, too. Mozilla was a crazy idea, when they
started in 1998: Writing a desktop app UI in JS was simply nuts. It
didn't work by chance, either. They *made* it work.
> There are some reasons to doubt the performance of JS implementations,
> not least of which is demonstrated lack-of-performance in some recent
> rewrites. I think there is enough reason that we should make an honest
> and earnest attempt to actually assess what the performance would be
> using JS versus using another implementation (such as Rust), and
> whether a JS implementation would be sufficient.
Agreed. The only way to find out is to try and measure, though. That's
why I propose: Start with JS. Use good programming practices (e.g. avoid
code in strings, avoid bloated libs, avoid copying lot of data etc.). If
we are too slow, measure and investigate where it's slow. Then, optimize
that. If we do find that we can't get a certain component - e.g. the DB
- fast enough in JS, we can still replace it with a native component.
If we start with a complex setup like half JS half Rust from the get-go,
we have project that's more complex, takes a lot longer to build before
having something useful, and we'll have a lot less contributors.
Thunderbird's biggest problem is the difficult learning curve for
contributors and deep technical dept caused by the C++/XPCOM/JS
symbiosis. I don't want to repeat that unless *proven* necessary.
Minimum viable product. Crawl, walk, run. And yes, crawl may be slow.
But if you try running right away, you'll never leave your spot. Which
is where we are since 3 years.
More information about the tb-planning