A point of reference

Ben Bucksch 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 
times there.

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 
even faster.

> 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 
> react.

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 mailing list