> If we're talking about e.g. Electron apps, the problem I see mentioned (and felt myself) is almost always the memory hogging, the GC-pauses, the battery impact and such -- not the rendering speed.
I see the opposite. VS Code feels somewhat slow, mostly because of rendering—it doesn't hit 60 FPS.
You cite GC pauses. One of the best ways to mitigate GC pauses is to move the noticeable rendering logic off the main thread so that your app doesn't freeze during GCs, which is precisely what Servo is designed to do.
> For something like Atom, is the slow redrawing because "DOM is slow" or because "doing the calculations needed for a sizable file, with syntax highlighting regexes, compiler checks, freeing memory, etc takes lots of processing time"?
The performance differential is because of many things, but regex performance and freeing memory relative to native aren't among them. JS engines' regex engines are best in class and easily exceed the performance of popular C regex libraries; this is a side effect of SunSpider and V8 including regex benchmarks. Memory deallocation in popular JS engines is faster than in native, because sweeping takes place all at once and generational GC nursery evacuation is very fast.
> That's not entirely true, as Objective-C dispatch was thoroughly optimized [1].
Those numbers are precisely what I'm referring to. In most cases, JS method dispatch is more like a C++ method call or an IMP-cached message send than a slow hash table lookup. Often it's even better, because the inliner kicks in, while inlining is very difficult in Objective-C. Objective-C's "fast path" is the slowest path in JavaScript, one that's only hit for megamorphic call sites.
> Besides, the performance differential is also in the time to process logic (and the network latency) which you don't address.
Pure computation in most apps is not appreciably slower for the end user in JS than it is in Android or iOS. And if it is, there's always Web Assembly! We're doing lots of work to improve JS performance; it's just not all under the Servo umbrella.
> And of course, aside from rendering (which often is just "show a few forms, buttons and lists" for most apps) a part of the heavy logic in Objective-C for lots of tasks is done in C or C++ frameworks at much faster speeds than modern JS engines.
That same "heavy logic"—by which I assume you mean audio/image/video decoding, JSON/XML parsing, image filters, vector graphics work—is also done in native code in browsers. And it's those very same tasks that we're optimizing in Servo.