Sunday, March 27, 2016

Babel 6 - useless by default - a lesson in how NOT to design software.

One of the hardest things about learning modern JavaScript programming is wrapping your head around the build systems - all the non-programming stuff you have to get going to run your code.

And for mortal humans it is *really hard* to grasp what the heck this complex ecosystem of build tools does and how they fit together, how to configure them and how to drive them.  REALLY hard.  Beginner JavaScript programmers who wish to do modern development face a massive learning curve just to get started. If you think it's easy then have climbed the learning curve and done your learning already and forgotten how hard it was.

So the easier the build tools are to install and use, the better.  Ideally, for common use cases, the end user will need to do precisely nothing apart from install the build tool to get basic and even advanced level usage out of it.

And Babel is one of the core parts of that build system.  It compiles ES2015 code to ES5 that can be run on any browser.

Out of the box, Babel doesn't do anything.  Literally useless by default.  Want to do something?  You MUST configure it.  And of course that means you have to start learning how to drive and configure Babel.

The first step in learning a new system is the hardest and most confusing and most time consuming.  To configure one tiny thing a vast array of questions come up.  Am I really meant to do this?  Should I be changing this setting?  Why do I need to do this? What does it do?  Am I breaking something?  Are there more things to configure? Am I working with the latest information or has the system changed since the documentation I am reading?  Why have I found three sets of conflicting instructions to do this configuration? And the biggest question of all - why do the instructions on this web page not match what I see on my screen? And then of course, "I've made the changes as instructed, why doesn't it work, what's wrong?". All these questions come from a hazy fog of ignorance of what the software is, how it holds together, what it's purpose is and why it works the way it does. You groan inwardly and sigh - fuck, how deep is this "simple" rabbit hole going to be? EVERYONE goes through this phase of learning a new technology.

If a build tool requires the user to make even one single configuration setting then they have imposed a huge learning cost on that user.  Possibly many hours of time and possibly (even probably) failure in trying to reach their goal.  For many users the cognitive load will be too high.  And the user may not even succeed in doing configuration that the developers consider to be basic and trivial.

Conversely, if a build tool requires a user to configure *absolutely nothing*, then they have saved the end user hours and driven them to a "pit of success".

Too many JavaScript build tools think that developers care about the build tool.  They think that developers want to understand the build tools, and want to learn and configure and program those build tools.  I'm not here to program build tools.  I am here to program application code.  I want my JavaScript build tools to anticipate likely use cases, come pre-configured to do as much as possible out of the box.

Experienced Babel 6 users will dismiss my assertion that configuration is hard. "It's easy!" they'll say.  You change one file: .babelrc, npm install your presets, install your plugins and modify your update your webpack config and you're good to go!  It's 60 seconds work so you are speaking garbage. "

Experienced developers forget how incredibly hard and time consuming and confusing it is for unexperienced users to do those 60 seconds worth of tasks.

It should only be necessary to configure JavaScript build tools for optimisation of final production code.  Forcing users to configure everything up front is premature optimization, wastes users valuable time, imposes a cognitive load on the user and makes the entire JavaScript development process massively more complex and hard and for some users trying to get started, will kill their enthusiasm and will kill the entire process for them

So when Babel 6 decided that it would do nothing out of the box, it did the opposite of conventional wisdom in software usability, which is to include sane defaults that anticipate the most common use cases and provide them, ideally with zero requirement for setup and configuration.

Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc.  They should throw everything in there that a developer might want to use.  The expert use case for Babel is to strip it down to the minimum.  It should not be the basic use case to build it up to usable. I shouldn't need to even think about how to configure Babel until I'm so far into my development process that I have already scaled the other learning curves that were essential such as learning ES2015 and browser programming.

Babel wants to exist, be seen and heard and talked about.  But in fact it is plumbing that you should really never have to give a thought to unless you're walking a very unusual road.  Babel's demands for you to configure it is like your taps in the kitchen needing you to get under the house with the wrench and hook up the hot water yourself, install a hot water tank, install solar panels and set the temperature in order to use it.  Not stuff you should need to do.  Babel should generally be neither seen or heard.  The Internet should not be plastered with blog posts instructing you on how to configure Babel, some right, some wrong, some out of date, some conflicting.  The developers should have configured it once, properly, so you don't need to think about it.

And finally, the cost to the Babel project itself is support issues and questions and problems from people who haven't managed to get things to configure, or didn't even know they were meant to configure - only that something isn't working.  The Babel project is shooting itself in the foot and making work for itself. The Babel developers should always be focused on how to reduce and remove the need for configuration, to find effective ways to preconfigure, and to find ways to allow people to use Babel with ever less knowledge that it even exists.

OK I'm headed back to see how to configure Babel to use async and await.  I really wish it was configured out of the box. What a waste of time.

P.S. and by the way I do know about Babel presets. That's too much configuration too.  The right amount of configuration is none.


  1. [Ask permission]May I translate it( into Chinese and publish it on my blog(

  2. Replies
    1. This post has been transalted into Chinese(zh-cn), you may check here:

  3. For your particular issue at the end, you can use rauchg's config for requireFromTwitter:

    > Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc.
    > I shouldn't need to even think about how to configure Babel until I'm so far into my development process that I have already scaled the other learning curves that were essential such as learning ES2015 and browser programming.

    The features you point out aren't es2015 and decorators are actually still stage 1 and pretty likely to change. Maybe we shouldn't be providing those by default if users are still learning ES2015 and might rely on things that might be completely different later?

  4. I recently decided to move on from being a WordPress-dev to something more substantial. In looking for a new framework to learn I decided to look into JS frameworks because apparently JavaScript is the new hotness. So far I have look at React, Angular 1, Angular 2, Ember and Meteor. About a year ago I install Node and NPM when I was looking at Ionic. In wanting to learn these frameworks I found out Node is at version 5.X while my system was at a 0.1.X version.

    Updating the few NPM modules I had on my system was a pain because 1 module will have 101 dependencies. Most of them where deprecated, renamed or no longer existent. Jesus Christ! Did I mention I am a Windows PC. How can a modules file path be too long to delete? It's like directories, in directories, in directories, ad infinitum.

    For a couple of month on and off of getting Node, NPM and npm modules kinda working on my PC, node-gyp on Windows, I finally decided to look deeply at React but that syntax rubs me the wrong way, plus getting webpack and gulp and grunt to work. I stopped. Then there is Meteor, I will come when they have a real DB system working with it. Angular 1 vs 2, I'll wait abit.

    At the end of it all I think I am going to stick with Rails because at the end of the day it just works. I just got tired of running 'npm install' and watching it take forever to install half of the NPM repo just to get 1 module to work.

    The JS module system as it is, is pure madness.

  5. I completely agree. I don't use tools that try to waste my time. Babel sounds like exactly that tool. If someone wants me to use such a tool, they will have to configure it. I have better things to do with my day.

  6. Just configure it one time and then use your bootstrap project. See a ton of it in github:

    Just choose your one! Or configure it yourself

  7. Agree and disagree. Conversion of ES2015 should have been on be default imo, not the kitchen sink though. Stage-0 features are likely to change, and should only be enabled if you chose to take that risk of potentially having to rewrite later. Have seen projects where I work enable this without being aware of this fact, and I fear it will lead to some headaches in the future.

  8. Thanks for sharing this excellent data. Thank you!

    Accounts Data Entry

  9. There is a chance you qualify for a new government sponsored solar energy rebate program.
    Click here to find out if you are eligble now!