That annoying thing about JavaScript

Or how to write next AngularJS

JavaScript being the only language supported out of the box by browsers receives a lot of shit. Mostly because people who love it, and people who don’t literally have no other choice. There are Dart, CoffeeScript, TypeScript, ClojureScript, Java compiler and even C++. But none of these, maybe with exception of Dart and GDT will allow you to ignore JavaScript entirely.

So some people complain, and some people decide to solve this problem, and write framework that will abstract annoying parts, and allow them to do what they like. Some decide to write compiler or invent new language altogether.

Anyways, this is my turn. And lets start from testing.

User Experience of Frameworks

But what annoys me in JavaScript is not language, I learned to live with it. I learned to use it, and create prototype factories back in ActionScript 1.0 days, when fastest EcmaScript was inside Flash Player. What annoys me in JavaScript is lack of documentation. Look at new hot thing — React.js. It’s cool, it’s shiny and it’s really robust. It blows away AngularJS in speed department, but I don’t see myself recommending it to any of my clients. Main reason is conflicting documentation. As of 18th February 2015 React.js documentation lacks proper explanation on how to organise code and unit test it. In fact you have to go to Jest site to find one, and then spend 10 to 30 minutes figuring out how to reconcile it with setup you currently using.

Another offender of documentation is Express—Expressjs is very laconic framework that was inspired by Ruby framework Sinatra, as far as I remember at least. But where Sinatra has solutions for simple examples and large scale applications Express tries to ignore things that don’t fit in minimal possible amount of lines. Would it kill you them to write code in examples that don’t just brag about one liners and DSL like features, but would also scale with my app? And yes write about best test techniques?

None of those problems are deal breakers. All of them take less than a day to figure out, but they are nagging and annoying for two main reasons:

  • When library written without testing in mind, it’s just scary to use it.
  • When documentation lacks best practices for testing, scaling and other important aspects in software engineering life cycle it makes every other developer invent own bicycle, and when we meet on a project, we can’t just start working on our cool project, we have to argue about Jasmine versus Mocha or Broserify vs RequireJS and other boring bullshit!

This is why Angular was so popular, not because it was fastest, not because it was best. It was popular because it listed HowTo on majority of boring decisions, with testing, Zepto vs jQuery and allowed me to actually work on my app, and most importantly — When new developers joined, we didn’t had to spend two days explaining bureaucratic bullshit and do our app! It was and it is the most interesting MV* framework because it lets me do interesting stuff.

Every time I read something along the lines that framework allows people to chose unit testing library or template language of their choice all I hear is “I couldn’t be bothered looking and deciding which one is better, so I just leave you this empty handler function, you decide”.

When developing framework, imagine a fucked up agency, with 3 junior developers and a project manager that programmed in C and Prolog in 1980s. Your task is to write framework, make decisions and write documentation so that team could make something stable. It doesn’t have to be shiny, but they have to ship it, and it has to function without crashing browser tab or server. They don’t even have to understand why you did some decisions, just know what to do.

In some way it’s a user experience problem, when we developing apps, in majority of cases we are trying to make simpler solutions, we trying to reduce unnecessary steps. You know all that simplicity and minimalism on the outset? Well in order to achieve simple application, it might have to do a lot of things behind the scenes. Proper documentation, case studies, example projects that cover entire lifecycle of application what makes framework easy to use, it makes people love it and want to use it.

That said, I did enjoy playing with React, and figuring out how to fit it all together with Meteor. But puzzles I solved today—on my day off would frustrate the hell out of team who actually have an interesting project to work on.

P.S. Also, can we decide how do we append “js” part? Expressjs, RequireJS, React.js. Let’s just decide whether it’s capitalised, one word or with a dot and go with it. Please, please, please! It’s small things that can slowly drive people crazy!

Show your support

Clapping shows how much you appreciated David Sergey’s story.