February 02, 2016
From nczonline.net, with love.


Hi everyone,

Change is hard, especially when it comes to something you know and love, like JavaScript. I've been writing about ECMAScript 6 for over two years and have spent a lot of time researching not just the implementation but the origin and rationale for new features. I haven't always been a fan of the everything, but I have come to a good understanding of why certain design decisions were made and the problems they are meant to address (these discussions are found in my book, which you can read online for free).

What's concerning to me is that we're already seeing a bit of a religious war going on with respect to ES6. People are making blanket statements that things like classes are bad and should be avoided at all costs, that arrow functions are horribly unreadable, and they don't understand why anyone would use template literals. The spread of FUD (fear, uncertainty, doubt) around ES6 features is scaring off beginners for no good reason.

And what bothers me even more is that many of the articles (though not all) I've read proclaiming some part of ES6 as "bad" are written by people who obviously have never even used the features they're criticizing. They're read description and looked at some examples, but never tried to actually use the features themselves. They focus a lot on aesthetics or how it's going to be confusing, but without trying to use them, how can you possibly know whether or not something is a problem?

I know the Internet is the place where people go to complain, but we owe it to ourselves to at least be informed about the things we don't like. After years of writing about ES6, despite my early reservations, I've come to have a deep appreciation for this evolution of JavaScript and the immense amount of thought that the committee put into these features. Yes, I think ES6 was too big and some of the features aren't completely hatched, but I haven't seen anything that I'd caution people to avoid. There are always incorrect uses of language features, but that's how best practices eventually develop. Let's find the rough edges and sand them down rather than throwing everything away because it looks different than what we're used to.

My ask of you is that if you come across one of these FUD articles, don't share them unless they are clearly researched and articulate something more than, "ew, yuck." There are plenty of people who are still uninformed about ES6, and we need to ensure that those posts we share with friends and colleagues are the ones that will educate, not scare them.

And don't forget, if you don't like some feature, you don't have to use it!

Be well.


P.S. If you have a minute, please fill out a brief survey about this newsletter. There are only five required questions and it will help me figure out how to keep this newsletter interesting for you!
JavaScript WeeklySponsor: Microsoft Edge
We're building Microsoft Edge in the open. View our roadmap.

Recommended Links

The Accessibility Mindset (article)
Accessibility myths like it's too difficult and too time consuming are still prevalent in web development. This article shows how this isn't necessarily the case, and how simple choices of markup can make a big difference. With example videos that show how screen readers interpret different HTML, this article is a must-read for a better understanding of basic accessibility concerns.

Front-end Application Libraries and Component Frameworks (article)
There's no doubt that client-side JavaScript architectures have shifted towards components. Each library has a slightly different take on components, and this article digs into some of the more popular libraries to compare and contrast their design and implementation. Covering Polymer, React, Rio.js, Vue.js, Aurelia, and Angular 2, you'll get a good overview of how components come in all shapes and sizes, their commonalities, and their differences.

What can we learn from how jQuery symbiotically pushed the web forward? (article)
It's been a decade of dominance for jQuery, the first real break-out JavaScript library. This article journeys back and explores how jQuery became the dominant player in client-side libraries and what parallels, if any, the current React movement has. 

Recommended Book

Back in the "old" days, Microsoft was famous for asking brain teasers as part of their interview process. The process was later famously adopted by Google, and How Would You move Mount Fuji? takes you inside that world, where interviewing for software engineering positions meant facing bizarre and downright nonsensical questions. How would you move a mountain? Why are manhole covers round instead of square? Why do mirrors reflect left to right instead of up to down? While brainteaser interviews have fallen out of favor, this is a great book to help you think more creatively about problem solving by investigating these riddles to reveal the methods for coming up with a solution.

Recently on NCZOnline

React and the economics of dynamic web interfaces
I've been doing web development since 2000, and in that time I've seen eras marked by libraries and frameworks come and go. The Ajax era began around the same time as the jQuery era began, the Backbone era began several years later, and the React era really began about two years ago. Each of these...

Why I'm not using your open source project
When you think of open source software, you might think of a few specific projects depending on your area of interest. If you work on web applications, the term "open source" might conjure up visions of Apache or Node.js; if you're into big data, then perhaps Hadoop comes to mind; if you care a lot...

Hidden performance implications of Object.defineProperty()
I've recently been working on a project to port Espree[1], the parser that powers ESLint[2], to use Acorn[3]. In so doing, I ran into an interesting performance problem related Object.defineProperty(). It seems that any call to Object.defineProperty() has a nontrivial negative affect on performance in V8 (both Node.js and Chrome). An investigation led to some...


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 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