It’s no secret that I’m a fan of various ES6 features. I use a lot of the new syntax options and methods on various objects whenever I can – in browser based apps as well as node.js apps. 

But I recently stumbled upon on a situation that had me wondering if the barrier to entry is really worth the cost, right now. 

A Brochure On Mountain Climbing

A friend of mine released a validation library. I’ve been needing one in my current client project, so I thought I would take a look.

The syntax looked nice. The library was small, but flexible. It had some built-in validators for common things, and it looked like it would work with just about any JavaScript object. 

Everything looked good and I was set to try it out.

Facing The Actual Mountain

I sat down to install it in a sample project, and learn how it works.

This is what I do whenever I get ready to try a new library of any kind. It frees me from the confines of a large and potentially complex project, and lets me focus on the library in question.

The first thing I noticed in the github readme was “npm install” – ok, great! No problem. I’ll try this out in node and see how it goes.

But the moment after I installed the library, I saw something that looked like this:

Sure, I know this code – the named import syntax for ES2015. I use this syntax in my browser apps a lot.

… Wait

I thought I just npm installed this.

The Mountain Is Larger Than The Picture

Ok. What do I do, now?

I’ve got a library that was installed via npm just now, but I’m supposed to be using the new ES2015 import syntax with destructuring assignment – two things that node.js doesn’t support yet. 

Oh, wait… is this library meant to be used within a browser?

Ok, sure. I can do that. 

Out Of Breath Before I Started The Climb

I just need to install babel, and browserify…

But, I don’t like the command line tools. Having to re-run them on file changes is obnoxious.

Instead, I’ll install grunt and the grunt plugins to automate this.

Wait, if I’m doing this for in-browser code, then I need a basic web server, too.

Sure – just grab express and then configure the output of babel and browserify to go into the public folder, right?

Packing Up And Heading Home

I thought about everything that I had to do before I could sit down and try out this little library.

Then I deleted the sample project folder and went back to hand-writing my own validation in the client project.

Caveat Emptor, ES2015

I honestly don’t know if the library my friend wrote is any good or not.

I never actually had a chance to use it.

The mountain that I had to scale to try it out was far more than I had signed up for.

And I get it – I do. My friend builds react/redux/flux/whatever-the-latest-crazy-name-is apps where he already has all of the precompiler and build tools he needs. I have all of these tools, too, when I’m looking at my client projects. 

But the barrier to entry for using a lot of ES2015 features is still incredibly high, and yet it’s something that I continuously see being glossed over in libraries. 

Explicit Dependencies; Easier Getting Started

In this particular case, there is zero mention of anything ES2015 build related. No mention of browserify or babel or react or any other tools that would be used to turn this beautiful new syntax into something that a JavaScript runtime could actually use. 

I’m fine with using new and better syntax when it makes sense.

But when I want to spend 10 minutes trying out a new library and it will take me an hour to configure a working build and runtime environment, then I might as well be using <insert your most hated, “enterprise” level, bloated language / framework here>.

There has to be an easier way to deal with the large list of build and runtime dependencies while we wait for browsers and node.js to catch up to the syntax we want.

And installing 2, 3 or even 1 tool that requires a ton of configuration for builds isn’t it.