I'll add one more negative sentiment. > Using a solid base architecture like Firefox is the perfect starting point. No, but why? Why does an email client need a web browser to function, and why is that the "perfect starting point"? The only reason an email client might use a web _view_ for, is for reading HTML emails, and even then that web view should be a far more restricted and barebones version of a traditional b…
Ex Mozilla here. > Why does an email client need a web browser to function, and why is that the "perfect starting point"? I'm not saying using Firefox is the best thing, but there are arguments to be made: first, Firefox is multiplatform, and good at it, and that's something Thunderbird needs as well. Then, like you said, an email client needs to display web pages, so no matter what, a web engine is needed (and it's…
> Firefox is multiplatform, and good at it, and that's something Thunderbird needs as well
I get that, but why isn't the UI toolkit and whatever multiplatform support that Thunderbird needs, not abstracted away from the web browser dependencies? Maybe it is so, but from this article, it sounds like actual Firefox components are reused by Thunderbird, for better or worse.
> an email client needs to display web pages, so no matter what, a web engine is needed
Again, I'm not familiar with the internals, but surely the engine needed to render just HTML and CSS for purposes of HTML emails, is not the same engine needed to render modern web sites with JavaScript and all the overhead of related technologies. You do say that it's possible to re-use Firefox core without all Firefox features, so I would assume that this purpose-built engine for Thunderbird is a very, very minor subset of Firefox, that could be isolated in a way to not pull in all other Firefox dependencies.
And keep in mind, that all this is to render HTML emails, a minor part of the feature set of an email client, which many users--particularly those that still choose to use a desktop email client--prefer to disable altogether.
> the whole TB code base is already in JS/XPCom, which would make the transition much easier.
I see, but this is a benefit for Mozilla developers, not users. Often technical decisions are made because it benefits the developer, rather than user experience. This is the reason we see the proliferation of so many Electron apps, and so many failed attempts at cross-platform mobile toolkits. The direction Mozilla seems to be headed in is to reinvent Electron for Firefox, which is again prioritizing the QoL of internal developers over users. No user _wants_ to run a separate web browser process that wraps a single web site just because it was convenient for developers to build it.
> There are millions of reasons why it made sense to remove XUL.
I can imagine that was certainly the case, but all reasons you've listed were problems for developers.
> performance was not on par with what overly-optimised HTML could achieve
You mean actual UI performance, or performance in some synthetic benchmark? I've used a few of the Firefox forks that still use XUL (Pale Moon, Basilisk, etc.), and while I chose to abandon them for other reasons, UI performance was never an issue.[1]
> I would love to see XUL come back, but we need a modern version of it, and to be honest, this could just be an extension of HTML.
As a user, my frustration wasn't with XUL going away. It was because it was removed without an equivalent replacement, while breaking and severely limiting many extensions. So I'd also like to see a modern XUL alternative, since a crossplatform and generic UI toolkit is exactly what's needed to build applications as diverse as a web browser and email client (or audio player[2], or chat client[3]).
> > without sharing any of their core dependencies > That's not true.
That's a sign of my technical ignorance then, but there's no reason why a sane UI toolkit _couldn't_ be built without a cross-contamination of dependencies between projects that use it.
[1]: After reading this article[4], which I highly recommend for anyone interested in the topic, it makes it clear that there were several issues with XUL/XPCOM that limited performance. IMHO, that's not a reason to remove XUL altogether, but to address these performance bottlenecks in a way that avoids throwing the baby out with the bath water. Indeed, a lot of effort seemed to go in this direction, but ultimately it was decided to scrap it entirely. It seems like Mozilla was chasing the performance of Chrome by becoming more like Chrome, rather than fixing the issues with XUL.
This comment[5] from a Pale Moon maintainer is enlightening. To summarize, there are warts and security issues with XUL (extensions, in this case), but such a framework can continue to exist if the maintainers prioritize keeping their existing user base of power users, instead of chasing the development model of Chrome. Yet Mozilla decided to do the latter, alienating their user base in the process, while still failing to attract new users. In retrospect, how was this a good decision?
[2]: https://en.wikipedia.org/wiki/Songbird_(software)
[3]: https://en.wikipedia.org/wiki/Instantbird
[4]: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...
[5]: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...