Tuesday, 13 September, 2016 UTC
Summary
If you look at the latest Chrome, Safari, Firefox and MS Edge browsers, you’ll notice the compatibility and feature implementation of ES6 is darn near complete.
And for the majority of developers that still have to support older browsers? Babel and other pre-compilers have you covered.
There’s so much adoption among the latest browser versions, the latest node.js, and pre-compilers, that you don’t have much reason to ignore ES6 moving forward.
But what does this mean for some of the old stand-by libraries that have not only provided great APIs and utilities, but also helped to define the feature set in ES6?
Tools like underscore and Lodash – are they now obsolete, with ES6 features replacing most of the utility belt that they had provided?
I have to admit – I rarely use underscore or Lodash anymore.
Other than my front-end code where I am still stuck in my Backbone / Marionette ways, I’m rarely installing underscore or Lodash into my projects, intentionally.
Every now and then I see enough need to install one of them. But, more often than not I turn to the ES5 and ES6 counterparts for the methods that I use frequently.
For example, some underscore -> es5/es6 array methods:
- each -> forEach
- map -> map
- reduce -> reduce
- find -> find
- filter -> filter
- contains -> includes
- etc, etc, etc
While the method signatures and behavior are not 100% the same, there is an unmistakable influence in the ES5/ES6 list of array methods, compared to the underscore and Lodash API.
Because of this, I have largely been able to do without these utility belts.
But I wondered if I was the exception or the rule.
I knew that my use of these libraries was limited compared to a lot of people.
After all, I’m rarely digging into the more functional / composition aspects of JavaScript. I don’t spend much time type checking with the various is* method, anymore, and frankly the various builds and advanced options of Lodash have often kept me away out of lack of time (effort) to understand them.
I had assumptions about this, because of my own experience. But, I wanted to verify that my thoughts on “underscore is dead” were shared in the community.
So I sent out a poll on Twitter and asked,
Are you still using Lodash / underscore?
are you still using underscore / Lodash, now that ES2015 is available most places / with precompilers?— Derick Bailey (@derickbailey)August 31, 2016
The results shown in the poll were nothing like my own experience and expectations.
Only 9% of the 236 responses said that ES6 (ES2015) makes Lodash / underscore obsolete.
Personally, I fell into the 17% of “yes, but rarely”.
But the overwhelming majority of respondents – nearly 75% of them – said they still use these libraries frequently, with nearly half the responses wondering they they wouldn’t use them.
With the responses pouring in, I had to know why. So I asked a follow-up question.
Why are you still using Lodash / underscore?
if you said yes, you are using underscore / Lodash still, what features / methods, and why?— Derick Bailey (@derickbailey)August 31, 2016
The responses were generally categorized into two things:
- Methods on objects, instead of just Arrays
- Functional / composition based coding
For example, there are a lot of methods in the ES5/6 Array object that can be applied to Objects, with these libraries.
@derickbailey AFAIK, es5 map/reduce/filter only work on arrays— Sean Corrales (@seancorrales)August 31, 2016
@derickbailey _.pick/omit, _.map for objects, _.isX, _.indexBy, _.sortBy, _.escape, _.debounce/throttle … I could keep going.— Ben Vinegar (@bentlegen)August 31, 2016
With the rise of functional programming, it’s also not surprising to see many people using these libraries in that paradigm.
@derickbailey Using Lodash/fp on almost all projects at work.— Cyril Silverman (@CyrilSilverman)August 31, 2016
@derickbailey also ES2015 didn’t added so much worth to me since I don’t use `this` and `prototype`-stuff. rest and spread are interesting.— Stephan Hoyer (@cmx66)August 31, 2016
And if you’re using these libraries already, might it be easier to use them everywhere instead of trying to remember which methods are built-in and which come from the library at this point?
@derickbailey I obviously don’t need to use `map`, `filter` etc at this point, but I’m invested enough in the library that its easier— Ben McCormick (@ben336)August 31, 2016
Frankly, it seems there are some good reasons to continue using these libraries, at this point.
Still, I had to wonder if the future of JavaScript might bring these to an end.
I mean, if these libraries are largely being replaced (at least in my use), and JavaScript is catching up to the capabilities that they provide while continuing to move forward, isn’t there a real chance that they will become obsolete?
It seemed like a possibility to me.
And I rarely use these libraries anymore, so doesn’t that show some evidence?
Well… maybe not.
John-David Dalton – the creator and maintainer of Lodash – steps in to the discussion with this:
Lodash is an active/evolving collection of 300+ modular utils that’ll continue to push beyond ES 5/6/7/.. additions. https://t.co/AvOLZXt5Wg— John-David Dalton (@jdalton)August 31, 2016
YMNK Lodash, by way of the jQuery foundation, has TC39 representation & is involved in the evolution of JS https://t.co/AvOLZXt5Wg— John-David Dalton (@jdalton)August 31, 2016
It makes sense, not just that Lodash has involvement in TC39 (the JavaScript standards / functionality committee), but that the future of JavaScript would continue to be influenced by Lodash and other libraries.
I’m reminded of a talk from Brandon Satrom, on CoffeeScript
At a conference in 2011, called RedDirtJS (which later became ThunderPlains – one of my all-time favorite JS conferences), Brandon gave a talk titled “CoffeeScript is for closers” (full video, below).
I’ve never cared much for CoffeeScript, for various reasons that don’t matter right now. It’s a language that isn’t important to me or the work I do.
Brandon’s talk, however, is an incredibly important look at CoffeeScript.
Not because the language itself should be used, but because of how Brandon approaches the language throughout the talk, and at the end where he says,
I really believe that as a community, we should embrace CoffeeScript because it represents a movement – not to replace JavaScript, but to evolve and improve upon it.
This presentation, for me, was the moment that CoffeeScript changed from something I would suffer through, to a language that I would respect for showing JavaScript the way forward.
And it’s in that same spirit that I now see Lodash and underscore.
Underscore may be mostly dead to me…
But, there’s no doubt that it had a profound impact on the JavaScript community, in it’s prime with Backbone. I built my current career path on top of it, after all.
I don’t see underscore taking up the mantle of moving the language forward, the way it once did, though.
And I don’t use underscore the way I used to, either.
Lodash? Well, it’s even more rare for me to install Lodash than underscore. Granted, this is mostly because of old habit in reaching for underscore.
But in asking the questions, above, and sifting through the answers, I’ve realized something.
The reports of Lodash’s / Underscore’s death are greatly exaggerated.
Whether or not I use Lodash, however, I see the way in which it moves the JavaScript community and language forward.
Think of it like the DOM API of today vs years ago, and how it has been directly influenced by jQuery.
In that way, I don’t see a future in JavaScript without the influence of major players like Lodash.
And I respect that, immensely.
Tweet