And as for Firefox on Android, I have plenty of hope for it. I'm seeing more and more people switch to alternative browsers for speed (the most common one is samsung's "browser" which everyone says is "super fast" but really only is a weird hack to make scrolling smooth which breaks a few standards).
Ios is another story, but at least on android if they make a damn good product, people will use it.
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.
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.
[1] https://www.mikeash.com/pyblog/performance-comparisons-of-co...
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.
[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
You make it sound like these are two orthogonal aspects. When rendering is faster, CPU usage obviously goes down. As does battery impact, since the CPU can go back to a sleep state faster.
Only as much as its the rendering, and not the core logic that consumes the CPU.
Degenerative case: a page with a single text entry field, where you enter a number and it calculates e.g. the fibonnaci sequence up to that number or factor primes etc. There's hardly any rendering, but lots of CPU.
Unless Firefox (and Servo) gets it GUI to not feel alien and clunky, it wont matter if it has a faster rendering engine. Rendering engines are plenty fast as it is anyway, it's CPU use and battery impact that matters to users. And when performance does matter, it's mostly Javascript performance, which Servo doesn't address.
It also wont matter for mobile, since Android will still keep Chrome browser, and iOS will still keep Mobile Safari -- they're both made by the platform's creators.