The big problem I see is entrenchment... it's an app where nothing can change. They can't go ahead and just do a Chrome 69 with it.
What I would love to see is a small team in Mozilla create a spin-off Electron app, and do it well. Electron has a bad rap, but it's mostly due to being misused. Electron can be used well (VS Code for example).
Mozilla LightningBird for example. I could get on board with that. Heck, I'd probably help out.
Edit: Jeeze! You guys sure hate Electron. Just because a tool is misused so often, doesn't mean it's a bad tool.
Hence the spin-off app. A ground-up, UX focused app which does not have to meet feature parity, would attract users who are already confused by email clients.
This is a different target audience to the people who typically use Thunderbird at this time.
Between github, SMS, social media, IRC & slack, video-conferencing, blogs, RSS, etc., email has become the medium of last resort. I still get a lot of email, but it's mostly automated notifications, and I usually have to log in somewhere to actually recieve a document because email is insecure.
I'm not expressing a preference, just pointing out what people do. You'd better like the features email has because it has a hell of a lot of inertia at this point. That said, it does have the killer feature of genuine interoperability, which virtually none of the new contenders even try for.
If someone do not use email hardly can be considered tech savvy. Sorry.
Perhaps he/she work for a company that do not really know IT so force their workers to use limited and limiting platforms, but it that's remain for personal world then no, it's might appear to you a tech savvy person but that's only due to Kant-ian glasses, not reality.
They need a stripped down HTML engine for rending incoming emails and composing emails. With an electron-based app how are you going to prevent HTML from rending in the view?
I think it's due to a majority of those who have been around the block a few times knowing a trainwreck of a fad when they see one. At the end of the day it's basically taking a web page and throwing it into a container without browser controls. Remember when Windows 95 IE4 enhancements got so much flak and jeers from hackers due to MSHTML? Electron feels even worse than that.
The Web still sucks, and we don't need to shove The Web into native applications. Learn to make an actual program. Heck, QT exists, learn to use it.
I'm not saying you can't use an HTML layout engine for help and info screens, but for the entire program it's pants-on-head stupid. The time spent trying to warp one's web designer skills to make an "app" could have been used to learn how to make an actual application that would've been portable, and take less than a gig of RAM.
I use Teams at work, and it's taking 300+ MB of RAM on startup when it's basically a glorified chat client. Insanity.
> we don't need to shove The Web into native applications
90% of the time I'd agree with this sentiment, but modern email clients need to be able to render rich web content. A browser engine integration is just the reality, at some level.
You have an a bit cached but true point, that's is: there was a so big push to web tech that actual local graphics libraries was left in an old era without real updates. That's the case even of Qt and their QML mess. That's the case of GTk mess etc.
However have a browser as a framework and environment for anything is even worse than actual X server architectures.
So yes, we need to rethink desktops, perhaps looking at past solutions like LispM GUIs and Plan9/Rio but certainly not move toward actual trend.
Explain how QML is a mess? I've been using it almost as long as it exists - which is much longer than the life of the average hot JS framework - and didn't notice the mess. It has problems and limitations like everything, but overall it's very productive.
Essentially because require tons of fragile boilerplate code to work and it's mostly designed with web principle in mind, not desktop one.
You essentially can't found a QML GUI that not exhibit tons of error, from commercial one like TeamViewer to Kde/Plasma. It's surely more flexible than classic widgets but it's flexibility is not designed in a manageable way.
> require tons of fragile boilerplate code to work
Well yeah, you need to implement the properties and data models in C++ and export them - if you are doing it right that is. But the UI code is very quick and easy to write in return!
> it's mostly designed with web principle in mind, not desktop one
Not mainly desktop, true - it is designed mainly for touchscreens, mobile or embedded. It is easy to use exactly because it's not a web technology bent for user interfaces.
> exhibit tons of error
Not for the things I've been working on, which includes KDE / Plasma and many commercial applications.
I don't get it, why can't anything change? In fact, the platform in which Thunderbird runs - XULRunner - is the equivalent of Electron for the Gecko engine, and a bunch of different applications have been done with it.
Most of the actual guts of Thunderbird are in mailnews/, particularly mailnews/base and mailnews/db for the this-is-what-eats-the-CPU things. That code is almost entirely in C++, although there is an effort to try to rewrite stuff in JS (which has gone slowly because, hey, that's 100KLOC of C++ you have to move at once).
By that definition would you call Firefox before version ~40 a javascript app? It obviously isn't despite using XUL and the elements implicit in that. The same is true of Thunderbird.
The technology in use is called XPFE. For a full (graphical) overview, see http://mb.eschew.org/1
It is different sorts of XML (XBL, XUL, RDF, DTD) controlled via Javascript and styled by CSS running on top of a C++ runtime. The components, the runtime exposes, can be accessed directly from within Javascript. Most of the application specific stuff is written in the XML+JS+CSS domain. There may be the one or other app-specific support library, but in the end, they all run on top of the same xulrunner binary.
The underlying rendering engine is in C++, of course. As is the JS implementation.
Which is to say, exactly like Electron. The only relevant difference that I can see between XUL and Electron is that the former had its own non-HTML-based markup language for UI.
Oops! I'm not actually familiar with the Thunderbird source's organization, so I just went by what was marked as owned by Thunderbird in that wiki page I linked.
In practice, Thunderbird is all of comm-central sans suite/ and chat/. calendar/ used to be Sunbird [a standalone calendar client], but those people decided to channel all of their resources into Lightning instead, so all of the Sunbird-specific stuff was ripped out.
Lightning is strictly speaking an independent project from Thunderbird, but it is far and away the most-used extension in Thunderbird and parts of it (particularly the backend) have essentially moved into the TB distribution for various policy reasons. There's some other stuff that's basically build system, release engineering, or testing gunk, but that stuff is mostly Python anyways and won't impact the SLOC metrics too badly.
Mere line count does not tell a truth, simply because you can do more thing with a SLoC in a language than another, also sometime to be on certain platform you need an enormous amount of code only for them that's have no other purpose that boilerplate for a platform.
Most of the backend is written in C++. This is the mail protocol suite, the message database store logic, most of the internal account glue stuff, and even the bits that drive the main message listing (although that's moving to JS because Mozilla is killing off nsITreeView, a move which I fear for the performance implications of). The parts that are in JS are most of the code that drives the actual display. Of the MVC for the display, essentially the main model and view are both implemented in C++ whereas the controller is JS.
The largest pieces of the backend that are in JS are the RSS functionality and gloda (one of the search backends), as well as half of the MIME parser.
Thunderbird is a XUL implementation with a lot of JavaScript being used for its UI. It's as close as you can get to being the Electron of Firefox without being in a PPA.
The most recent version (Thunderbird 60) introduced sweeping UI changes that went much deeper than even Chrome 69's.
There is a big difference between using an object model designed for UIs and using the DOM or canvas, even with the same language (JS). An appropriate model can vastly simplify and accelerate layout and painting. I'm thinking of QML here - the performance situation is probably similar with XUL, ugly as it may be.
A total rewrite almost sank Netscape[1] long ago. It's still generally a bad idea.
There's an electron based mail client called Mailspring[2], and having used it for a few months, I definitely understand the antipathy towards electron. You might like it.
Huge rewrites of firefox are saving it today. Seems like the best way is to rewrite in chunks allowing you to use new bits in the existing application.
What I would love to see is a small team in Mozilla create a spin-off Electron app, and do it well. Electron has a bad rap, but it's mostly due to being misused. Electron can be used well (VS Code for example).
Mozilla LightningBird for example. I could get on board with that. Heck, I'd probably help out.
Edit: Jeeze! You guys sure hate Electron. Just because a tool is misused so often, doesn't mean it's a bad tool.