6 ms·

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. T

by kbd 9y ago

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! [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part https://www.joelonsoftware.com/2000/04/06/things-you-should-... [2] https://www.joelonsoftware.com/2000/11/20/netscape-goes-bonkers/ https://www.joelonsoftware.com/2000/11/20/netscape-goes-bonk...

cwzwarich 9y ago
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: https://github.com/servo/servo/wiki/Roadmap/_compare/47f490bf43c0a61b7d234aa2d7ed87f15210b012...9ffba10e5fc455c3443faa923221b7f46a6131f6 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.
- majewsky 9y ago
  When I looked at browser.html, it was what you could call an "alpha-quality browser", unless we use different definitions of the term "alpha-quality".
  - fabrice_d 9y ago
    We all due respect, browser.html can do so little that it's hardly more than a prototype. Also, Servo itself as a web engine is still far from supporting enough of the web stack to be usable in a daily browser. I guess putting effort in Stylo diverted some resources from Servo - I feel it didn't progress much the last year in terms of "sites I can browse for more than 5 minutes". At this point it's clear that Mozilla is unlikely to staff Servo to fill the gap (although cpearce and others are working on getting the gecko media stack in Servo), but I wonder what will happen once WebRender makes its way in Gecko; are there any other pieces of Servo that can be useful?
    - pcwalton 9y ago
      > are there any other pieces of Servo that can be useful I definitely think Servo layout can be made useful. There have been no indications that parallel layout doesn't work in practice. Our performance tests have had good results, comparable to the results we saw in Stylo. I would like to redo the way Servo layout scheduling works, possibly when async/await lands in Rust. I believe that will not only improve performance but also fix a whole bunch of random bugs relating to floats where our scheduler currently just does the wrong thing. (That doesn't mean we have to throw out all of that code or anything like that; it just means I'd like to redo how that works.) Once you have layout, style, and graphics out of the way, what remains—really, at that point, the difference between Gecko and Servo, aside from embeddability—will mostly be DOM APIs and relatively isolated components such as image decoders. It's an open question how to use Servo DOM API implementations in Gecko. In any case, though, Servo's DOM story may change with the arrival of Alan Jeffrey's Josephine or something like it, and it probably makes sense to revisit this question once we decide how all of that will shake out. And, personally, I don't know if you consider Pathfinder part of Servo or not, but I'm certainly aiming to get that in. One thing's for sure: we won't be running out of things to do in Research any time soon. :)
mjw1007 9y ago
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.
- aidenn0 9y ago
  In Joel's defense, we don't know that gecko is better than X years of incremental changes to Netscape 4. One of the big issues with software engineering advice is that it is really hard to find apples-to-apples comparisons for outcomes.
  - mjw1007 9y ago
    True. I think we can say that Gecko ended up technically better than incremental changes to Internet Explorer, which I think was starting off from a more maintainable codebase than Netscape 4. That's hardly conclusive but it's some evidence.
    - aidenn0 9y ago
      Indeed. My intuition based nothing other than my subjective experience is that there are times that throwing away the code is the correct decision, but they are a rounding error compared to the times that people want to throw away the code, so to a first order of approximation "never start over from scratch" is correct. Simply shifting the burden of proof to the "rewrite" side is usually sufficient. Where I currently work a rewrite request is not answered with "no" but "show me the data." 90% of the time the requester doesn't even try to gather data, the other 10% of the time results in some useful metrics about a component that everyone agrees needs some TLC, whatever the final decision.
pvg 9y ago
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.
- digi_owl 9y ago
  The first thing to consider is that MS let IE stagnate, and had large deviations from W3C standards. Mozilla rode in on the cry for standard adherence. Chrome on the other hand is not stagnant, far from it. And Google is not letting Chrome stagnate. Never mind that Google is using their marketing muscle to push Chrome every chance they get. Just try downloading some shareware on Windows, and you are bound to get Chrome along for the ride. Hell, even Adobe offers Chrome as a Flash bundle even though Google is using Chrome to effectively kill Flash...
  - ksec 9y ago
    Actually the two incident is pretty similar. While Google has not let Chrome stagnate, the Chrome today is no longer the Chrome when it was released. Chrome has definitely felt slower and heavier over the years. Google today is no longer the Google it once was*, and it is getting lots of sticks over privacy problem. Firefox happens to be in the right place at the right time.
  - littlestymaar 9y ago
    > Chrome on the other hand is not stagnant, far from it. And Google is not letting Chrome stagnate. That's not Brendan Eich's point of view as part of the tc39 (the standardization body for JavaScript) : https://youtu.be/gO2tt9x9zBc?t=11m58s https://youtu.be/gO2tt9x9zBc?t=11m58s
jakewins 9y ago
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?
- steveklabnik 9y ago
  It’s not. There’s no canonical reasons, and there’s multiple non-canonical ones.
- kbd 9y ago
  I noticed that too and was curious. A quick search doesn't say that's where it came from, but I agree it would be ironic. Maybe that planted a seed in someone's mind.
- Manishearth 9y ago
  The name has multiple origins, Graydon notoriously gave a different story each time he was asked. One of the origins mentioned is that Graydon thought that rusts (a kind of mushroom) were pretty cool (they are! they have a super complex lifecycle and it's pretty interesting). Another is that Rust is actually not something with new concepts in it, everything in Rust is a very well established concept from earlier PL research, Rust just packages them nicely.
  - Quixoticelix3r 9y ago
    I'm not really sure if calling rust a kind of mushroom is being that fair on it.

by kbd 9y ago

cwzwarich 9y ago

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: https://github.com/servo/servo/wiki/Roadmap/_compare/47f490bf43c0a61b7d234aa2d7ed87f15210b012...9ffba10e5fc455c3443faa923221b7f46a6131f6 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.

majewsky 9y ago
When I looked at browser.html, it was what you could call an "alpha-quality browser", unless we use different definitions of the term "alpha-quality".
- fabrice_d 9y ago
  We all due respect, browser.html can do so little that it's hardly more than a prototype. Also, Servo itself as a web engine is still far from supporting enough of the web stack to be usable in a daily browser. I guess putting effort in Stylo diverted some resources from Servo - I feel it didn't progress much the last year in terms of "sites I can browse for more than 5 minutes". At this point it's clear that Mozilla is unlikely to staff Servo to fill the gap (although cpearce and others are working on getting the gecko media stack in Servo), but I wonder what will happen once WebRender makes its way in Gecko; are there any other pieces of Servo that can be useful?
  - pcwalton 9y ago
    > are there any other pieces of Servo that can be useful I definitely think Servo layout can be made useful. There have been no indications that parallel layout doesn't work in practice. Our performance tests have had good results, comparable to the results we saw in Stylo. I would like to redo the way Servo layout scheduling works, possibly when async/await lands in Rust. I believe that will not only improve performance but also fix a whole bunch of random bugs relating to floats where our scheduler currently just does the wrong thing. (That doesn't mean we have to throw out all of that code or anything like that; it just means I'd like to redo how that works.) Once you have layout, style, and graphics out of the way, what remains—really, at that point, the difference between Gecko and Servo, aside from embeddability—will mostly be DOM APIs and relatively isolated components such as image decoders. It's an open question how to use Servo DOM API implementations in Gecko. In any case, though, Servo's DOM story may change with the arrival of Alan Jeffrey's Josephine or something like it, and it probably makes sense to revisit this question once we decide how all of that will shake out. And, personally, I don't know if you consider Pathfinder part of Servo or not, but I'm certainly aiming to get that in. One thing's for sure: we won't be running out of things to do in Research any time soon. :)

mjw1007 9y ago

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.

aidenn0 9y ago
In Joel's defense, we don't know that gecko is better than X years of incremental changes to Netscape 4. One of the big issues with software engineering advice is that it is really hard to find apples-to-apples comparisons for outcomes.
- mjw1007 9y ago
  True. I think we can say that Gecko ended up technically better than incremental changes to Internet Explorer, which I think was starting off from a more maintainable codebase than Netscape 4. That's hardly conclusive but it's some evidence.
  - aidenn0 9y ago
    Indeed. My intuition based nothing other than my subjective experience is that there are times that throwing away the code is the correct decision, but they are a rounding error compared to the times that people want to throw away the code, so to a first order of approximation "never start over from scratch" is correct. Simply shifting the burden of proof to the "rewrite" side is usually sufficient. Where I currently work a rewrite request is not answered with "no" but "show me the data." 90% of the time the requester doesn't even try to gather data, the other 10% of the time results in some useful metrics about a component that everyone agrees needs some TLC, whatever the final decision.

pvg 9y ago

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.

digi_owl 9y ago
The first thing to consider is that MS let IE stagnate, and had large deviations from W3C standards. Mozilla rode in on the cry for standard adherence. Chrome on the other hand is not stagnant, far from it. And Google is not letting Chrome stagnate. Never mind that Google is using their marketing muscle to push Chrome every chance they get. Just try downloading some shareware on Windows, and you are bound to get Chrome along for the ride. Hell, even Adobe offers Chrome as a Flash bundle even though Google is using Chrome to effectively kill Flash...
- ksec 9y ago
  Actually the two incident is pretty similar. While Google has not let Chrome stagnate, the Chrome today is no longer the Chrome when it was released. Chrome has definitely felt slower and heavier over the years. Google today is no longer the Google it once was*, and it is getting lots of sticks over privacy problem. Firefox happens to be in the right place at the right time.
- littlestymaar 9y ago
  > Chrome on the other hand is not stagnant, far from it. And Google is not letting Chrome stagnate. That's not Brendan Eich's point of view as part of the tc39 (the standardization body for JavaScript) : https://youtu.be/gO2tt9x9zBc?t=11m58s https://youtu.be/gO2tt9x9zBc?t=11m58s

jakewins 9y ago

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?

steveklabnik 9y ago
It’s not. There’s no canonical reasons, and there’s multiple non-canonical ones.
kbd 9y ago
I noticed that too and was curious. A quick search doesn't say that's where it came from, but I agree it would be ironic. Maybe that planted a seed in someone's mind.
Manishearth 9y ago
The name has multiple origins, Graydon notoriously gave a different story each time he was asked. One of the origins mentioned is that Graydon thought that rusts (a kind of mushroom) were pretty cool (they are! they have a super complex lifecycle and it's pretty interesting). Another is that Rust is actually not something with new concepts in it, everything in Rust is a very well established concept from earlier PL research, Rust just packages them nicely.
- Quixoticelix3r 9y ago
  I'm not really sure if calling rust a kind of mushroom is being that fair on it.