Hacker News Reader

Comment by prima-facie | Hacker News Reader

XUL was ahead of its time when it was introduced by Netscape/Mozilla many years ago. It was a capable XML based language used to describe rich graphical user interfaces. Together with XULRunner this was supposed to be a generic framework for creating graphical applications. This was long before HTML became what it is today. Back then people still thought Java would take off on the desktop. I believe that most Mozilla products such as the Mozilla suite, Thunderbird and Firefox used this for a very long time.

https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...

View on HN

A bit of nostalgia: I created an application based on XULRunner at the end of high school. The project started out as a Firefox Extension, and since I wanted to create a standalone application, XULRunner was the obvious choice. I didn't know much programming, but it was, coupled with the excellent documentation on MDN, enough to get me started. What I remember best are the following few things:

- XULRunner had an included application update mechanism. You basically created a diff between two application versions and placed that on a server. XULRunner would automatically detect it and apply it. No configuration needed. This was huge.

- XULRunner obviously had a built-in browser. Using a few XML elements, you could embed a browser view.

- Porting from a Firefox extension to a standalone application was very easy. Add some boilerplate and you are done. Pretty much no need to change the application code.

- Since my application didn't include any native code, it was automatically cross platform. And it integrated beautifully into all platforms.

What was the application for? Just curious

Music. You could search for music, and the application would search a few mp3 sites for the track and play it automatically. Also, if the built-in browser detected music files or links embedded in the page, a bar popped up from the bottom offering to play the music.

Cool, I actually used XULRunner for a cross-platform application!

The tooling was great, and it did set the precedent for what we expect today.

I recall playing with it, when I first heard about it: "You mean I can create a native-looking app that's actually browser-based?"...

This had to be sometime in the mid-late 1990s?

I recall the documentation about everything was "ok-ish" - enough for me to create a simple "app" and have it communicate with a "backend" using POST (IIRC) - nothing fancy, but I could tell it actually worked.

But at the time, I had to shelve it - and I was working with a VB6 application for my employer, and I mostly forgot about it. It was always in the back of my mind, though - and I knew that Firefox, Thunderbird, etc - still had support...

Today, it was just a legacy technology that never went anywhere, and it amazes me why it didn't. It's yet another example of something "ahead of its time"; it was frustrating to me back then as to why nobody was using it and making it better - especially when there was a "reference app suite" right there!

But no - we had to wait another decade or so for everyone else to "catch up" to the concept. Sigh.

From my POV, it didn't catch on because:

- It had all the problems of Electron in a time where memory was a much more of an issue

- Low quality documentation that didn't go into the details (although it had a great overview)

- Performance problems due to the high abstraction level and bad JS interpreter

- Memory leaking that appeared on several versions and disappeared on other versions, that randomly affected people and nobody could explain

All those problems got corrected eventually, but by then it was too late.

I remember trying to write something in it and the performance was atrocious, it used masses of memory and I hadn't even really done much. I wasn't anything like the developer I am now back then of course, I was an undergraduate CS student, but still... also yes, the documentation was awful! The experience for an Electron developer today is far superior with documentation, performance and all sorts so much better before you even start doing work on making it go fast.

I'll pause now for my regular appreciation of what the Visual Studio Code team have managed to do with Electron.

It didn't catch on because Mozilla never gave a shit about XULRunner, and they were clear about it.

In the late 2000's there were many companies who launched products based on XULRunner (Miro, Songbird, Joost, Tom-Tom...), but when they encountered bugs in the platform Mozilla's response was always "bug doesn't affect Firefox, we don't care". Even if you made a PR yourself (actually a patch at the time), good luck to get it merged if Firefox wasn't impacted.

Note that XULRunner was called this way but you didn't have to use XUL, you could use HTML for UI just like in Electron today.

If Mozilla saw the potential in their platform as a development platform for third party, it might still exist and have a bigger market share than Electron today. Maybe GitHub would have used it instead of developing electron, actually.

I have to agree... I'd wanted to use it for a few things in the early 00's, but the support just seemed absent.

> Back then people still thought Java would take off on the desktop.

You know, I find myself using a substantial amount of Java desktop software.

I license JetBrains products and earn part of my living using them. DBeaver is another frequently used tool. I've spent no small amount of time in Minecraft (the Java implementation.) Java desktop software even pops up in hobbies; SimSmith is one example.

There are others. Doubtless there will be more in the future. Are we all sure Java failed on the Desktop? It certainly didn't wipe out the competing paradigms, but it's still here and still seems to work pretty well for a lot of people. There aren't any Java web browsers, but then there aren't any C# or Python web browsers either, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software.

And then there's Android......

Java succeeded massively on the desktop, just not in quite the way people expected. We now run software that's written in Java without really knowing it's written in Java, with native wrappers and suchlike. Turns out the way to succeed is to hide, maybe.

After all, how many people know something like Slack is written with a web browser engine and a massive pile of JavaScript?

> but then there aren't any C# or Python web browsers either

There are python-webbrowsers, like qutebrowser for example. Unless you mean 100% and purely written just in python.

>, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software.

When people say "Java failed on the desktop", it's in relation to the initial massive hype in 1995 by Sun Microsystems as the "Microsoft evil empire killer". Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit.

There was a popular Java slogan back then of "write once, run anywhere"[1]. In other words, instead of writing desktop apps that specifically target the Win32 API, you write Java & Java byte code for the Java Virtual Machine. Instead of writing raw Javascript, code in Java to run as Java applets in the web browser. This was the same time period as the slogan "the network is the computer" that Oracle's Larry Ellison was also pushing. Both Sun and Oracle were trying to minimize Microsoft Windows' dominance with Java.

So yes, even though niche desktop software like JetBrains IDEs running on Java is a reality today, it is still somewhat of a failure when it's measured against the 1990s breathless promises.

It turns out that Java was much more successful on the server side. Ebay, Amazon, Google, etc all run tons of server-side Java. It is ironic that Javascript as the "toy" language to add a little dynamic interactivity to webpages over-achieved on the desktop while Java the "serious" language under-achieved its goals for the desktop.

[1] https://en.wikipedia.org/wiki/Write_once,_run_anywhere

> Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit.

I'm fully aware of the history. I was there and watched it unfold at the time. I also don't think it's terribly relevant; 1995 was a quarter century ago. Sun is dead. I'm just objectively counting the number of Java desktop programs I presently use and wondering if this supposed "failure" on the desktop isn't really just a widespread misconception. The software that I cited isn't riding the coattails of a 24 year old marketing campaign; they thrive of their own merit.

>I also don't think it's terribly relevant; 1995 was a quarter century ago.

It's relevant because the context of the conversation was this gp's quote you responded to: "Back then people still thought Java would take off on the desktop."

The "back then" is referencing XUL circa ~1997. And the "Java would take off" was the ambitious idea of most desktop apps being written in Java to weaken the MS Windows ecosystem. Not only was Java hyped to be a Microsoft killer, it was also touted to be a C/C++ killer. (E.g. the idea was that computer desktops have gotten so powerful with so many wasted cpu cycles that manual memory of C/C++ is obsolete and letting GC use the excess cpu to automatically manage memory is the future.) History has now shown us that prediction didn't happen either. C/C++ is still heavily used for new desktop apps. That's a different idea than today's 2019 landscape with some niche Java apps like Jetbrains IDEs.

I do understand your point. Yes, you can also have an alternative definition of "not a failure on desktop " because you can count some current Java apps today. That's also a valid perspective. However, for the sake of not confusing the conversation... that's not what the gp was originally talking about. I don't think there's any misconception about what "Java failed on the desktop" means -- especially among the HN audience. I also regularly use Jetbrains IDEA for Android deveopment and Webstorm for Javascript but my usage of those Java apps doesn't change what "Java failed on the desktop" means to other people.

Yes, I moved the goal posts making my point. I believe the storied history of Java clouds the contemporary reality of Java too much, to the point where one can argue Java "failed on the desktop" specifically among people that spend a good fraction of their waking hours using Java desktop software, and I appear to be one of the few that notices this irony.

An app I use called Zotero uses XUL, though I believe they're trying to transition to Electron. It seemed like a potentially robust platform, but damn if I couldn't figure how it worked enough to even contribute a minor fix.

I think Zotero started out as a Firefox extension, and when Firefox deprecated those in favor of the new-style WebExtensions they saw the writing on the wall and converted it to a standalone XUL application.

The same team behind Zotero has another newer application called tropy (https://tropy.org/), which is based on Electron, and apparently they were happy with that and are indeed planning to transition Zotero to Electron as well.

> I think Zotero started out as a Firefox extension, and when Firefox deprecated those in favor of the new-style WebExtensions they saw the writing on the wall and converted it to a standalone XUL application.

To add a bit more detail / a slight correction: Zotero did indeed start purely as a Firefox extension, but Zotero Standalone was released in 2011[0], far before the switch to WebExtensions. For a while, the Firefox extension and Zotero standalone were equally featured — i.e. you could use just the Firefox extension, or use Zotero standalone + the Chromium connector extension, and in both cases you'd get the same functionality. After the switch to WebExtensions, the Firefox extension was reduced to being purely a connector, just like the Chromium one.

[0] https://en.wikipedia.org/wiki/Zotero#Zotero_Standalone

Neat. Hadn't heard of Tropy

I built some personal desktop apps with XUL(Runner) ~ a decade ago, it was fun to use web technologies (markup, JS, CSS, web browser view with relaxed security etc) to create a cross-platform executable. I have recently played with Electron and got the impression that it barely scratches the surface of what was possible back then but makes up for this thanks to the advancements in JS performance & ES6 syntax, CSS features (like flex, which was part of XUL) and the huge ecosystem of third party libraries.

I learned Smalltalk in the 1980s as a middle school student. There was always the hope that Smalltalk would actually take off...

Ironically, the use of the browser as the target for programming has, slowly, haltingly, and through nearly-infinite compromises and kludges, actually provided the working platform Smalltalk promised us Gen-Xers when we dabbled in programming as kids. I think it's ultimately for the best, even if not the ideal path to have gotten there...

For years I used Komodo IDE, which is (was?) written using XUL — writing plugins for it was a breeze even though the docs were a little lacking, because JavaScript and XUL got me exploring easily. I miss that editor. Now everyone’s moving away from it. Ahead of its time indeed!

Ah, Komodo! I wrote a bunch of extensions for it [1][2][3] that got me started with XUL. I loved both. XUL always felt like every feature you can think of was available and thoroughly thought out, you just had to discover it (not always straightforward given how lacking the documentation was, especially for internal/private APIs). XUL was way ahead of its time.

[1] https://github.com/StanAngeloff/komodo-html-toolkit [2] https://github.com/StanAngeloff/komodo-fuzzy-open [3] https://github.com/StanAngeloff/komodo-aero-theme

And ultimately a huge waste of time. It set back Netscape and Firefox development for several years. Meanwhile IE6 took over, leading to the web dark ages while Mozilla reinvented the world.

For more details there is the famous Spolsky post about things you should never do—rewrite a product from scratch. Mozilla went one further and tried to reinvent GUI programming as well as building a new product.

It's famous that Mozilla and Firefox went through many rewrites and stalled progress. But I don't think you can blame that for IE6. Some amount of that is due to the Windows monopoly and that it was preinstalled.

The blame is not for the monopoly exactly. Rather the reason IE dev stagnated for five years. With no competition and WWI over, MS retired the team.

Right, so, in that period, IE stagnated, and so did Mozilla. But IE was the dominant stagnant browser and not Mozilla or Firefox. That's somewhat on the monopoly.

In much of those days I used Netscape 4.x and it really wasn't much worse than IE. Then I used pre-1.0 Mozilla and various forks, and early firefox, they were all pretty acceptable for the time. The big issue was that all the content was authored for IE and not tested anywhere else. Monopoly.

Yep, I used Communicator for many years. But it always drove me nuts that it couldn’t resize the window without redoing the whole page from scratch. The new Mozilla browser took years to stabilize. It was frustrating chapter for the web... the bad old days.

Sounds like a superior version of anything electron. I used apps built in it extensively and electron doesn't compare.

So is Thunderbird still using XUL or not?

If yes it's only a matter of time until it transitions away from it too.

Likely only because it doesn't see enough attention to be migrated.

Yes and so is Firefox. So far they only removed XBL not XUL, and while they are slowly migrating things to HTML most of the UI is still XUL.

I worked on an application based on XULRunner for a couple of years and I do miss it sometimes. The mixture of (in our case) C++ based XPCOM, mixed with JS and XPIDL fine to work with.

What I wonder thoug is whether that company was able to migrate of it already or not...

Evergreen ILS used the heck out of this XULRunner

Reply on news.ycombinator.com