A brief, painful attempt to understand JSA

JSA is “JavaScript for Automation”, aka Apples attempt to embed JavaScriptCore into their Apple Event model.

The use case here is, roughly, “I know JavaScript and [love|like|tolerate] it, but I cannot under any circumstances be arsed to do anything useful in AppleScript, because AppleScript is easily one of the worst software platforms ever created by man”.

Seriously, AppleScript is extremely bad. I have in my life encountered a few people who loved it; and nearly 100% of them are not work-a-day programmers. AppleScript is purpose-built to confuse, annoy, and frustrate people who can chew through languages like Swift with little effort.

(I’m not trying to start a “you’re not a real programmer” thing; if you write a program – any program – you’re a real programmer! I’m just saying that the norms AppleScript adheres to are typically diametrically opposed the stuff we work-a-day programmers have deeply, deeply internalized as “normal”.)

Anyway! I decided rather than replace a bunch of light switches my wife has decided are no logner aesthetically pleasing, I thought I’d spend the morning trying to hack on some JSA. After all: how hard can it be? It’s JavaScript and I know JavaScript, and I have once or twice managed to fumble around with AppleScript until I accomplished something useful.

I can sum up the morning with the phrase, “Oh, for fuck’s sake”.

Continue reading “A brief, painful attempt to understand JSA”

A brief and uninteresting review of ReactJS

You might have heard of React (or ReactJS) lately. It’s a Facebook JS platform thing. You can find lots on it: here, here, or here, or perhaps this well-reasoned discussion. And probably other places: it’s starting to really get talked about a lot.

Naturally I did the obvious thing, and found the smallest possible project I could lever it in to, and implemented it. I wrote a mailing-list-and-whatever-else email system for work (using Lamson and Redis). Me being me, the “user interface” is a bunch of scripts in bash and Python, and `redis-cli`, along with a giant README on just what the hell is going on. 

Once I took it live, I decided “phase 2” was to at least put up a read-only view of things like “who is on what mailing list”. Obvious first choices here are Express or Flask, and a little AngularJS front-end; so React will work nicely. 

The server-side code itself is unremarkable: get a Redis key, then `res.json(result)`. Nothing special, so I won’t bore you with the details.

React itself was somewhat uninteresting. A somewhat dismissive but also not entirely inaccurate description is, “it’s just a thing for making directives”, a directive being what Angular calls its template/view/DOM-manipulation mashup; in other words, UI.

It relies on hierarchy, and at the higher levels all elements are new/non-standard; so in the tutorial it uses a “CommentBox” top-level element which contains a “CommentList” element, which contains a list of “Comment” elements, and so on. If you’ve ever done programming in something like GTK, this should be familiar. Only at the lowest level do you start dealing with HTML. 

Since it’s just “directives”, React contains no methods for talking HTTP, and it has no 2-way data binding. This is not entirely awful, because not every single element benefits from 2-way. It’s also not entirely great, because now you’re back at least partly in jQuery-land. I’ll always have affection for jQuery and will never say bad things about it, but I don’t think it’s a truly unfair statement to say sometimes larger applications can get unwieldy or difficult to manage.

For large projects, then, it seems like you’re just trading one hard-to-maintain method (a twisty maze of selectors and bespoke events in jQuery) to another (just what the fuck is a TopLevelStructuredListElementClass, anyway?). You can look at any “standard” AngularJS app and immediately understand how it gets JSON from a remote service, and with a few minutes of noodling you can probably reason where the Angular service code is and how it works. I don’t see that at all in React. 

I will probably deploy it (instead of rewriting in Angular), because it’s a very small app that does exactly 1 thing and will almost certainly not be changed for years, and maybe I’ll open-source it if I can. That said, I’m sticking with Angular for now.

My frustration with NodeJS specifically and JavaScript in general is just through the roof at this point.

The churn of frameworks and libraries in NodeJS is getting completely out of hand. I have a few feeds (Reddit, etc) and it is almost exclusively some new Rails-a-like packaging of Express, a new build system meant to replace `make` and shell scripts, or more MV* frameworks (each with varying amounts of ES6 and weird features).

I just can’t take it. I think it’s finally overwhelmed by ability to give any fucks. Being involved in the NodeJS or JavaScript “community at large” is a guarantee of drinking from the firehose of this nonsense, and I am just done. I can’t be arsed to care much any more.

My heart is wandering back to Python more and more. Staid, ugly, boring Python. Synchronous, the global interpreter lock, give it to me. The rate of change is far too slow, but Python can speed up. The Python community can change.

I don’t believe JS can be reasonable at this point. They’re too invested in not caring about sustainability, “the long term”, whatever.

Maybe I’ll change my mind later. I still like JavaScript for lots of things: it’s optimal for so many tasks. But I feel like, writing big programs in JavaScript at this point is just adding to the noise.

(Totally unrelated, when did WordPress start to act like Tumblr? I mean, they have the same posting category thing now.)

A little Coda 2 plugin

I made a little Coda 2 plugin for fun: wrapping js-beautify. You can download it here

Pay close attention to the documentation; the script environment doesn’t do what you think it does, and so you’ll be very grouchy.

I want to love Coda a lot; as I mentioned in my review of Komodo IDE, I mention as one of its downsides it’s so very not-native. Coda is extremely, wonderfully, beautifully native. So there’s that.

But it’s ultimately an app for cranking out WordPress plugins, not doing serious work. If you want to build serious, production web applications – and especially in something other than PHP – look elsewhere.

NodeJS isn’t cancer (more like a bad case of food poisoning)

Recently at work I got involved in a somewhat lengthy (and at times a little heated) discussion about the efficacy of Node.js being introduced into our stack. 

For context, our application consists of a few disparate components: a kernel of applications written in C/C++/assembler, then a huge mass of mostly Python (654,852 SLOC according to sloccount) to handle everything of core system administration to the web. There is considerable Python expertise in-house; at one point we even employed core Python committers. Our build and test rigs use Python. One of my projects, converting the internal network applications to virtual machines, makes heavy use of libvirt’s Python API. There is more Erlang in production than Javascript. 

Naturally, for the next iteration of the web side of the application, a completely from-scratch rewrite using Node.js makes the most sense, right? Of course it does. At least, that’s the argument I lost. But I’m not bitter[1].

But! I’m an adult, and so I’m aware that I either do my job or find a new one. I think the AR15 platform is a piece of shit but I didn’t really waste any time yelling at the Marine Corps that there’s lots of better ways to kill bad guys, I just did my best to keep mine clean and my proficiency at peak. (Also, we’re talking about a prototype here; we have nothing to lose and everything to gain. If it doesn’t work, no problem, we have other directions to go. If it does work, our application is that much better.)

So to prepare for the clusterfuck^Wgreat leap forward in our application, I’ve been spending some quality time with Node.js. The original Node.js rant, “Node.js is cancer”, is no longer on the web, sadly. You can find other rants elsewhere; my current favorite are on Youtube, here and here. (“You may recall sequential code; that’s the code you can read.”)

I’ve found a few things about Node that I really like, though.  It’s not all cancer.

Fun Thing The First: Modules Are Pretty Great

I really, really don’t miss modeling everything as a class. Maybe I’m just bored of OO, but organizing code by gross function feels much more natural and easy these days. I’m sure over the long run it’ll lead to tears[2] but right now it’s very pleasant to work with.

Fun Thing The Second: The Real Deal On One True Platform

One of the holy grails of web work is that you can do all your real work in one platform. For most of history, people talked about the “web stack”. Oh, it was a stack alright; a stack of fecal matter. It was perfectly reasonable to have in one medium-sized web application a set of technologies like:

  • HTML
  • JavaScript
  • CSS
  • Some sort of scripting language (Perl, Python, PHP, Ruby) for core logic
  • SQL
  • Shell scripts
  • Probably another scripting language – perhaps 2 or more – driving all the tangential parts (sysadmin, deployment, back-end services, etc etc)
  • And if you’re lucky, something compiled, like a C library/extension for one or more of your scripting languages

I’ve seen people suffer from horrible task switching: one time a coworker spent over an hour typing what amounted to Perl into a PHP file, because he’d spent the first part of the day fixing a perl script. He went right into the next task and his brain didn’t come along. We’ve all done it.

I’m pretty sure Node.js comes very close to fixing this. Throw in a NoSQL database and you don’t even need to worry about SQL! The worst case is the odd shell script here and there. 

JSLint provides a fully automated dunce-cap to keep the stupid down 

Thanks to jslint you can pretty much punch anyone in the neck who tries to do something really stupid. If you are some sort of “all Node.js, all the time” and your code doesn’t at least mostly clear a reasonable set of jslint settings, congrats! You’re awful.

It’s not cancer but I’m pretty sure it’s a lot like having food poisoning

I’m immensely frustrated with Node.js. To name but one example, everyone insists on making everything a motherfucking EventEmitter despite Node.js shipping with fully synchronous functions. Yes, the core library ships with not even remotely asynchronous functions. Why? I don’t know, maybe the core team realized sometimes it’s just easier. This logic never filtered out to the great npm-famous masses, so every time I grab a simple library for doing anything, I’m on column 120 before I get to the heart of the matter.

Moreover, I feel like I’ve been sold a bill of goods when I see 3/4 of the README dedicated to hooking up the application to memcached and Redis. Node.js is scalable, please pay no attention to the 40 proxies, key-value caches, and other doodads actually keeping the application running.

But whatever. At the end of the day, every large web application requires all that stuff anyway so perhaps building it in from the start to serve the 5 people using your application is actually the right choice.

It’s probably worth it, if Node.js can truly deliver a smaller “stack”; given the size and complexity of our system, it may end up that we can iterate faster by not having to context-switch. Moreover lots of really talented people are working on making Javascript better; Python in stuck in that weird place of “we’re not porting our library to 3 until there’s a critical mass of users/we’re not switching our app to use 3 until everyone ports their libraries to it”. That in and of itself should give any reasonable person The Fear(™); Node.js and Javascript aren’t going anywhere any time soon and to its credit Node.js has been very out in front of “this API is stable” stuff.

So no, it’s not cancer, but it gives me a lot of occasional irregularity. 


[1] Haha, I’m lying, I’m insanely bitter.

[2] I imagine code reviews thus: “What the hell is this code doing here?” “Because fuck you, I was in a hurry.”

So why don’t we replace AppleScript?

So AppleScript sucks. What’s the alterative?

I don’t get why Apple hasn’t seriously entertained a “next generation” scripting engine, in particular one based on JavaScript. All the things are there:

There’s the “canonical” JavaScript OSA component but it doesn’t fit the criteria: it uses Spidermonkey, not Squirrelfish/JavaScriptCore. Still, its API is pretty spot-on (since it’s an OSA component). It’s also pretty old.

JSTalk is another contender. It’s sort of the opposite number of the JavaScript OSA: it uses entirely modern, native components – stuff Apple almost literally has laying around – but does not feature an OSA-compatible API (as near as I can tell anyway). But, it’s modern and very friendly with Cocoa.

The sweet spot is the fusion of the two; the “already works on top of an OSA layer” of the former and the “all the modern stuff” of the latter.

Someone at Apple please make this happen! Make scripting the Mac awesome.