Another Big Milestone for Servo: Acid2 (opens in new tab)

Here's another really fantastic reason for the research Servo is doing: by using concurrency and parallelism pervasively, Servo is discovering and mapping out all the places where sequentialism is baked into the web standards themselves. With any luck, their experiences will help to guide the next generation of web standards and prevent them from being inadvertently hostile to parallelism.

DOM objects are reference counted in Gecko, and there is a cycle collector to collect JS/C++ cycles. They aren't allocated in the JS heap.

WebKit is similar, but without the cycle collector.

> (I believe) Trident does.

I doubt it, Trident's DOM is COM objects. Not only are the heaps separate, the DOM heap is page-independent and in the old days you could leak DOM objects for whole sessions if you created a circular reference between JS and DOM (because you set up an event handler closure for instance, the DOM element would reference the closure and the closure would close over the DOM element). There were tools (Drip and later sIEve) whose sole job was to wrap MSHTML, reload pages and detect objects remaining from the page you'd just left.

> that a web page cannot easily distinguish two user agents.

Don't need to, to be more precise.

Benchmarks at this point would be pointless, Servo doesn't do so many thing Gecko does that any benchmarks is pointless.

E.g. Gecko renders every element on the page according to spec and spends 10seconds, while Servo renders like two in a millisecond (because it stubs the others).

To make stuff worse, Gecko will be super-optimized for browser benchmarks (like storing previous values of used functions to speed things like sin(x) ) that Servo will look way slower than Gecko, or maybe even Firefox 6.

There are a lot of problems with asm.js: the heap can't be resized after creation, the code size is really large (esp. with things like C++ templates, which are duplicated for each specialization), threads don't work, datatypes like 32-bit floats and 64-bit integers are problematic, interop with JS and DOM APIs is slow. These things can only be improved with browser cooperation, which sort of defeats asm.js's main advantage of working in any browser.

Native Rust support would be far better.

The same reason people want asm.js: speed, and avoiding the many problems of JavaScript.

Javascript is a terrible language, even though Rust is experimental it would be a big improvement. And it does have attractive aspects as a language.

More broadly, breaking the iron grip Javascript has on client-side development would be wonderful and Mozilla is the last stumbling block in front of this goal.

This is one of my pet peeves. Any language can be either compiled or interpreted. I think what you mean is, "No one has written an interpreter for Rust." But that is also nonsense, as all compilers contain an interpreter. The difference is just that instead of streaming instructions straight to the CPU, compilers wrap the instructions in an executable format and save them to a file.

Like the interpreted language that is Java? :) A JIT compiler could make sense for Rust, though I'd agree that the usecases for that are probably not very interesting compared to some other languages.

Which might be true but seems odd to bring up in the blog post.

Also they say:

>> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler.

Are they referencing reverse heartbleed here? Browsers themselves were not vulnerable to heartbleed, I don't even this they were vulnerable to reverse heartbleed.

There is no way Servo would have prevented the heartbleed bug, no browser could have, I feel like that sentence has no place in this blog post.

> Rust's static type checker would prevent bugs that caused HeartBleed

I believe its more a case that it would have been a run-time error due to Rust's automatic bounds checking. This is because Rust uses 'fat pointers' for strings, vectors and slices that include bounds information rather than a single, raw pointer like in C. Do note there are unsafe ways around bounds checking, but these are restricted to unsafe blocks, which makes them easier to audit.

Lots of bits of Servo use the FFI, but we've been replacing them as we go along with Rust versions. We did this so we could stand up a whole browser as fast as possible and then iterate on the important pieces first.

As an example, we used to use Netsurf's C library for CSS stuff, but now we have our own parser and style system written in 100% Rust.

> It's also true that at the moment most of, or at least a lot of, real work done in Rust eventually ends up calling into some C library.

I'm not entirely sure this is a correct claim, unless you mean 'system calls are implemented by the kernel, which is written in C.'

While it's true that FFI in Rust is really good, most things (notably, _not_ crypto) are just straight-up written in Rust.

This is one of those only on HN moments. From grandparent's web page:

"A long time ago, in a galaxy far far away, I worked for a company called Sun Microsystems. One of the things I did there was to join a renegade band of engineers who were off in Palo Alto working on a technology that nobody within Sun could see any possible use for. That technology was of course Java."

http://www.mcmanis.com/chuck/java/

It is the complexity tradeoff. I built a really simple widget using an LCD which you can send "standard" HTML (as in the base DTD) over a serial line. Built using an Cortex M3, a SPI connected LCD, basically libft2, libpng, and a minimal drawing package. If you look at LED signs, this is one of those, but with a screen instead of LEDs and a more 'standard' layout engine. Three fonts, (serif, sans, fixed), three weights (normal, bold, italic), old skool HTML (no css, no script) and a simplified img tag. The most complex thing in the code is the table rendering code.

Basically if you want to throw up a quick status display, it can do quite a bit.

So I thought I would update it to HTML4, maybe a bit of ECMA script for animations. Did a couple of runs at it and found most existing code had a bunch of stuff in it so that it could render "commonly occurring, but non-standard" HTML pages. In order to fit in a limited memory foot print system I was ripping things out left and right but stuff has more side effects than Cymbalta. So I tabled the project.

Starting from the premise of rendering "just the stuff we promise we can render" allows me to add stuff until I run out of memory and then stop.

I worked for a medical software company which had to deal with incoming digital images (DICOM) from all kinds of manufacturers (Siemens, GE, Philips, and tons of other smaller players).

I once heard one of our lead developers say that 80% of the code we wrote was to work around problems in everyone else's implementations. The DICOM format has a bunch of predefined fields and supports custom fields that manufacturers can use, but a lot of manufacturers would, for no reason I could figure out, use fields incorrectly a surprising amount of the time. They would store one of the most basic pieces of information in the wrong field, and then store that data nowhere, or put it in a custom field, or store it in the wrong format, etc.

Enough manufacturers doing 95% of things right and 5% of things wrong, making everyone else jump through hoops to handle their broken behaviour, and suddenly your code grows massively. Sure enough, we had to write an entire system for remapping fields from certain machines so that incoming data from broken implementations would be somehow magically coerced into being correct (either by simply copying data over to fields, or more advanced post-processing).

The less time browsers spend wondering what to do with inherently, irredeemably broken HTML, the faster they can render content which actually does work properly.

Unfortunately, that only works in controlled environments, like store kiosks, intranets, etc. Otherwise you end up choking on the 95% of the content which is only 5% broken.

Added complexity and baggage for his use case?

Well, then I'll hope for a Servo equivalent of Luakit before too long.

And for those who don't follow Rust closely, it's important that it's "the DOM thread only," as Rust's opt-in GC is on a per-task (thread) basis, so the threads that don't use GC don't even know it's there or running.