It's gratifying to see how successfully the same organization has learned from the debacle that was the rewrite from Netscape 4 to Mozilla in the first place. That time, they didn't release for years, losing market share and ceding the web to Internet Explorer for the next decade. Joel Spolsky wrote multiple articles[1][2] pointing out their folly.
This time, their "multiple-moonshot effort" is paying off big-time because they're doing it incrementally. Kudos!
Joel is making two separate claims there, though he doesn't cleanly distinguish them.
One is that rewriting from scratch is going to give you a worse result than incremental change from a technical point of view (the « absolutely no reason to believe that you are going to do a better job than you did the first time » bit).
The second is that independent of the technical merits, rewriting from scratch will be a bad commercial decision (the « throwing away your market leadership » bit).
We now know much more about how this turned out for his chosen example, and I think it's clear he was entirely wrong about the first claim (which he spends most of his time discussing). Gecko was a great technical success, and the cross-platform XUL stuff he complains about turned out to have many advantages (supporting plenty of innovation in addons which I don't think we'd have seen otherwise).
It's less clear whether he's right about the second: certainly Netscape did cede the field to IE for several years, but maybe that would have happened anyway: Netscape 4 wasn't much of a platform to build on. I think mozilla.org considered as a business has done better than most people would have expected in 2000.
The original plan was for the Servo project was to develop a new browser engine separate from Gecko, similar to the original Mozilla transition. An alpha-quality browser with Servo as an engine was originally a 2015 goal, and the active goal tracking this was removed from the roadmap in 2016:
As someone who was involved with Servo during that time period, I was disappointed at the time that it was quite obviously not going to happen. However, looking at what has happened since then, the change of focus towards Firefox integration was definitely a good move.
Wasn't the original Mozilla leading into Firefox wildly successful, though? It certainly put a dent in IE's market share. The opposite has been true for Chrome so it seems their recent history is not one of successful adaptation.
I'm curious - in both of those articles Joel uses the expression "software doesn't rust", to make fun of Netscape.. is that where the name for the Rust language came from?
> Stylo was the culmination of a near-decade of R&D, a multiple-moonshot effort to build a better browser by building a better language.
This is the most impressive, and useful aspect of all the recent work in Firefox. Rust is an amazing language. It really brings something new to the table with its borrow checker.
The fact that rust was created as part of a greater effort to work on a web browser is amazing.
What I wonder, and I do not mean this in negative way, is whether this would have happened in a more commercially oriented organisation. Mozilla remains a foundation, and I consider Rust a fruit of their labour in itself.
To put it another way, I find it hard to justify developing Rust just for a web browser. But if you consider it from the perspective of a foundation developing tools for the developer community as a whole, it makes much more sense.
Yeah. I got a taste of Rust in the last two years and it's the first tool set I really want to continue using. And it gave me the interest to dig into systems programming. I'm very grateful for that!
> They borrowed Apple’s C++ compiler backend, which lets Rust match C++ in speed without reimplementing decades of platform-specific code generation optimizations.
This was a pretty smart move by the Rust team, and this gave them a rock solid platform to go cross-platform. In words of Newton, "If I have seen further it is by standing on the shoulders of giants". Kudos team Rust, and let's hope they eat C++'s lunch soon.
It might sound very naive to say this, but I found it very cool that it was someone from the States, an Aussie and a Spaniard working on this, open source is something magical when you think about it. Props to everyone involved, all those projects sound like a lot of fun for a good cause.
Both the stylo and servo teams are extremely distributed.
For servo we've had long periods of time where no two employees are in the same office (it helps that most folks are remote).
In both teams we found it impossible to pick meeting times that work for everyone so we instead scheduled two sessions for the recurring meetings, and you can show up for one of them (the team lead / etc are usually at both so they're scheduled such that it is possible for them to attend both). Though for Servo we eventually stopped the meeting since we're pretty good at async communication through all the other channels and the meeting wasn't very useful anymore.
Also, to clarify, while that was the initial team, shortly after getting Wikipedia working the team grew with folks from the Servo and Gecko teams. Eventually we had folks living in the US, Paris, Spain, Australia, Japan, Taiwan, and Turkey working on it. As well as volunteer contributors from all over the place.
I love Firefox Quantum and it has replaced Chrome as my browser at home. It's memory consumption is far lower with the same amount of tabs open.
That said, why does it perform slower than Chrome on most benchmarks? Is it due to the Chrome team doing much more grunt work regarding parallelism and asynchronous I/O? Or are there still features in the current Firefox build that still call the original engine?
Which benchmarks are you talking about? It depends on what those benchmarks measure.
For example, a lot of the Quantum work was in user-percieved UI latency; unless the benchmark is measuring that, and I imagine that's a hard thing to measure, it's not going to show up.
> Does Rust have a runtime penalty as Golang does?
One thing I've been wondering is that Stylo and Webrender can parallelize CSS and Paint, respectively, but I haven't seen any mention in Project Quantum (the project to integrate Servo components into Firefox/Gecko) of any component to parallelize layout, which is probably the biggest bottleneck on the web at the moment.
Is parallel layout something which can only be done through a full rewrite, hence with Servo, and bringing Servo up to full web compatibility, or can this be handled through the Project Quantum process, of hiving off components from Servo into Firefox?
Now, once stylo and webrender are in play, ideally layout can just fit in between. All the interfacing already exists from Servo.
However, there are a lot more things in Firefox that talk to layout. This would need work, more work than Stylo.
But this isn't the major issue. The major issue is that Servo's layout has a lot of missing pieces, a lot more than was the case with its style system. It's hard to incrementally replace layout the way webrender did with rendering (fall back when you can't render, render to texture, include it).
The OP links a video from 2015 that implies that one of the advantages of making Stylo the first Servo component in Gecko is that the next phase in the pipeline, layout, will be able to benefit from having a well-defined interface in place. I'm curious about this as well!
Speaking of which: does anyone know if some new optimization land in the beta versions a couple of days ago? Or if some bug that caused delays on Linux got fixed?
I updated my developer version yesterday and it was as if Firefox - already ludicrously fast compared to before - turned on the turbo booster.
> For example, register allocation is a tedious process that bedeviled assembly programmers, whereas higher-level languages like C++ handle it automatically and get it right every single time.
Ideal register allocation is NP-complete, so a compiler can't get it right every single time.
I'm not sure how good in practice modern compilers are at this, but would be curious to know if there's some asm writers who can actually consistently outperform them.
They're not saying that C++ compilers do the best possible register allocation, they're saying that C++ compilers generate a register allocation that works and doesn't contain bugs. Technically, spilling everything to memory and loading only what you need to issue instructions is "getting it right" by this definition. No compiler strives to get the "optimal" anything in the general case, but we do expect them to strive to be "correct" in all cases. The language we use determines which properties are included in our idea of "correctness".
I found this example interesting. I found myself comparing it to how Rust does memory management, which is certainly not "automatic" as that would describe a garbage collected language.
Optimal register allocation has been polynomial time for more than 10 years - for some definition of optimal. IIRC it started with programs in SSA form and has dropped that requirement more recently. Modern GCC uses SSA form and I think LLVM might too.
I really like the new Fox. I’ve tried switching over completely but I think it’s causing some random BSODs on my Latitude E5570. The laptop does have a second Nvidia graphics card, for which there is no driver installed. ( don’t ask :) I’m perfectly fine with the onboard Intel and I much prefer the extra hours of battery life)
> The teams behind revolutionary products succeed because they make strategic bets about which things to reinvent, and don’t waste energy rehashing stuff that doesn’t matter.
This is a great write-up that gives me warm fuzzy feelings.
What also is interesting for me to realise, though, is that a lot of this was happening at the same time as Mozilla was largely focused on Firefox OS, and receiving a lot of flak for that.
It's a shame that Firefox OS failed, but it was clear that they had to try many different things to remain relevant, and it's excellent to see that one of those is very likely to pay off. Even though Rust might've been dismissed for the same reasons Firefox OS was.
FF has for me crashed more times in the last week than in the previous year. - Multiple installs on different Linux systems. The last crash was with a clean profile.
And then there's the disappearing dev tools - that's fun.
EDIT:
I hope that there is something weird with my systems. But I fear that the rush to push this out might have been a little hasty.
EDIT EDIT
Apart from the crashes the new FF has been nice. I've been able to largely stop using chromium for dev work - so not all is bad.
You can go to "about:crashes" to get some more information about reported crashes. If you open a crash report and click the "Bugzilla" tab, you can find out if a bug is on file for that specific stack trace.
I have been using Firefox for several months, using Windows 10, and several GNU/Linux distributions, different hardware, etc., and have never experienced a crash.
It's definitely something weird to do with your systems, meaning it's a real bug that you are experiencing, and I am not.
So please share crash reports, and file bug reports. Different hardware/software quirks may reveal bugs in Firefox/Linux/drivers/window managers/anything. By submitting a bug report for Firefox, you may be able to help find a video driver bug, etc.
For example, register allocation is a tedious process that bedeviled assembly programmers,
Yet more propaganda. I’ve been part of the cracking and demo scene since my early childhood. If you didn’t code in assembler you might as well not have taken part in it at all, because small fast code was everything. None of us ever had an issue with register allocation, nor do we face such issues today. Not 30+ years ago, not now.
> the breadth of the web platform is staggering. It grew organically over almost three decades, has no clear limits in scope, and has lots of tricky observables that thwart attempts to simplify.
It would be great to create the html/css/javascript stack from scratch, or at least make a non-backwards-compatible version that is simpler and can perform better. HTML5 showed us that can work.
Yeah but Firefox is already struggling while supporting all the possible standards and more ("sorry our site is better view with Google IE4... ehm Google Chrome").
The whole Mozilla strategy of corroding Firefox piece by piece is actually very professional. Big backwards-incompatible transitions in technology almost always fail.
It's a matter of allocating time to implement the missing parts and get it to work properly. Right now the people who could do this are working on other things but it will get done eventually.
[+] [-] kbd|8 years ago|reply
This time, their "multiple-moonshot effort" is paying off big-time because they're doing it incrementally. Kudos!
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[2] https://www.joelonsoftware.com/2000/11/20/netscape-goes-bonk...
[+] [-] mjw1007|8 years ago|reply
One is that rewriting from scratch is going to give you a worse result than incremental change from a technical point of view (the « absolutely no reason to believe that you are going to do a better job than you did the first time » bit).
The second is that independent of the technical merits, rewriting from scratch will be a bad commercial decision (the « throwing away your market leadership » bit).
We now know much more about how this turned out for his chosen example, and I think it's clear he was entirely wrong about the first claim (which he spends most of his time discussing). Gecko was a great technical success, and the cross-platform XUL stuff he complains about turned out to have many advantages (supporting plenty of innovation in addons which I don't think we'd have seen otherwise).
It's less clear whether he's right about the second: certainly Netscape did cede the field to IE for several years, but maybe that would have happened anyway: Netscape 4 wasn't much of a platform to build on. I think mozilla.org considered as a business has done better than most people would have expected in 2000.
[+] [-] cwzwarich|8 years ago|reply
https://github.com/servo/servo/wiki/Roadmap/_compare/47f490b...
As someone who was involved with Servo during that time period, I was disappointed at the time that it was quite obviously not going to happen. However, looking at what has happened since then, the change of focus towards Firefox integration was definitely a good move.
[+] [-] pvg|8 years ago|reply
[+] [-] jakewins|8 years ago|reply
[+] [-] thomastjeffery|8 years ago|reply
This is the most impressive, and useful aspect of all the recent work in Firefox. Rust is an amazing language. It really brings something new to the table with its borrow checker.
The fact that rust was created as part of a greater effort to work on a web browser is amazing.
[+] [-] stingraycharles|8 years ago|reply
To put it another way, I find it hard to justify developing Rust just for a web browser. But if you consider it from the perspective of a foundation developing tools for the developer community as a whole, it makes much more sense.
[+] [-] ticklemyelmo|8 years ago|reply
[+] [-] haberman|8 years ago|reply
[+] [-] pcwalton|8 years ago|reply
[+] [-] pimeys|8 years ago|reply
[+] [-] FlyingSnake|8 years ago|reply
This was a pretty smart move by the Rust team, and this gave them a rock solid platform to go cross-platform. In words of Newton, "If I have seen further it is by standing on the shoulders of giants". Kudos team Rust, and let's hope they eat C++'s lunch soon.
[+] [-] sp332|8 years ago|reply
[+] [-] guelo|8 years ago|reply
[+] [-] VeejayRampay|8 years ago|reply
[+] [-] Manishearth|8 years ago|reply
For servo we've had long periods of time where no two employees are in the same office (it helps that most folks are remote).
In both teams we found it impossible to pick meeting times that work for everyone so we instead scheduled two sessions for the recurring meetings, and you can show up for one of them (the team lead / etc are usually at both so they're scheduled such that it is possible for them to attend both). Though for Servo we eventually stopped the meeting since we're pretty good at async communication through all the other channels and the meeting wasn't very useful anymore.
Also, to clarify, while that was the initial team, shortly after getting Wikipedia working the team grew with folks from the Servo and Gecko teams. Eventually we had folks living in the US, Paris, Spain, Australia, Japan, Taiwan, and Turkey working on it. As well as volunteer contributors from all over the place.
[+] [-] linkregister|8 years ago|reply
That said, why does it perform slower than Chrome on most benchmarks? Is it due to the Chrome team doing much more grunt work regarding parallelism and asynchronous I/O? Or are there still features in the current Firefox build that still call the original engine?
Does Rust have a runtime penalty as Golang does?
[+] [-] steveklabnik|8 years ago|reply
Which benchmarks are you talking about? It depends on what those benchmarks measure.
For example, a lot of the Quantum work was in user-percieved UI latency; unless the benchmark is measuring that, and I imagine that's a hard thing to measure, it's not going to show up.
> Does Rust have a runtime penalty as Golang does?
Rust has the same amount of runtime as C does: very very little. https://github.com/rust-lang/rust/blob/master/src/libstd/rt....
[+] [-] DonbunEf7|8 years ago|reply
This is more generally known as Constant Flawless Vigilance: https://capability.party/memes/2017/09/11/constant-flawless-...
[+] [-] Brakenshire|8 years ago|reply
Is parallel layout something which can only be done through a full rewrite, hence with Servo, and bringing Servo up to full web compatibility, or can this be handled through the Project Quantum process, of hiving off components from Servo into Firefox?
[+] [-] Manishearth|8 years ago|reply
Now, once stylo and webrender are in play, ideally layout can just fit in between. All the interfacing already exists from Servo.
However, there are a lot more things in Firefox that talk to layout. This would need work, more work than Stylo.
But this isn't the major issue. The major issue is that Servo's layout has a lot of missing pieces, a lot more than was the case with its style system. It's hard to incrementally replace layout the way webrender did with rendering (fall back when you can't render, render to texture, include it).
So it's doable, but a lot more work.
[+] [-] kibwen|8 years ago|reply
[+] [-] fulafel|8 years ago|reply
[+] [-] vanderZwan|8 years ago|reply
I updated my developer version yesterday and it was as if Firefox - already ludicrously fast compared to before - turned on the turbo booster.
Obviously, I'm not complaining ;)
[+] [-] agentultra|8 years ago|reply
[+] [-] pitaj|8 years ago|reply
Does anyone know if this is being worked on? Should I submit a bug report?
[+] [-] m0th87|8 years ago|reply
Ideal register allocation is NP-complete, so a compiler can't get it right every single time.
I'm not sure how good in practice modern compilers are at this, but would be curious to know if there's some asm writers who can actually consistently outperform them.
[+] [-] kbsletten|8 years ago|reply
[+] [-] Manishearth|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] dom96|8 years ago|reply
[+] [-] phkahler|8 years ago|reply
[+] [-] bdmarian|8 years ago|reply
[+] [-] vatotemking|8 years ago|reply
This needs to be emphasized more
[+] [-] Vinnl|8 years ago|reply
What also is interesting for me to realise, though, is that a lot of this was happening at the same time as Mozilla was largely focused on Firefox OS, and receiving a lot of flak for that.
It's a shame that Firefox OS failed, but it was clear that they had to try many different things to remain relevant, and it's excellent to see that one of those is very likely to pay off. Even though Rust might've been dismissed for the same reasons Firefox OS was.
[+] [-] JupiterMoon|8 years ago|reply
And then there's the disappearing dev tools - that's fun.
EDIT: I hope that there is something weird with my systems. But I fear that the rush to push this out might have been a little hasty.
EDIT EDIT Apart from the crashes the new FF has been nice. I've been able to largely stop using chromium for dev work - so not all is bad.
[+] [-] mbrubeck|8 years ago|reply
[+] [-] thomastjeffery|8 years ago|reply
It's definitely something weird to do with your systems, meaning it's a real bug that you are experiencing, and I am not.
So please share crash reports, and file bug reports. Different hardware/software quirks may reveal bugs in Firefox/Linux/drivers/window managers/anything. By submitting a bug report for Firefox, you may be able to help find a video driver bug, etc.
[+] [-] kccqzy|8 years ago|reply
[+] [-] Annatar|8 years ago|reply
Yet more propaganda. I’ve been part of the cracking and demo scene since my early childhood. If you didn’t code in assembler you might as well not have taken part in it at all, because small fast code was everything. None of us ever had an issue with register allocation, nor do we face such issues today. Not 30+ years ago, not now.
[+] [-] thomastjeffery|8 years ago|reply
It would be great to create the html/css/javascript stack from scratch, or at least make a non-backwards-compatible version that is simpler and can perform better. HTML5 showed us that can work.
[+] [-] dullgiulio|8 years ago|reply
The whole Mozilla strategy of corroding Firefox piece by piece is actually very professional. Big backwards-incompatible transitions in technology almost always fail.
[+] [-] jacobr|8 years ago|reply
[+] [-] notriddle|8 years ago|reply
[+] [-] gjem97|8 years ago|reply
Edit: I don't intend for this to sound like I'm complaining, just interested.
[+] [-] cpeterso|8 years ago|reply
https://wiki.mozilla.org/Oxidation#Rust_components_in_Firefo...
Completed:
In progress:[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] steveklabnik|8 years ago|reply
[+] [-] mi_lk|8 years ago|reply
[+] [-] nicalsilva|8 years ago|reply