Share this post

Link to post

Share on other sites

I've been looking at whether it would be possible, but I think the only way would be to distribute the Node binary with the workflow.

The list of supported languages are all installed by default on Mac OS, but Node needs to be installed manually. You could just assume that it is installed and provide instructions to users that they must install it, but this isn't a great user experience and many people won't be able to do it.

To allow Node scripts in Alfred would require distributing Node.js which is 10MB. Considering most workflows seem to be < 100KB, it seems unreasonable to include it with one, especially if multiple workflows are all going to require it. Alfred 2.0 is also 4.6MB (uncompressed) so I doubt Andrew wants to include it by default.

It is possible to write a system to run JavaScript plugins using JavaScriptCore which is included in Mac OS, I'm actually writing one myself for another project, but the downside of this solution is that it is not a Node environment. You don't get NPM, no Node modules will work, and all the file system/http/etc APIs need to be written from scratch. This is a huge amount of work in itself and as Bash, Python, Ruby and PHP are available there is really very little to be gained from this work.

Python and Ruby are good languages with great communities, lots of documentation, support, and libraries that have already been written. I highly recommend them as an alternative to JavaScript.

Share this post

Link to post

Share on other sites

Just to further support what Dan said, the choice of languages / interpreters was made based on things that were installed by default in OS X. Additional language/interpreter support won't be included with Alfred's installation because, as was also pointed out, some users may not want things like that automatically installed on their system.

Share this post

Link to post

Share on other sites

I think this is a great idea. Downloading Node seamlessly in the background when the first Node-requiring workflow gets installed would be the perfect solution.

Imagine the possibilities here: attracting developers used to JavaScript/Node (this is definitely the no1 reason I haven't developed any workflows myself) and equipping developers with the power of the massive amounts of libraries available for the platform.

Share this post

Link to post

Share on other sites

Or they could just learn Python. It's already installed on the system, has far more available libraries than node.js, and is trivial to learn for anyone familiar with programming. The same applies to Ruby. Or PHP.

Node's advantages as a platform are almost entirely irrelevant in the context of workflows.

Share this post

Link to post

Share on other sites

You can do (3) by selecting bash as the interpreter and using /usr/local/bin/ruby myscript.rb. I tend to do this in any case, even when I'm using the system installation 'cos I prefer to keep the code together in source files, not in info.plist.

I don't think Alfred "blessing" the install of additional runtimes is a very good idea. It would either lead to a bloated Alfred install (it'd have to install its own private versions to prevent breaking folks' stuff) or, as Dan Palmer pointed out, 10+ MB workflows.

There are already 7 options, and if you want to use a different runtime, you can do that today.

There's no reason why someone couldn't make a "library" workflow that contains a node.js (or whatever) install and other workflows could use that via the bash option and ../node.js/node SuperCool.js.

Share this post

Link to post

Share on other sites

Or they could just learn Python. It's already installed on the system, has far more available libraries than node.js, and is trivial to learn for anyone familiar with programming. The same applies to Ruby. Or PHP.

Node's advantages as a platform are almost entirely irrelevant in the context of workflows.

To dredge up an old thread, NPM has nearly double the number of packages available than Python, and indeed more than Ruby now. I agree with the sentiment though, no need to add additional languages, just call your script via bash.