DerickBailey.com

Trade Secrets Of A Developer / Entrepreneur

  •  About
  •  Twitter
  •  G+
  •  RSS
  • Blog
  • Courses
  • Products
  • Newsletter
  • Publications
  • Podcasts
  • Work With Me!

The High Barrier To Entry For ES2015 (ES6)

April 18, 2016 By Derick

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. 

Scaling es6

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.

Tweet

 


 

Related Post

Docker for JavaScript Developers: On-Site Training
3 Features of ES7 (and Beyond) That You Should Be ...
How a 650MB Node.js Image for Docker Uses Less Spa...
3 Rules For When A New JavaScript Feature Is Ready...
Never Use The :latest Image From Docker Hub

Filed Under: Anti-Patterns, BabelJS, Browserify, Code, Config, Dependencies, Development Environment, ES6, JavaScript, NodeJS, Practice

About Derick

Derick Bailey is a developer, entrepreneur, author, speaker and technology leader in central Texas (north of Austin). He's been a professional developer since the late 90’s, and has been writing code since the late 80’s. Derick has built software for organizations of all shapes and sizes, including contributions to Microsoft's MDSN library, running several very highly regarded open source projects, creating software solutions for large financial organizations, healthcare orgnaizations, world-class airlines, the U.S. government, and more. These days, Derick spends most of his time working on content for his own entrepreneurial efforts at WatchMeCode.net, playing video games when he gets a chance, and writing code for for his few remaining clients. You can reach Derick at DerickBailey.com or on twitter, @derickbailey.

Derick Bailey Around The Web

  • Twitter: @derickbailey
  • Google+: DerickBailey
  • Screencasts: WatchMeCode.net
  • eBook: Building Backbone Plugins

Copyright © 2016 Muted Solutions, LLC. All Rights Reserved · Log in