> Rendering engines are plenty fast as it is anyway, it's CPU use and battery impact that matters to users.
That's at odds with almost every single sentiment I've seen regarding native vs. Web apps. Take one look at any HN thread about the two.
> And when performance does matter, it's mostly Javascript performance, which Servo doesn't address.
If that were true, then there wouldn't be a performance differential between native and Web, since Objective-C and Dalvik are slower than modern JS engines. (Look at how method call dispatch works in Objective-C!)
Besides, a lot of what shows up as "JS performance" in a profiler is actually blocking on DOM operations. With off-main-thread layout, these operations can be done in the background, resulting in improved DOM performance.
>That's at odds with almost every single sentiment I've seen regarding native vs. Web apps. Take one look at any HN thread about the two.
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. Although, there is talk of getting to 60fps web apps etc.
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"?
>If that were true, then there wouldn't be a performance differential between native and Web, since Objective-C and Dalvik are slower than modern JS engines. (Look at how method call dispatch works in Objective-C!)
That's not entirely true, as Objective-C dispatch was thoroughly optimized [1]. Besides, the performance differential is also in the time to process logic (and the network latency) which you don't address. 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.
> 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.
Modern JS is pretty fast yeah, but I still don't think it rivals Objective-C does it? If we stipulate it's 1/2 as fast as Swift, it's still much faster than v8 on the benchmarks game [1]. Can you be trickier with JS code than those toy programs are?
Well now that I think about it, maybe in the context of your original argument a comparison against Swift makes sense. It's hard for me to see JS ever being competitive with Swift or a similar compiled language.
That's at odds with almost every single sentiment I've seen regarding native vs. Web apps. Take one look at any HN thread about the two.
> And when performance does matter, it's mostly Javascript performance, which Servo doesn't address.
If that were true, then there wouldn't be a performance differential between native and Web, since Objective-C and Dalvik are slower than modern JS engines. (Look at how method call dispatch works in Objective-C!)
Besides, a lot of what shows up as "JS performance" in a profiler is actually blocking on DOM operations. With off-main-thread layout, these operations can be done in the background, resulting in improved DOM performance.