Live data from Hacker News

A Quantum Leap for the Web

medium.com

61–70 of 141 posts

Re: A Quantum Leap for the Web

#61

Heh. It's interesting to me that in the vernacular a quantum leap is a large change while in physics it's a very quick, extremely tiny event.

"Although changes of quantum state occur on the sub-microscopic level, in popular discourse, the term "quantum leap" refers to a large increase.[5]"

Isn't that more or less what I said?

Re: A Quantum Leap for the Web

#62
post #38

we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months. From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows. A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching…

Mozilla engineer Bill McCloskey describes how Quantum DOM will use both multiple OS processes and cooperatively-scheduled, user-space threads to preempt and throttle iframes and background tabs:

https://billmccloskey.wordpress.com/2016/10/27/mozillas-quan...

Re: A Quantum Leap for the Web

#63
post #38

we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months. From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows. A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching…

Servo has a solution for that: it runs all origins in separate threads. (Note that this goes further than Chrome does; Servo runs cross origin iframes off the main thread too, while Chrome does not.)

Gecko is solving this too, with Electrolysis and Quantum DOM. But because the architectures are so different at the DOM level (direct bindings vs. an XPCOM/direct binding hybrid, tracing vs. reference counting, off main thread layout vs. main thread layout, Rust serialization vs. IPDL, etc.) the Servo solution doesn't directly apply to Gecko. So Gecko and Servo are working on their own solutions mostly independently, rather than sharing code as in most of Quantum.

Re: A Quantum Leap for the Web

#64

This sounds to me like Mozilla is getting impatient with Servo. Servo was more than just a parallel browser engine it was the only new web engine not based off of decade old codebase. It was a statement that it's feasible to hold off on monoculture because compatibility isn't impossible to achieve on new engines.

Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" switch with behavior specified for both branches. :(

> Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit"

woah! that's truly tragic.

at the risk of ruining the rest of my week, may i ask where?

Re: A Quantum Leap for the Web

#65
post #10

Does anyone know how this compares to the current implementations of competing browsers? ie. is Firefox still playing catch up in some respects or is this leaps ahead of the competition too?

I think performance of the style systems in Blink and Firefox are similar. Since Servo's style system is linearly scalable, we expect most users to get a ~4x speed improvement on styling. Users's don't care specifically about style performance, though, but about things like interactivity. We think Servo's style system will improve those things, but don't have numbers for that on hand. To give a concrete example, it t…

Just curious, has anyone seen if there are performance improvements in Javascript DOM manipulation (eg adding elements or attributes in JS)?

Re: A Quantum Leap for the Web

#66
post #38

we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months. From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows. A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching…

You can alleviate this problem by increasing dom.min_background_timeout_value.

Re: A Quantum Leap for the Web

#67
post #10

Does anyone know how this compares to the current implementations of competing browsers? ie. is Firefox still playing catch up in some respects or is this leaps ahead of the competition too?

Here my experience with the current Firefox compared to Chrome :

- Firefox consumes way less ressources than Chrome. I can open 20 tabs it will consume a reasonable amount of memory.

- Firefox crashes way more often than Chrome. I get a crash everyday mostly because of a aggressive Javascript found in pages riddled with ads that abuse tricks in order to force the viewser to see ads ( Adblock can help )

- Firefox is way slower when it comes to Javascript execution than Chrome, no question and it looks like it supports less HTML5 features than the competition.

If Servo can effectively limit Firefox crashes then the investment is worth it. Because that's tne most annoying thing with Firefox. But the amount of memory used by Chrome is just unacceptable, along with spawning 20 processes just because they can ... Chrome is a memory and resource hog.

Re: A Quantum Leap for the Web

#68
post #38

we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months. From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows. A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching…

> A problem that Chrome has solved years ago.

The trade-off is the crazy amount of resources Chrome uses,even on a multicore machine. 20 process spawned and shit like this can bring down any computer. Chrome resource usage is excessive.

Re: A Quantum Leap for the Web

#69

Earlier quoted context omitted.

How does WebKit's JITing style system compare? (As far as I'm aware, nobody else has anything like it, though it is still single-threaded as far as I'm aware.)

I would eventually like to look into a CSS JIT. But I would not like to just copy WebKit—I would like to look into treating CSS as a global DFA and compiling accordingly instead of looking at local optimizations only. As always, the problem with JITs, especially on the Web, that it's hard to beat the interpreter when you take compilation time into account, and most selectors you see in the wild only apply to a small…

For context, [here's an IRC discussion about implementing style matching as a single global DFA, and what it's tradeoffs would be](http://logs.glob.uno/?c=mozilla%23servo#c550146).

Re: A Quantum Leap for the Web

#70
post #34

Earlier quoted context omitted.

Speaking for myself, I don't want "Servo components" in Firefox; I want Servo in Firefox. I want an engine as fast as the one they have shown of Servo as being; not pieces of it that make Firefox incrementally better; I want a browser that is miles ahead. That's always what I found interesting about Servo.

Even if you don't care about Gecko, this benefits Servo. It lets us battle-harden core components like WebRender and the style system.

It also benefits the Rust language for the same reasons. Firefox is already shipping components compiled in Rust[1].

[1] https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/

Post reply on HN