Is the issue of platform support just packaging/installation?


I have to ask this just out of personal curiosity. I am presuming that Linux and Windows support just involves packaging up an installer for those platforms? I ask this because I think the idea of a full stack web-based installed application is awesome. Of course a big part of this promise is easy portability, perhaps even close to free portability.

Am I correct here, or is there something else in the core that is platform-native? Really interesting stuff.


I don’t work at Github so I’m not as familiar with Atom as they are and I would never call myself an expert, so take the following with a grain of salt, but I’ll try to explain it to the best of my knowledge.

It’s a bit more than just packaging. The lion share of the code can run on all platforms, but a small percentage is platform dependent. Some of the node.js modules Atom uses are written in C++ (some are even bindings to Objective-C code from Cocoa which is only available on OSX), so they have to be written with the platform and libraries available on that platform in mind. The spell-checking module for example uses the native NSSpellChecker on OSX and the Hunspell library on Windows and Linux.

Then there’s things like different directory structure and limitations of some operating systems that also apply to the JavaScript/CoffeeScript portion of the code, so even though the CoffeeScript/JavaScript code runs on all platforms, you need to write different code for each platform when it comes to the file system and a few other things.

In quite a lot of places, the Atom core already has if…else constructs in place that make Atom do different things if Atom is running on OSX or Windows, but I’ve seen a few places were it seems to be missing and it looks like there is even more missing when it comes to Linux, but that might just be because Windows and OSX are much more different than Linux and OSX are, I’ve only given the code a cursory glance so far. If you want to check these cases in Atom out, look for lines with process.platform in the .js files.

And then there’s of course always bugs. Even though Chromium does try to make everything work the same on all platforms for the most part, there do tend to be bugs now and then were something doesn’t work on one platform as it should (or doesn’t work at all), so you still have to try everything out on all platforms to verify that it works right and that takes time, especially if you have to write workarounds for these problems until they get fixed upstream. It’s not nearly as much work as having to support multiple web browsers in a web app, but still, it means that you can’t just assume it’ll work everywhere.

All in all, I think it’s not that much different from writing an app using Qt or GTK in combination with a high level language like Ruby or Python, so I wouldn’t call portability one of it’s huge advantages over other cross platform technologies. Qt for example works on more platforms than Chromium, although JavaScript runs everywhere, so if you replaced Chromium you could make the code much more portable.

The biggest advantage I think is that you can use JavaScript, CSS and HTML to extend and modify the app, technologies that most programmers are familiar with at least a little, that are very powerful and (for the most part) easy to use and let you get stuff done quickly. And as for JavaScript in general, it has become one of the fastest languages out there (according to benchmarks it’s faster than Ruby and Python by orders of magnitude) and lots of languages can compile to it, so it’s a good choice when it comes to high level languages.


I would imagine much of it would be between integration (ui/menus/etc) and wanting to limit the user base (somewhere else I read they said they already have all they can handle with OSX)

I doubt however the modules are the issue (vs the core runtime). In trying (unsuccessfully) to get it running under node-webkit/linux (don’t own a mac); I was able to compile/rebuild dependencies without issue after a few tweaks. apm also works well on linux, though they package it with an OSX binary of node 0.11 (easy enough to swap out).

there’s process.atomBinding they use that I’m guessing is what ties into their API under there chromium/node build that looks to tie into things like screen, dialogs, clipboard, etc… those would most likely need to be ported over. (only guessing, haven’t dug into their usage enough yet to really tell)

IMO it’s a decision to focus on one platform with the resources they have, and then port it and make it cross-platform at some point in the future. I cannot say I agree completely, but many projects are single platform for at least some time to get the core functionality down before expending resources delivering to multiple platforms.

As stated above, if they have bindings into things like Cocoa as part of the core, those bindings will need equivalents in the other platforms to get everything running.