> 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 browser tab.
This approach simply inherits all the security issues from the insane complexity of modern browsers, just to reuse some common components that should've been extracted and separated from all the browser baggage.
Hey, Mozilla, remember XUL? Before you decided to deprecate and remove it from Firefox, it was the unified UI framework that both a browser and an email client could use, without sharing any of their core dependencies. What a concept!
I'm surprised Mozilla still has interest in maintaining Thunderbird. I'm curious to know what the userbase for it is, but I can't imagine desktop email clients have a mainstream audience anymore.
> 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 absolutely possible to re-use Firefox core without building and including all the HTML features regular Firefox comes with). And finally, the whole TB code base is already in JS/XPCom, which would make the transition much easier.
> Hey, Mozilla, remember XUL? Before you decided to deprecate and remove it from Firefox, it was the unified UI framework that both a browser and an email client could use
That's an unnecessary snarky. There are millions of reasons why it made sense to remove XUL. Yes, on paper XUL is great, but it was based on old UI ideas, we had to make tons of hacks to work around those old ideas, and performance was not on par with what overly-optimised HTML could achieve. XBL was way to limited, and tons of features were just useless (remember RDF and templates?).
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.
> without sharing any of their core dependencies
That's not true.
> I'm surprised Mozilla still has interest in maintaining Thunderbird
It's not Mozilla-Mozilla who's maintaining Thunderbird, but another entity.
> Yes, on paper XUL is great, but it was based on old UI ideas, we had to make tons of hacks to work around those old ideas, and performance was not on par with what overly-optimised HTML could achieve.
Criticizing the quality of something by saying it’s from “old ideas” is a total non sequitir. Old is not the same as bad (there are plenty of great ideas that are old) and modern is not the same as good.
The pointlessness of just saying XUL is old is underlined when you suggest replacing it with HTML. HTML is even older than XUL and a pretty good idea.
And by the way whatever you replace(d) XUL with will be an old idea soon too.
Thanks for your comment. I'm commenting as a long-time user of Mozilla software--since the Netscape days--and I'm not familiar with the internal or technical reasons that led to these decisions, so I appreciate your perspective. My snarkiness is coming from a place of tough love and frustration with the current state of Mozilla, so allow me to push back against some of your points.
> 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?
The thing is, people want to read html emails. MS outlook doesn't need a web browser to run, because it uses ... MS Word to render emails, which if you've ever tried to send formatted emails programmatically you'll know it's a dark, dark state of affairs.
Good. Pretty much all emails I care about would be better off without any formatting beyond what e.g. Markdown provide - and that subset of HTML works well enough in Outlook.
I dread the day that Google manages to grab enough of Outlook's marketshare so that they can dictate the direction of email just like they have been doing to the web - we're almost there already.
> 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 browser tab.
This approach simply inherits all the security issues from the insane complexity of modern browsers, just to reuse some common components that should've been extracted and separated from all the browser baggage.
Hey, Mozilla, remember XUL? Before you decided to deprecate and remove it from Firefox, it was the unified UI framework that both a browser and an email client could use, without sharing any of their core dependencies. What a concept!
I'm surprised Mozilla still has interest in maintaining Thunderbird. I'm curious to know what the userbase for it is, but I can't imagine desktop email clients have a mainstream audience anymore.