Pale Moon Devs Ponder Dropping Current Codebase And Starting From Scratch (softpedia.com)
An anonymous reader writes: The developers of the Palo Moon browser are thinking of scratching their current codebase due to the fact that it doesn't support many of today's current Web standards, and because future Firefox plans will introduce incompatibilities within its codebase. The team plans to build a new browser from scratch, which they'll use to replace Pale Moon when it reaches a stable version. As with the old Pale Moon, the browser will keep Firefox's pre-Australis interface and still support many features removed in Firefox, like Tab Groups and full themes.
Because it's not from Microsoft.
Circumcision is child abuse.
where they are at now is the inevitable, coming back to bite them in the ass. you can't maintain a fork and backport features from the donor forever... not when you keep fucking around with the donor code, like they have, with both the browser and the render engine. granted, mozilla isn't doing them any favors with their own molestation of firefox.. but pale moon dug this hole themselves.
current firefox with a couple addons to restore some old features like previous ui and tab groups is all you need.
sounds familiar
http://www.joelonsoftware.com/...
who needs another browser anyway?
Just to be clear... this is not Pale Moon writing their own web browser. This is Pale Moon reforking from a newer Firefox branch and reimplementing the features that distinguishes them from Firefox. So, the article and summary says "from scratch", which is misleading because it's not "from scratch" as most people understand the term (writing a new browser yourself from the ground up), it's modifying the newly branched Firefox code, adding their own new features or stripping out crap from Firefox. It's the Pale Moon features only that would have to be rewritten "from scratch".
Joel's advice doesn't account for this scenario, in which you're building new code on top of an existing forked codebase that is lagging behind modern web standards. There are only two choices: Moon Child can try to integrate massive amounts of Mozilla developer changes back into an older fork (impossible, really), or he can refork and redo his own changes. Given that undoubtedly Firefox's changes have been far more numerous and substantial, it probably makes sense to re-fork and rewrite the Pale Moon code.
Honestly, I'm not sure how this is really sustainable, as the same thing is bound to happen again in the future. And I've never figured out how anyone can be assured that Pale Moon is at all secure, either. I have a sneaking suspicion it's "secure" in the same way Macs (and Linux, actually) used to be secure - too small a target for anyone to bother with. I mean, I love the guts of these guys trying this, but... well, I wish them the best.
I also really hate whenever someone trots out this article of Joel's and presents it as gospel, because while it's a good rule of thumb, it's foolish to view any particular development rule as 100% inviolable. I've personally been involved in several highly successful near or partial complete rewrites of very large codebases. I'd say it's certainly a good default position to take - you'd need to convince me before tossing code and starting over. But there are times when doing so would actually be more damaging and end up compromising your new design too much in order to maintain compatibility. Often, it's far better to simply put in a compatibility shim, leave the old code behind, and build a new module next to it, switching over when backward compatibility is needed and slowly depreciating required dependencies.
Irony: Agile development has too much intertia to be abandoned now.