Sunday, September 25, 2016

JavaScript Is Gradually Supervised Chaos

Imagine if, after Google graduated from tiny startup to megacorp, it had been replaced with a well-run public utility. This is a controversial idea in America, but public utilities can be pretty great. The public subway system in London, for instance, is fantastic. Compare that to private utilities like Comcast.

In this alternate universe, there's some kind of system which kicks in after the success of a startup. "Congratulations, you've made billions, you're rich now, but what you've created is so essential to our society that we can't risk it turning into another Comcast, so we're going to run it as a public service which every American gets for free." This would be a very different America.

There's this weird thing in the US where conservatives refuse to believe that the government can do anything well, but also are outraged if you criticize the military or the police. It's as if working for the government is a guarantee of incompetence, but working for the government and carrying a gun is a guarantee not only of competence but also moral superiority. I don't understand it.

But this is just a mental exercise, set in an alternate universe, so humor me. Imagine this alternate-universe America is like Switzerland, where public utilities are run so efficiently that trains arriving three minutes late constitute a political scandal.

So we're in this alternate universe where the US government takes over companies that become so essential to basic everyday life that we can't risk them turning into Comcasts. In this alternate universe, Comcast itself was taken over, and nobody ever has to deal with their shit. It's a different place, but it's a nice place.

The purpose of this mental exercise is to explain JavaScript. Every time a developer from some other language dives into JavaScript, they freak out at the chaos. You can import specific language features from a spec which has not yet been actualized. There's multiple different package managers. You use them to install each other. There's more than one require() syntax, but there's also really no require() syntax at all.

This chaos occurs because JavaScript, which was born in chaos anyway, operates by allowing its open source communities to develop solutions for failings in the language, and then folds some of those solutions up into the language itself. ES5 turned jQuery into querySelector; ES6 adopted () => from CoffeeScript. This folding-up necessarily lags behind the development of new solutions. And it works well enough that you often get a situation in JavaScript where multiple solutions which are pretty good compete with each other; npm vs Bower, for example, or CommonJS vs RequireJS (which will fade in importance once ES6's import becomes viable, but not disappear immediately).

Most language communities don't operate this way, but most language communities don't have the enormous size or reach that JavaScript does. Everything runs JavaScript today, and every programmer uses it. Go on a job ads site and search for "JavaScript" — you'll see ads for jobs in every programming language that exists, with a little bullet point that says "oh btw you also need javascript," far more often than you'll see jobs that are about JavaScript. Getting a group as colossal as the JavaScript user base to agree on hypothetical descriptions of their needs, or hypothetical solutions, would be incredibly difficult. Letting this massive "community" splinter into subgroups and compete is a better solution.

I'm not saying it isn't messy. I'm just saying there's a reason.

Thursday, September 22, 2016

Elm Is The New Rails

About 10 or 11 years ago, a friend asked me if I'd heard of Rails. She had a developer building something for her, and he wanted to build it in Rails. She asked me to look into it; she figured anything that could get the job done was fine with her, but she didn't know if Rails could get the job done. So I looked into it, and I was like, "holy shit." Then I told her, "yeah, that can get the job done," and aside from some dabbling in Node and front-end work, and a whole bunch of bootstrapped entrepenurial whatnot around information products, Rails has pretty much been my career ever since.

That last part's been true for a lot of people. I don't know if Elm will see the same massive success, but when I compare what it felt like to discover Elm vs. what it felt like to discover Rails, I see a lot of similarities. First, both Elm and Rails represent very curated experiences with a very strong emphasis on being enjoyable to use. Second, that curation involved deep thinking, in each case, about the best way for the framework to do its job, which thinking came in each case to idiosyncratic and (in my opinion) superior conclusions.

Third, they both showed up in very similar environments. Rails had two main sources of competition: an over-ambitious, platform-y technology which was painfully boring and tedious to work with, and an overly simple alternative which encouraged you to write very hacky code once your project grew beyond a certain size. Angular 2 would be the equivalent to J2EE in this analogy, and obviously React, as a view-only technology which intermeshes presentation markup with application logic, would be the PHP.

OK, I apologize. I know Angular intermeshes markup and logic too, and I know both have insane ambitions of being platform-agnostic mega-/meta-frameworks, and indeed, Elm itself has you write your HTML as Elm functions, so it too blurs the line between logic and markup somewhat. But I needed a J2EE and a PHP, and Angular is definitely the over-engineered one.

Only time will tell if these two analogies hold, and indeed I'm a lot more confident in the Angular snark than the React snark. I could be wrong about both. I built a toy recently with React and enjoyed it a lot (but then again, PHP makes a ton of sense for really simple barely-dynamic pages). And certainly, Evan Czaplicki doesn't seem like a DHH to me at all, although I could totally see him as a Matz.

Still, one of the weirdest aspects of Rails's success has been a particular contrast: everybody steals ideas and vocabularies from Rails, but virtually no other project has said, "yes, Rails is right, programmer happiness should be a top priority." You can find migrations, REPLs, code generation, and "REST means CRUD" in every language now, but you won't find "programmer happiness is the top priority" in many other places.

I think this is partly because a lot of the old blog posts where DHH praised and imitated Kathy Sierra have vanished, so nobody remembers that making users happy is about making them awesome, and a framework which makes its users awesome is doing what a framework should do. It could be that the "look at me, I'm awesome!" vibe of early Rails devs was hard to take, so nobody did any serious thinking about it. It might even just be because it's hard for anybody to take DHH seriously in the first place when he has such an egregious straw man problem.

However, one way or another, DHH told everybody that programmer happiness is the secret to Rails's success, and everybody gathered around wondering "what's the secret to Rails's success?" and virtually nobody ever considered the possibility that when DHH said it was programmer happiness, he was telling the truth. And this confused me, and it continued to confuse me for a full decade, and then I found Elm.

I have absolutely no idea if Elm's focus on being fun to use comes from any awareness of Rails at all. But Elm's designed to be fun to use, and, as a consequence, it's fun to use. What a shock! And as it turns out, everything that makes Elm fun to use also makes it a good framework. It has a clean mental model. It doesn't throw mysterious, aggravating runtime errors. Its compiler errors are easy to understand, easy to correct, friendly, and so polite that its British users assume the language itself is British. It's fast as hell in development and production — pull up a Chrome timeline sometime and compare an Elm "hello world" with the festival of document.write that is an Om "hello world" — and it's basically awesome.

I think my new rule of thumb should be that all of my code should be fun to use. It worked for Rails, and it's working for Elm too.

Thursday, September 15, 2016

God What An Awful Directory Name

One aggravation I have with the asset pipeline, and it's not the worst by far, is that app/assets/javascripts is just a terrible directory name.

First, if you're building anything remotely modern, your JavaScript code isn't really an asset, it's an app.

Second, "JavaScripts" is not appropriate here. These are not scripts written in Java. The only meaning the term "JavaScripts" could ever actually have in the English language is if you are talking about varieties or dialects of JavaScript. For instance, ES6 is a much more usable JavaScript than the JavaScript of 1997, but both these JavaScripts have some really weird edge cases, especially around numbers and numeric comparison.

If the directory were called app/assets/javascript-scripts, that would still be stupid, but it would at least have a meaning.

Unless you are, for some insane reason, storing ES7, ES6, ES5, and/or several other entire dialects of JavaScript in app/assets/javascripts, that plural is just wrong.

Update: and I forgot the most obvious reason!