Big changes afoot for Firefox.
We intend to move Firefox away from XUL and XBL, but the discussion of how to do that is in the early stages. There are a ton of unanswered questions: what technologies/best practices for web development should we adopt in its place? How does this affect add-on developers? Is there space for a native-code main-window on desktop like we have on Android? How much time should we spend on this vs. other quality issues? What unanswered questions have we not asked yet?
This clearly isn’t a small endeavour, but the rationale given seems sound to me.
Why don’t they start from scratch with a new browser based on older code, like Mozilla->Firefox and IE->Edge?
They are already making a new engine from scratch:
https://en.wikipedia.org/wiki/Servo_%28layout_engine%29
Edited 2015-07-07 01:42 UTC
Because starting from scratch is rarely a good choice – it sounds appealing, but it takes huge resources to achieve, and still ends up taking far longer than expected. And in the meantime, your existing product is being neglected, and you sink into oblivion…
Incidentally, Firefox isn’t a rewrite of Mozilla code – it was just a new shell around the same code. You’re probably thinking of the original Mozilla browser, which was a complete rewrite of the old Netscape code. The delays in getting a working release were at least a contributor to the death of Netscape…
As for IE->Edge, that’s not a complete rewrite either. As far as I can tell, “Edge” is just a new UI on top of the same rendering engine as IE11 used – they’ve dropped a lot of the legacy support modes, but there’s not much new about it.
Edited 2015-07-07 02:24 UTC
I didn’t mean start COMPLETELY over, but do what Microsoft did with IE and Edge – bring over all the old parts to the new project that aren’t legacy and leave the old cruft behind, instead of trying to retrofit a new UI engine into the old code base.
Because this:
http://www.joelonsoftware.com/articles/fog0000000069.html
Yeah, pretty much. There *are* cases where the “rewrite from scratch” approach has been successful – but there are a *lot* more cases where it’s been an unmitigated disaster that’s destroyed the company that did it. Evolutionary change is more painful, but also much more successful.
There is this trend these days to build microservices.
Because of this ‘cloud’ thing developers and operators from companies wanted to stop depending on single machines and want to get the benefits of auto-scaling.
These services are a lot smaller. They combine at least part of the unix philosophy (small specialized programs) with some of the ideas from for example the mostly failed Service Orriented Architectures from the enterprise Java world.
Every microservice is usually stateless so it can easily be scaled. With a seperate data store per microservice.
The seperation that these microservices create usually in large companies also fall along the boundries of the company (deparments and so on).
If you make small programs you can much more easily rewrite them. And this actually happens.
Even Mozilla is only writing it’s engine (rendering of HTML pages). Not the Javascript engine or the networking code or the interface, etc.
What they are trying to do is make HTML rendering a parallel process: https://www.youtube.com/watch?v=7q9vIMXSTzc
Lennie,
This is very informative!
And it’s true, alot of legacy code/design holds back better code/design. We continue to use it because it’s “good enough”. And incrementally evolving software to cope with new demands is also “good enough”. But when the goals and demands change over time the “evolution” approach forces us to take a different path than what would have been designed with those goals in mind. The resulting compromise between new goals and legacy codebases really can be hideous and complex as anybody who’s been in the industry for any length of time should be able to attest to.
The thing is, a project manager looks at it this way, and the rewrite is almost always more involved:
X man-hours for upgrade.
Y man-hours for rewrite.
Y>>X
Yet as years drag on and X is aggregated, eventually the sum of X will exceed Y, such that it would have made sense to commit to Y hours for a rewrite rather than maintaining a legacy codebase. But the thing is you need a rather long outlook, focusing on short term results usually takes a rewrite out of the cards, for better or worse.
I have enough experience with legacy code to know that maintaining it can be far more complicated and time consuming then any of the project backers want to admit.
I also have enough experience with new code to know that if it’s not done correctly, or communication channels are poor between end users and developers, then that will amplify problems with Y. And unfortunately the project managers themselves (as middlemen) are often the cause of communications problems. They abstract the end user for developers, and they abstract the developers for end users. 30 minutes worth of actual developer work can become days and days of expensive multi-party conference calls.
Of course not every place is like this, it really depends on the business environment. In my opinion though, when there’s a top-heavy structure with lots of middle managers, it strongly favors minimizing changes.
Edited 2015-07-07 17:50 UTC
The catch is that if you focus on the long term and neglect the short, you usually don’t last long enough for the long term to matter.
Delgarde,
To me, “a catch” implies something unexpected – as in “what’s the catch?” But if you have reasonable expectations and remain nibble, then ditching an old problematic code base can pay off. Mind you a rewrite isn’t necessarily the right choice, it depends.
I’ve subcontracted for clients who still use IBM mainframes, which is the ultimate legacy code. Sometimes it’s good enough. But other times the owners need extremely complex roundabout solutions to make it work with more modern systems or are getting grief from the users on limitations that are practically impossible to fix without a rewrite. These are the times when a rewrite can be favorable.
However I think corporate culture itself can be more important than whether it makes sense on paper. Companies with nibble teams and low political resistance will be able to achieve turnaround (and savings) far quicker than those entrenched with bureaucracy. Because lets face it, when corporate politics are involved, not everyone will be on board and some will prefer that the replacement fails. Project managers with cushy jobs will likely have better retirement prospects if they play along with the status quo and don’t try to change things (for better or worse).
The really fun projects are those that already at the end of the first development period requirements change significantly. Preferable a short time before the deadline. Those are the best. 😉
Luckily we, as an industry, did learn a little bit from previous mistakes.
Lennie,
Hmm, masochistic or sarcastic
Yea changes do happen. There have even been some occasions when I knew beforehand that we were going down the wrong track (ie not what the customer would want), but got overridden by the PM. Low and behold, the customer comes back and asks us to re-implement something the way I thought it should have been done from the beginning.
I’ve learned to raise my concerns in detail up front, but then play along with whatever the PM says, this way I’m not overstepping my bounds but at the same time I can at least say that I did bring it up.
I like this development which sometimes goes along with this devops trend.
Basically: find something we can measure and give a team of people a task to improve those meaurements and let them do it any way they see fit.
Like: change the design of the website to get more people to sign up for our services. This is something you can measure because you know the number of sign ups per day. Or maybe it means: the website loads to slow or doesn’t work on mobile or whatever. Who knows, let them figure it out and solve the problem.
This could mean things like: do A/B testing on the website to see what design works better, etc. etc.
What this also means is: there is no PM and all that stuff. Just people trying to get shit done and getting results for clear business goals.
Lennie,
I also like that approach, it’s more fun to have a longer leash. My inclination is that worker competency & motivation matter much more than management for our kind of work (aka management should mostly stay out of the way). However I was not able to find a study showing a correlation between management strictness and productivity.
Opera is a good example of that. They threw their code out for a standard rendering engine which is a good idea but threw out 90% of the interface and features many of their users were relying on.
In the end people screamed and ran away from the browser to Firefox and other alternatives that were flexible enough to cover most of the missing features.
I hope Firefox doesn’t Opera itself.
Because they’re far, far too busy copying every bad idea from Chrome’s UI designers.
My gut reaction to talk of tossing the basis of a platform out like this is skepticism. It is rarely a good idea to do so rather than fixing the platform.
That said one time I spent a few months diving into mozilla code to develop a native extension and that was by far the worst coding experience of my life (and that includes spending 4 months working on a 80kloc web app written in VB6 and managed by Visual Sourcesafe)..
Which is why the Mozilla folk don’t seem to be talking about “rewrite the whole thing”. The mailing-list post is kind of vague, but I assume this ties in with past discussions and experiments around using the HTML engine to render the Firefox shell, instead of maintaining the separate XUL engine and related pieces.
So, what I’d expect to come out of this is that they gradually rewrite parts of the existing UI – maybe starting with the relatively-separate pieces like the developer tools, and preferences, and add-on manager, then the main browser shell itself. Eventually, they’ll be left with a system that doesn’t use XUL/XBM at all, and they’ll be able to delete them.
I take two points from the linked email:
1. they plan to move from short release cycle to a rolling release model;
2. they thing about rendering the Firefox UI with HTML, thus transforming Firefox itself in a big HTML app.
I am really unsure about either, but very few details are provided.
Well, XUL is already rendered by Gecko, so moving to HTML5 to write the interface isn’t a significant change.
They may also go with a native-code UI, as they do with Android.
In the meantime I learned there is another half for this story, a second email announcement: https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003062.html
I found that even more worrisome, as it talks about more features removal and deeper integration with 3rd party [proprietary] services.
> Every feature in the browser should be polished, functional, and a joy to use. Where we can’t get it to that state, we shouldn’t do it at all.
sounds to me like mozilla’s modus operandi is still “copy others poorly.” great
But they also said:
If it’s just stuff packaged as bundled add ons that could be disable with a check box, then who cares?
The very first wrong is, this stuff must be opt-in, not opt-out.
Look at the OpenH264 plug-in as a sound example: Mozilla installs it without asking for permission and then provides no way to *remove* it, only to *disable* it. That’s simply and plainly wrong.
Why would you want to remove OpenH264 codec? Services like Pocket must be uninstallable sure… but codecs and other low level stuff… not so sure.
BTW I think the big problem with Firefox is not the lack of customization… it’s its horrible, slow and outdated user interface.
As is possible to download a version free from the OpenH264 codec (http://download.cdn.mozilla.net/pub/firefox/releases/39.0/win32-EME…) it also make sense to be able to remove it. As *why* one may not want it installed, it’s simple: not wanting a closed, proprietary and undocumented plugin to taint a free and open browser.
Regarding the Firefox user interface, do you talk about their lame attempt to copy Chrome’s UI? If so, I agree and that’s the reason I use the Classic Theme Restorer extension.