May 24, 2016
From, with love.

Library Agnosticism

Hi everyone,

One of the worst arguments for using a particular library is, "because that's what people want to use." I've seen this happen over and over again in my career, where developers choose JavaScript/CSS/other libraries or frameworks believing that this will enable them to hire more people and keep their own developers happy. While this holds true for choices of technology (using Node.js, using AWS, etc.), the same can't be said for libraries that exist within a technology stack. Why? Because libraries often have very short lifecycles (technologies have longer lifecycles), and tying your success to that lifecycle is a gamble.

When I worked at Yahoo, the company was entirely YUI-centric. No one would have dared to slip jQuery into their web application for fear of being a social outcast. I loved the atmosphere because it was one where everyone in the company was contributing to make YUI the best it could be and we were never slowed down by, "what library should we use?" discussions. And even though we were using a library that wasn't the library, we had no problem hiring.

The trick to our hiring ease? We didn't ask people to use YUI during the interview. There was no reason -- we knew that most candidates wouldn't know the library by heart. What we did instead was ask candidates to solve their problems without using a library. We wanted to see if people understood the fundamental concepts of web development rather than one specific implementation of it. Doing that, we could filter out the people who were overly reliant on libraries and therefore would have a hard time making the transition. Further, we knew that if people understood fundamental concepts, we could easily teach them how those concepts were implemented in YUI. 

The end result was that we were able to hire people who were strong front-end engineers even when they couldn't use their library of choice. That made things even easier when we went through the transition for YUI 2 to YUI 3, which had a completely different API. Because our engineers weren't overly-reliant on one specific library, they were able to make the transition to a new library without much trouble. People didn't leave in protest, and generally people didn't feel stuck.

To this day, I am weary of engineers who apply for or promote jobs working with specific libraries. When you hire library-specific developers, you're often put into difficult personnel decisions when the library has to change. Sometimes you end up with people who just can't function without that library, and other times you can end up with people who just don't want to work with something else. The choice of library should always be based solely on the technical advantage that the library gives to your project, not on popularity or prospective new developers. As engineers, the thing that makes us most attractive to employers is our ability to learn and adapt, and it's those who continue to learn and adapt that ultimately have successful, long careers.

Be well.

JavaScript WeeklySponsor: O'Reilly Docker Online Course
Join Sean Kane for a hands-on, in-depth introduction to Docker, June 28-29. 

Recommended Links

What the heck is "Script Error"? (article)
Web browsers have a long and storied history of providing opaque error messages, and the infamous "Script Error" is one of them. Do you know what the problem is when you see that error message? Most likely, there's an issue with a script being loaded from a different domain. This article digs into the specifics behind this error message.

Accessibility and Performance (article)
You might have heard of accessibility, and maybe you've even done some accessibility work, but do you know how accessibility and performance relate? This article talks about the technical details of implementing specific accessibility features and how an internal browser structure called the accessibility tree is important. If you enjoy reading about DOM trees and render trees, then you'll enjoy learning about the accessibility tree relates to them.

Debugging Scroll Jank in Chrome 51 (video, 7 mins)
What's causing your page to scroll slowly? Chances are, you're just doing too much in your JavaScript. This video shows how to use the Chrome DevTools to identify the cause of slow scrolling and how to use passive event listeners to solve the problem. If you've never done an in-depth investigation into performance issues, this video is a great introduction to how Chrome DevTools can help.
JavaScript WeeklyHelp Support This Newsletter
Did you enjoy the newsletter? Leave a tip or become a patron.

Recommended Book

One of my favorite books, Outliers looks at different hidden trends of successful people. One of the main lessons: there is a significant amount of luck to achieve success. Why was it Bill Gates who founded Microsoft and went on to become the richest man in the world? Why was he programming before almost every other kid in the world? The book digs into that story and more. One of my favorite parts of this book is how Gladwell describes what can happen when you specialize in something while it's unpopular and then, all of a sudden, it becomes popular. I definitely experienced this effect when I learned JavaScript back in the late 1990s and all of a sudden, around 2005, JavaScript became something that was in high-demand. This book will change the way you think about success, and maybe give you some ideas about how to create more success in your own life.

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join over 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences