Hacker News Reader

Comment by hacker_9 | Hacker News Reader

> The world needs a new browser engine

> As a non-dev

I expect you are just responding to the inherent lack of performance that the javascript + html + css bundle shamelessly provides, which Servo will do nothing to sort out. Webassembly on the other hand is the first step to bringing superior performance to all browsers.

View on HN

Improving HTML + CSS performance is absolutely one of the goals of Servo. Here's a video from pcwalton demonstrating reflow (HTML), repainting, and CSS animations on the GPU in Servo: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... (much of this code is being uplifted to Firefox as WebRender). It's true that Servo won't have any effect on Javascript performance, but WASM won't have any effect on HTML or CSS performance.

I understand that, but the idea that HTML + CSS can only be sped up by some hugely parallel structure requiring a whole new programming language and browser engine is really quite shocking. I think once webassembly is established and in use, we will start to see steps in the direction of replacing HTML + CSS altogether, with something that has performance in mind.

A new programming language is not required, it's just a bonus to help developers handling safety and concurrency.

It seems like a valid point that many of the details of HTML and CSS, while you can use all kinds of fancy techniques to make them a little faster, impose limits on performance.

It's true that the DOM is a bottleneck on many apps (I don't think anybody is disputing that), but "a little faster" undersells what Servo is trying to achieve: order-of-magnitude speedups on GPU-parallelizable tasks, and at least factor-of-two speedups on CPU-parallelizable tasks, all while providing stronger guarantees WRT user security than any contemporary browser.

If you mean throwing out the DOM entirely for something canvas-based, I'm sure that will happen in some cases but I'm very skeptical that it will ever be anything close to the dominant paradigm for the web.

If you listen to talks about the design architecture of Servo you will understand the HTML CSS is not the problem. It actually is an advantage when you want to build an engine that works like a high performance game engine.

I'm not so sure. I remember a presentation of Webrender with nice demos : https://www.youtube.com/watch?v=erfnCaeLxSI&spfreload=10

Everything was perfecty smooth, but according to pcwalton the bottleneck was CSS handling.

It's building an engine from scratch as opposed to using legacy code and design decisions.

Why wouldn't you expect that to be faster?

Servo doesn't really do anything for JavaScript (which is pretty much as fast as it's going to get, thanks to all the hard work of the V8, Spidermonkey, and SquirrelFish teams). But speeding CSS up is kind of the whole point of Servo.

And not just "CSS" but the whole DOM itself, which is more often than not what most people "perceive" as the slowness with web apps (and the entire reason why virtual-DOMs have caught on)

One of the things Servo gives us is the ability to experiment with new models for scripts to interact with a page. Imagine an IPC-based API exposed to WASM for instance.

The concurrency story could also expand on the limited capabilities of web workers support for shared memory.

Servo plus browserhtml could become a nice alternative considering that mozilla plans to kill XUL and thus firefox interface customization.

More that half the browsers I experience crash or freeze on a constant basis, and yet Chrome seems to handle it in significantly more cases.

Would web assembly help out with desktop web applications running on stuff like electron?

It can help there exactly as much as it can help non-desktop web apps.

Reply on news.ycombinator.com