|Pale Moon Highlight Problems With Following Firefox
|Written by Mike James
|Wednesday, 23 March 2016
Pale Moon is a browser that tries to put right all that is wrong with Firefox. But, being a fork of Firefox, it brings with it some interesting problems. Now the Pale Moon team are contemplating starting over because of the churn in the Firefox code base.
Pale Moon doesn't have a huge market share. However, its users tend to be passionate about using it. It is a fork of Firefox Extended Support Release 24 which seems like a reasonable choice on which to base another browser. After all, Extended Support suggests that bugs will be fixed.
Pale Moon keeps the original fully customizable Firefox UI and adds a range of efficiency and security extras. Its supporters claim that it has gone down the road that Firefox should have gone down rather than copying Chrome and ignoring core features.
Being a fork of Firefox doesn't insulate you from Mozilla's decisions. In a post on the Pale Moon forum MoonChild, the project's lead developer, has raised the subject of how to progress MoonChild in the future and suggests the best option would be to start over.
The problem is that while the Pale Moon community has been adding features the web has moved on. The version of Firefox that it forked may be Extended Support, but this doesn't mean that Mozilla goes back and adds features such as ES6, promises and new CSS support. In addition Mozilla is changing the Firefox architecture in radical ways. The simple fact is that Pale Moon doesn't have the manpower to implement the upgrades to the code that they inherited.
You might think that the code in the latest Firefox could be used to implement the upgrade but as MoonChild reports:
"... the Mozilla code has been very unstable, not just from a product view (although it's been one of the main reasons we forked when we did) but from an actual code structure point of view. This is mainly because of some rapid changes that started happening with many refactoring changes upon refactoring changes, e10s and FirefoxOS considerations that fundamentally changed some of the underlying structures, not to mention changes in coding style, which makes porting code increasingly difficult (and regularly impossible) because they build on (and were designed for) the changed underlying structures."
He goes on to say:
"Mozilla code has become extremely heavily reliant on templates, classes, overloading, virtualization of functions and many, many stub and redirect functions to "pass the buck" to the correct module to process things in, which makes working with the code base very difficult."
There is also the small matter that Mozilla has moved to using Visual Studio 2013, which has introduced breaking changes to the original code base which used VS2012. Put simply, Pale Moon can't compile the new code with its compiler and can't compile itsold code with the new compiler.
The suggestion is that the best way to get out of this trap is to re-fork the Firefox code at a more up-to-date point, but not so up-to-date that the architectural vandalism that is being inflicted has much effect:
"This re-forking would be done on the last stable version of Mozilla code that hasn't had a sledgehammer put to it yet and that offers the features and capabilities we as a project would still want (i.e.: Sync 1.1, XPCOM binary components in extensions, XUL, XBL, complete theme support, etc.)."
This would still mean that Pale Moon could support a lot of the old Firefox features that makes it so attractive but it would mean that it would have to re-implement all of its code extensions and modifications all over again - not a nice prospect. However, when you think of it in terms of the stark choice between working on someone else's unknown undocumented code or reworking the code you created and know, it doesn't seem like a bad idea.
Whatever the Pale Moon community decide,s it is a lesson to all of us that forking a code base because you are dissatisfied with the direction of the original product isn't quite the solution it seems to be. As soon as you start to mutate the fork you introduce incompatibilities with the original and can no longer take advantage of the progress that the progress it is making. In the case of Firefox the problem is made worse by the radical changes in architecture that are being implemented and the high rate of code churn. This may all seem obvious, but when you fork a code base that is much bigger than your community can work with then you are doomed be left behind.
The problem is that if Pale Moon reforks then the chances are the same thing will happen in a few years.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 23 March 2016 )