Live data from Hacker News

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

mail.mozilla.org

221–230 of 243 posts

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

#221
post #50

I wonder, if they want to use JS, why not QtQuick? I'm a heavy Thunderbird user but I would move to pretty much anything else if it were to switch to Electron.

I think the reason QtQuick hasn't taken over this space, is that you still need to deal with C++ and cross-compiling. If QT had an option that made it clear you could develop and distribute in JavaScript only, that would be a hit.

You can write QML apps in like every popular language, there are well supported bindings everywhere.

I dont get the C++ hate though. C++11 and up is a totally new language and much more productive than its reputation gives it.

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

#222
post #117

Earlier quoted context omitted.

> quickly scroll through a list of up to 100000 messages. You can do this with JS and HTML. There are some popular small JS libs that do just that. It works like this: it creates a div with a very big "height" value to get the scrollbar look like there is a long list, and JS just loads in the visible area plus a few items above and below, and reloads data as you scroll. It works very good in Chrome and Firefox, and e…

Does it still work well if I click-drag the scrollbar very quickly from the top to the middle or bottom of the list? Or if I use a keyboard shortcut to jump immediately to beginning or end?

Yes, that's the point. The div is a normal HTML element with a normal scrollbar.

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

#223
post #27

"JavaScript is the best choice." (Citation Needed). This proposal identifies serious legitimate concerns with Thunderbird development going forward, but the proposed solution looks more like a hammer seeking a nail than a thoughtful approach to addressing the concerns.

Yeah, I cringed at the JS thing. Why not do it in Rust and start with some of the Servo code as a base? That would give the developers an intermediate application to work with that doesn't require the full capability of a web browser.

The whole tirade read like a thinly veiled "building an Electron-based MUA is just easier by now", which is a thing I've been contemplating toying with because, to paraphrase another well-known MUA, all those desktop email clients† flat out suck and the best ones are barely above the tolerable threshold.

> Why not do it in Rust and start with some of the Servo code as a base?

Thought about it, but I think Servo might just not be that ready yet given the expected timeframe. Could be of a great synergy and a nice real-life testbed for Servo though.

† I've extensively used a lot on various OSes, from Claws to Gmail (web) to mutt to Mail.app to Eudora to Fastmail (web) to Outlook to AirMail. For none of them could I ever say "nailed it" and while some do have their pluses they're all broken one way or another which brings the whole package down.

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

#224

Earlier quoted context omitted.

Hum, it would be interesting to know how you use it (with respect, I'd suggest you have very basic email needs). For me Thunderbird is badly broken. This is not the place to list bugs, issues, limitations etc. in any detail but there are very many indeed (so I'll only provide a skeletal outline of them here). Frankly, on occasions, I find Thunderbird is unusable for some jobs and I end up using either an ancient copy…

I guess we all have our opinions but if you are composing long emails with intricate formatting I'd suggest you're doing it wrong. Email messages should be short, and preferably plain text. You have a little more leeway than in a tweet, but more than a paragraph or so and you lose the reader. I see this so often -- people will send me a treatise in email and I simply cannot comprehend that much text on a computer scr…

It's exactly the other way around for me. Any text that isn't directly in the email will either get ignored or I won't reply in as much detail as I would have. It's much more difficult to quote selectively from attached files so I don't do it.

And printing is about the most horrible thing ever invented. I only do it under threat of financial loss (return labels, letters to tax authorities). There's nothing as broken as printing. It never works flawlessly and I can't focus on printed text anyway.

Printed text has no search, no copy and paste, no changing font sizes or brightness, no hands free reading, no place to put paper without it getting fatty or full of coffee stains.

So I guess the conclusion has to be that there is no general right or wrong when it comes to the length of text in email. I depends on who you are sending it to. I pity whoever has to correspond with the both of us :-)

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

#225

Earlier quoted context omitted.

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

I didn't say anything about using JS as the alternative. I happen to think it's a rather poor language and that using it for anything other than running front-end code on a web site until we have better alternatives is usually a mistake. But there are a lot more languages out there than C, C++ and JS, and I don't think any of those is a particularly good choice for this sort of task.

Oh no doubt there's better languages in terms of general purpose programming. I'm biased towards OCaml myself since it has nice syntax but there's plenty of options to choose from. I'm just pointing to C/C++ languages since they're the most mature and widely available in terms of documentation, IDEs, etc.

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

#226

Earlier quoted context omitted.

Hum, it would be interesting to know how you use it (with respect, I'd suggest you have very basic email needs). For me Thunderbird is badly broken. This is not the place to list bugs, issues, limitations etc. in any detail but there are very many indeed (so I'll only provide a skeletal outline of them here). Frankly, on occasions, I find Thunderbird is unusable for some jobs and I end up using either an ancient copy…

Re the editor, the Gecko editor component has long been plagued with the issue that the module owner didn't really want to hold that position. For a time, the owner was completely hostile to anything Thunderbird, despite the fact that Thunderbird was the heaviest and most notable implementation of the editor. I will also point out that there is actually some fairly deep integration code within the Mozilla editor with…

Thanks for that reply. That makes sense. My comments about the editor were deliberately made from the perspective of the end user. Whilst I used hyperbole to emphasize the fact that the editor was the main culprit, I agree things usually are not that simple.

However, the key point I was trying to make still stands which is that irrespective of the state of the underlying code/Gecko editor components etc., etc., for some reason third party developers (here BlueGriffon's developers) have managed to tame the code in a much more successful way than Mozilla itself has done. The implication being that as principal developer Mozilla should have been able to do a better job than third party developers should. Thus, it amply demonstrates Mozilla's lack of commitment to the Thunderbird project per se (and that this has been so for a very long time (ipso facto, so have the bugs/problems) without Mozilla bothering to attend to them).

I am not a Thunderbird add-ons developer/TB code expert so there's little point me attempting it, but it would be very informative to find out why the BG editor works and the TB one is so brain-dead. As I see it, it's important to cut to the core of these problems if for no other reason than to show the skeptics or those who've simple requirements and find little or no problem with TB that there are real longstanding problems with Thunderbird and that some of us are not just being argumentative for the sake of it.

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

#227
post #174

Earlier quoted context omitted.

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

> 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. Uh, that's exactly what an email server does. Thunderbird is just the client used to access it from any device.

Was going to reply with the same - it is called IMAP

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

#228

I like the gpg integration using enigmail in Thunderbird. So I can send encrypted messages to my friends and people I write code with.

You'll be happy to learn that the P=P folks are most likely going to be handling full end to end encryption integration for Thunderbird, for the current version, and the new one (if it happens):

https://pep-project.org/

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

#229
post #136

Earlier quoted context omitted.

> Google Inbox used be called Sparrow ( https://en.wikipedia.org/wiki/Sparrow_(email_client) ), which was a regular app that Google acquired. I used it since the beginning. It was a new paradigm back in 2011, which is now the standard in modern clients. Could you name a few apps that have the Inbox/Sparrow features like snoozing an email until some time in the future? I would love to have that, I looked for Thunderbi…

Lots of them, on what OS are you? Apple Mail has it.

I'm on Linux and use Thunderbird (sometimes with Exchange integration, but that's not required).

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

#230

Earlier quoted context omitted.

Hum, it would be interesting to know how you use it (with respect, I'd suggest you have very basic email needs). For me Thunderbird is badly broken. This is not the place to list bugs, issues, limitations etc. in any detail but there are very many indeed (so I'll only provide a skeletal outline of them here). Frankly, on occasions, I find Thunderbird is unusable for some jobs and I end up using either an ancient copy…

I guess we all have our opinions but if you are composing long emails with intricate formatting I'd suggest you're doing it wrong. Email messages should be short, and preferably plain text. You have a little more leeway than in a tweet, but more than a paragraph or so and you lose the reader. I see this so often -- people will send me a treatise in email and I simply cannot comprehend that much text on a computer scr…

With respect, it is some time since I've read the various email RFCs (822/2822/1123 etc.), but I cannot recall any of these email standards saying that emails (a) have to be short and (b) that formatting doesn't matter. In fact, there are numbers of RFC standards that actually specify the standards for text formatting, for example, the Multipurpose Internet Mail Extensions (MIME) standards have allowed 'rich text' formatting in emails for years now.

Thus, to be compliant, email clients should comply with these email standards—this means their editors should also format text to those standards. I contend that there is indisputable evidence that Thunderbird does not fully comply with these internet standards by a considerable margin (nor has it ever done so). Moreover, in parts, Thunderbird is so bad/non-compliant that it is essentially not fit for purpose.

This has absolutely nothing whatsoever to do with the fact that some users will only ever use a subset of those features [standards] when composing emails.

As long as users comply with the email standards, they are entitled to use any formatting they so desire. Whilst many emails are short, the fact is that there are those who often send highly formatted emails of many pages in length.

As fauigerzigerk says, in many instances, attachments are often not suitable so they must be sent in-line. This then requires the editor to handle in-line text/images etc. correctly (Thunderbird does not do this without fault).

Post reply on HN