8 ms·

The State of Desktop Applications in Node.js

138 points by callum85 12y ago

callum85 12y ago
Last time I tried building a 'blank' node-webkit app for OS X (using https://github.com/Dica-Developer/generator-node-webkit https://github.com/Dica-Developer/generator-node-webkit), the resulting .app came to ~100MB. Does anyone know the base size for an atom-shell app?
- mcs 12y ago
  The flat packages you would most likely distribute for the application come in around 30mB for me.
- FooBarWidget 12y ago
  Seriously, does anybody nowadays care about a 100 MB desktop app? I developed my first app in 1997 with Delphi and it was only 200 KB, so from that perspective I always cringe when I see that an app I've developed is multiple MB. But in all seriousness, do users actually care? Every time I download an OS X app, it's at least 50 MB, but I find that even I don't care anymore because downloading 50 MB nowadays only takes 10 seconds, and my machine has more than enough RAM to load all the bundled libraries. We are in an age where people deploy VM images and Docker containers that are many hundred megabytes, and it seems people are happy that way. The alternative is not making apps self-contained, but instead to make them rely on shared libraries. This is much more efficient, but apart from a few neckbeards who cry "bloat" it seems that most people care more about avoiding dependency hell and ease of use, even if that means large packages due to library duplication.
  - callum85 12y ago
    I would agree with you if you were talking about 20MB. I think that would be my threshold for not caring about how big an app is, i.e. even if it's something really basic like a countdown timer app I would be OK with it being up to 20MB, because as you say, connections are fast and space is cheap. But 100MB? I don't know.
    - jiggy2011 12y ago
      You could install more than 1000 apps on a moderate SSD at 100MB each. How many apps does the average person have installed?
      - callum85 12y ago
        It's nothing to do with how much space it will take up. The problem is that, as a user, I would be very suspicious of a 100MB countdown timer app. I would think that either it's got some kind of adware in it, or just that it's incompetently designed.
        Carrok 12y ago
        >as a user, I would be very suspicious of a 100MB countdown timer app You mean as a developer. Your average 'user' does not know or care how big an app 'should' be.
        callum85 12y ago
        I disagree. App file sizes are displayed in app stores because many users care about them. A significant number of users would notice an app being dramatically larger than it ought to be. I've seen a lot of reviews like "why the hell this app over 100mb??!!1". There is a huge spectrum of technical competence between "I don't have any sense of what a megabyte is" and "Developer".
      - cyorir 12y ago
        My laptop has a 256GB SSD. My media collection is 337GB. So a 100MB app doesn't just need to compete with other 100MB apps, it has to compete with my music, videos, and photos. Is a 100MB app better than my photos reminding me of my time in Sapporo, Japan? That depends on the app, but I'm more inclined to delete a 100MB app to make room for more photos than a 20MB app.
        jiggy2011 12y ago
        If your media is 337GB then you must already be storing it somewhere other than your 256GB SSD! Besides, does it matter much if you delete an app when it can be downloaded again in a matter of minutes?
  - kyllo 12y ago
    I can confirm that I don't use Atom because of the overhead of the browser engine. It takes about 30 seconds to launch, and it hangs frequently, which to me is unacceptable for a program that edits plain text files.
    - evilduck 12y ago
      30 seconds to launch!? Are you running it on a RaspberryPi or something? On my MBP, it launches about as fast as SublimeText3, 1-2 seconds tops.
      - kyllo 12y ago
        Lenovo ThinkPad T440 running Windows 7 (not by choice, standard issue for my work). I just launched it and timed it at 28 seconds. Then I closed it and launched it again and it took 3 seconds, so I assume there's some sort of caching going on. But basically Atom is too slow and bloated for what I need it for, which is just editing text files, CSV files, XML files etc. Sometimes I really need the multi-line cursors for a CSV though, and I'll use ST2 for that, as it seems a little snappier than Atom, although it also takes a little while to start up. When I write code, I use Eclipse if it's Java (for work) or emacs for everything else (personal projects). I think I'm just going to install emacs on my work machine and start using it for all my text editing needs though.
  - hamoid 12y ago
    Our connections and cpus get faster, our memories and hard drives larger, but then we write slower and bigger software to compensate. It reminds me of Newton's third law: "For every action, there is an equal and opposite reaction."
  - boracay 12y ago
    Of course. The world is bigger than SV :P http://blog.chriszacharias.com/page-weight-matters http://blog.chriszacharias.com/page-weight-matters
mid-kid 12y ago
The web wasn't made to be used as a desktop app replacement, and it will never be. Quit trying to make it that way, and start using a widget toolkit like you should. Hell, if you love html/js so much, there's a big chance you won't dislike QML. The web is for sharing content, not for games, text editors, and all that stuff. I see google trying to blur the lines between that, but why is it necessary? Just because people are too lazy to adapt themselves to the platform they're writing for, and allow them to create slow, shitty "web apps"?
- nawitus 12y ago
  >I see google trying to blur the lines between that, but why is it necessary? So that people don't need to install, maintain or update applications, and can access them everywhere in the world using just a web browser? And because they're also more secure than traditional applications that you need to install on your PC?
  - depr 12y ago
    That applies to Google's apps, but not to these Node desktop apps.
  - mempko 12y ago
    Having apps magically always update without user consent is developer friendly, but not user friendly. Have you ever used a web app that changed in ways you didn't like?
    - nawitus 12y ago
      I'd say "not always user friendly". There are of course drawbacks with web apps.
- depr 12y ago
  Also, if you're making a desktop app you don't have to use HTML/JS, why on earth would you use those if you don't absolutely have to?
Rauchg 12y ago
Check out thrust as well: https://github.com/breach/thrust https://github.com/breach/thrust multi-platform and easily bindable to any language
- rdtsc 12y ago
  That looks promising. It is used for Breach but are there any other users?
mnkypete 12y ago
There is also a quick way to start a new application with Atom: https://github.com/atom/atom-shell-starter https://github.com/atom/atom-shell-starter
rrdharan 12y ago
This article doesn't accurately convey the state of Chrome Applications. There's actually a much richer way to build apps that have a more native look and feel, including their own branded top-level window with fewer of the limitations the author cites. https://developer.chrome.com/apps/about_apps https://developer.chrome.com/apps/about_apps
- evv 12y ago
  The article's title is "The State of Desktop Applications in Node.js", and chrome applications do not let you run node.js on the local machine. If you can't run your own userland code on the machine and talk to hardware, then you can hardly call it a desktop app. Google wants to keep you locked in their sandbox.
  - juliangregorian 12y ago
    I don't know, they seem to tout interfacing with network and hardware pretty heavily.
zzzcpan 12y ago
Related question: what are the other ways to build a desktop application on Linux that works on Linux, Windows and OSX on slow machines, like intel atom, and doesn't require anything from the user?
- pavlov 12y ago
  Qt is great for this. It's used by lots of desktop applications, from small open source tools to large commercial content creation apps like Maya. http://qt-project.org/ http://qt-project.org/ It does have a substantial learning curve. The traditional desktop stuff is all C++. The new mobile stuff is easier to develop, with a nice declarative UI system and JavaScript, but it's not applicable if you want native-feeling desktop widgets.
- ksherlock 12y ago
  Qt, WxWidgets, SDL, zoolib, Java (I guess that require something), python [http://docs.python-guide.org/en/latest/scenarios/gui/ http://docs.python-guide.org/en/latest/scenarios/gui/]
- toddan 12y ago
  Gtk works on all those plattforms. But your application will have an Gtk look and feel. If java is acceptabel i would look into JavaFX.
snide 12y ago
We ended up building Mac and Windows apps for http://www.webhook.com http://www.webhook.com built on a Node / Chromium shells. Essentially we're a Wordpress competitor, but Node powered, and wanted to provide a simple one-click install for people that didn't know how to work their command line or how to install Node properly. This solution ended up working great. It basically allowed us to build a non-destructive sandbox dev environment for them that had a UI experience similar to the CMS itself. Better yet, the app points to hosted JS and CSS files so really there's never a need to "update" the app. When we have feature or bug changes, we just push out new files and everything just works. This kind of stuff isn't for all apps, but for our use case it was almost too good to be true. We built everything out in about two to three weeks. I don't know how long it would have taken for us to do something similar with true Desktop tooling. Here's a video of the end result in case anyone in interested... https://vimeo.com/108922566 https://vimeo.com/108922566
- ncphillips 12y ago
  Super cool!
- thoughtpalette 12y ago
  That is awesome!
- callum85 12y ago
  This is great. Did you use node-webkit?
pjmlp 12y ago
2014, still catching up with the desktop. If one really really wants to use JavaScript, at least make use of QML or Nashorn/JavaFX.
- woah 12y ago
  Just for the delicious pain of Java development?
  - pjmlp 12y ago
    Java development is pure pleasure when compared with web development.
    - mateuszf 12y ago
      Usually said by Java developer not understanding JavaScript.
      - penprog 12y ago
        You see, I barely need to "understand" Java to use it and get decent and performant code but I need to be a javascript expert to be able to do anything not horrible. Please stop trying to act like the state of web and javascript is good because it's shit. Web development is basically a bunch of people suffering from stockholm syndrome.
        woah 12y ago
        You've coded a lot in languages very similar to Java and that is an argument for Java's ease of use?
        penprog 12y ago
        My argument was that the idea of having to work on a javascript project with >10,000 lines of code makes me want to vomit while the idea of working on a java project with >1,000,000 lines of code doesn't make me feel anything special. People that complain about verbosity really don't have their priorities in line
echoless 12y ago
I've played around with both node-webkit and atom-shell, and I prefer atom-shell over node-webkit, due to some minor inconveniences with node-webkit. * When an error occurs in node-webkit, it loads an error page instead of simply logging it to the console like normal web pages. Even after fixing the error and hitting reload or navigating back, the page doesn't go away. You need to manually enter the url(copy/paste doesn't work). * I don't know if this is something that was my fault or the app's, but when I made a call to a sqlite3 database using the node-pure-sqlite3 gem, it would take around 3 seconds to execute. With atom-shell it would take less than a second. * The developer console is a separate window from the application in node-webkit. I prefer having a single window hold both the app and dev console during development(which atom shell-allows).
- ep103 12y ago
  completely clueless programmer checking in. How is atom's performance? The one app I tried that used it was always slow and cludgy...
  - echoless 12y ago
    For DOM performance, they are pretty much identical. Both use Chrome(each uses a different version though, usually atom-shell uses more recent versions). For performance of node.js calls, I haven't run any benchmarks, so I cannot help you there. However subjectively, both felt about the same to me(except in the node-sqlite-purejs case).
doublerebel 12y ago
There are a number of ways to make desktop apps with JS. TideKit/TideSDK uses V8 IIRC. On Linux, Gnome has the GJS API. Tint and Quaxe are two more promising newcomers. All of these use a JS engine to create native platform UI controls. So for anyone who thinks JS is limited to webviews, you missed the boat. Thousands and thousands of native apps are already created and shipped on a JS core. The async nature of UI and I/O makes JS a perfect fit, so I expect this trend to only continue and the tools to improve. It's so much faster and more efficient to create using JS than "native" languages, it's a no-brainer for any business who has a dev with this experience.
one-more-minute 12y ago
The post mentions Light Table as a node-webkit user, so I'll mention that we're actually in the process of moving to atom-shell [1]. After having some issues with NW we found that atom-shell gave us a more suitable architecture and some nice desktop integration features for only a few days work. The multi-process model is definitely more complex and probably not for everyone, but it's working really well for us so far. [1] https://github.com/LightTable/LightTable/pull/1756 https://github.com/LightTable/LightTable/pull/1756
benjismith 12y ago
I've been using node-webkit for the past 18 months or so, and it's been absolutely delightful. One thing this article gets slightly wrong is this sentence: "This means that Node.js modules must exclusively use functions and classes provided by Node.js or modules from npm, as the DOM is off limits." This might be technically true, but there's an easy enough workaround: 1) Use a script tag to include jQuery in the index.html page 2) Pass the jQuery object ($) as a dependency into a node module. 3) Profit. I regularly modify the DOM from node context using this pattern.
teleclimber 12y ago
If you are targeting Mac only and don't depend on Node an alternative would be MacGap: http://macgapproject.github.io/ http://macgapproject.github.io/ The packaged app is tiny compared to a chromium+Node shell app.
edem 12y ago
Try out the new StarUML beta. I was surprised to see that it uses node.
abimaelmartell 12y ago
~100 MB for a hello world...
tyrion 12y ago
Is there some way to have a "Firefox shell" instead of a Chrome/Chromium shell?
- jamii 12y ago
  https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XU... I'm not sure if it's still actively developed though.

138 points by callum85 12y ago

Last time I tried building a 'blank' node-webkit app for OS X (using https://github.com/Dica-Developer/generator-node-webkit https://github.com/Dica-Developer/generator-node-webkit), the resulting .app came to ~100MB. Does anyone know the base size for an atom-shell app?

mcs 12y ago
The flat packages you would most likely distribute for the application come in around 30mB for me.
FooBarWidget 12y ago
Seriously, does anybody nowadays care about a 100 MB desktop app? I developed my first app in 1997 with Delphi and it was only 200 KB, so from that perspective I always cringe when I see that an app I've developed is multiple MB. But in all seriousness, do users actually care? Every time I download an OS X app, it's at least 50 MB, but I find that even I don't care anymore because downloading 50 MB nowadays only takes 10 seconds, and my machine has more than enough RAM to load all the bundled libraries. We are in an age where people deploy VM images and Docker containers that are many hundred megabytes, and it seems people are happy that way. The alternative is not making apps self-contained, but instead to make them rely on shared libraries. This is much more efficient, but apart from a few neckbeards who cry "bloat" it seems that most people care more about avoiding dependency hell and ease of use, even if that means large packages due to library duplication.
- callum85 12y ago
  I would agree with you if you were talking about 20MB. I think that would be my threshold for not caring about how big an app is, i.e. even if it's something really basic like a countdown timer app I would be OK with it being up to 20MB, because as you say, connections are fast and space is cheap. But 100MB? I don't know.
  - jiggy2011 12y ago
    You could install more than 1000 apps on a moderate SSD at 100MB each. How many apps does the average person have installed?
    - callum85 12y ago
      It's nothing to do with how much space it will take up. The problem is that, as a user, I would be very suspicious of a 100MB countdown timer app. I would think that either it's got some kind of adware in it, or just that it's incompetently designed.
      - Carrok 12y ago
        >as a user, I would be very suspicious of a 100MB countdown timer app You mean as a developer. Your average 'user' does not know or care how big an app 'should' be.
        callum85 12y ago
        I disagree. App file sizes are displayed in app stores because many users care about them. A significant number of users would notice an app being dramatically larger than it ought to be. I've seen a lot of reviews like "why the hell this app over 100mb??!!1". There is a huge spectrum of technical competence between "I don't have any sense of what a megabyte is" and "Developer".
    - cyorir 12y ago
      My laptop has a 256GB SSD. My media collection is 337GB. So a 100MB app doesn't just need to compete with other 100MB apps, it has to compete with my music, videos, and photos. Is a 100MB app better than my photos reminding me of my time in Sapporo, Japan? That depends on the app, but I'm more inclined to delete a 100MB app to make room for more photos than a 20MB app.
      - jiggy2011 12y ago
        If your media is 337GB then you must already be storing it somewhere other than your 256GB SSD! Besides, does it matter much if you delete an app when it can be downloaded again in a matter of minutes?
- kyllo 12y ago
  I can confirm that I don't use Atom because of the overhead of the browser engine. It takes about 30 seconds to launch, and it hangs frequently, which to me is unacceptable for a program that edits plain text files.
  - evilduck 12y ago
    30 seconds to launch!? Are you running it on a RaspberryPi or something? On my MBP, it launches about as fast as SublimeText3, 1-2 seconds tops.
    - kyllo 12y ago
      Lenovo ThinkPad T440 running Windows 7 (not by choice, standard issue for my work). I just launched it and timed it at 28 seconds. Then I closed it and launched it again and it took 3 seconds, so I assume there's some sort of caching going on. But basically Atom is too slow and bloated for what I need it for, which is just editing text files, CSV files, XML files etc. Sometimes I really need the multi-line cursors for a CSV though, and I'll use ST2 for that, as it seems a little snappier than Atom, although it also takes a little while to start up. When I write code, I use Eclipse if it's Java (for work) or emacs for everything else (personal projects). I think I'm just going to install emacs on my work machine and start using it for all my text editing needs though.
- hamoid 12y ago
  Our connections and cpus get faster, our memories and hard drives larger, but then we write slower and bigger software to compensate. It reminds me of Newton's third law: "For every action, there is an equal and opposite reaction."
- boracay 12y ago
  Of course. The world is bigger than SV :P http://blog.chriszacharias.com/page-weight-matters http://blog.chriszacharias.com/page-weight-matters

mid-kid 12y ago

The web wasn't made to be used as a desktop app replacement, and it will never be. Quit trying to make it that way, and start using a widget toolkit like you should. Hell, if you love html/js so much, there's a big chance you won't dislike QML. The web is for sharing content, not for games, text editors, and all that stuff. I see google trying to blur the lines between that, but why is it necessary? Just because people are too lazy to adapt themselves to the platform they're writing for, and allow them to create slow, shitty "web apps"?

nawitus 12y ago
>I see google trying to blur the lines between that, but why is it necessary? So that people don't need to install, maintain or update applications, and can access them everywhere in the world using just a web browser? And because they're also more secure than traditional applications that you need to install on your PC?
- depr 12y ago
  That applies to Google's apps, but not to these Node desktop apps.
- mempko 12y ago
  Having apps magically always update without user consent is developer friendly, but not user friendly. Have you ever used a web app that changed in ways you didn't like?
  - nawitus 12y ago
    I'd say "not always user friendly". There are of course drawbacks with web apps.
depr 12y ago
Also, if you're making a desktop app you don't have to use HTML/JS, why on earth would you use those if you don't absolutely have to?

Rauchg 12y ago

Check out thrust as well: https://github.com/breach/thrust https://github.com/breach/thrust multi-platform and easily bindable to any language

rdtsc 12y ago
That looks promising. It is used for Breach but are there any other users?

mnkypete 12y ago

There is also a quick way to start a new application with Atom: https://github.com/atom/atom-shell-starter https://github.com/atom/atom-shell-starter

rrdharan 12y ago

This article doesn't accurately convey the state of Chrome Applications. There's actually a much richer way to build apps that have a more native look and feel, including their own branded top-level window with fewer of the limitations the author cites. https://developer.chrome.com/apps/about_apps https://developer.chrome.com/apps/about_apps

evv 12y ago
The article's title is "The State of Desktop Applications in Node.js", and chrome applications do not let you run node.js on the local machine. If you can't run your own userland code on the machine and talk to hardware, then you can hardly call it a desktop app. Google wants to keep you locked in their sandbox.
- juliangregorian 12y ago
  I don't know, they seem to tout interfacing with network and hardware pretty heavily.

zzzcpan 12y ago

Related question: what are the other ways to build a desktop application on Linux that works on Linux, Windows and OSX on slow machines, like intel atom, and doesn't require anything from the user?

pavlov 12y ago
Qt is great for this. It's used by lots of desktop applications, from small open source tools to large commercial content creation apps like Maya. http://qt-project.org/ http://qt-project.org/ It does have a substantial learning curve. The traditional desktop stuff is all C++. The new mobile stuff is easier to develop, with a nice declarative UI system and JavaScript, but it's not applicable if you want native-feeling desktop widgets.
ksherlock 12y ago
Qt, WxWidgets, SDL, zoolib, Java (I guess that require something), python [http://docs.python-guide.org/en/latest/scenarios/gui/ http://docs.python-guide.org/en/latest/scenarios/gui/]
toddan 12y ago
Gtk works on all those plattforms. But your application will have an Gtk look and feel. If java is acceptabel i would look into JavaFX.

snide 12y ago

We ended up building Mac and Windows apps for http://www.webhook.com http://www.webhook.com built on a Node / Chromium shells. Essentially we're a Wordpress competitor, but Node powered, and wanted to provide a simple one-click install for people that didn't know how to work their command line or how to install Node properly. This solution ended up working great. It basically allowed us to build a non-destructive sandbox dev environment for them that had a UI experience similar to the CMS itself. Better yet, the app points to hosted JS and CSS files so really there's never a need to "update" the app. When we have feature or bug changes, we just push out new files and everything just works. This kind of stuff isn't for all apps, but for our use case it was almost too good to be true. We built everything out in about two to three weeks. I don't know how long it would have taken for us to do something similar with true Desktop tooling. Here's a video of the end result in case anyone in interested... https://vimeo.com/108922566 https://vimeo.com/108922566

ncphillips 12y ago
Super cool!
thoughtpalette 12y ago
That is awesome!
callum85 12y ago
This is great. Did you use node-webkit?

pjmlp 12y ago

2014, still catching up with the desktop. If one really really wants to use JavaScript, at least make use of QML or Nashorn/JavaFX.

woah 12y ago
Just for the delicious pain of Java development?
- pjmlp 12y ago
  Java development is pure pleasure when compared with web development.
  - mateuszf 12y ago
    Usually said by Java developer not understanding JavaScript.
    - penprog 12y ago
      You see, I barely need to "understand" Java to use it and get decent and performant code but I need to be a javascript expert to be able to do anything not horrible. Please stop trying to act like the state of web and javascript is good because it's shit. Web development is basically a bunch of people suffering from stockholm syndrome.
      - woah 12y ago
        You've coded a lot in languages very similar to Java and that is an argument for Java's ease of use?
        penprog 12y ago
        My argument was that the idea of having to work on a javascript project with >10,000 lines of code makes me want to vomit while the idea of working on a java project with >1,000,000 lines of code doesn't make me feel anything special. People that complain about verbosity really don't have their priorities in line

echoless 12y ago

I've played around with both node-webkit and atom-shell, and I prefer atom-shell over node-webkit, due to some minor inconveniences with node-webkit. * When an error occurs in node-webkit, it loads an error page instead of simply logging it to the console like normal web pages. Even after fixing the error and hitting reload or navigating back, the page doesn't go away. You need to manually enter the url(copy/paste doesn't work). * I don't know if this is something that was my fault or the app's, but when I made a call to a sqlite3 database using the node-pure-sqlite3 gem, it would take around 3 seconds to execute. With atom-shell it would take less than a second. * The developer console is a separate window from the application in node-webkit. I prefer having a single window hold both the app and dev console during development(which atom shell-allows).

ep103 12y ago
completely clueless programmer checking in. How is atom's performance? The one app I tried that used it was always slow and cludgy...
- echoless 12y ago
  For DOM performance, they are pretty much identical. Both use Chrome(each uses a different version though, usually atom-shell uses more recent versions). For performance of node.js calls, I haven't run any benchmarks, so I cannot help you there. However subjectively, both felt about the same to me(except in the node-sqlite-purejs case).

doublerebel 12y ago

There are a number of ways to make desktop apps with JS. TideKit/TideSDK uses V8 IIRC. On Linux, Gnome has the GJS API. Tint and Quaxe are two more promising newcomers. All of these use a JS engine to create native platform UI controls. So for anyone who thinks JS is limited to webviews, you missed the boat. Thousands and thousands of native apps are already created and shipped on a JS core. The async nature of UI and I/O makes JS a perfect fit, so I expect this trend to only continue and the tools to improve. It's so much faster and more efficient to create using JS than "native" languages, it's a no-brainer for any business who has a dev with this experience.

one-more-minute 12y ago

The post mentions Light Table as a node-webkit user, so I'll mention that we're actually in the process of moving to atom-shell [1]. After having some issues with NW we found that atom-shell gave us a more suitable architecture and some nice desktop integration features for only a few days work. The multi-process model is definitely more complex and probably not for everyone, but it's working really well for us so far. [1] https://github.com/LightTable/LightTable/pull/1756 https://github.com/LightTable/LightTable/pull/1756

benjismith 12y ago

I've been using node-webkit for the past 18 months or so, and it's been absolutely delightful. One thing this article gets slightly wrong is this sentence: "This means that Node.js modules must exclusively use functions and classes provided by Node.js or modules from npm, as the DOM is off limits." This might be technically true, but there's an easy enough workaround: 1) Use a script tag to include jQuery in the index.html page 2) Pass the jQuery object ($) as a dependency into a node module. 3) Profit. I regularly modify the DOM from node context using this pattern.

teleclimber 12y ago

If you are targeting Mac only and don't depend on Node an alternative would be MacGap: http://macgapproject.github.io/ http://macgapproject.github.io/ The packaged app is tiny compared to a chromium+Node shell app.

edem 12y ago

Try out the new StarUML beta. I was surprised to see that it uses node.

abimaelmartell 12y ago

~100 MB for a hello world...

tyrion 12y ago

Is there some way to have a "Firefox shell" instead of a Chrome/Chromium shell?

jamii 12y ago
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XU... I'm not sure if it's still actively developed though.