Live data from Hacker News

June in Servo: real world compat, media queries, SharedWorker, and more

servo.org

61–70 of 72 posts

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#61
post #36

Earlier quoted context omitted.

If you're going by binary size then Servo is already as big as other browsers. 106 MB excluding dependencies, or 274 MB including dependencies.

Does Servo still launch a herd of processes like Electron?

Doesn't look like it but if Servo wants to be a production-ready browser they will likely need to do the same. Better security and reliability having processes handling different roles.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#63

Earlier quoted context omitted.

From the presentation announcing Rust inside of Mozilla: https://venge.net/graydon/talks/intro-talk-2.pdf > We are not “rewriting the browser”. That's impossible. Put down the gun.

Impossible in 2010, maybe

Regardless if it's still true or not, the original purpose was not to re-write Gecko.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#64
post #36
post #24

Earlier quoted context omitted.

Yes, that's why Servo is so exciting. It doesn't have to implement _all_ the standards, just a subset that is compatible with the full set. So that if you can develop an app within that subset and have it working in other browsers. But not necessarily vice versa.

If you're going by binary size then Servo is already as big as other browsers. 106 MB excluding dependencies, or 274 MB including dependencies.

You can trim it quite a bit, and it also compresses quite well. The dependencies are the main issue, there's just a lot of stuff there.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#65
post #49

Earlier quoted context omitted.

Ridiculous because it's absolutely guaranteed to fail. Irresponsible because if it does succeed against all odds, the internet will actually become a worse place. If you can't implement most of the web standards (not even all, just most of them), then one of the following will happen: - your engine will never catch on (best case scenario) - your engine will be forever known as "this browser where nothing works" and w…

>and will be perpetually ignored in all discussions about cross-browser compatibility If violence doesn't solve your problems, you use not enough violence. Also if you don't implement web standards, it's doesn't mean that nothing works. Adblock and noscript break web standards, but people use them just fine, they actually make web work better. >A massive project like that will have massive code complexity, which lead…

I didn't say nothing would work. I said it'd be known as the one where nothing works. Think: IE6. It implemented like 95% of all web standards as of 2006. But this missing 5% was the difference between being at the forefront of progress and holding back the entire industry.

Today, IE6's 95% would be less than 10%. So you'd need to implement several times more features than IE6 had to be even remotely close to the status of unworkable mess that webdevs are better off not supporting.

Low-level exploits like heartbleed are quite rare actually. The vast majority of security bugs in Chrome and Firefox are in unsafely handling edge cases in parsing HTML and other media types, not isolating script execution enough, and bugs in runtime interfaces (cookies, local storage, mic&cam APIs, location APIs, etc.) Realistically, there's no way to avoid these bugs - browser engine has too much inherent complexity, statistically you're bound to mke amistake every so often. Moreover, IIRC about half of those bugs are caused by buffer overflows and similar memory bugs. So by using Rust, you can expect to have half as many security holes than you'd have otherwise. The number is still in the thousands either way.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#66
post #28

Earlier quoted context omitted.

This is awesome! Do you think you can host something like React Native if you add a JS engine?

Yes! There are a few experiments with JS engines going on (all very early stage atm (and many vibe coded) but looking promising enough to justify doing a proper implementation in future). With this you can actually run regular React DOM (so fully compatible with deploying the same codebase to web). There is then the potential to mix in native components, although that's not fully built-out today. Finally, as part of…

Thanks!

It'd really interesting to try static Hermes with it ( https://github.com/facebook/hermes/tree/static_h ).

iOS is braindead and doesn't allow JITs, so regular JavaScript is not a good option.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#67
post #64
post #36

Earlier quoted context omitted.

If you're going by binary size then Servo is already as big as other browsers. 106 MB excluding dependencies, or 274 MB including dependencies.

You can trim it quite a bit, and it also compresses quite well. The dependencies are the main issue, there's just a lot of stuff there.

Electron also compresses well but people complain about unpacked size, too. You're likely not going to see an embedded browser actually smaller unless you can disable features at compile time.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#69
post #65

Earlier quoted context omitted.

>and will be perpetually ignored in all discussions about cross-browser compatibility If violence doesn't solve your problems, you use not enough violence. Also if you don't implement web standards, it's doesn't mean that nothing works. Adblock and noscript break web standards, but people use them just fine, they actually make web work better. >A massive project like that will have massive code complexity, which lead…

I didn't say nothing would work. I said it'd be known as the one where nothing works. Think: IE6. It implemented like 95% of all web standards as of 2006. But this missing 5% was the difference between being at the forefront of progress and holding back the entire industry. Today, IE6's 95% would be less than 10%. So you'd need to implement several times more features than IE6 had to be even remotely close to the sta…

FWIW C++ can do bound checks aka hardened STL. On the other hand google did riir some of their programs and removed bound checks there for speed, welcome to real world, so absence of bound checks is not a mistake, but an intended performance goal.

Re: June in Servo: real world compat, media queries, SharedWorker, and more

#70
post #65

Earlier quoted context omitted.

I didn't say nothing would work. I said it'd be known as the one where nothing works. Think: IE6. It implemented like 95% of all web standards as of 2006. But this missing 5% was the difference between being at the forefront of progress and holding back the entire industry. Today, IE6's 95% would be less than 10%. So you'd need to implement several times more features than IE6 had to be even remotely close to the sta…

FWIW C++ can do bound checks aka hardened STL. On the other hand google did riir some of their programs and removed bound checks there for speed, welcome to real world, so absence of bound checks is not a mistake, but an intended performance goal.

Google is consciously making Chrome less secure because otherwise the performance is unacceptable. The end result is about 300 CVEs every year for the last 10 years. That's for an almost 20 year old project that had most of its security issues resolved very early on.

And you're saying somebody who is not Google can make a brand new browser engine from scratch in 2026, have it perform good enough to be actually usable in practice, and not be an absolute security nightmare?

Post reply on HN