Hacker News new | past | comments | ask | show | jobs | submit login

> the way Thunderbird is designed was that it was a kind-of-fork of Firefox, and too many resources were being wasted just keeping the "fork" up to date from changes to internal Firefox APIs.

No. Thunderbird was built against something that the Mozilla foundation used to tout as the future of building software in general: XUL. And there also was a XULRunner which was to Gecko/Firefox what Electron is to Blink/Chrome: a way to develop native apps using the browser engine as a UI toolkit. The difference with electron is that it was built with more native-apps facilities, like spawning up Wizard dialogs: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu... All written in their XML.

It wasn't developed specifically for Thunderbird. Firefox is also built on top of the same technologies. XULRunner versions were released concurrently with new Firefox versions.

The reason why Thunderbird is a dead is because XUL is dead, or rather, will die soon. They are rewriting everything related to UI in Firefox and also terminating the traditional addon API which.. required XUL, in favor of Chrome's addon API.

Thunderbird is not the only notable app written in XUL beside Firefox. There's also Miro, Songbird, Google's adwords editor ( https://support.google.com/adwords/editor/answer/106323?hl=e... ) and many others.

Most software written in XUL has either been abandoned or going to die, anyway.




XUL was the future of old-school, heavy desktop applications. But people generally aren't interested in those anymore. At least HTML and the rest of the web stack work OK on mobile platforms.


> XUL was the future of old-school, heavy desktop applications.

The old-school, heavy desktop apps seem to be so unbelievably light in comparison to current electron-based craziness. But I guess we deserve all the bloat for not being able to come up with sensible common API for desktop development :(


Thunderbird didn't lose to an Electron-based app, it lost to Gmail.


Yes, but we're talking about XUL the platform. That platform was built with the same use-case in mind that Electron has: allowing people to build cross-platform desktop applications with web technologies (html, js etc).

Unfortunately Mozilla failed to execute on that vision, leaving the field open for Electron and friends to emerge. Part of that failure was due to bad technological choices (RDF-XML was terrible), part to the unwieldy Mozilla legacy (the build system was notoriously byzantine) and part to them de-prioritizing anything that Firefox did not need. They had a working general-purpose JS-based UI runtime more than 15 years ago, and still the rise of nodeJS and html-based toolkits passed them by pretty spectacularly - because they had eyes only for Firefox and vanity projects like FFOS.


But lots of people did write apps in XUL. My first IRC client and my first FTP client were both XUL apps. I'm not convinced that Electron today is any more popular than XUL was back then (aside from Atom (or VS Code, based on Atom), I can't name any programs that use Electron).

Additionally, XUL uses web tech, but it is not a standard and was never intended to be a standard (not even an informal specification exists AFAIK), so it's a stretch to say that Mozilla failed to execute on pushing XUL. What would the web gain by pushing it?


> I'm not convinced that Electron today is any more popular than XUL was back then

comex already named two highly popular ones (slack in particular can't be overlooked) but there are more. https://github.com/sindresorhus/awesome-electron

https://electron.atom.io/apps/

Outside of Slack, WhatsApp and Discord (see a pattern? pretty much all new chat apps are using it), I'm not sure if there's any other truly popular (among users) electron app, but among developers, electron definitely is popular and far more often used than XUL was. It's arguably more popular now for new apps than even toolkits like Qt and WxWidgets. People are writing, not one, but multiple competing implementations of things like.. unix terminal emulators in electron. These are not just webapps contained in chrome, they definitely need native access to local APIs. There's a frenzy among devs.

> so it's a stretch to say that Mozilla failed to execute on pushing XUL. What would the web gain by pushing it?

They didn't fail to "push it to the web". They failed to push it to app devs. They were rather enthusiastic at some point:

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Th...

> Whether you need to migrate an existing web application to the desktop, are looking for a technology that will enable you to easily port your applications to multiple platforms, or want to integrate your own cool features into the browser, XUL warrants serious consideration.

And now they are arguably failing to push it to themselves as they're entirely abandoning it for Firefox and will rewrite the UI and extensions APIs to get rid of XUL.


> Outside of Slack

Slack has a standalone app? I've only ever used the web version. What more does it do?

> Discord

Likewise, I never even realized Discord had a non-browser implementation.

> WhatsApp

I never even realized that WhatsApp had a non-mobile implementation.

> they definitely need native access to local APIs

Which ones?

> And now they are arguably failing to push it to themselves

Er, the whole point of Mozilla is to champion standards-based web tech. They're rewriting their UI using CSS/HTML/JS because this is feasible today, whereas it wasn't in 2005. So I ask again, why would Mozilla want to retain XUL instead of making web technologies more powerful?


> Slack has a standalone app? [...] I never even realized Discord [...] I never even realized that WhatsApp [...]

But that's exactly how Electron and friends got popular: they allow for web-first development. Desktop support is a bonus for people who need it.

When Mozilla started working on XUL, the future of the web looked a lot like XML and fat clients. Applications would be built by desktop developers targeting the desktop in a way that would allow for the web to integrate in the background. They wanted to bring the web to the desktop, woo-hoo!

As it turns out, the opposite workflow won: applications are now built by web developers targeting the web, in a way that allows for desktops to come onboard where required. In this scenario, XUL is just too complicated for people who simply need "a web view with a couple of extra APIs". This is still "bringing the web to the desktop", the fundamental role of the runtime is exactly the same; but the paradigm is opposite to what Mozilla had envisioned.

> They're rewriting their UI using CSS/HTML/JS because this is feasible today

XULRunner/Gecko was already built on CSS and JS, but it lived in a desktop paradigm of pseudo-native widgets - because HTML interfaces were terrible back then. It wasn't even a performance issue, but rather that everything was a page refresh because nobody knew any better. AJAX had not been formalized, and XMLHttpRequest was used (guess what) to pull actual XML. HTML4 was considered a hack that was supposed to eventually go away. It wasn't a "this is not possible today" problem, but rather "why would anyone want that?". Already there were lots of arguments on whether JS was "good enough" for desktop development, whether CSS was too verbose, and so on...

> why would Mozilla want to retain XUL

XUL is battle-tested to a different level, having survived almost 20 years, and it's a better option for pure-desktop development than web views. If Mozilla had paid more attention to its evolution, rather than going on quixotic adventures like FFOS, maybe they could have competed with Electron-style apps. Alas, now it's probably too late.


> Electron and friends got popular

Maybe I'm just an old fuddy-duddy (I'm in my 20s, jfc), but I don't see how Electron's popularity is considered a given. I know plenty of people who use the given services, but none who use the desktop interfaces. VS Code is the only Electron app that I've ever seen used in the wild. Am I just hanging in the wrong crowds? Which ones should I be looking at, if so?

> It wasn't a "this is not possible today" problem

Hence "feasible" rather than "possible". :P (And conspicuously not "easy" rather than "feasible", either...)

> maybe they could have competed with Electron-style apps

I sound like a broken record by now, but I still don't see what people think Mozilla has to gain by offering a native GUI framework that people have already proven they don't want. And frankly, I think FirefoxOS, while ill-fated, was at least audacious. :P


> VS Code is the only Electron app that I've ever seen used in the wild. Am I just hanging in the wrong crowds?

Just to note: Atom is the original Electron app. I assume you've seen more people use that than Code.


> As it turns out, the opposite workflow won

Maybe for you, definitely not for me. Most of the applications I use daily are desktop ones and I'll refuse to install an electron one unless I have to.


His point was about the fad amongst developers (well, "developers"...), not users.


> Slack has a standalone app? I've only ever used the web version. What more does it do?

Chew up a bunch of RAM and glitch display compositing if my experience is typical.


My slack has been running for days now, and it's humming along at 50mb.


Electron is multi-process. If looking in Windows task manager, there will be the initial process at 50 Mb and then e.g. 7 more background processes.


That puts it at 250mb. That is quite a lot for a chat app.


> Likewise, I never even realized Discord had a non-browser implementation.

Can't give an answer on slack, as it's not something I use (and I wouldn't use any of the three services if I had a choice, but you don't get to make choices for entire communities as an individual and chat apps are about communities..), but I can say something about discord.

Custom keybindings, ability to do things like push to talk while you're in game, general integration with your OS desktop features (systemtray, native OS notifications), GUI that can overlay over your full-screen window ( like this: https://youtu.be/aVQyk_GX7aE?t=98 ) and probably other features I haven't paid attention to.

> I never even realized that WhatsApp had a non-mobile implementation.

http://www.theverge.com/2016/5/10/11653606/whatsapp-mac-wind...

Released in May, 2016.. and the webapp launched in 2015.

> Which ones?

Are you seriously asking that of terminal emulators that are supposed to be drop-in replacement for iTerm or Gnome Terminal and whatever else? how do you think your bash scripts can operate without breaking on your local data in a webapp without added native calls? I feel like I'm getting trolled here.

> Er, the whole point of Mozilla is to champion standards-based web tech. They're rewriting their UI using CSS/HTML/JS because this is feasible today, whereas it wasn't in 2005. So I ask again, why would Mozilla want to retain XUL instead of making web technologies more powerful?

So a great deal of selective quoting up till here while acting sassy and not paying attention to what was quoted to support the point yet still asking the question?

Why would they retain a competitive edge when other platforms like electron are attracting all the developers to enhance their application with native access goodness, why indeed.

I'll quote it again.

> Whether you need to migrate an existing web application to the desktop [...] or want to integrate your own cool features into the browser, XUL warrants serious consideration.

Is what Electron and Chrome actually do for people now, successfully, in droves and was an aspiration they had before. As for what is feasible now that wasn't before.. electron is not going away any time soon and webapps haven't replaced native. Even more so on mobile platforms, as 90% websites are begging you to install the app with full screen popups.


> still asking the question?

Yes, because the question isn't "how is this useful", it's "how is it in Mozilla's best interest to invest in this?" Mozilla came up with XUL because they wanted a cross-platform way to develop a large graphical application, and given that they're an open source organization they figured they might as well try to popularize the framework to hopefully get some volunteer contributions to the codebase. But XUL was never an end, only a means to an end, and the technology itself no longer has any strategic advantage.

As for "failing to execute" on taking over the world of desktop apps with XUL, I don't think Mozilla will lose any sleep over it. The secret sauce to Electron isn't Chromium, it's Node.js. We can say that Mozilla failed to execute the opportunity to popularize server-side Javascript first... but that's Rhino was for, and really, nobody in 2005 would have foreseen that developers would eventually want to write their backends in Javascript. :P


> Why would they retain a competitive edge when other platforms like electron are attracting all the developers to enhance their application with native access goodness, why indeed.

Be careful with generalizations, I am surely not part of that list and know quite a few others that want their computers Electron-free.


Slack and Riot.im use Electron; Signal's desktop app uses the soon-to-be-deprecated Chrome app platform and will probably end up on Electron (AFAIK). I refuse to use any of them, having been spoiled by IRC clients that can actually handle large message volumes without flopping over.


VS Code is not based on Atom.


It's built on Electron, which was created as the heart of Atom.


In an amusingly ironic twist though, Electron apps with their Javascript frontends also have byzantine and terrible build processes.


FWIW, and this is not make a point either way, Google Mail downloads about 14 MB, two thirds of which is JS. Most of that can be cached, though. It also uses 120 MB RAM after initial load, more as I click around. Figures as reported by the Firefox dev tools.


Because Google usually does a pretty good job as far as performance is concerned.

ie: They have a simple 404 page instead of some novelty page with funny text and a random webm playing in the background


Maybe different Google departments have different opinions about such things. Chrome's error pages include a game http://www.omgchrome.com/chrome-easter-egg-trex-game-offline


But performance-wise, the error pages still load instantly and don't waste CPU when the game isn't activated, so who cares?

...though I don't know why anyone would care about slow 404 pages either, given that they should be rarely visited and quickly left.


I know this might sound insane to everyone, just hear me out.

I always thought Mozilla should have built a Linux distribution (or rather, forked debian like everyone else ha!) and implemented their Firefox UI kit (Gecko right? I'm not as familiar.) and made a Front end for it that was smooth and easy to build apps for using web technologies, but could still run native *nix apps via debion packages.

I believe that now as much as I did when I was younger, but the itme for desktop OSs may have passed.

It would have been a hit I think. Well designed, well maintained, well documented. At least in my starry eyed version of this universe where unicorns exist


They tried that for mobile devices and failed. I doubt they'd have done any better on the desktop.


in my opinion, the last iteration of FFOS looked pretty good. Granted, apps were not there, no shocker. I thought they did a great job with it design wise though, and it had some neat features. I think if it was done 5 years ago it'd been a game changer for linux on the desktop.


I think you might be describing something fairly close to ChromeOS.


Yeah, except ChromeOS is shipped with ubuntu 15.04 i think, and its heavily modified, and you don't have regular access to the greater file system, and the front end isn't really rendered out from blink/chrome, i don't believe.


What definition of heavy are you using here? Because despite often being 'thin clients', most of the programs I run that embed HTML engines for the UI end up being stupendously resource-intensive compared to their native equivalents.


I think that your parent commentator is noting that people pretty much just stopped writing desktop apps altogether, at least relative to webapps. In my childhood I downloaded desktop apps left and right for everything, but nowadays I only download apps in two categories: developer tools and Steam games. E.g. something like http://hirnsohle.de/test/fractalLab/ would have invariably been a desktop app only a few years ago.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: