News for hackers. Stuff that matters.
Re:Proposal to start a new implementation of Thunderbird bas... by randomdata on Thursday April 20, 2017 @01:37PM (#14158915)
Is a rewrite necessary to improve on those aspects over modifying the existing codebase?
Re:Proposal to start a new implementation of Thunderbird bas... by hashhar on Thursday April 20, 2017 @06:57PM (#14161631)
Yes. Because the Thunderbird and Firefox codebases are diverging so much that instead of just maintaining Thudnebird people will have to maintain a fork of Gecko too.
Re:Proposal to start a new implementation of Thunderbird bas... by Certhas on Thursday April 20, 2017 @01:41PM (#14158958)
Maybe not, but from the sound of it, a rewrite is necessary just to keep the lights on and to keep Thunderbird compiling in the long run.
Re:Proposal to start a new implementation of Thunderbird bas... by Silhouette on Thursday April 20, 2017 @02:11PM (#14159241)
What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely?

Changing the UIs within this particular family of software products has often given questionable results, confusing or upsetting the core user base for little real benefit. Other UIs built on JS and HTML technologies have so far tended to be slow and buggy compared to using native technologies on the desktop and mobile platforms. If the exercise is expected to take as long as 3 years with the available resources and the hope of getting back to more of a community-supported culture, that seems like a huge amount of work to essentially stay where you already were.

Re:Proposal to start a new implementation of Thunderbird bas... by jcranmer on Thursday April 20, 2017 @02:29PM (#14159413)
> What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely?

Short answer: security bugs. Gecko has too high of a code churn to maintain long-term support branches, particularly for people who have little knowledge of the components in question (e.g., SpiderMonkey). Forking Gecko might be a viable short-term strategy, but it's not at all viable long-term.

Re:Proposal to start a new implementation of Thunderbird bas... by Silhouette on Thursday April 20, 2017 @03:09PM (#14159816)
That makes a lot of sense if we're talking about using Gecko to render the contents of arbitrary HTML emails. However, this proposal seems to be about problems supporting the UI itself and proposing a move to some other JS+HTML rendering system as an alternative. At first glance, that appears to be a separate issue, other than both types of functionality possibly relying on Gecko today and rendering engines being quite large so using two different ones not being desirable.
Re:Proposal to start a new implementation of Thunderbird bas... by jcranmer on Thursday April 20, 2017 @03:16PM (#14159887)
Gecko is actually quite difficult to embed (Mozilla more or less gave up on there existing non-Firefox/Thunderbird embeddings around 2011 or so).

There's a lot of low-level interfaces and design decisions that filter through Thunderbird, for example networking interfaces. Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.

Re:Proposal to start a new implementation of Thunderbird bas... by Silhouette on Thursday April 20, 2017 @03:59PM (#14160285)
Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.

Right, but isn't the argument quite a few people are making here that moving to a different UI rendering engine doesn't seem to be obviously justified, given the goals of the project and its current situation? If the architecture is as inter-dependent and non-modular as your comments suggest, wouldn't that make changing significant parts of it even less likely to be successful?

At that kind of level, you might be better putting the whole project into legacy mode with emergency updates only, and just letting it carry on for as long as it's useful and then die of natural causes when the time is right. For the other goals mentioned in the original proposal we were talking about, if there's sufficient interest to support doing that much work then an entirely new project with no baggage at all seems like a safer and more realistic bet.

Re:Proposal to start a new implementation of Thunderbird bas... by Certhas on Thursday April 20, 2017 @03:35PM (#14160046)
As a result of this thread I have tried the Nylas mail client which has a javascript UI, and I am very pleasantly surprised by just how smooth the UI is.

Honestly, if I could use it without a Nylas account I would very seriously consider it as a Thunderbird replacement.

From reading the original email thread it also looks like the Thunderbird guys are paying attention to Nylas.

Re:Proposal to start a new implementation of Thunderbird bas... by dotancohen on Thursday April 20, 2017 @05:23PM (#14161053)
VSCode and Slack are two other Electron apps with snappy UIs. Though I commend the devs on their snappy UIs, both those apps churn the CPUs and consume crazy amounts of memory. They absolutely kill the battery on laptops and make other applications unusable.

I do not want my mail client or any other app that should be always running in the background to be written in Electron.

Re:Proposal to start a new implementation of Thunderbird bas... by Certhas on Friday April 21, 2017 @11:59AM (#14166706)
That's a pity. Given that they are exactly aiming for mobile applications though I really hope they will keep these issues in mind though and make informed decisions on this.
Re:Proposal to start a new implementation of Thunderbird bas... by hackuser on Thursday April 20, 2017 @11:37PM (#14162933)
Not only are security bugs an issue, as mentioned, but what about maintaining compatibility with changing platforms? Who will fix the bugs when future versions of Windows, MacOS, and Linux introduce growing numbers of 'minor' incompatibilities, and maybe major ones? What about changes in protocols, such as IPv6 (though mail protocols are mostly mature)?

If Thunderbird isn't updated, it will slowly die of bit rot.