I think this is the 3rd time I've heard Thunderbird is/is going to be unmaintained and that I should avoid it, but I'm yet to see a good alternative. Claws was crashy and didn't DPI scale properly on Windows, OS X Mail had strange behavior with my IMAP server and I just wanted a consistent UI with my Windows and Linux system. My next option is webmail but there's no good IMAP webmail client that seems to be able to handle 8 accounts at once with thousands of messages in each. The best alternative I've seen is probably Alpine, a CLI based client, but that was difficult to use and seemed to randomly send deleted characters from emails to clients, which was almost a major issue on one occasion.
I'm just going to keep running Thunderbird until there are gaping security holes, people say Thunderbird is bad but everything else is worse.
I think a lot of people are forgetting that there is still a community developing it since Mozilla stopped "updating" it, beyond maintenance, in 2012. The product isn't dying, just will no longer be Mozilla backed. I assume that maintenance, like ongoing updates, will be passed to the community and hopefully another company steps up to back the project.
No problem. I think everyone got out their pitchforks without reading Mozilla's announcement and looking at the repo.
There are always issues to help out on. Here's a bit more info on contributing [0]. I imagine it won't change much as the project is officially handed off to the community. It's largely led by the community anyways at this point.
I saw this on hacker news a while ago but it seems like a great alternative to thunderbird. I've used it and I really like the look and feel of it compared to thunderbird. I'm pretty sure I saw an option for IMAP too. It's called N1 and it's from Nylas. https://www.nylas.com/n1
Nylas is a beautiful app and, by design, easily extensible. As a result, I think that it has a better chance than other open source mail clients of providing an experience that's as polished and complete as Gmail. Doing that requires a bunch of affordances like calendar integration, Youtube previews, warning if you forgot to add an attachment, 10-second "undo send", and so on. Letting the community write those as add-ons seems smart.
To really make Nylas compelling over Gmail, and also to replace Thunderbird, here's what I think needs to happen:
1. Bundle Sync Engine and N1 into a single program.
2. Implement local search. Faster than IMAP search and doesn't rely on a network connection.
(As it stands, Nylas requires an internet connection to work. As long as that's the case it's no Thunderbird replacement at all, and will have a v hard time winning over Gmail users.)
The good news is that both Sync Engine and N1 are GPLv3, so it's totally possible. The bad news is complexity:
* Sync Engine is written in Python and uses MySQL for persistence
* N1 is built with Coffeescript + React + Electron, and uses SQLite for persistence
So we need to simplify. We can't just bundle all that into an app, it would be a monstrosity. Here's how I think we could do it instead:
* Use Sync Engine as the basis for a Node library for IMAP sync
* Use the SQLite full-text feature (fts4) for search
That way you'd have a single Electron app with all persistence in SQLite.
I'm prototyping this now. Thoughts? Let me know if you have ideas or want to help!
N1 actually works offline. Obviously it won't fetch new mail, but you can read, archive, compose, and search for local messages. When you reconnect, those tasks will persist to the backend and Gmail/iCloud/Exchange.
Search is definitely an area we can make dramatic improvements, and we're working on it.
It may be open source, but it's a thin client-side with your data being handled by the servers of a third party. No thanks, as trusting Google or FastMail with my email is a tough pill to swallow already, trusting an intermediary as well is way too much.
Looking through their API docs, one of the things that I noticed is that they added a transaction log ("delta" field), which IMAP doesn't have: https://www.nylas.com/docs/#deltas
Having a server communicate with IMAP (which is slow), cache the results, and export a more efficient/log-structured alternative probably makes syncing client computers much faster.
Nylas N1 requires a custom server (Nylas Sync Engine) to do notifications. Why? Their FAQ is extremely vague about it. Apparently it suffers the same performance issues as plain IMAP for search. It seems this might be to support their Electron based UI, which seems... bloated to say the least.
The sync engine handles all the compatibility or dozens of IMAP and Exchange servers, and uses a variety of heuristics for real-time notifications. It also does the heavy-lifting for the huge amount of data in most people's mailbox. The N1 app can cache your entire archive in about 10% of the disk space required if you also download all unprocessed headers+attachments.
Right now our search implementation just sends a proxy request to the IMAP search, so you'll get the same performance as Gmail web, Mac Mail, etc. It's not ideal. We're working on our own faster search system, but it's tough to build a huge distributed search cluster that handles tens of terabytes. (And is growing quickly!) If anyone here wants to work on that, we're also hiring. ;)
N1 is built on Electron, which under the hood is Chromium+NodeJS so that comes with a bit of weight. But the app itself is pretty manageable. You can check out the source here: https://github.com/nylas/n1
I believe the sync engine translates between IMAP and a custom JSON protocol they've created. I'm not sure what the performance difference is, but looking at the API docs, it looks a lot nicer to work with than IMAP: https://www.nylas.com/docs/
It also seems to more accurately represent modern semantics for working with email. For example, it allows using OAuth for authentication, and it has separate fields for folders and labels, depending on the backing email service. (And unlike IMAP, the labels field is actually useful.) You can also download a transaction log to make sync faster, which I don't think has an analog in IMAP.
Subjectively, I've found the performance to be rather snappy in most cases.
I've moved to Mutt/OfflineIMAP on most every machine I own, and it's worked remarkably well. It's a CLI app, yes, but it outshines Thunderbird (and most other GUI clients, for that matter) in a number of ways:
- FAST. Mutt lets you process thousands of messages in short order. Mutt is directly responsible for helping me dig out of a 50k deep email hole brought on by years of GMail's approach (archive, never delete) in a few days of on-and-off cleanup.
- Plays well with others. Uses a bog standard Maildir format that anything sane can read (including Thunderbird, so migration should be easy), provides a very powerful hooking system which can do anything from verifying PGP signatures to checking your spelling before sending to displaying attachments.
- Sane defaults. Doesn't require a lot of in-depth customization to provide the basics, and the bells and whistles are hardly out of reach.
- You have a backup of your mail for free (by using OfflineIMAP)
- Not hard to learn (at least for the crowd here). If you can use Vim, you can be using Mutt at full speed in less than a week.
- Search capabilities that blow nearly every other project out of the water (regexes with some very cool niceties)[1]
- Secure by design. Mails are rendered as plaintext, HTML is decoded by piping messages through a program like w3m. Tracking bugs can't do their job, spammers can't see that you've looked at their stuff, and you're immune to whatever image decoding bugs crop up. (Though you can still view images, it's an explicit process). Also, builtin GPG support.
I followed Steve Losh's guide[2] on setting it up.
That I'm not 100% sure of. I know for receiving, you'd just configure OfflineIMAP to deliver each account's messages into a different folder, and just switch between them in Mutt, but I don't know how it would work for distinct from-addresses, contact lists, etc.
Some quick googling[1] makes it look like you indeed do that first thing, and then set up a hook to load a different configuration file when you enter the folder for a different mailbox.
While I like command line apps, and am a die hard vim user, there are just some applications that I really want to use a mouse for, and email is one of them. I've tried mutt a few times before and it's just never clicked with me. It's not that I can't learn how to drive it --- it's that I don't want to have to. Finding little-used commands is so much easier if there's an actual menu.
That's funny, because every time I use an MUA other than mutt I'm frustrated by how janky it feels to process email with a mouse. :)
The little-used commands can be found by pressing "?" in any mode. You get a nice list including any custom macros you've set up (I don't use many, but a few are essential). It's far simpler than clicking all over menus and dropdowns and hovering inscrutable icons...
For Webmail or IMAP mail, look no further than Fastmail. These guys know exactly what they are doing with IMAP and they can easily accomodate your multiple accounts.
I've been a Fastmail user for almost a decade. I've never been happier with any email provider (or any provider, to be honest). You pay for the service, but it's worth the money and more. You are treated like a valued customer and the support, if needed, is rapid and professional. I cannot recommend Fastmail enough.
I'm basically okay with Webmail if it's self hosted and supports notifications on many accounts.
If I recall correctly, fastmail cannot be self hosted and I really don't feel like trusting some random service with my personal and business email. Or paying them money for something I currently get for free for that matter.
I understand, but send these guys an email. One of the founders will likely respond to you.
I used to run all my own stuff, but when my children came along, I didn't want to spend all my time chasing issues with servers.
Look the Fastmail guys up. If anyone is doing email correctly, it's Rob, Bron, and the guys at Fastmail. They actually write some of the code for the Cyrus IMAP server, so if you were in doubt as to how talented these guys are, don't fear. I would now NOT trust my email to anyone else. They are that good. Yes, I know, I'm some random guy on the Internet, but I'm an IT guy, which in itself says nothing, but I'm nothing if not extremely picky about my own IT. These guys can fix any issues you may have and probably give you some awesome suggestions. They are approachable, something you will never get from any other company. They are based in Melbourne, Australia, but use NYI here in the US. Worth a call if you value good service and top-notch know-how from guys who know email better than anyone else I'm aware of. They routinely post in the Email Discussions Web site forum.
> They are based in Melbourne, Australia, but use NYI here in the US.
Mhm, 2 of the "Five Eyes" countries. Yeah, you're really selling me on this one.
I'll admit I'm being a bit ridiculously paranoid, but it's cheap paranoia for me, Thunderbird works well as a client and I spend maybe 5 minutes per month doing mail server admin stuff. I'm really not willing to switch to any hosted solution for this.
Just looking for another mail client option if/when Thunderbird goes down hill, not a mail server.
Yeah, definitely looks interesting, but the issue I have is again the multi-account issue. Thunderbird has very nice handling of many different email accounts.
How does it compare to, say, Gmail enterprise? Well, apart from the whole Google Apps.
I'm curious because we'll have to migrate to a better email provider in a month or two, and Gmail enterprise seemed to be the best fit for us (price, storage, good iOS app to leverage push notifications, etc).
Google's apps for iOS are subpar compared to its Android counterparts, or even to other iOS apps. I'm a heavy Android user, but on my new iPhone I actually prefer the native email app, because it is simple, effective, more standards complaint than Gmail and has quick swipe actions for both delete and archive, which is all I need.
On push, Google Apps gives you ActiveSync as a protocol, as an alternative to IMAP. But the integration with iOS Mail is weird and I could not use it.
FastMail also has a native app that does push notifications, but it's just the packaged web interacts with push notifications added. This is both good and bad. It's good because the mobile web interface is very decent, compared to Gmail, and this means you always have a decent UI on whatever OS you have. It's bad because it doesn't feel native, but then there's nothing more native than the iOS Mail app.
Google's rendition of IMAP isn't following any standard but their own. Fastmail uses Cyrus IMAP server, which most certainly follows standards.
I've been a Fastmail user for almost 10 years. Never an issue that was not solved in very short order and most professionally. Fastmail offer a modern product with old world service and charm. A win-win.
We use either Postbox, Thunderbird or Apple Mail and all of them should work with Gmail like every most common mail client. So the point about IMAP doesn't have a practical impact for us. Am I missing something? Good to know about their strong reliability though
Postbox is pretty good, and would have been the solution to my mail client woes, except that:
* even after you've paid for the product, the only way to get support is to pay $10 for every question you want to ask, however basic or advanced it is - and you'll need support, because...
* there's erratic unpredictable behaviour at many places; is it some subtle bug in the software? or is it some weird about:config option that you have to set to get things working as expected? Who knows! If you're lucky, you'll find a solution in the Thunderbird forums that works. Often though, that dialog option has been removed from Postbox or that about:config option no longer does anything, and...
* the documentation is no help. It's no worse than the average startup's help pages, except in this case, as mentioned above, there's no support - so you'd expect that to be compensated with exhaustive documentation, but no such luck. The docs cover just the most basic cases and leave all the complex interactions of emailing to your own guesswork. Also...
* the devs avoid users like the plague. The only-paid-support thing is (explicitly stated as) a consequence of this, but this even extends to bug reports and feature requests - which are free of cost to submit, but the two bug reports (and one or two feature reqs) I submitted were met with only gaping silence. The interaction on Facebook and Twitter too seems limited to version announcements and rare one sentence replies.
I really wanted to like Postbox, for it to be the solution, because it was quite a good product with advanced capabilities and a quite reasonable cost. But it didn't seem like a reliable option for the long run given these limitations.
A recipe for a terrible product. I tried Postbox when it came out and found it to be unbearably buggy (like they had released an alpha version). I couldn't even get Gmail to work, which should have been user story #1 for them: set up Gmail account.
Now I understand the culture that made it such a piece of garbage and will continue to avoid it like the plague.
Interesting, I'll definitely take a look at this. I don't mind paying for it, but I'd be a bit iffy on going from a nice open source solution to a proprietary one.
EDIT: Nevermind, no Linux build, that's out for me unfortunately.
Interesting story tangentially related to this question. I just finished building my new gaming rig - the only thing left is a GPU which should be coming in the mail pretty soon. The CPU I have, a core i7 4790K, has a pretty decent GPU so I was testing it out the last couple of days. The first game I tried was GTA 5. It ran smoothly (albeit at the lowest possible settings and 720p resolution). I was pretty impressed with the integrated graphics' performance. Yesterday I tried GTAV out again for a little bit and I observed that it was ... way too choppy and basically unplayable. I couldn't figure out the reason why. Then I saw that Thunderbird was the only application that was open aside from Steam and GTAV. I closed it down again and boom, back to consistently high framerates.
What is the catch here? Granted I'm using the integrated graphics that came with the CPU but I have 32 GBs of RAM. What gives!??
How long was Thunderbird open before this happened? It could have been a memory leak, which can be really expensive when working with web-rendering software.
It was open for a bit. This experience has made me start to question all those times I had slow-ish response times and Thunderbird was open. Slowness or game choppiness should be unacceptable given that I have a 4.0 Ghz CPU and 32 GB RAM. I guess it is time to look for a new email client :/
"didn't DPI scale properly", "strange behavior with my IMAP server", "consistent UI with my Windows and Linux system", "handle 8 accounts at once with thousands of messages".
If you have enough rigid requirements nothing will ever be a good fit.
This is true, but sort of specious. The point is that for the grandparent (and me) Thunderbird meets all these requirements, and other stuff doesn't. Could we adjust our decades-mature workflow to accomodate other tools? Sure. But it would suck. So we use the tool we have that does what we want until something unambiguously better comes along.
Of course! But Thunderbird does a pretty good job of all these requirements, it's the only reason I feel like I can be so stringent with them. Only reason I've been trying to leave is everyone else telling me it's bad or it's going to stop being maintained properly.
I second that. It's hard to find a functional and usable mail client. I may switch to claws for personal use, but I am still using thunderbird for work.
They already released 5.0, and didn't change anything. What is more likely to happen is the development of a Plasma Mobile QML UI built on top of Kontact and the new Akonadi that you can switch between, and that the desktop version might just use a reactive designed mobile UI as default with the current UI being available as a toggle option.
That's a pity. I didn't get KF5 one yet since it's still in experimental in Debian[1] and I assumed it's not usable enough. Settings UI in KMail really needs some serious streamlining.
Yeah I use it in some places actually but unless I'm missing something, you can't connect to multiple accounts, see them simultaneously and get notifications on all of them.
While we’re still at a pretty early pre-release version, we already do multiple accounts and unified inbox with ownCloud Mail: https://github.com/owncloud/mail
If you do try it, please let us know of your feedback in the issue tracker! :)
(And that is, you can also run ownCloud with the Mail app locally. We’re working on improved caching.)
I personally use mu4e. If you've tried it a year or so ago, it has made many improvements since then. It is terminal based, but I find I can't use thunderbird any more after switching.
So do I. offlineimap for syncing mails with my IMAP server at fastmail and mu4e for reading mails. Search is superfast, but I miss a better handling of spam mails. Thunderbird is really good at sorting out spam once you've trained the spam filter.
It's a robust IMAP client that has cross account message rules, smart filters, blocking external images, OpenPGP, Google's wonky IMAP implementation, great support, and a lot more.
They want to kill XUL for Firefox so they can be all fancy HTML. So they have to kill Thunderbird, a XUL app.
In a few years the all new HTML Firefox will come out. My bet is that it will suck. It will lack a TON of features that the existing Firefox has, but hey, it's all HTML! And you won't be able to stick on the old one, because within a week or two some critical security flaw will be discovered and eventually (like six weeks later) they'll stop supporting those for old Firefox.
Initially the HTML Firefox will suck. When you take an app that's been worked on for 15 or so years and then replace it's UI you're going to lose a TON of features. They'll slowly reintroduce some of the most popular features (hamburger menu will be priority #1!) but there will be a TON that they will not reintroduce. Why? Because when they were first introduced a decade ago it was a cool idea someone had, and no one knew how popular it would be, so heck, why not implement it. But now they know that only 10 million or even 1 million people use that feature, and they're only interested in 100 million user features! If Google Chrome doesn't have it, it must not be important!
As much as people complain about XUL not looking native, wait for HTML Firefox, it will take them forever to get where XUL was years ago.
They can't just kill XUL for Firefox though, they have to burn down the XUL ecosystem first so they're just releasing a new Firefox, nothing to see here.
1. They try to kill xulrunner as a project separate from Firefox. They try to move everyone to firefox -app.
2. They stop releasing binaries for xulrunner.
3. They deprecate XUL extensions.
4. They distance themselves from Thunderbird. They say it's better for Thunderbird. Yeah right! Thunderbird is built on XUL, it's not going to be rewritten in HTML any time soon, definitely not by volunteers. It's not going to be able to maintain XUL either, and when Mozilla stops supporting XUL for Firefox a few years after deprecating XUL extensions then Thunderbird will be screwed, but hey, it's not our project! We abandoned it years ago!
So when the crappy HTML Firefox shows up, with way less features than the Firefox of today, remember that this (Thunderbird) was one of the things given up to have it.
But hey, donate to Mozilla! $5, $15, $25, anything helps. Because we already make hundreds of millions of dollars and we do whatever is shiny and new, screw the "community" of existing stuff. We're fighting for an open web! (where you can use Gmail for email)
XUL was a weight on developing for Firefox. It worked like HTML, but was nonstandard. At first, it meant they could quickly implement things like flexbox (<hbox> / <vbox>) and gridlayout (<grid>) long before they were a thing in CSS.
But as HTML and CSS slowly got more features than XUL, XUL development slowed down, up to the point where writing the Firefox UI in XUL became a pain because of poor tooling and sneaky bugs. More and more pieces of Firefox got written in HTML inside XUL, and factorizing code between the pieces in XUL and those in HTML was nightmarish.
Dropping XUL means putting those bugs and issues behind us, and focusing development on a single DOM language. You would probably be surprised by how much of the UI already is in HTML; tab groups is almost all HTML, and the DevTools' editor and DOM inspector are in HTML as well.
As for donating to Mozilla, the distinction between Mozilla Corp and Mozilla Foundation is understandably complex for outsiders, but basically only Mozilla Corp makes money from the partnerships.
I'm glad to see it disappear, it's one of those things the world doesn't need. A failed experiment. And an HTML UI for firefox makes sense in the long run.
Fun fact of the day: Did you know XUL uses DTD to store translations? That's right, if you have a string you want to translate, you just have to create a new XML element in a localized DTD file. Isn't that just a wonderful idea.
I was just going to mention that, but you beat me to it. It's just bizarre to use XML external entities for internationalization.
I worked on TomTom Home, which was implemented in xulrunner, and I developed some internationalization/localization tools that had to deal with XUL DTDs as well as several other different and incompatible file formats for storing translations. I could never for the life of me figure out why they decided to use DTDs with external entities for translations.
XUL wasn't a failed experiment. From what I understand it served as the inspiration for some of the new features found in HTML. If that's the case it was a useful experiment.
It was meant as a pro. Since it was their own language, they could do anything with it. They could make a better HTML.
But HTML caught up. Currently, I believe HTML is better than XUL, and making XUL great again is both a silly reuse of a political slogan and a waste of effort.
I for one would rather see efforts made to allow CSS styling of all input elements in HTML.
Good luck - the main advantage of XUL IMO is that it looks and feels native to the platform. This is completely lacking in any HTML based UI I've ever seen. It's been a major advantage for FF extensions and I can't help but feel like it's a major step backwards to lose it.
>
Good luck - the main advantage of XUL IMO is that it looks and feels native to the platform.
That you say that is a testament to how well the meticulous CSS styling of the XUL elements—which applies equally well to HTML (try it in a browser chrome shell!)—worked.
I don't think that has anything to do with XUL directly, you can still find its original look by furing up Seamonkey, but that Firefox developers opted to rework the UI subsystem so that it translated XUL elements into native elements as much as possible. Iirc, this was done in part to speed up the Firefox UI compared to Seamonkey.
> Being nonstandard is completely irrelevant here.
It's relevant in that much of the work has to be duplicated (documentation but also layout implementation & the like) and none of the new and improved web development tools can be used for XUL.
The problem as I understand is more about the documentation, the hidden quirks and also the barrier to bring new contributors to the source code. It's always easier when they don't have to learn a custom language first.
> Being nonstandard is completely irrelevant here.
No, it's not irrelevant. Standards are also about documentation (it's easier to document standardized things) and familiarity (people are more familiar with standardized things).
I was poking at the non-standard portion. Lowering barrier to development of plugins, patches, etc is fine, but being standard doesn't help or hinder that. Popularity and ease of introduction help that. Javascript (that is, the dialect of ECMAScript that is implemented by Firefox) itself is non-standard and Mozilla isn't throwing that one out for exclusively ES2015.
Actually, tons of nonstandard SpiderMonkey features have been removed. Sharp literals were axed, E4X was removed, "let" is being changed to the ES6 behavior, and so on.
It happened before, with the transition from Mozilla Suite to Firefox. And let's be honest: XUL was just lipstick on the pig that is cross-platform development. HTML/CSS/JS are now fast enough to look like a slightly better pig, so here we go.
Also, there's a generational shift underway. You and me could find crazy that people would openly choose to use IDEs built on HTML/CSS/JS, but that's what a lot of young folks are doing (Atom, VSCode etc etc). That's their world, that's what they like. An entire generation now exists, who learnt to code from web scripting rather than C or BASIC. They have taken over. It's just how it is.
(this said, I agree that donating to Mozilla feels a bit silly, looking at how much money they make from commercial agreements. It's like donating to Ubuntu or RedHat.)
I'm all for writing new apps in HTML, I think Atom and VSCode are awesome, but I'm not for rewriting huge legacy apps to be HTML apps for no good reason. The reasons given, that XUL requires maintenance that Mozilla engineers don't enjoy doing, is a joke considering the amount of effort to maintain XUL is less than 1% of the amount of effort to move Firefox to HTML.
No one has listed the ten awesome features that we're going to get from HTML Firefox (cause there ain't many) or the 1,000 features (tons of little details) that will be lost. If users listed their 10 biggest problems with Firefox I doubt any of them would be solved by moving to HTML.
Imagine if instead of writing VSCode from scratch and releasing it alongside Visual Studio Microsoft had rewritten the Visual Studio UI in HTML, abandoned all the nonessential features, and abandoned the old native Visual Studio.
One might say that Mozilla will wait to release the new Firefox till it has all the old features of the old Firefox, but that's not been my experience with how teams work. They'll get frustrated with the rewrite and want to get it out the door. "We can add those features later" they will say, and then they'll never get added.
> The reasons given, that XUL requires maintenance that Mozilla engineers don't enjoy doing, is a joke considering the amount of effort to maintain XUL is less than 1% of the amount of effort to move Firefox to HTML.
Ah, but maintaining XUL means working on old code (which is boring), but moving Firefox to HTML means working on new shiny code (which is exciting).
Well, or Firefox as a web browser has to render HTML/CSS/JavaScript no matter what, and now that HTML/CSS is at feature parity or better with XUL in the space XUL is meant to occupy, it doesn't make sense for Mozilla to maintain two competing technologies when one receives 95% of their internal developer attention and 99.99999999999999% of external developer attention.
Instead, they plan to render the UI natively, with only "some" parts in HTML.
So, instead of XUL + HTML, we’re going to get GTK + WinForms + Cocoa + HTML. Great, eh?
And we lose the ability to style it with addons – your themes can only change the background image of the header bar, that’s it.
And the remaining addons can’t modify the UI (tree style tabs, bottom tabs, etc) anymore either, instead you can only modify page content.
I’m seriously pissed off now, because Firefox was the last browser where I could actually customize it how I liked it.
I hope the person who made this decision is going to have to use software without any config options and with horrible defaults, like GNOME. For the rest of their life. May their car always have have either 60°C+ heat, or -20°C AC, may their screen of their phone always either be too dark, or too bright.
> Part of the decision has already been made. We are moving Firefox addons (themes and extensions) away from a model where you can perform arbitrary styling or scripting of the browser chrome. This is an engineering-driven decision, and it's unavoidable and necessary for the long-term health of Firefox. Not only are we moving Firefox away from XUL, but we are likely going to make significant changes in the way the UI is structured. It is likely that some parts of the UI will be implemented using native widgets, and other parts will be implemented in HTML, but the exactly DOM structure may involve independent connected with well-defined API surfaces.
Official statement from the Mozilla post in the discussion regarding removal of support for "heavyweight" themes. Emphasis mine.
That’s a pretty clear statement that it won’t be 100% HTML.
Also, the fact that "arbitrary styling and scripting" won’t be possible is another issue.
Tell me how I am supposed to write an addon that adds tab-previews as thumbnails when you hover over a tab like Vivaldi is doing it: http://i.imgur.com/vqysJs1.png ?
How am I supposed to write an addon that colors the navbar and the current tab in the theme color given by the HTML, or, if not existing, the favicon?
With current addons I can do that, with the new addon system, I’m seriously fucked.
You're citing jwz's CADT post in a thread discussing Firefox? It's a product for which people regularly complain about open bugs that are 10 or more years old.
He's right. Mozilla, a $200-300 million a year outfit, currently maintains their software including Firefox. It's a huge C++ application. People who code XUL in their spare time, even a bunch of them, aren't likely to make a dent in keeping parity between a Firefox fork and the main release. They'd likely have trouble even porting it.
So, a fork is a rough solution and will have maintenance issues for an app this size.
As an active user of Thunderbird I am very disappointed with these news.
But these rants are just silly. XUL is a technology that needlessly duplicates what HTML/CSS do these days. And if you ever want to have a smooth transition to servo, which solves real, deep problems, having a html UI is going to be dramatically important.
I really want to agree with you that Atom is awesome, and it is, in principle, but in reality a text editor should not be using 300MB of RAM. Sublime Text, which I consider to be a direct competitor, barely uses 20MB of memory on my machine even after hours of use. Heck, does Intellij even use that much memory?
I'm just really discouraged with how more and more desktop apps are being written in HTML, CSS and Javascript and suffer in quality as a result.
Considering my first 16 Bit computer had 3MB RAM and ran MS Word alongside a GUI, I am wary to say "Amount X of RAM is preposterous for a given task".
As long as Moore's law provides enough lift under our wings, RAM usage is one of the less important aspects of an application. However, I fear the trend of building application UI's in HTML/CSS because invariably it will lead to wildly inconsistent look, feel and behavior.
It's worth pointing out that for a couple of years Mozilla has been building a replacement for their rendering engine (Servo), so I imagine that to some extent deprecating XUL now is preparation for not having to re-implement it for Servo. Just speculation.
> One might say that Mozilla will wait to release the new Firefox till it has all the old features of the old Firefox, but that's not been my experience with how teams work.
Realistically, getting to feature parity after rewriting a core part of any application is going to be nearly impossible. You end up with different features, hopefully better ones, but not exactly the ones you had before you started. You can't step twice in the same river.
What bothers me about being older is my first browser was Internet Explorer, then I got to play with MOSAIC's slow arse in school, then used Opera/Mozilla, and so on. Got to see where it came from. And the new stuff, especially Firefox, is coming full circle in how friggin' slow they run to serve the lowest common denominator of web pages.
It's annoying. I miss Web 1.0. Add just a bit of dynamic functionality plus broadband and it would be fine for 80-90% of cases. And FAST!
Instead, we get Web 2.0, 3.0 (4?) which makes pages on 40-50Mbps load like my old 28Kbps modem on AOL. Seriously...?
> And the new stuff, especially Firefox, is coming full circle in how friggin' slow they run to serve the lowest common denominator of web pages.
It should be easy to find performance numbers showing how Firefox 42 renders old, pre-CSS pages slower than, say, Netscape 4, then.
Netscape 4 didn't have a JIT, didn't use hardware accelerated layers, trapped into kernel mode for GDI calls, didn't use accelerated SIMD for painting, and didn't have HTTP 2. It barely had any optimizations for dynamic restyling, so tons of stuff would get reflowed when it didn't have to. This is just the tip of the iceberg.
Browsers have gotten more complex, but the complexity is often in the service of making things faster.
Notice my references to Web 1.0, 2.0, etc? That means my comment was talking about not just the browsers but the sites designed for them. The combination of the two have made web sites really slow that could be designed to load up instantly. Instead, they load up as slowly as some sites did on my old Pentium 2 running Opera, etc. You'd think they'd be significantly faster with all the Moore's law iterations and browser improvements. Modern sites make sure that doesn't happen, though.
And I never mentioned Netscape: it was called Netscrape then and hackers despised it. I used Opera and IE mainly.
Back in the Netscape 4 days, the architectures of those engines were broadly the same (in the sense that Linux and FreeBSD have broadly the same architecture). Of course the codebases were different.
In the late '90s, the time frame this thread is about, it was well known that the layout engines at the time were not dynamic: they could not in general reflow only parts of the page. Everything else I mentioned in the post that triggered this subthread is obvious simply based on browser engine and OS history.
I don't even know what we're arguing about anymore. Do you dispute this?
> (Netscape 4/Opera/IE) didn't have a JIT, didn't use hardware accelerated layers, trapped into kernel mode for GDI calls, didn't use accelerated SIMD for painting, and didn't have HTTP 2. It barely had any optimizations for dynamic restyling, so tons of stuff would get reflowed when it didn't have to.
Disabling js has given me the fastest turn-round on page-load times. It's usually not the browser, but loading 15 different un-optimized JS engines that causes the problem.
I am 29, started coding at 14, I've built UIs based on mIRC Scripting, VB/Winforms, C++/Qt, C#/WPF, Java/Android layouts. Using IDEs such as Visual Studio, Eclipse, Qt Creator and Android Studio.
I must say: Atom Editor is great. Using HTML/CSS/JS to build desktop/mobile apps really makes sense to me, especially given that:
- You only have to support one rendering engine.
- You have access to the latest Web Components/ES6/CSS3 features.
- You can rely on native Node.js modules when needed.
It's good for portability, HTML/CSS became better at UI, JS becomes a better language, current IDEs are great, live debugging tools are great.
- There are far fewer native components, leaving accessibility down to the developer of the app and making it nonexistant.
- Platform integration is impossible, which means there is no way for the framework, for example, to create widgets differently on OS X, Windows or Linux (these platforms have many different conventions)
- Theming globally becomes impossible. If you want to write a dark theme for your desktop, you go from writing a theme once for GTK and once for Qt to once for each and every app you run. Uuuurgh.
But only supporting one rendering engine, yay! Much better than the 6 different engines we have to support in Qt (huh?).
And having access to all the latest JS additions! ... that were copied from other languages you could develop desktop apps in, because JS is a terrible hack.
And relying on native Node.js modules, yay! As opposed to native modules for literally every other better language out there.
I'm not sure what you're actually comparing this workflow to. Maybe one day writing HTML apps will be great, but today is not that day. Today, writing HTML apps is only beginning to be an idea that doesn't completely suck. But for the user, it does massively suck. Massive apps that ship their own copy of webkit/blink/whathaveyou, with security flaws that won't get patched, disgusting performance on low-end hardware, atrocious battery usage and decades of UX knowledge thrown out of the window just because the app developer doesn't have the knowledge to see it.
I don't look forward to this. And I'm younger than you.
> "Platform integration is impossible, which means there is no way for the framework, for example, to create widgets differently on OS X, Windows or Linux (these platforms have many different conventions)"
So web apps can't have reusable components now?
> "And having access to all the latest JS additions! ... that were copied from other languages you could develop desktop apps in, because JS is a terrible hack."
WebAssembly will take over for web apps eventually.
> "decades of UX knowledge thrown out of the window"
UX knowledge isn't toolkit dependent, UX knowledge is just as applicable on the web. You can make a dog of an app with any toolkit, native toolkits offer no guarantees for good UX, you can only hope that designers choose to follow best practices.
I'm not saying they can't, I'm saying they don't. You go ahead and try to fix that, create widget#772981 that still won't support typed-selection, or will break with large text or what not... I've seen too many of those, most of them bad, and none of them standard. So far, React is the only thing that even comes close to a sane model for a contender to UI development on the desktop, and it still mostly fails the accessibility checkbox.
> WebAssembly will take over for web apps eventually.
More eventualism. Do you have evidence for that? Do you even have evidence that it'll be better than what we have now in other languages if it does take over?
> UX knowledge isn't toolkit dependent
A lot of it is. You'd be surprised just how much UX is crammed into Qt Widgets for example. Years of experience making them more accessible, more usable, more consistent with the platform they're running on, etc.
> "I'm not saying they can't, I'm saying they don't."
They already do. Electron, Web Components, etc...
> "Do you even have evidence that it'll be better than what we have now in other languages if it does take over?"
Compare the performance of vanilla JS vs. asm.js. It is clear from what developers have stated that WebAssembly performance will exceed the performance of asm.js, the threading improvements alone should offer noticeable benefits.
> "Years of experience making them more accessible, more usable, more consistent with the platform they're running on, etc."
So what are we looking at to replicate that? A theme per platform? Some accessibility work? What else?
It should be noted that the web isn't starting from zero with UX either, we've already had 20+ years of refinements to the web user experience.
> They already do. Electron, Web Components, etc...
And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization.
> Compare the performance of vanilla JS vs. asm.js.
That's not what I'm comparing. I'm comparing the performance of native toolkits vs web toolkits on asm.js. It pales in comparison, and the battery usage is through the roof. ymmv?
> So what are we looking at to replicate that?
1. Standardization of components (developer does not have to build their own scrolling system, context menu, etc)
2. Themability of components at the application level (developer can style components not to clash with the style of the application)
3. Themability of components at the platform level (user can style the application not to clash with the style of their own desktop)
4. Performance needs to shoot way, way up. Apps can't rely on a performant GPU, it's unreasonable to ask that of every device at this point in time. Some day maybe every device will come with their own high performance GPU, but eventualism cannot excuse bad coding practices and unnecessary layering.
The rest should follow. But I still don't see us getting any of those things, any time soon. These are not easy problems to solve.
An app based on React Native isn't a web app anymore. But it's not quite native either; it doesn't use the native button and list view controls on either iOS or Android.
>I'm not sure what you're actually comparing this workflow to.
He is comparing it to what they have now, XUL + CSS + JavaScript. Replacing it with html isn't as big a change as it sounds, their UI is already written in XML and rendered by Gecko, all they are doing is moving from a custom XML like XAML(MS) or FXML(Java) to standard HTML rendered by Gecko.
Unlike you know something I don't about Kunix specifically, I don't think he's talking about Mozilla development in particular, but rather development in general.
Unlike the original parent post I don't think this announcement anything to do with XUL. Thunderbird just doesn't have the userbase Mozilla expects it to at this point because, surprise, the people who want an email client are a small subset of the people who want a web browser.
<rant>
This is lost in a sea of replies now but I'm sure pissed off Mozilla is completely losing their root mantra of fighting for the free web. Persona, Thunderbird, two critical components of a "free web": free global authentication, free email client. I'm sure next mozfest the same suits as every year will talk about how they're so proud of "keeping the web open". What a crock of crap. Firefox isn't even that good of a browser anymore.
It is easy to forget that freedom and creativity are not a numbers game. There are benefits to a majority when a minority is free to create. An argument could be made that the majority consumption patterns are made possible by the minority creator patterns, hence it makes economic sense to fund the minority out of majority profits.
This is one of the reasons why iPads have stalled - pro developers can't make money, for well documented reasons. The web equivalent will be the starving of open communication, thought and creativity, leading to homogeneous noise as a poor substitute for ground-breaking content.
I don't see why it couldn't, they are doing it for FireFox. On the other hand Mozilla has been on the path to retire Thunderbird for some time, this is just the next step.
Mostly I think it is an effort vs reward thing. Thunderbird doesn't have the user base and doesn't have a revenue stream the way fire fox sells the search box. I wonder if anyone over there has thought about cleaning it up and selling it as a white label email client.
> - You only have to support one rendering engine. - You have access to the latest Web Components/ES6/CSS3 features. - You can rely on native Node.js modules when needed.
So, developer convenience trumps user experience? Who cares about your battery run time, how hot your PC runs, the bandwidth overhead, the massive attack surface from all the useless components shipped, how badly the webapp integrates into your OS, as long as we can ship faster and faster?
Oh, I'm writing web apps myself, but Gods, am I hating myself for it. OS integration is somewhere between a nightmare and impossible – and yes, it is desirable, unless you're on like Gnome 3 –, the resource requirements are abysmal (400 MB for an app that consists of a single input form, a table, and a search field, really Chrome?), performance is actually pretty lacklustre (non-blocking is one thing, actual multithreading another!), the UI isn't actually all that nice if you want to use it, not just look at it (say goodbye to accessibility; hell, even just proper keyboard navigation is black magic for most frameworks); and if you ship the engine yourself, you're now responsible for orchestrating and shipping bi-weekly browser updates to your customers to make sure your browser engine stays patched.
Is all that bullshit really worth… whatever we're saving? (Our company is mainly saving in developer salaries, because we can force kids fresh out of school to work for minimum wage, instead of hiring experienced developers… we'll see how long this keeps working.)
I've also frequently seen complaints to the effect that Atom is much too slow, even on machines only a few years old. Even my 486 laptop back in 1997 could run a text editor with syntax highlighting (specifically, JPad for programming in Java). What are editors doing these days that needs so much CPU power?
This review (6 months ago) is based on an early version of Atom Editor (0.204.0), the latest stable (1.2.4) is way more mature and provides very nice packages [1].
It’s not really JavaScript, I’d argue it’s a different reason.
node-webkit apps are cheaper to develop. Far cheaper.
Everyone can write a webapp, a native application requires professional developers. The payroll looks completely different.
And then the devs who have only worked with node-webkit don’t know how much better they could have it. I know devs who refuse to use map, reduce and filter, because "it’s black magic and we always used for".
The fact that you are being(edit: was) downvoted for constructive opinion shows unwarranted prejudice of HN hivemind towards web technologies. HN discussions on this topic are effectively useless, any constructive truth finding is drowned.
edit: I'll take my downvotes with pleasure. The fact that I am able to use Atom or Nylas N1 or Nuclide on linux with 0 problems alone is enough to welcome proliferation of web tech on desktop.
Same here, I'm 26. The industry has changed a lot when people realized you could make a shitload of money with the web/scripting stuff. Coding schools, open source communities and huge companies love HTML and JavaScript and Python and Ruby for their simplicity. Just take a bunch of people, tell them they could make a lot of money by learning some dead simple languages and there you go. Doesn't matter if they write the most disastrous code in the whole universe.
Look at Code Academy, for example. They add new programming languages and technologies every now and then, but basically it's always the same. Just like their audience. They won't add C to that list, because that wouldn't work for this average not-nerdy-enough-for-real-programming audience.
Yes! JS, Python and Ruby are just "dead simple" "scripting" languages that only serve to "make a shitload of money" and aren't "real programming".
Real programmers (like me) use C.
Seriously, no. Just no.
And if I wanted to prevent people from writing "the most disastrous code in the whole universe", teaching C instead of JS would be much, much lower in the list than teaching how to split code into modules/libraries, write testable code, etc.
> And if I wanted to prevent people from writing "the most disastrous code in the whole universe", teaching C instead of JS would be much, much lower in the list than teaching how to split code into modules/libraries, write testable code, etc.
And for me that would be much much lower than teaching how to keeps things simple. The whole modern web has a bad case of over engineering, everything is modules of modules of modules, with so many tools associated you get a headache trying to install a simple JavaScript library (what is wrong with a download link and I drop the lib on my page, nothing that is what).
I'm all for modern approaches but I can't help but feel many developers have lost touch with what writing clean code is, it's not making module, libraries or even tests, it's making sure what you are doing is as simple as it can be and efficient at it. Sadly most modern web stack fail at that. All hidden in mumbo jumbo of modules and dependencies no-one really needed or asked for, often created by people who never questioned the purpose of what they were doing, or if the whole internet needed it (because you are at Google and have found a neat way to deal with your huge JS stack doesn't mean the whole web needed it too, and that you needed to spent a whole lot of effort making people adopt it).
As much as you make fun of C, learning and writing C will teach you to keep you programs simple and efficient, because the language requires it. And that's coming from someone who started programming with Perl, then PHP, and only learned C later on.
Makes thing simple not simpler should be the cardinal rule of programming, not modularize and test everything, those are situational, the former applies all the time.
I didn't make fun of C. I made fun of a comment posted by a C programmer, which is very different. I have absolutely nothing against C.
> C will teach you to keep you programs simple and efficient, because the language requires it
From what I've read, the OpenSSL codebase is definitely not simple, and I'm not sure it's efficient either—it would depend on how you define efficiency. So your affirmation seems factually incorrect.
Other than that, I agree with your post. Simplicity is awesome. No point in using Angular to build a landing page if static HTML can do the job just as well. (Edit: let me take that back. There can be a point: the pleasure of experimenting and learning something new.)
You write code that can be broken up finely enough into discrete, stand alone modules that can each be run through a series of tests.
For instance, you might create a model class, and then you know that model should have a name, shouldn't be able to be saved without a name, the name should be x-number of characters.
Then you can write a series of tests that makes sure that, regardless of how the model implements that name, all your assumptions about what that name should look and act like don't change without throwing a red-flag up to whoever is changing that model.
Say you want to test how a program fares when strings are malformed, or the disk is full, etc. It can be hard to simulate this if the code refers to variables and results from functions from all over the place.
Making code into reusable modules code is generally a good thing, but it's even better if you make them in a way that will help you test those chunks independently as well - that is testable code.
Usually it's about keeping it granular enough that various sub-activities can be tested in isolation. If you have one function with 10000 LOCs, that's not really testable beyond "something doesn't work".
Then of course you need some way to automatically run these tests, but that's usually provided by IDEs or standard libraries these days.
The only good thing (I think) of a generalist is that one is used to adapt, but yeah... it gets boring sometime. Although after a while, is interesting to see how we reinvent wheels and show them with a new fancy name, it is a pattern that you would see more or less each 10 years.
Sometimes it feels like everything was already invented in the 60's.
>Reading up on the capabilities of early mainframes is eye-opening if you (like me) grew up on Pentiums.
Close enough... I grew up on XTs, i286, i386, so on :) All of them way weaker than my phone (Not sure if that was what you were referring to).
However, in terms of architecture, algorithms, programming language features... It feels like we haven't advanced too much. Actually, the opposite... we are encourage now to do not be too clever on programming because processing power and memory usage is close to be a commodity and clean code is more important (which is fine but less fun).
Referring to architecture, algorithms, language features, etc obviously. They were all better on many machines from 1960's-1980's. Market kept rejecting anything that wasn't backward compatible with existing garbage and had max performance per dollar. So, dumb CPU's, COBOL, and C it is. :)
Gave examples of what features old ones had in the essay below with the first link mentioning the specific systems for further inspection:
Note: B5500, System/38, and Ten15/FLEX are all especially worth considering. Two were basically HLL machines with type-safety and interface safety enforced at hardware level. System/38 was object-based with HW- and SW-level protections plus portable microcode layer.
I'd say Channel I/O counts as one that kicks modern systems' asses. Servers have been copying it bit by bit over past ten years, maybe even exceeding it, but server OS's are inherently inferior in usage given mainframe OS's are designed for I/O offloading at core. Near interrupt-less architecture with acceleration engines makes many apps scream with performance. And would only cost $10 per CPU on desktops but would require Windows & Linux rewrites. (sighs)
The modern equivalent to System/38, IBM's POWER hardware running IBM i still has the same benefits. I actually really like the concept and the way the ILE runtime works, but it's too bad that much of the platform is stuck with legacy design decisions and hasn't been modernized.
I agree with about everything you said. The System/38 design was one of the best cathedrals of old. Very forward-looking, thorough, consistent, and great for admins of the time. Still the only capability system bringing in revenue. Adapted pretty well to modern stuff but main OS's issues & stagnation hurt it as you said. I think the fact that it's pricey and proprietary kept the OSS innovation out, too.
However, the change to the AS/400 and POWER cost it one of its greatest features: hardware-enforced integrity at the object level. That's the feature that would still be giving hackers hell if it was widely deployed. The Intel i432 APX and i960MX had similar property. Interesting enough, IBM actually has secure CPU's they've prototyped and even sold to select customers. Would be great if they integrated one with IBM i at microcode, compiler, and OS levels. That plus an optional interface for new customers without legacy crap would be a huge differentiator that might give it new life.
Yes, especially the MULTICS operating system was so advanced and dozens of decades ahead that we still borrow from its concepts. It had for example 16 security rings. Intel CPUs support only 4 CPU rings, and Windows e.g. uses only 2 rings (for kernel mode and user mode) (hypervisor mode uses another ring in recent iterations).
Initial software based Multics had 64 rings, and as I recall only 8 in the hardware versions. No more than 4 were needed in practice: 0 for root, 1 for mail (e.g. you could delete mail you'd sent to other people from their mailboxes if they'd not read it yet), 4 for normal users, and 5 for some stuff that e.g. allowed anyone to use, but was restricted at touching anything deeper in the system.
AMD dropped rings in their 64 bit architecture which Intel was forced to adopt, so they're becoming a historical curiosity.
> AMD dropped rings in their 64 bit architecture which Intel was forced to adopt, so they're becoming a historical curiosity.
Not quite. Hypervisors are operating in Ring -1, SMM is equivalent to another ring above that, and I can't find anything about AMD64 dropping Ring 1/2? Ring 0/3 at least are still in use.
I tried looking at the latest 4.2 kernel tree - but the assembler/c-code that sets up and deals with sys-calls has been rather re-factored, so I'm not entirely adamant it's ring 0 and ring 3 for both 32bit and 64bit - but I think so? (From a quick glance, no sections stand out as calling out ring 3 explicitly when talking about returning to user-land -- granted I didn't do any searching over the code).
I submit that "supervisor/user" isn't an implementation of "rings", plural (and it's got to predate Multics by a lot, but I can't quickly prove that), and that SMM is something entirely different. Hypervisors and there use really aren't comparable to Multics Rings.
A couple of minutes with Google only found hints that confirm my memory WRT to AMD64 and rings, and/or Intel not copying a segmentation feature added to later versions of AMD's chips.
So this generation is rewriting everything that was made and working in the 90s. Was everything written in the 90s also a rehash of stuff from the 70s/80s? Just curious, what was the equivalent of HTML/CSS/JS in the 80s?
In a way, yes. If you look at OS interfaces from the '80s and compare them with modern ones, you'll see a lot of cpu power is now spent on eye-candy but functionally they're not terribly different. Except they're all built on C++, whereas before they were in C or lower-level languages. OO was the HTML/CSS/JS of the '90s.
Could all the large software applications of today have been created without OOP, just on functional programming paradigms? If OOP was beneficial 10 years on, maybe the cross-platform nature of HTML/CSS/JS will also be vital to future applications.
> maybe the cross-platform nature of HTML/CSS/JS will also be vital to future applications.
There are already cross-platform toolkits that can deliver everything a browser engine can, faster and safely.
Face it, "web technologies" are not winning because of any massive technological advancement, just like C++ wasn't this huge advancement over C. They just managed to achieve enough critical mass to make everything else look less popular. In the '90s, OOP did that through academia and commercial push (in what was a much smaller tech sector); html/css/js did it through the accidental monopoly that is the web browser. The end result is basically the same.
As with all design decisions, it's a trade off. The main benefit of web apps is found in their cross-platform nature. If this is desirable then you may choose to sacrifice a little performance to get that.
To give an analogy, it's like programming languages. It's possible to write very fast code with assembly languages, yet their portability to other architectures is practically non-existent. Part of the reason higher level languages like C/C++ are used is because they are much more portable.
LISP, a semi-functional language, was originally invented to solve the biggest, hardest problems. Scheme, Common LISP, Ocaml/ML, and Haskell have all been used in large systems with good performance. Entire OS's were written in LISP's with some benefits that modern machines still don't have:
Note: And some that are laughably obvious and available today lol.
So, yes, what people use today is an accident of history. That includes COBOL, C, C++, OOP languages, HTML/CSS/JS, HTTP-centric everything, and especially whatever crap is being built on them next.
If you're curious, here's the history I put together on C language and UNIX in numbered list form. You'll see how IT evolution often works in practice to give us lowest common denominator. And afterwards people swear it was product of good design and great achievement. (rolls eyes)
The most remarkable part of "web apps" is probably what they do not improve on:
Smalltalk had (has) messaging and decent object orientation (and you have that especially in latest js) - but Smalltalk never had one standard vm implementation - different versions had different image (ram-saved-to-disk, source code and byte-code) and vms. Javascript has common source code, but no common vm/image format.
Office Suites had rich documents with smart(ish) widgets, but no security - a macro in Excel had access to all your spreadsheet data. Web apps don't really have any good encapsulation either -- so we'll likely repeat the macro-virus era with web virus era (I'm not sure if we already are or not, there's certainly been a few self-replicating ones, that eg spread via facebook updates etc. Not sure if they generally live in the phone-apps or various web-apps. Probably both).
We already had the future of web applications within reach years ago - but apparently no-one cared: http://lively-kernel.org/
> what was the equivalent of HTML/CSS/JS in the 80s?
Depends what are looking as an equivalent. Browsers didn't exists but markup languages have been around since the 70's (mentioned for first time in late 60's)[1]
Maybe an equivalent to express GUI as resources? yeah, we called it RAD back in the day and they were quit popular among some circles. Does somebody remember Hypercard? Or even the first versions of Visual Basic?
I still get mad when people talk bad about Fortran and replacing the code with some slow solution. The power of CPU and cheap RAM has caused the world to favor the hand holding of developers.
No, what almost killed them was the transition from Netscape Navigator 4.0 to Mozilla Suite 1.0 — that's where the massive rewrite happened. Looking at that first link, it's it doesn't point out where Firefox development started: mid 2002. By that point Netscape had already almost entirely lost all its marketshare.
> You and me could find crazy that people would openly choose to use IDEs built on HTML/CSS/JS, but that's what a lot of young folks are doing (Atom, VSCode etc etc). That's their world, that's what they like. An entire generation now exists, who learnt to code from web scripting rather than C or BASIC. They have taken over. It's just how it is.
Dude, you're likely typing on the "wrong" keyboard layout and use a "wrong" calendar... convention trumps correctness pretty much all the time. What matters is that enough people are doing it to make it "the way". I fully expect that we will eventually see a Javascript OS, because "it's so much easier to maintain".
> you're likely typing on the "wrong" keyboard layout and use a "wrong" calendar
When someone shows me/I find a better way to meet a requirement I will adopt it (static site generators, Go routines, ...). I won't doggedly stick to the first thing I learned; I don't expect the world to adapt to suit me.
It's still a scripting language, and you still can't write an OS in it. There's no low-level access to the hardware. You could of course write all the low level parts in C, but then you haven't written an OS in JavaScript.
I think the only bit that really needs to be in assembly is the context switch, but even that can be embedded in the C (which you might consider cheating, but isn't even an option in JavaScript).
> "You and me could find crazy that people would openly choose to use IDEs built on HTML/CSS/JS"
Why is that crazy? Makes perfect sense to me, especially as the performance of the programming language element improves. Ultimately these IDEs are sure to make use of WebAssembly, which should take away the remaining performance concerns.
It's crazy because, apart from performance concerns (it looks like we love to make our computers slower and slower every 10 years), you're just discarding all the features of the containing desktop OS. Formatted copypasting, usability features, network features, etc etc... you'll have to reimplement them all, solving all the problems that systems developers solved 10 or 20 years ago. The OS will become little more than a very expensive pixel pipe. But that's what people like, because C++ is hard, native widgets are hard to customise, and everyone loves designing interfaces, so that's where we're going.
I anyone ever starts making javascript-optimised CPUs and GPUs, they're going to make billions. At the moment we only have micropython, but who knows...
Which network features do you need for a coders editor? In the case of Atom/VS Code, can't think of a single one that a browser engine doesn't already provide. Not going to need things like AD-integration, etc...
> "The OS will become little more than a very expensive pixel pipe."
If that's what people want, then so be it. I see no problem with simplifying the OS, most of them are already too bloated.
> " But that's what people like, because C++ is hard, native widgets are hard to customise, and everyone loves designing interfaces, so that's where we're going."
The main advantage is the cross platform compatibility. If certain OS vendors didn't make it hard to build apps that utilised a common base then there'd be much less drive to produce web apps. It has very little to do with the complexity of C++.
> "I anyone ever starts making javascript-optimised CPUs and GPUs, they're going to make billions."
As I've said a number of times now, the final target with web apps won't be JS, it'll be WebAssembly.
Not to mention death of accessibility features - those HTML apps are effectively unusable for disabled users because they don't implement accessibilty features available in native UIs.
Sure, but with the end benefit being a universal UI toolkit.
Also, 'expensively' is debatable, I'm sure it'd be possible to have reusable accessibility components, wouldn't necessarily have to reinvent the wheel for each new web app.
So we finally have a free choice of OS.
It's not the full story to complain about people solving the problems that the OS side had already solved decades ago. The big new thing is that they are doing so in a platform agnostic way. That I have nine different virtual machines installed on four different operating systems and the same code base can run on all of them smoothly.
Except that's not true: Webkit, Gecko, Trident... they are all different "OSs" you're writing for, you just wave them away by shipping the OS with the application. You could do the same by shipping a virtualised image running a stripped-down Linux configured to run only one application. One of these solutions is now socially acceptable, but both manage to completely discard everything the desktop OS achieved in 30 years.
Not really, you still a browser that implement all this stuff. The only difference is Open tech vs proprietary.
Open technologies are obviously a good thing. Writing a software as complex as Photoshop for instance with the exact same features with HTML/CSS and JavaScript isn't going to fly and be usable for someone who has to work 10 hours a day on it. The performance issues will be significant. It's not a big deal for an text editor though I still can't open a 5mb log file in Atom for some reasons. No problem with Sublime Text 2 or Vim. Why is this ?
My point wasn't that they are a silver bullet. My point was simply to say that while something is obviously lost (performance, native integration, etc...), something else is gained. And that is massive portability.
To be fair, what I have heard (I am not a Mozilla insider so I can't say personally) is that donations go to the Mozilla Foundation and the commercial agreements give money to Mozilla Corporation. So you aren't donating to the same place.
From the same source, apparently the Mozilla Foundation does a lot of important work that the Mozilla Corporation can't/won't do but most of the development is done by the Mozilla Corporation currently (possibly due to not enough donations to the Foundation?).
I haven't really verified that, but thought it was worth pointing out.
When you take an app that's been worked on for 15 or so years and then replace it's UI you're going to lose a TON of features. They'll slowly reintroduce some of the most popular features (hamburger menu will be priority #1!) but there will be a TON that they will not reintroduce. Why?
Hmm, that's how Firefox (then Phoenix) started in the first place in comparison to the bloated Mozilla Application Suite.
>So when the crappy HTML Firefox shows up, with way less features than the Firefox of today, remember that this (Thunderbird) was one of the things given up to have it.
Please recall that Phoenix/Firebird/Firefox was born as a lightweight, fast alternative to the bloat of Netscape Communicator/Mozilla Suite. Dropping features from an old bloated application is what launched Firefox to fame in the first place.
> In a few years the all new HTML Firefox will come out. My bet is that it will suck. It will lack a TON of features that the existing Firefox has, but hey, it's all HTML!
> As much as people complain about XUL not looking native, wait for HTML Firefox, it will take them forever to get where XUL was years ago.
And isn't Mozilla/Netscape literally the poster child for how to destroy your product with a rewrite? They only regained their market share because Microsoft let IE stagnate to a ridiculous degree.
> But now they know that only 10 million or even 1 million people use that feature, and they're only interested in 100 million user features! If Google Chrome doesn't have it, it must not be important!
I've pretty much only stuck with Firefox because of its extensions and the quirky little features it has. The more they focus on aping Chrome, the more they decrease the friction for switching away to it.
Vivaldi seems neat, which is essentially Chromium with a HTML5 GUI built by the old Opera folks intended to restore the best features of old Opera, with a heavy focus on customization.
My hope is that Mozilla will take the direction of using Servo to build something Vivaldi-like (instead of everybody running with Webkit/Blink) and start to restore old API:s and frameworks from old XUL-Firefox that all the best old addons relied on (things llike NoScript, Session Manager, Vimperator, uBlock, Tab Mix Plus, etc...) instead of just sticking with a blackbox rendering engine and settling with Chrome addon API parity.
Have you tried using Vivaldi? It's awfully slow to respond to user interaction because it's all HTML. Say what you want about XUL, but for something aiming to be like HTML it never felt slow. If Vivaldi's non-existing responsiveness is what the new Firefox will be, then they should seriously consider to rewrite the whole thing like a game (in OpenGL/Vulkan) instead. Oh and XUL was optimized for memory efficiency, which will have to be reoptimized for the HTML-only interface, but that can benefit the whole web.
Vivaldi is much faster than Firefox on both Linux and Windows, where I'm using it. Of course it's still alpha software, but the UI is blazing fast compared to FF.
It's substantially slower than Chromium and Firefox for me on Linux. Both Chromium and Firefox are very fast in comparison on my machines. I'm glad it's faster for you, I really am.
I do believe Otter is doing a better job of restoring Opera's past glory, feature-wise. Vivaldi, even with it's HTML gui feels like another opera/chrome/chromium derivative.
> " When you take an app that's been worked on for 15 or so years and then replace it's UI you're going to lose a TON of features. "
What makes you think they'll drop XUL as soon as the first release of the HTML-based UI? It's pretty obvious they'd want to support both until the HTML UI was close to feature complete. You're finding problems where there aren't any.
Have you ever met a team that wants to support two things instead of one? :) No one wants to support the old stuff, especially when no one's paying for it. If they make staying with the old too convenient, people won't convert to the crappy new, and their adoption graphs will suck! Can't have cannibalism!
I spent a good deal of time dealing with XUL, heck I even helped with the French community. Designing UI was a ton more robust with it than with HTML, but XULrunner was (and still is from what I saw) not the most pleasant beast to run.
I'm not advocating a rewrite for the sake of novelty, but they're part of a product life cycle.
You mentioned that it would mean dropping some features. I think that's a good thing; an opportunity to cut the fat and make sure only what is proven and useful makes its way back into Firefox.
You seem to think volunteers won't pick up the maintenance of Thunderbird; if so then why should Mozilla care about it?
Now, I don't think HTML, CSS and JS are the best technologies. They each suck in their own way. But they are winning, and Mozilla is merely embracing that.
Now that I actually have a career and money I have no problem giving back. I'm glad I can donate to Ubuntu and Wikipedia nowadays. I am grateful for everything Firefox has given me for well over 10 years...
I really don't know what XUL is (intermediate language between HTML and FF UI?), but I guess I do feel sorry for people who have been using Thunderbird. I hope it's significant enough a property that people will want to continue, write it in Rust?
XUL (or rather XULRunner) is a cross-platform UI toolkit, basically a Javascript+XML runtime built with C++. It's what Mozilla programs are built with today, abstracting out a lot of OS-specific details. It's unlikely to ever be rewritten in any language, and pretty much failed to get any traction outside of the Mozilla ecosystem.
Maybe they decided there's too much technical debt and they can't make changes to the browser as fast as they wish they could in the current framework?
Not 'broken' in a traditional sense but still a valid reason to rewrite.
Yeah, but there is a trade-off involved. If you spend 3 years rewriting your toolkit, then the time you will eventually save on further changes has to offset those 3 years, and that's very hard for most projects.
Joel was right and wrong.. Firefox was a huge success (or at least in my mind it was) but some might say the Netscape company was trashed during the process (I don't know if I agree).
Starting over isn't always a bad thing but I agree that is also highly overrated.
It was a failure as he said because the goal was to rewrite it for the company to do better. They failed at that. More work was done including by Mozilla. That worked but was too bloated and all-in-one. Eventually, someone trimmed it up to make Firefox and added the customization features. That succeeded.
So, there was a failure, years of struggling changes, several new audiences, and another big change before it made it. Not seeing it as a counterexample as much as good luck for a project that seemed doomed to failure.
I don't disagree it was a bad idea to do the rewrite but rather the company (Netscape) was on a downward spiral regardless (it didn't help but I don't think it was the sole reason).
Definitely wasn't the sole reason, their server software generally sucked, e.g. a lot of people happily switched to Apache once it was perceived as being sufficiently trustworthy. I could see the latter happening in the 1995-6 period.
One thing I've read about the rewrite is that Netscape accuihired? (back before that was a word) a failed company, and put its failed managers in charge, who I guess were good at what really counts in the short term (looking out for themselves). An obvious corollary to the "don't do a rewrite" is "if you're going to do one, employ really good people to do it".
Its funny (and ironic to me given the topic) you mention Netscape and Apache. One of my first jobs out of college was rewriting an old LiveWire application (yes ... the original server side Javascript) to a JSP Tomcat application.
I forgot LiveWire existed. One of few that finally faded from memory. Of old & commercial ones, AOL server + a TCL web framework are still getting updated. Opera is getting redone. The product with the coolest name is still scraping by per .cfm pages I see. Some ancient tech still around but mostly going bye bye.
Only thing left is maybe to redo Mosaic in Ruby or Java to see if it's technically feasible to slow its rendering down any further.
Was it really HTML+JS? Because it was fast, many years back (used it just as an RSS reader though). Also, they shipped it as a standalone product[1], but I don't think it ever got updated after that.
From memory, it was C++, much like the rest of the Opera UI. It used Quick — Opera's in-house cross-platform UI toolkit, and it died (along with the rest of the old Opera) because Quick was heavily entwined with Presto.
It's all open source right? You are not the first person I see complaining about losing XUL, why is no one forking it instead of just making sarcastic comments? I thought that was the whole point of open source, that when the original maintainer loses interest the community takes over. You even say in another comment that the effort is not very big (I don't know, never seen the code) so why not?
But hey, donate to Mozilla! $5, $15, $25, anything helps.
They're starving over at Mozilla. They took in a mere $323 million in 2014. How can you expect them to properly fund multiple projects on such a pittance?
Which would be a ton of cash for most applications, but this is a web browser and they are in direct competition with not just one, but several, of the biggest companies in the world. Here are their 2014 revenues: $86 billion (MS), $182 billion, $66 billion. Budgets for the other browsers aren't clearly defined, but we do know it's a big focus for all the manufacturers and they each have major incentives to keep users inside their own ecosystem.
Even just keeping up with all the standards, and contributing to them, is an enormous undertaking at this point in the web's evolution. Let alone UI design, devtools, porting to mobile OSs, etc.
I'm fairly sure the revenue attributable to Firefox dwarfs what any of the bigger competitors are spending on their browsers, so it's not really for lack of resources if Firefox falls behind. But it's the cash cow that subsidizes pretty much everything Mozilla does, some of which is great and some dubious. Everyone can make their own case for which projects are great and which are iffy.
Personally, I would think an e-mail client is the perfect complement to browser development, and something that could/should be another significant source of revenue instead of a burden.
> I'm fairly sure the revenue attributable to Firefox dwarfs what any of the bigger competitors are spending on their browsers
I suspect you would be wrong at least for the cases of Google and Microsoft. I don't have a good feel for how many people Apple has working on Safari and WebKit, but both the Chrome and IE teams are significantly bigger than the Firefox team from what I can tell, and probably more expensive unless you think Google and Microsoft pay developers less than Mozilla does. Let me ask you this: how many people do you think Mozilla, Microsoft, and Google each have working on their respective browsers? Ballpark figures, of course.
Also, estimates are that the money Google spends annually just _advertising_ Chrome in the last few years (TV ad campaigns with Justin Bieber and Lady Gaga, worldwide ads on public transit, etc) is comparable to the entire annual revenue attributable to Firefox.
Reaching number 42 is not a sign of stopped development. I checked out TB once again. And it looks a lot nicer. I was surprised to see updates for windows 10 too!
Flex is not Flash and Apache Flex distribution is not exactly a poster child of abandoneware surviving as an OSS project. Apache Flex releases are infrequent, not bug free and generally smell of death.
Apache Flex has seen more success than I expected it too. The Mailing list traffic makes it one of the busiest projects in the Apache Foundation and it has had 7 major releases [if I'm counting right] since it got donated.
I wasn't aware of any bugs in new releases; but I know lots of legacy bugs have been fixed; plus lots of new components and other code has been donated.
Its ties to Adobe Flash Player may be an albatross, but the FlexJS project has done impressive things.
[Disclaimer: I am an Apache Flex PMC Member and all this is my opinion/perception; I do not speak on behalf of the Apache Foundation or the Apache Flex PMC]
You've been brainwashed about the "community" stuff. Mozilla _is_ a corporation. Linux is built by a corporation. Last time I checked, less than 18% of Linux patches were from independent contributors.
Everything big enough to be known by Joe average hobbyist is built by a corporation.
Let's see the community in action taking the lead when Mozilla drops the ball.
Not sure what you're implying. Mozilla stopped developing Thunderbird since 2012. I would also be curios in what corporation (singular) is developing Linux.
I'm implying that "open source-ness" is not necessarily _the_ ingredient that will save a massive abandoned project.
You need also 'drive' - and good hackers are put of by massive corporate projects. They have better things to do than clean up corporate mess.
Open source, mostly defined by the right to fork, is a prerequisite for the survival of abandoned projects. You can say that abandoned open-source projects don't necessarily survive, but for proprietary projects abandonment is a guaranteed death sentence.
I've also started to resent the word "hacker", because it sounds as some kind of social class made up of special snowflakes. If the project has value and users, then interested programmers will find a way to keep the project going and there are hundreds of projects in the Linux ecosystem that survive because of volunteers or companies scratching an itch. If there isn't interest, then surely the project might as well die. But that's a tautology.
I use TB daily - I did not ask a for a feature that did not find. But for several years it has been neglected. And the "open source community" did not step up to the plate and fix the problem.
I argue that there is no such a community that will save TB after Mozilla drops it.
> "I argue that there is no such a community that will save TB after Mozilla drops it."
Yes, I realise that was your point, but my point is what work is required? If there's no work required, then there's no need for the community to save it.
It's an email client. So long as it sends and receives email, and can be compiled for the latest OS versions, what work is needed?
The ability to show all events for the current day in the Today Pane. It only shows events at or past the current time. I've looked everywhere for an option.
If this was an open source "project", rather than a "foundation" whose mission is to build a better web for its users, I'd say it was their call and that's the beauty of OSS. This is not that.
This is another decision in a long string of decisions which are either not in their users' interest, questionable, or poorly communicated and implemented.
If I were to give the benefit of the doubt here over the question of whose interest this is in (Mozilla or its users) it is still being horribly communicated (otherwise one might better understand why it's in one's interest) and horribly implemented, to the point which I'm beginning to question whether Mozilla, as an organization, is up to the task of building a better web for its users.
Why not more discussion around Pocket, the new tab page, Thunderbird support, etc. Why pop these decisions, fully made, on their user base? And why not, in the case of XUL, incrementally replace features or develop in parallel until a drop-in, validated solution exists.
To me, one of two things is going on. Either Mozilla is not acting in the best interest of its users or this is amateur hour. Both scenarios suck.
Uhhh... the final point in the mailing list message is this:
---
> 12. This message is about the future and there’s a lot to work out. It’s explicitly not to announce changes in daily activities at this point. People using Thunderbird will not see any change in the product they use. We have started this conversation early because Mozilla works best when our community is engaged. This is how we gather the people who are interested, and enable those folks to engage productively
---
So this is exactly not a case of confronting people with made decisions, but discussing long term strategic considerations in the open. Bakers message is actually remarkably explicit about this, discussing various pros and cons explicitly out in the open.
---
> 10. The fact that the Foundation is facilitating these discussions does not necessarily mean that the Foundation is or is not the best legal and financial home for Thunderbird. The intent is not to make technical decisions about support of Thunderbird by Mozilla employees, or merging repositories, etc. Point 6 above is the shared organizing principle for both of us.
---
So Mozilla is actually not talking about no longer supporting Thunderbird, they are talking about decoupling the projects, possibly within Mozilla. When did it become hip to just randomly hate on Mozilla for everything? I use Firefox daily, and some random Pocket icon appeared there. I don't know what it is, it took me one right click and one left click to remove it from my toolbar, done.
When Facebook forces a user to opt-out it's acceptable to denounce their actions. How is the Pocket example different?
One of my biggest, if not my biggest, complaint about the OSS community it the lack of sympathy toward non technical users. If I was a point-and-click, non-technical user do you think I'd have any clue what you meant by 'mailing list'? Not likely.
And if I was that user what are the chances that I understand that the Pocket application was a third-party application and that my data was not staying with Mozilla? Would I understand that removing the icon did not remove the code for my install?
Bigger picture here, and the point I was trying to convey in my original comment, is that this is another instance in a string of instances that, when each taken on its own might not be a huge deal, together paint a picture. The writing is on the wall, as they say.
I'm not a Mozilla hater. But before I am a Mozilla user, I'm a citizen of the Internet. So when a participant of the Internet begins to lose their way, I figure I should do what good partners do, which is to plainly speak my mind in a manner that is respectful and open to listening. I think Mozilla is great, and I think they'd value others being constructively honest with them.
> When Facebook forces a user to opt-out it's acceptable to denounce their actions. How is the Pocket example different?
Except Pocket is still opt-in; you have to click the button for it to do anything. I think springing these integrations was a poor move strategically for Mozilla, but it's not like they installed Alexa toolbar on everybody's browser. The code for the extension is even open source.
I haven't seen any denouncing of Facebook in a long time, even though they keep getting worse every month. I assume it is because people accepted they are assholes, they won, they can't be replaced and that's that.
And personally I consider the backlash against Pocket to be either undeserved kneejerk reactions, or a discreditation strategy sponsored by Mozilla's competition. Because seriously, why aren't we seeing the same backlash against Chrome, which includes proprietary bits not present in Chromium (like the PDF viewer) and that explicitly does not support extensions on Android because of Google's fear of losing ad revenue? Or maybe we should talk about how Chrome does not encrypt data by default, most users giving access to Google for their whole browsing history. We could talk about IExplorer^WEdge or Safari and how Apple and Microsoft are blocking alternative browser engines on their mobiles, but that's not as fun as bashing the only open browser that's backed by a non-profit without ulterior motives.
But then lives without our double standards would be boring.
The difference is that Google and Facebook have always been commercial entities with a profit motive, they are not public utilities. Exactly because Mozilla is (supposed to be) something else, it's held to a higher standard by its users and donors.
> We could talk about [...] how Apple and Microsoft are blocking alternative browser engines
But we do. In a way, Mozilla is what it is because a lot of people were pissed off at MS.
A "public utility" has very specific meaning, being an organization that maintains the infrastructure for a public service, that is subject to forms of public control and regulation and for which you pay taxes.
Is Mozilla subject to forms of public control and regulation? Do you pay taxes for Mozilla's existence? If not, then Mozilla does not qualify.
My problem is actually twofold. On one hand bashing Mozilla is like bashing a charity and most people doing it have never donated or contributed anything. But also I don't understand what's the freaking deal with that Pocket button, which is nothing more than a shortcut that consumes nothing, that can be easily removed and for which Mozilla got nothing in return for the deal.
This is why Free Software will never happen at scale. Far more aggravating than the problem of the business model is all the shit these people have to put up with.
The problem is that Mozilla really really would like you to believe that they're doing a public service. "We keep the web open! We defend your privacy! Donate now or Bad People will win!" That's their message. So yeah, it's a charity, but they make it sound like it's a charity that must exist, so it borders on being a utility.
> most people doing it have never donated or contributed anything.
Since when, in order to criticise something you use, you have to join it first?
> But also I don't understand what's the freaking deal with that Pocket button
I'll bite. Two issues:
1) Pocket is basically a centralized service to keep track of your reading. This goes quite clearly against Mozilla's own message of placing privacy and users' rights above everything else. Shipping such a feature as opt-out and fundamentally un-removeable is just bad on every possible level; it could have been worse only if Mozilla had started routing all your traffic through Microsoft servers.
2) There are umpteen services like Pocket, always have been, and none of them ever got a button in Firefox. So why Pocket? Why not one of the bazillion other services? Who chose it and why? Does that mean FF's toolbar is now open for business? Who do I bribe to get a button? ... That's a very opaque and fundamentally corrupt process, in an organisation constantly preaching openness.
You can ask a priest how it feels having to constantly adhere to a higher moral standard; it's the price you pay for getting people to listen to you, trust your judgement, and give you free labor. At any time you can just stop preaching and go do your own thing, but then you can't expect other people to still follow you.
> This is why Free Software will never happen at scale.
There's scenario 3: a news site took a mail on a project mailing list, and wrote a misleading article with a clickbaity headline. So far so common.
To their credit, they did include the full text of the mail, and it simply doesn't support the "Mozilla about to stop Thunderbird maintenance" subject this is being titled with. And the title here on HN looks nothing like the title of the actual article either (though that might have been edited later, of course).
It might be. But what about the discussion? Is focusing on a native mail application not inline with their mission statement, given all the privacy issues of late? And your point doesn't address the issue of implementation. Firefox is one initiative out of many initiatives in Mozilla's portfolio. And the web is not the browser. So I, personally, would say no, focusing on a browser to the exclusion of all other aspects of the Internet is not inline with that mission. But, I'm one of many users, and without open dialogue, it's impossible to say whether other Mozilla users agree with me.
"The problem with Thunderbird is not that it is a mail user agent or that user agency in messaging is unimportant. The problem is that Thunderbird has had a serious technical debt problem since the day its code-base transitioned from Netscape. Its low-level integration with Gecko has been a maintenance burden for Thunderbird developers and non-Thunderbird developers alike.
The Mozilla Foundation and Mozilla Corporation put serious financial resources into trying to address both of these problems with the creation of Mozilla Messaging. The idea, as I understand it, was to attempt to alleviate the burden on Firefox development by separating Thunderbird development while simultaneously providing Thunderbird with
people and resources to attempt to address this technical debt."
"An important question that falls out from all of this is and your original question is: which is more important? Mail user agency or Thunderbird the product, especially if there are serious opportunity costs related to Thunderbird?
Within the funded efforts of the Mozilla Corporation[2], mail user agency has not been abandoned and continues to be advanced as part of an open development process."
I agree a discussion of a kind is occurring. My reply was specific to the comment it addressed, in that, the comment did not fully engage with my initial comment and instead cherry picked one part of it. A more fully formed response, much like yours, wouldn't have elicited my above response. Context.
Why do they have a public discussion to justify their actions. If they choose to, fine but I do not see why they have too.
> the web is not the browser
Actually yes, the web is the browser, or more correctly the browser is your interface to the web. HTTP/HTTPS is the web, everything else is the Internet. Mozilla is focusing on providing a web experience, a SMTP client is not the web experience and they no longer wish to expend resources on it.
I think this is just a reaction to Firefox's rapidly declining market share. We've been through this cycle before, when MSIE and Windows were the dominant browser platform and Netscape Communicator hit a local maxima. It took a few years, but they came back, with Firefox.
Before we did a big transition from Desktop to Web; now a lot of people are shifting their focus from Web to Mobile. The Desktop never went away, and the Web won't either, but development there will likely stagnate. But unless Mozilla and Firefox reinvents itself for mobile, it will become mostly irrelevant, like DOS and Netscape and Opera.
As I mentioned in another comment, Mozilla stopped developing updates back in 2012 and passed it to the community. I imagine the maintenance will move likewise.
If you're upset about decisions that have been made with Thunderbird, submit a pull request.
Mozilla is pretty much a regular for profit as this point, it just doesnt have share holders.
Still is for profit. Mainly benefits the people at the helm instead.
Thunderbird has been my email client ever since I used unix as my day-to-day platform and it's a real pity that Mozilla stops maintenance but on the whole it doesn't need that much maintenance. It just works, I don't think I have a wishlist of features or any bugs that are so bad that they need fixing.
Just keep it as it is and I'm perfectly ok with it. If mozilla did the same with FireFox a and would focus on long term stability and bug fixing rather than grafting new parts onto it and re-writing old parts that are working just fine I'd be OK with that too. (The default seems to be that bugs are not fixed before the part of the code base that contains them is replaced by something new which in turn also contains bugs.)
Even making sure that a program keeps compiling can be a big effort. Target platforms keep moving, toolchain changes, libraries die and must be replaced, it's not trivial.
I hope they find a way to manage all of that because I don't want to use web mail and I don't know of other equivalent clients on Linux.
> If mozilla did the same with FireFox a and would focus on long term stability and bug fixing rather than grafting new parts onto it and re-writing old parts that are working just fine I'd be OK with that too.
Although I agree 100% with the sentiment, the trouble with this approach is that the web moves much quicker than email.
It is my opinion - which is not shared by many, I'm aware of that - that the web is moving too fast. This is why we're dealing with massive data leaks and unreliable services on a daily basis. If the quality of desk top software in the 80's and the 90's had been as bad as the quality of your average consumer website (my bank for instance) then the PC revolution would have never happened.
I'm all for a slower pace with a much stronger focus on quality.
I agree with your opinion and am one of those that shares that thought as well.
"If the quality of desk top software in the 80's and the 90's"
Exactly. And it couldn't be as bad back in the day when things had to be good simply because you didn't want to have to update by floppy (or even CD) a bunch of software with issues.
The focus on quality isn't there. It isn't there because of the safety net of being able to update people over the web. Nothing appears to be thought out in advance anymore. Maybe "no beta or alpha testing" might be an exaggeration but it just seems like "shove it out and when problems develop patch it".
A large part of the instability and security problems are also because software is so, so SO much more complex these days. There is just a lot more to consider when writing code than there used to be. So it's not necessarily that it's moving too fast, it could also just be from increased complexity.
We actually make it more complex. That's self-fulfilling prophesy, software is more complex because we choose it to be so. It does not have to be so. Feature wise we could do just about what we can do today, maybe a bit less eye candy but rock solid if we chose to walk a different path.
I don't know about Windows, but on Linux... I try every so often to use other clients, but Thunderbird is still the only one I can bear.
For some reason there's always something that doesn't work with Gnome or KDE clients, keystore stuff that doesn't let me save my passwords, or seems to but doesn't actually remember them, or some indexation service insisting on taking half my CPU, or...
And the desktop-agnostic clients are ugly and lack features.
So through all this time, I've both hated Thunderbird and considered it the only usable client. I really wonder which one I'll switch to in the future.
If by "enterprise-ready" you mean "slow, bloated, and byzantine", then yes, it fits that ecosystem perfectly.
But despite being a single-threaded, half-XML-half-C cancerous pile of dirty hacks, Thunderbird is still faster and more stable – not to mention more extensible – than Evolution could ever hope to be.
God, I hope the Unix people abandon C and start using Rust. It's going to raise the quality of open source desktop applications so much. Or, well, it'll at least be the first clear improvement in many decades.
I don't know much about Rust but the Wikipedia page says the original Rust compiler was written in OCaml, and that the new compiler is self-hosted and written in the Rust language itself.
The OCaml bytecode interpreter is implemented in C. The OCaml compiler generating said bytecode is implemented in OCaml, as is the other OCaml compiler that generates machine code.
Seeing as much of the kernel is written in it, of course. Working efficiently with raw memory pointers requires an unsafe language. Even Windows is written in C/C++
No, by enterprise-ready I mean it works better than others at integration with various Exchange accounts, including calendar scheduling and contact lists.
> not that advanced and mature, but a pleasure to use...
No encryption, no CardDav, no Sieve support. Yes, I need plugins for this in Thunderbird, but I can have them if I want to. geary is also hectic on which distribution/release is supported.
What are viable alternatives (FLOSS+Mail+Calender+GUI)? I've used Evolution before and it was pretty good, I guess I'm switching back to that (more importantly I will have to switch my parents' computers as well, they have happily migrated to Linux). Claws also seems good at first glance.
Have heard KMail and Trojita mentioned before but I'm not sure how much overhead having Qt for them would be (so basically ceteris paribus I'd rather have something GTK as Xubuntu is my distro of choice).
I guess Exchange integration would be needed eventually but I could work around that if need be.
Linux and OS X support preferred, could live with Linux only.
[...] Thunderbird, the free email, chat and news client
it first developed in 2004 [...]
In 2004 Thunderbird spun off the Mozilla Suite (Browser, Mail, WYSIWYG HTML editor, IRC-chat client), like Firefox.
And Mozilla Suite is based itself on Netscape Suite, that AOL donated as open source code and formed the Mozilla Foundation (Mozilla was the internal codename of Netscape).
The Netscape Suite was a complete rewrite of Netscape Navigator 4. That long rewrite phase and the choosen technology (XUL, XPCOM, etc) contributed to loosing the Browser war agaist IE 5/6.
Thunderbird barely changed since 2004. Back then it was a direct competitor to Outlook Express.
I use claws. Very simple, very efficient, very robust (well I just use textual email mostly and in a very one-person way, that is, I've got a few mails a day, mostly from less than ten mailing lists)
Funny I should see this today, I spent yesterday afternoon reading articles about Thunderbird and other mail clients and ended up migrating from Thunderbird to mu4e [0] (purely for reasons of usability).
If this is true (and there is some reason to doubt it, as this isn't the first time Thunderbird has been declared "dead"), and considering that Geary is no longer in active development either (maybe the Elementary OS guys picked it up?), Mailpile [1] might have a chance to fill that gap. Other than that, there's always Claws Mail [2].
Development by Mozilla has been stopped since 2012, which means that Thunderbird has been relying on community support for maintenance and new features, Mozilla still contributing security updates. For details see here: https://blog.lizardwrangler.com/2012/07/06/thunderbird-stabi...
Development has been slow since then, but the project is far from dead. I'm on version 42 beta (latest Firefox is 43 I think) and for example they've just includes the Lighting add-on in the base install. Plus all add-ons that interest me are compatible, like Markdown-here.
Mailpile looks interesting, but the Mac package is unavailable: "Packages are being reworked". That makes me think twice -- and I'm not even a Mac user. Though I'd rather see a pulled release than a dangerous one, it's been like that for at least a couple of months now.
I dislike every email client I've used. I dislike Tbird the least.
If Tbird doesn't survive this transition, I've thought in the past of using something like Mutt, with <something> to display rendered html, and <something else> to compose html mail.
And <yet another thing> for calendar access to my fastmail calendar.
I've been using Postbox since 2012. It's a great client and while I've tried a ton of others (Apple Mail, Thunderbird, AirMail, Sparrow, Dropbox Mailbox, etc), I always come back to PostBox. It's stable, simple, has access to some Thunderbird extensions, and just works like I need it to.
My only gripes are that development is inconsistent at best (v4 took far too long to come out, in my opinion) and they seem to focus on features that don't add much value to the client. But overall, it's a great client that I was more than happy to pay for.
I love Postbox. It's been my primary email client ever since I was forced to switch from Eudora. It even supports Thunderbird plugins with some small tweaks (mostly just recognising the Postbox User Agent).
My biggest complaint about Postbox is that it's too cheap. It's only $15... I paid more than that for my Twitter client. Email is mission critical for me, so I'm happy to pay at least $50 (maybe $50/year?) for whatever is the most efficient, powerful & reliable email client. I want to pay that money to a company so they'll keep developing & advancing the program, not abandon it like Mozilla is doing now.
It's funny how Microsoft was once in court over essentially shoving browser components into UI, and now this.
I wish that the features of web engines were more compartmentalized. The "convenience" of a Thing That Does Everything will also introduce fragility and bloat (and maybe even security exposures).
For example, I would probably love to call functions to lay out some rectangles for me. I know a web engine can do that really well, and I don't even mind passing in CSS strings to describe what I want. The problem is, I don't want "Internet in a box" to come with it; I just want the layout in that case. It would also be a lot easier to identify problems and contribute solutions if there was a way to "only" do X and focus on that part of the engine to fix.
It would be awesome to be able to take those kinds of low-level details, and start really going cross-platform with them. Make a library that can finally lay out whatever the hell you want consistently across machines, that can be patched into all existing UI libraries or other tools. Make a portable text rendering and text layout system. Make a portable GL viewer. But don't tell me that each of those things only works if I create an InternetInBoxView. Instead, refactor InternetInBoxView to use those separate parts.
When development "stopped" a while back, I tried to switch to alternatives. Evolution is high quality, but doesn't fit the way I want to work...no matter how many notifications I turn off, it always seems to find a way to be annoying and invasive. There are no OSS webmail clients as good as Thunderbird or GMail (even though I work on Usermin, and it is a competent webmail client compared to other OSS options, we just don't have the resources to push it forward enough to match native or something as amazing as GMail or Inbox, especially since it is not our core business).
So, I will keep using Thunderbird, and hope that it keeps seeing occasional updates. I assume it will...it's got millions of users. Surely some of them are developers, with itches to scratch.
I'm using TB since two years, when Apple Mail failed to load after an OSX upgrade. I wanted to move, preparing for moving to Linux later on. I have several family members using TB on Windows. My mother used Eudora for years, I believe seven years after development stopped. It never had a problem. I could copy it to Windows 7, just copying the folder with the program files in it, and it all worked.
How big is the risk if TB development stops altogether? What security risks are there when you keep using it?
My mother cannot handle changing to something new anymore. So I guess I have to take the risk.
I migrated from Thunderbird on Linux to OSX by simply moving the profile directory and modifying the new configuration file to point to that directory.
Anyone know how this impacts the e-mail functionality of Seamonkey?
(I've actually started using Seamonkey again on a whim. The last couple of weeks. Somehow, browsing feels more snappy with Seamonkey than with Firefox.)
The demise of Thunderbird does not mean anything to Seamonkey, but the deprecation of XUL will make it hard to continue to develop it since the whole user interface is based on XUL. The only viable option would be to pick up maintenance for the XUL-supporting Gecko engine.
This also seems like a shame. I'm not sure Thunderbird was ever a great product, but it was always a decent alternative to worse things, and I remember Enigmail being quite a good option as a relatively simple way of signing and encrypting emails.
I feel the complete opposite about this -- it's a really good example of management not just making a conceptual decision but diving into the details and making a call, but with respect for all involved. Note that:
* The chairperson joins in and speaks with authority. This isn't a VP of eng making a call about two repos.
* It's not a binary decision - "cancel development, fire the people affected, leave the product to wither on the vine" - but a nuanced one: don't make decisions that make Firefox worse, I don't pretend to have all the details but will give you an example of one decision that I have an opinion on and who you should look to for advice (the platform and infrastructure teams)
* Recognizes that it's not just a technical call but has legal and community issues, and tells you who will be sorting those out as well.
Management is hard -- you can't just make a blunt statement and expect people to fall in line, especially in open-source projects. Would you have preferred a harder line? Do you think that would've been better for the community in the long run?
I think I probably would have preferred something brief and written in plain English. Its author was previously a lawyer, and it shows. I'm sure it's very measured and careful and so forth - but really everyone here can read between the lines that Mozilla want rid of Thunderbird because it's tying up their development resources and it's not their core focus.
I'm sure everything is complicated at Mozilla because there's a Foundation and a Corporation and they work on open-source projects and do "research" stuff (like Servo) and no doubt the lines between all of these things are confusingly blurred (at least to an outsider like me, but maybe internally too), and perhaps that necessitates a hundred line missive from a lawyer about laser focus... but really, does any of it need to be that complicated?
If you think that's corporate drivel at its worst, you haven't seen much corporate drivel. What's so bad about it? She is diplomatically trying to say, "Hey, we don't have the money or resources necessary to support Thunderbird, we're probably going to abandon it".
Open Source may be well and good but the engineers at Mozilla still have to earn money for their families. Look at the Corporation's Financial Statements (https://static.mozilla.com/moco/en-US/pdf/Mozilla_Audited_Fi...) - they don't exactly show a company flush with cash that is pulling support for a product because they don't like it or something.
I like Enigmail though, just as you do, and tried introducing my family to it. Sadly that didn't stick :/
It's long, it's rambling, it uses phrases like "laser-focussed" (twice). Fine, it's not corporatese at its absolute worst (there isn't a "synergistic" in there), but it's also not going to win any awards for clear communication; it could be every bit as diplomatic whilst also losing about 70% of the words.
Many inside of Mozilla, including an overwhelming majority of our
leadership, feel the need to be laser-focused on activities like Firefox
that can have an industry-wide impact. With all due respect to
Thunderbird and the Thunderbird community, we have been clear for years
that we do not view Thunderbird as having this sort of potential.
However, as I say, it’s clear to me today that continuing to live
with these competing demands given our focus on industry impact is
increasingly unstable.
So, their stated goal is market dominance for Firefox, period. Nothing else really matters. Clearly they are failing at this goal, so they are focusing their resources on it and discarding anything else.
>Firefox and Thunderbird have lived with competing demands for some time now
But we mashed Pocket into Firefox because we think some weird non-bookmarking bookmarking (non)solution is more important for browsing the internet than viewing emails.
>At the same time, build, Firefox, and platform engineers continue to pay a tax to support Thunderbird.
Not many people use Thunderbird so we don't want to fix it anymore.
>These competing demands are not good for either project.
They're built on identical platforms but we just don't want to maintain Thunderbird.
>Engineers working on Thunderbird must focus on keeping up and adapting Firefox’s web-driven changes. Engineers working on Firefox and related projects end up considering the competing demands of Thunderbird, and/or wondering if and how much they should assist Thunderbird. Neither project can focus wholeheartedly on what is best for it.
We don't care or think about Thunderbird when developing Firefox. Firefox is our main priority and we let Seabird die a pathetic death a long time ago so why pretend to develop anything besides just a web browser?
>“Neither project can focus wholeheartedly on what is best for it”
We don't want to develop Thunderbird anymore.
I could keep paraphrasing but it's basically just "gmail rawks" over and over and over again in different words.
It's sad but basically someone needs to fork Thunderbird as it is now (FossaMail, anyone?) and just run with it from there. The beauty of Open-Source is that now the community can maintain it's own email client. If you don't want a web-based client apparently that's going to be the only way to view your emails and also not want to kill yourself going forward.
> I could keep paraphrasing but it's basically just "gmail rawks" over and over and over again in different words.
Given that the author of the mail uses Thunderbird as her mail client, it's fairly unlikely that "gmail rawks" is what she's actually thinking here.
But of course it's easier to snark about "built on identical platforms" without worrying about technical realities like "security and the need to do multiprocess require some fundamental changes to the way networking works in Gecko and changing the IMAP implementation in Thunderbird accordingly is... let's say rather involved".
Note that we (Gecko developers) have in fact taken great pains to not break Thunderbird so far, and are carrying some significant technical debt as a result. The big question is whether we should keep doing that or whether we should invest more heavily in Thunderbird to rewrite large pieces to allow Gecko to stop carrying that technical debt, or to decouple Thunderbird and Firefox in some way so that we can make the changes Firefox needs without breaking thunderbird, or something else. This mail is part of the discussion about that; mostly about figuring out which of those options we should really pursue.
So a foundation with a 300 million Dollar budget can't support the most widespread free mailing software out there? A software that shares many parts with the Firefox browser? This makes no sense to me. It's ridiculous that they stop this project instead of going full stem forward to make it finally great. They are not that far away to malomg it a viable free alternative to Outlook (and they'd have happy followers)
Just yesterday I had commented in a donation related thread here that it would be nice to donate to Thunderbird as one of the causes that's important. [1] As a long time Thunderbird user in an Exchange/Outlook environment, I'm disappointed each time I hear news about its priority being pushed further down.
The TechCrunch article says, "Apart from the fact that Mozilla had cut off most development support in 2012, Thunderbird has become a somewhat anachronistic product." For any enterprise or business environment where email still rules, calling Thunderbird "anachronistic" sounds misinformed and insulting. Thunderbird may not have the market share of Outlook or the glamor of smartphone based mail apps, but I'm sure those who use Thunderbird are really passionate about what it provides and the extensibility that comes with it.
One of the things I don't like about the Mozilla of the past few years is the high amount of effort and time spent on Firefox OS. I don't want to put that down, but Mozilla is trying very hard with very less traction on it and still pushing onward.
Mitchell's message sounds like more planning is in the works to separate Thunderbird and probably make it stand on its own. This will take some time to plan and execute, with Thunderbird just languishing in the meantime. There could also be a complete re-write of Thunderbird, which is not really a great idea. I can see both optimistic and pessimistic views on what the future holds.
When Mozilla Messaging was announced, I had high hopes for better integration with Exchange calendaring and also improved search. All that went to nothing in 2012.
If Thunderbird ends up as a separate entity that I can donate directly to, I'll be one of the first to do so!
I'm saddened because the only thing holding me back from using Linux full time at work is the lack of a good calendar and e-mail application.
Of course thunderbird is insufficient for me who rely on Microsoft Exchange at work but it could still be a contender to Evolution given the right development focus.
Evolution, the number one alternative I know of today, has had shaky EWS support from day one and in Fedora 23 on my personal laptop it's still not fully resolved. Also I find its calendar option quite hideous actually, it tries to mimic Outlook but that's not a good thing imho. The best calendar I've used is Calendar.app on Mac OS.
Of course you can't blame anyone but us, the community. The one EWS plugin for Thunderbird is pay-2-play and the one for Evolution is the one having all the issues. So either Microsoft is hard to develop for or demand isn't high enough.
Have you checked out Exchange EWS Provider [1], currently maintained by Ericsson? This has been around for a few years [2], and when the developer could no longer spend time on it, Ericsson took it over. The extension is not perfect, but you can get some stuff done.
Another alternative is the DavMail gateway [3], which runs as a separate (Java) program that sits between your Exchange server and Thunderbird. [I haven't used this one for years ever since the Exchange EWS provider became available]
I'm using [1] against exch2013 without any major issues.
Make sure your exchange environment autodiscover is properly configured, and ensure you have IMAP available (for thunderbird mail) and the setup will go smoothly.
I've never been completely satisfied with Thunderbird and have tried to switch multiple times, reverting to web clients every time. Now I am using Nylas N1 built on electron(imagine that!) and it looks very promising.
Also, arrogance of tech conservatives in every Mozilla or web tech thread on HN is becoming unbearable.
N1 is a game changer for desktop clients and I'd love to contribute. What is the best place to send ideas concerning general product strategy? Tech feedbacks goes to github, obviously.
Well, in this context those who are angry and are actively opposing proliferation of new web tech. Web tech may include new front-end JS frameworks, electron apps built with HTML/CSS for desktop, node itself, es2015 features.
It is a shame... But I am much more irritated, lacking a better term, with the chronicall lacking of a proper mail client for Linux. Thunderbird is the best as far as I used them, but I am not satisfied with the performance, UK and features, especially considering Windows only counterparts.
Sad to hear, Thunderbird has been my major and actually sole email client for a few years, not a Windows user so outlook is out, do I have to use mutt from now on?
On Android I use K-9 which works well, it seems for Desktop the web email will be my only choice, not good at all.
I don't mind paying for Thunderbird, hope someone picks up the development. Firefox is great but there are alternatives, Thunderbird is great and _unique_ (across platform and an overall good product), I somehow feel Thuderbird is of more use to me than Firefox itself.
So people here just give webmails as alternatives...
Theres a reason people use thunderbird. Its the only non webmail, non mobile client that has a gui, works on most platforms and doesnt suck too horribly.
People using it obviously don't care about webmail alternatives...
The suits have been trying to ditch the email client since I worked at Netscape (nearly 20 years). I remember sitting in a meeting with someone asking "What's the email client for our mail server supposed to be -- Outlook??". My hunch is the same thing will happen this time -- it will endure. Perhaps this is a play to get some of the big businesses that depend on having a viable non-Microsoft/works-on-Linux email client to pony up some cash?
It's a little troubling to see only one mention of PGP in the comments. Thunderbird+Enigmail+GPG makes a highly functional way to send and receive PGP-encrypted mail.
I've been meaning to look into Nylas N1 for a while now, maybe now's the right time.
I didn't see anything that stood out like a sore thumb when compared with Thinderbird (except for maybe PGP), but it'd be really awesome if it had a snoozing feature like Inbox or Mailbox.
I use Thunderbird's calendar and think that this is good news. Thunderbird has been in a sad state for long time. It is slow, buggy, and behaves unpredictably. I hope this will create the necessary momentum for a new project or at least a new approach to developing Thunderbird further.
You can't put in emails chained together with a semicolon. So I posted a bug report about address field parsing being broken. I was told that it was working as intended and was completely sandbagged. I don't have too much respect for the dev team right now.
I switched to KMail around the time when Mozilla announced that they stopped active development of Thunderbird. Lack of any desktop integration in KDE (like new mail icon in notification area) contributed to that.
That's sad. I like Firefox and use it a lot, but I need Thunderbird a lot more than I need Firefox. There are other good browsers out there, I don't know any other good email client.
Most of their reasoning about this decision revolves around it being a distraction from Firefox. Maybe they should update the manifesto to put web browsing as goal #1. As it stands, it talks about the Internet, but the WWW is clearly their priority.
So many words to say "an email client does not generate search engine traffic"...
In this age of abundant js transpilers it's kind of surprising to see XUL not being one of the many valid X for "compile X to JS+CSS", but it kind of makes sense, giving the limited scope of XUL.
>Many inside of Mozilla, including an overwhelming majority of our leadership, feel the need to be laser-focused on activities like Firefox that can have an industry-wide impact.
Can we have another alternative for pocket built-in?
Both Thunderbird and XUL are slow, so good riddance. Hopefully, dropping these and 32bit support will allow Mozilla to concentrate on improving Firefox performance. And add Wayland support in Linux as well.
I suppose you use webmail supplied by a corporation. With all your old messages available for scanning when they or the government see fit. Some of us are not okay with that.
I hope someone picks up the reins. I install TB on every OS I have. I prefer it. I damn near require it for its cross platform consistency. Anything but Google or Microsoft (and I like both of those companies).
Your link redirects people to a "no hotlinking" image when used directly. For those affected: if you find the page in Google by searching for "The CADT Model" it does let you see the content via that route.
Though to be honest I really don't have time to look into it, if he doesn't want us there then fine I'll add that domain to those in my "causes irritation" blacklist so I don't waste time on it in future.
I'm just going to keep running Thunderbird until there are gaping security holes, people say Thunderbird is bad but everything else is worse.