5 ms·

Is a rewrite necessary to improve on those aspects over modifying the existing codebase?

Certhas 10y ago
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.
- Silhouette 10y ago
  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.
  - jcranmer 10y ago
    > 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.
    - Silhouette 10y ago
      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.
      - jcranmer 10y ago
        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.
        Silhouette 10y ago
        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.
  - Certhas 10y ago
    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.
    - dotancohen 10y ago
      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.
      - Certhas 10y ago
        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.
  - hackuser 10y ago
    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.
hashhar 10y ago
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.

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.

Silhouette 10y ago
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.
- jcranmer 10y ago
  > 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.
  - Silhouette 10y ago
    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.
    - jcranmer 10y ago
      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.
      - Silhouette 10y ago
        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.
- Certhas 10y ago
  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.
  - dotancohen 10y ago
    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.
    - Certhas 10y ago
      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.
- hackuser 10y ago
  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.

hashhar 10y ago

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.