Live data from Hacker News

Proposal to start a new implementation of Thunderbird based on web technologies

mail.mozilla.org

101–110 of 243 posts

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#101
post #6

So it'll be a self-hosted webmail service with a custom web server that runs locally?

That doesn't seem to be what they're aiming for here. The goal is supposed to be a new UI that looks and functions very similar to today's.

That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.

Obviously there are some relevant standards here and you could set something like this up with enough technical knowledge using other tools that already exist. However, that reduces the potential market by a few orders of magnitude to those who are sufficiently expert with those tools, and then probably by a few orders more for those who have the time to actually do it.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#102
post #97

Does anyone actually have any problems with Thunderbird? I feel like it is "done" software. It works, perfectly, for all my needs. It's fast. It has great UI. It lets me read and write email.

Haven't used it in years. Some questions: 1. Can I tag messages? If not, it is unusable for me. Once you get used to notmuch/sup type workflows, everything else sucks. 2. How good are its searches? Can I say I want all messages after a certain date, with a certain word, with no attachments (or with attachments > 100 KB, or with attachments whose name includes "xxxx")? 3. Does it support virtual folders, which essenti…

1. Yes, tagging is supported in-client only. Tags are not propagated outside of the client.

2. Search filtering options are all there, however the actual search algorithm is mediocre as fuck. You'll probably eventually find the email you are looking for.

3. Yes, virtual folders are supported.

Overall it's a great, however clunky piece of software. I didn't realize the code base was ~20 years old, so I fully support them doing a new implementation. Thunderbird has been a great client for me for 5+ years but imagining it powered with fresh, up-to-date tech excites me even more.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#103
post #92

Earlier quoted context omitted.

Why do you oppose things being run on something like Servo categorically?

Because there's existing libraries which solve many of the same problems which they inevitably run into and then re-implement them in JS. The "not invented here" mentality has to stop. Unless there's a significant reason to not utilize a library then it shouldn't be avoided. There's no good reason to replicate that functionality.

The "not invented here" mentality has to stop.

This is true, but the track record of bugs and poor security inherent in using relatively low-level languages like C and C++ for everyday Internet-connected applications also has to stop.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#104

Does anyone actually have any problems with Thunderbird? I feel like it is "done" software. It works, perfectly, for all my needs. It's fast. It has great UI. It lets me read and write email.

I feel the same way personally. I feel like I see tons of people complaining about it, but it's just what I want out of a mail client. The UI is a great, the GPG integration is great with enigmail, it's a very polished product. Not only that, but making one based on web technologies that moves away from the native look and feel it currently has would truly be a loss in my opinion. I'd probably give Claws Mail and alp…

It's an incredible product as-is, but I feel like they are stuck between a rock and a hard place with moving forward and forecasting beyond the immediate future.

I don't see why a new implementation couldn't maintain the current UI/native feel outside of poor decision making.

I could see it as a net positive, with cleaner easier to maintain code base built on more recent tech that is more accommodating to younger developers.

If they could pull off what Atom.io/Github did for the old ingrained IDE world in a mail client, that would be incredible, IMO.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#105

Does anyone actually have any problems with Thunderbird? I feel like it is "done" software. It works, perfectly, for all my needs. It's fast. It has great UI. It lets me read and write email.

The search is unusable -- wedding finds 'weds'. There is no way to do exact searching. I reported this 5 years ago, lots of other people have complained about the stemming, there has been no fix. There is no support for outlook/exchange. Not saying it's trivial, but it's useful in the modern era. IMAP folder support is very flakey, I reported some bugs but nothing got fixed.

I'm trying to keep an offline copy of my inbox using IMAP. I changed every setting I could find (like no cache limit, download the entire message instead of just the headers, ignore message age, don't delete any messages) and it still wants to download entire folders from time to time instead of just the changes. Maybe I did something wrong but that's my experience with IMAP support. It's also pretty slow but that might be some Gmail limitation.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#106
post #45
post #19

Earlier quoted context omitted.

No no no you missed what I am saying. I use horrible hardware appliances with built in md5 ssl certs for remote administration. I am not a web developer. I need to be able to access them to secure them and to work on hardware problems. This isn't even on the internet, this is on a local lan serving a small business. We're not going to buy new hardware because my browser updated, so I'm stuck having to boot up a mint…

That's the problem of the hardware appliance, and the company who makes it has basically abandoned their customer if they have no updates that let you manage it with a modern browser. Who makes this product? They shouldn't be supported.

The trouble is, from the point of view of basically everyone producing those devices, the current "what will every browser do this week" situation is not a viable platform to support in the traditional way. They can tell you their box works with certain browsers that are available at the time you buy it, but why is -- or should -- it be their problem if they supply a working product and then someone they have no control over updates a browser they didn't know you were using and something breaks?

If admins don't like this, they need to expect to pay a huge amount of money for ongoing support contracts that actively update to support new versions of browsers, or they need to stop demanding web-based config interfaces and get used to installing native software that uses proprietary protocols that will reliably still work next week as well.

The idea that vendors of devices that often have working lifetimes of 5-10 years or more should be responsible for keeping up with every little browser update for every "evergreen" browser throughout that lifetime as part of routine support is just not commercially viable, and that's why approximately no-one offers it.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#107
Whatever you do, make it render emails in a sane way. I still prefer mutt text-only rendering of emails (content) than any email rendering software, but if you're going to render and digest html, actually do it. The total time involved in and barbarity with which web atrocities have been committed to make emails render correctly in Outlook or even Gmail cannot be understated.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#108

Earlier quoted context omitted.

Because there's existing libraries which solve many of the same problems which they inevitably run into and then re-implement them in JS. The "not invented here" mentality has to stop. Unless there's a significant reason to not utilize a library then it shouldn't be avoided. There's no good reason to replicate that functionality.

The "not invented here" mentality has to stop. This is true, but the track record of bugs and poor security inherent in using relatively low-level languages like C and C++ for everyday Internet-connected applications also has to stop.

That doesn't really help you when the platform you run on be it a browser or a virtual machine is written in C/C++ which by implication can be exposed to the same security flaws if/when they utilize unsafe design patterns or idioms. So, all you've done is pass the buck onto Servo/Gecko/Safari. The reality is that you can't make an argument that's ironclad in favor of forcing JS to become the new C. Let JS do it's wonders for the web and let C/C++ and other languages that have great native application tools do their wonders for the desktop?

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#109
> We need 2 persons for the framework, 3 for backend modules, 4 for frontend UI, and 1 for theming.

Doesn't 4 people dedicated to front-end UI seem excessive/unnecessary? At least, at the beginning? I would dedicate almost all work to the framework and backend modules; UI with web technologies is far from complicated compared to everything else the client would require.

Re: Proposal to start a new implementation of Thunderbird based on web technologies

#110

Earlier quoted context omitted.

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 pr…

> 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 c…

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.
Post reply on HN