I strongly disagree with that MDN is a mess, it is one of the best places to find good documentation about web development. Especially for the more advanced topics. For example I had issues with the Math.round() method, and at MDN they have a great example of how to fix it! https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This is just one of many examples!

> Servo is an "experimental" browser engine. While Chromium is cranking out features, servo is yet to reach version 1.0.

This would be a more convincing point if any of memory safety, parallel styling, parallel layout, retained mode rendering as suggested by the GPU vendors, and so forth were on Chromium's roadmap.

I agree with you, but in the end it is a Beta vs VHS uphill battle.

I'd be more than willing to hear your technical thoughts as to why the features I mentioned are not "100% proven better" than the status quo. From my point of view, having measured this stuff over and over again for years, it's undeniable that they result in wins. The remaining bugs are features at the margins and will not affect the overall results. You seem confident, so I'm sure you have specific technical reasons, right?

> Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value.

Doing nothing is an even bigger risk.

I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?

The question isn't whether you should or shouldn't try to improve, it's where to invest your resources. Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. I don't think the sentiment is "lets be complacent", rather that Servo is optimising in the wrong places. We need to fix the web platform so that apps don't need to rely on performance killing techniques. Servo is cool, but I don't think it's solving what really ails the web.

Disclaimer: I work on Chrome.

> Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. We need to fix the web platform so that apps don't need to rely on performance killing techniques.

This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).

The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo.

The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.

To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.

I have never implemented a custom layout in JS because the browser's layout is slow. My JS-based layouts are always slower than using CSS.

I do layout in JS because the existing layout capabilities don't cover my use cases. I create complicated visualisations in SVG, and SVG's layout capabilities are so pathetically anaemic that I have no choice but to take over and use a mixture of D3 and custom JS to arrange things.

Similarly, I don't do synchronous layouts because I'm a moron who doesn't understand performance, but because I need to measure the size of various data-bound elements and feed those dimensions back into my custom multi-pass layout algorithm.

AFAIK, Houdini is an actual attempt to solve both of these problems: It will let run my custom layout algorithm in a worklet, and give it access to the font metrics and element sizes it needs to run efficiently.

The Houdini people seem to be the only web platform people who actually "get it" with respect to these kind of problems. Everyone else seems to be either ignorant or dismissive that these problems even exist.

If you're actually using Houdini for custom layouts (including SVG—SVG doesn't really have any layout at all), then I don't have a problem with it. My issue is more with the performance-oriented Houdini specs, for example Animation Worklet.

I think that's a bit unfair to Houdini. As others noted here, one of the main goals for Houdini is to make CSS cleanly extensible, so every time some cool new feature comes along you don't have to choose between a) waiting for it to be standardized and implemented in browsers and b) abandoning CSS entirely.

Of course, I agree with the rest of your points.

That's fair. I don't have an issue with Houdini if it's actually used to create custom layouts that you can't reasonably do in CSS.

> which means that layout performance affects what looks like script time

Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading.

> And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).

I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it.

> If layout were fast, we wouldn't see people implementing layouts in JS

Are people re-implementing layout/paint because it's slow? Or because we didn't bake in the little detail they want into the platform through a multiyear standardisation process? I think it's naive to think developers will just stop writing JS if the browser gets x% faster.

> If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.

I disagree. Developers will always find something to fill it with. IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms.

I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive.

In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web. Lets all innovate independently and let the results speak for themselves :).

> I think this is a great example of how having multiple rendering engines is healthy for the web.

Yeah, it's too bad that Google's Chrome-first/Chrome-only approach to Web development these days is making that increasingly difficult to sustain.

> Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading.

If you can multithread iframes, then I think Amdahl's Law will start to kick in unless you improve style and layout performance. For instance, if I block the ads on washingtonpost.com, then style + layout is nearly as big as script.

But in any case, you have to look at how that affects the user experience. If done properly—i.e. everything remains responsive—the user won't notice slow script very much.

> I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it.

Servo definitely does address it, because it runs all cross-origin iframes in separate threads (and has from the beginning). Even same-origin iframes get separate style/layout threads, even though they share the same DOM thread. It can also do process isolation, as ipc-channel lets us abstract over the thread/process distinction.

I think multithreading is a more scalable solution for performance than process isolation, because with process isolation you need heuristics to avoid ballooning the number of processes out of control. You could have a throttled "ad process", but then you'd have to figure out what the ads are and hope you don't mess up, or else you might hurt iframes that matter. It's a lot simpler to just put separate origins in separate threads to begin with.

> Are people re-implementing layout/paint because it's slow?

Yes, because they've been told to use CSS transforms instead of real layout because those "run on the GPU".

> I think it's naive to think developers will just stop writing JS if the browser gets x% faster.

They won't, but we can certainly help things along a lot by making it easier to just use the platform. (I think we're in agreement here.)

> IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms.

I agree with the general principle, but I disagree with way it's implemented in existing browsers. The compositor thread is super limited; it's a thing that handles a weird subset of CSS that you have to be careful not to fall out of or else your performance drops. This is no way to treat Web developers! It's a historical accident, too, one that stems from the fact that Core Animation was developed independently of Mobile Safari for the iPhone 2G, Mobile Safari retrofitted a subset of CSS to that API, and then everyone copied Mobile Safari.

It makes more sense to have a dedicated thread for all style and layout and another thread for all painting, eliminating the paint/composite distinction. No matter what you do, the styling/layout runs off main thread, and the painting runs in yet another thread. That's Servo/WebRender's design. It's not easily compatible with existing engines, but that's why Servo exists :)

> I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive.

The problem with focusing just on adding new stuff to the platform is that, while Google's evangelism operation is impressive, it's hard to get existing Web developers to move to new stuff. It's the classic Itanium vs. x86 inertia problem. To take Washington Post as an example, they layout thrash like crazy when loading, despite it being known for years that that's a massive performance problem. By contrast, by making existing patterns faster, we improve the user experience for all Web sites, old and new.

To be clear, we should both introduce new APIs (IntersectionObserver is a very important one) and work on improving performance of the old. They're not mutually exclusive.

> In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web.

Oh, it's hardly a silver bullet. Those don't exist. By the same token, though, new APIs and things like AMP aren't a silver bullet either ;)

> I think this is a great example of how having multiple rendering engines is healthy for the web.

I agree, which is why I disagree with the "Chrome Won" defeatist attitude of the article.

> Doing nothing is an even bigger risk.

True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship? 1, 2 years? Was there a market research before hand? Like I said its a big question mark. Cant blame me if I have doubts after Firefox OS.

> I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?

I dont know and I dont have something to do with it. Personally, I think the popular opinion on HN is pro Rust and pro Servo.

> I'd be more than willing to hear your technical thoughts...

Wait, are you using the "if you cant talk technical GTFO" card on me? We are straying from my original comment.

To make this perfectly clear:

Im not against improvement. Im against Mozilla's poor business decisions. You can see that was my point in the original comment.

No im not downplaying all your hard work. But ive seen this happen before. Happened to me as well. "Oh this will be great when it ships" at the expense of the company. Im trying to give an alternative opinion here contrary to the constant positive reinforcement when Rust and Servo is posted on HN. Nothing personal.

> Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship?

Bits have already landed, and another major piece is being worked on right now. That's the whole idea of Quantum; no need to wait till Servo is done for Firefox users to start seeing benefit.

> True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands?

Are you sure that people will download Firefox over Chrome when Mozilla does nothing?

The answer to that is obvious not a question mark.

> You can criticize Go but it has a more thriving ecosystem than Rust.

I think Go has already become unavoidable for those working in cloud like environments, thanks to Docker and Kubernetes.

Anyone working on those areas needs a working knowledge of Go, even he/she dislikes the language.

The killer argument for Rust, especially when writing a web browser, is security. I don't care about the general market share of Rust - personally I prefer Go for the things I usually do, but I am very excited for a web browser written in Rust.

If it gains any meaningful traction, I'm kinda expecting WebAssembly will make Rust a useful additional language for web devs currently working with stuff like C#, Python or JS.

It's definitely put it firmly on my radar as something to pick up recently, and since I don't already know C or C++ it feels like a good starting point.

rustjobs.rs

There are not a ton but there are more than zero.