What JS engine is Alfred using?

[pier]

I'm wondering what kind of features are available in the JS engine used by Alfred.

 

Can we use ES6, async/await, fetch(), etc?

[deanishe]

The engine is whichever version of JavaScriptCore that JXA (JavaScript for Automation) uses on your system.

 

Here's a list of ES6 features in JXA.

Edited April 15, 2017 by deanishe

[pier]

Thanks @deanishe

 

It would be awesome if Alfred provided an easy to distribute workflows that use Node instead.

[vitor]

41 minutes ago, pier said:

It would be awesome if Alfred provided an easy to distribute workflows that use Node instead.

 

Node.js’ pkg installer alone is seven times the size of the Alfred dmg/twice the size of Alfred.app. Not to mention the amount of technical work that would require to integrate it with Alfred and keep it apart from the node on the system (if any) and (insert a bunch of other limitations and disadvantages).

[deanishe]

1 hour ago, pier said:

It would be awesome if Alfred provided an easy to distribute workflows that use Node instead.

 

Alfred doesn't provide a way to distribute any workflows, let alone ones that depend on languages that aren't a standard part of macOS.

 

If Node is your thing, then there's Alfy by @sindresorhus, which has mechanisms for distributing and installing workflows via npm.

 

There are several reasons why that's a bad idea, but it's there if you want it.

[pier]

2 hours ago, vitor said:

 

Node.js’ pkg installer alone is seven times the size of the Alfred dmg/twice the size of Alfred.app. Not to mention the amount of technical work that would require to integrate it with Alfred and keep it apart from the node on the system (if any) and (insert a bunch of other limitations and disadvantages).

 

Yes I'm aware of that. I'm not suggesting Node should come bundled with Alfred by default. Workflows could define a Node dependency so that Alfred could install it for the user.

 

As for the technical work I really can't say how intricate it would be but other projects like Electron have already solved that.

 

2 hours ago, deanishe said:

Alfred doesn't provide a way to distribute any workflows, let alone ones that depend on languages that aren't a standard part of macOS.

 

But Alfred does define the workflow specifications. Hence if a workflow could say "hey I need Node", Alfred could in principle download it for the Alfred user.

[deanishe]

3 minutes ago, pier said:

But Alfred does define the workflow specifications. Hence if a workflow could say "hey I need Node", Alfred could in principle download it for the Alfred user.

 

Alfred has no mechanism for declaring or resolving dependencies.

 

Adding one would be a significant undertaking, and for what? So 20 KB workflows can require hundreds of megabytes in dependencies in the shape of Node, which doesn't do anything Ruby and Python (which are already installed) don't?

 

It's a lot of work to add a feature that decreases usability (wait 10 minutes while Node installs) and increases fragility (what if the computer's offline?). I just don't see it happening.

 

If you want your workflows to Just Work without requiring users to jump through lots of hoops, you should strongly consider using JXA, Ruby or Python.

 

[vitor]

1 hour ago, pier said:

but other projects like Electron have already solved that.

 

Which is an ongoing project in and of itself, backed by a popular company about development, full of developers, with hundreds of outside developer contributions. Alfred’s team is two people, and only one does the coding. Electron hasn’t solved bundling node in apps. They bundle it in their own app/framework for their specific purpose, and tightly integrate it in their code base as a major dependency. Their other component is a full-fledged web browser that has a javascript engine that was itself the basis for the creation of node. That work isn’t transferrable to Alfred.

nvm, which downloads and manages node versions, would be a more apt reference. It’s something like that that Alfred would need to do. But again, the downsides are humungous.

Edited April 16, 2017 by vitor

[deanishe]

7 hours ago, vitor said:

Electron hasn’t solved bundling node in apps.

 

A bad solution is still a solution

[vitor]

54 minutes ago, deanishe said:

A bad solution is still a solution

 

Agreed, but the point still stands that Electron solved it for themselves, not others. For you to benefit from their node integration the app has to be built inside Electron. The node integration isn’t transferrable to non-Electron apps.

 

I saw that article when it became popular on HN, and here’s my issue with it.

 

Quote

I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU.

 

Which naturally led to

 

Quote

why suggest moving away from electron instead of suggesting that users learn how to use it correctly, or perhaps suggesting that electron better educate users on how to use it correctly?

 

Without trying to turn this thread into a discussion on the merits of Electron, in practical terms I actually like that it exists. Simplifying the argument, I agree that in many cases the alternative to an Electron app is no app at all. I know it for a fact. What sold me was their API documentation. It’s so clear and well-organised, I revamped the Homebrew-Cask docs to mimic its better parts. With Electron I end up reading more documentation and thinking “oh, I can enhance the code with this”. By contrast, with Xcode/Cocoa I find myself scouring the web for a way to do a particular thing, and seldom find it. Because of that, I never finished a macOS native app.

But I would prefer to. If I could easily transform an Electron app to a Cocoa Webview one¹, I would.

I find it beneficial to see Electron as another stepping stone. Because we were stuck with javascript on the web, V8 was created to make it bearable. That new speed opened doors to things that were impractical before and gave javascript a boost of attention that eventually circled back into efforts to make the language itself better. Similarly, Electron validates a desire to make Desktop apps and to do so with the help of web technologies. Eventually that might circle back to official OS support and decent performance (and isn’t Microsoft starting to incentivise/support similar things on Windows?).

 

I also thoroughly separate Electron from node. Node’s problem is cultural. They reached the absurdity point of abstraction, where every library depends of 30 others, from which 28 consist of a single line.

 

Having said that, all other things being equal I’ll prefer/prioritise the native app, naturally.

---

1. Because I usually use Electron to package an already existing website and add features to it, not to make apps from scratch.

[deanishe]

9 minutes ago, vitor said:

I saw that article when it became popular on HN, and here’s my issue with it.

 

I agree. I'd compare Electron to PHP: its accessibility as a platform invariably attracts higher numbers of crappy developers who turn out turds.

 

12 minutes ago, vitor said:

If I could easily transform an Electron app to a Cocoa Webview one

 

I've tried (and failed) to do this a few times, too. It was much easier to figure out how to do in Qt, so I used that instead. (Not that I find Qt's documentation much better than Cocoa's.) If JavaScript is the only tool in your box, you can also use that with Qt (or Cocoa for that matter, if you're a real masochist). Also, it's a real GUI library.

 

As a rule, I use epichrome for things like this unless I need to add extra behaviours.

 

31 minutes ago, vitor said:

Node’s problem is cultural.

 

Not really surprising to my mind: JavaScript as a whole has a cultural problem, imo. Namely, hardly anyone is actually happy with plain old JavaScript.

 

Having said that, if you want my Vue.js, you'll have to pry it from my cold, dead fingers.

[pier]

3 hours ago, vitor said:

If I could easily transform an Electron app to a Cocoa Webview one¹, I would.

 

If your app doesn't use Node you use this https://github.com/francoislaberge/shrinkray (macOS only)

 

2 hours ago, deanishe said:

JavaScript as a whole has a cultural problem, imo.

 

JS is in a teenager phase like PHP was 15-20 years ago. Hopefully it will mature and learn from its mistakes if Web Assembly doesn't kill it...

[pier]

Hey guys I just found this: https://nodekit.io/ relevant to the discussion about Node.

 

It's a cross platform Node replacement that uses the JS engine provided by the OS so it provides a very lightweight implementation of the Node API. The motivation page gives a bit more of insight.

[deanishe]

2 minutes ago, pier said:

If your app doesn't use Node you use this https://github.com/francoislaberge/shrinkray (macOS only)

 

Now that I will definitely be trying out. One of the demos uses Java, which leads me to hope I could embed a Go/Python "backend" in it.

 

That would be so much more efficient that Electron with all its Node and libchromium gubbins, which is my main gripe with it (and NW.js, and Qt for that matter).

 

2 minutes ago, pier said:

JS is in a teenager phase like PHP was 15-20 years ago. Hopefully it will mature and learn from its mistakes if Web Assembly doesn't kill it...

 

JS is 21 years old. The same as Ruby and PHP, and just a bit younger than Python. And it's a fine language (unlike PHP, which is still a steaming pile).

 

JavaScript's issues are cultural. (Which is also true of the other languages to different degrees, imo.)

 

The community can't seem to stop itself from re-inventing everything each year, even though most JS devs think it's bonkers, too, and anything Node-related always has an absolutely insane number of dependencies because no snippet is too small for a Node developer to call it a library and upload it to npmjs.

 

Web Assembly will probably go the same way if it's being used by the same developers.

 

 

[pier]

1 minute ago, deanishe said:

JS is 21 years old. The same as Ruby and PHP, and just a bit younger than Python.

 

You are of course technically correct, but I feel since Node and NPM entered the scene we are in a new JS renaissance that it's still trying to trying to define itself. I don't mean the language itself but the whole development process. Maybe I'm delusional, but I think (I hope) we should reach a maturity plateau in a couple of years.

[deanishe]

21 minutes ago, pier said:

Hey guys I just found this: https://nodekit.io/ relevant to the discussion about Node.

 

It's a cross platform Node replacement that uses the JS engine provided by the OS so it provides a very lightweight implementation of the Node API. The motivation page gives a bit more of insight.

 

Meh. I only find Electron etc. interesting because of the GUI aspect. For me, JavaScript is part of the price you pay, not a selling point.

 

The only time I willingly choose to use JavaScript is when AppleScript is the other option.

 

Everyone draws the line in a different place, and for me, weak typing is on the wrong side of it. I like my languages to throw an error if I try to add an integer to a string.

 

[pier]

5 minutes ago, deanishe said:

 

Meh. I only find Electron etc. interesting because of the GUI aspect. For me, JavaScript is part of the price you pay, not a selling point.

 

The only time I willingly choose to use JavaScript is when AppleScript is the other option.

 

Everyone draws the line in a different place, and for me, weak typing is on the wrong side of it. I like my languages to throw an error if I try to add an integer to a string.

 

 

Sure, but it would solve many of the issues about trying to make Alfred work with Node.

[deanishe]

Just now, pier said:

 

You are of course technically correct, but I feel since Node and NPM entered the scene we are in a new JS renaissance that it's still trying to trying to define itself. I don't mean the language itself but the whole development process. Maybe I'm delusional, but I think (I hope) we should reach a maturity plateau in a couple of years.

 

Maybe. There were dozens of frontend JS libraries kicking about before everyone settled on jQuery.

 

I wouldn't call it a renaissance. More that Node gave JS a role on the server, which it never had before, and it's particularly suited to tackling the C10k problem, as JS has always had an event-driven execution model (probably due to its GUI heritage).

 

Async IO and event-driven programming is new to more traditional backend languages (and especially the programmers using them), which have always revolved around threading.

[vitor]

9 minutes ago, pier said:

You are of course technically correct

 

Which is the best kind.

 

51 minutes ago, pier said:

If your app doesn't use Node you use this https://github.com/francoislaberge/shrinkray (macOS only)

 

I’d encountered it before, but it seems too undeveloped (read, useless) yet. I also find this part of the README both funny and worrying:

 

Quote

Create desktop apps in Javascript. Lightweight alternative to Electron because of only supporting macOS (for now).

 

“This is pretty lightweight now. But don’t worry, we’ll make it bloated soon”.

 

9 minutes ago, pier said:

Sure, but it would solve many of the issues about trying to make Alfred work with Node.

 

I don’t see how that sentence relates to the post you quoted.

 

18 minutes ago, deanishe said:

I only find Electron etc. interesting because of the GUI aspect.

 

Same here.

 

9 minutes ago, deanishe said:

There were dozens of frontend JS libraries kicking about before everyone settled on jQuery.

 

And now everyone seems to be moving away from it to vanilla JS and Vue or React.

[deanishe]

1 minute ago, pier said:

Sure, but it would solve many of the issues about trying to make Alfred work with Node.

 

Alfred works perfectly fine with Node. It doesn't care in the least which language your workflow is written in.

 

Even though you can put Python or Ruby or JS code in Alfred's Code boxes, many developers always set the Language to /bin/bash and use the Code box as a shell to launch an external script, e.g. /usr/bin/python myscript.py "$1". (Because Alfred's Code box is a crappy editor, and having all your code in info.plist doesn't play so well with version control.)

 

This works equally well with any language.

 

The only "issue" with Node is that it isn't installed by default on macOS and it's far too big to include in a workflow.

 

If Nodekit is small enough to bundle, you're already good to go.

 

But as for Alfred providing a mechanism for handling workflow dependencies, it just isn't going to happen (in my opinion, for the reasons explained above).

 

[pier]

1 minute ago, vitor said:

I don’t see how that sentence relates to the post you quoted.

 

Because @deanishe basically said "I don't like JS" and I simply insisted that Nodekit would solve the problems stated earlier about using the Node API from scripts in Alfred.

[deanishe]

5 minutes ago, vitor said:

Vue

 

Did I say Vue is awesome? I think I said Vue is awesome.

 

Vue is awesome.

[pier]

2 minutes ago, deanishe said:

The only "issue" with Node is that it isn't installed by default on macOS and it's far too big to include in a workflow.

 

If Nodekit is small enough to bundle, you're already good to go.

 

Yes, that was what I was suggesting.

[deanishe]

1 minute ago, pier said:

 

Because @deanishe basically said "I don't like JS" and I simply insisted that Nodekit would solve the problems stated earlier about using the Node API from scripts in Alfred.

 

I thought we were still talking about Electron, not Node. I guess @vitor did, too.

[pier]

Just now, deanishe said:

 

Did I say Vue is awesome? I think I said Vue is awesome.

 

Vue is awesome.

 

It is indeed.

 

We used React in 2016 and this year we are moving all our new projects to Vue.