This is a list of people who influence how I think, not only about JavaScript, but also about writing code for a living. If you don’t follow these folks, I encourage you to do so. For each person, I provide links to their Twitter profile as well as some of my favorite parts of their work.

Rich Harris

I’m kicking things off with Rich because I love the way he thinks. He’s the author of multiple projects that you may be familiar with including:

  • - an ES6 module bundler most often used in libraries
  • an innovative front end framework that is super fast 🚀
  • - another front end JavaScript framework Rich created while working at The Guardian

Here’s one from Rich that gives a sense of what he focuses on in his work:

We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use – and that what really mattered was performance once your app was already interactive.

But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly.

And on CSS:

It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.

So the JavaScript community rolled up its sleeves and got to work. Over the last couple of years, there's been a Cambrian explosion of libraries aimed at making CSS behave, collectively referred to as CSS-in-JS.

What you might not realise is that the biggest problems with CSS can be solved without CSS-in-JS. Without those problems, writing CSS isn't just tolerable — it's enjoyable. And you don't have to find solutions to the additional problems that CSS-in-JS introduces.

Selected writing:

Twitter:

Dan Abramov

Aside from being a great developer, Dan is one of the most generous and patient people I’ve seen in issue queues. He is the author of the popular state management library, Redux, as well as a member of the React team. And through his work on Redux, Dan is responsible for introducing me to functional programming.

A from Dan:

Experts often don’t know the problem any better than you. What they learned is not to trust themselves. They dig deeper and keep reducing the test case even if nothing obvious jumps at them for several hours. They know there is a problem somewhere, and finding it is a boring, mind-numbing but usually finite process.

Selected writing and talks:

  • (if you want your library to do well, write docs like Dan)

Twitter:

Kyle Simpson

Kyle is a prolific author and trainer. If you’ve been following JavaScript for a while, you’ve almost certainly come across his work at some point. There have been quite a few times when Kyle has made my brain hurt. This dude knows JavaScript in a deep way…and yet he makes it accessible for people just getting started.

A couple of my favorite books from Kyle are (that book is $2.99 by the way!) and his latest, , which is fantastic.

In addition to his books, Kyle has done a through Frontend Masters. You may also be able to access those courses on Pluralsight, Lynda.com and other places, so be sure to look him up if you have a membership to those sites.

Great by Kyle:

I've come to believe something very deeply in recent years, so much so you could almost call it a religious belief. I believe that programming is fundamentally about humans, not about code. I believe that code is first and foremost a means of human communication, and only as a side effect (hear my self-referential chuckle) does it instruct the computer.

The way I see it, functional programming is at its heart about using patterns in your code that are well-known, understandable, and proven to keep away the mistakes that make code harder to understand. In that view, FP -- or, ahem, FLP! -- might be one of the most important collections of tools any developer could acquire.

One …love this!

They say knowledge is power. I disagree. Knowledge is potential. Skill is what you do with knowledge. And that is power.

Selected writing:

  • (six book series)

Twitter:

Gregory Brown

It’s not just that Gregory is a good software developer, it’s that’s he’s a wise software developer. And he has a knack for saying things in a way that I really connect with. For example:

When first starting your career, spend time getting to know people much older than you... They have insights that will prepare you for the road ahead. As you advance in your career, spend time around people much younger than you. They will challenge your views and inspire you. ()

And…

Reading articles and books is not practicing, it's studying. Watching screencasts is not practicing, it's studying. Listening to podcasts is not practicing, it's studying. Attending talks is not practicing, it's studying. Want to improve quickly? Study less. Practice more. ()

He’s also the author of . Great title, right? Gregory isn’t a JavaScript developer per se, but his insights apply to anyone writing code for a living.

Selected writing:

Twitter:

Addy Osmani

For me, Addy is often the voice I hear on a project saying to me, “You can do better.” Since Addy is a tireless advocate at Google for web performance, his words often come when I’m trying to get a site to load just a little bit faster. To my mind, Addy is one of the people making the web a much better place.

Great from Addy:

When you’re given too much choice you can also end up increasing your expectations. Maybe you feel that if you hold out, you’ll find the ‘best’ one. The unicorn in the herd. Clearly, with so many options to choose from, the correct choice must be amazing. Often, however, on discovery of what the ‘correct’ choice is like we can feel unfulfilled. Such high expectations are difficult to meet, leaving us in a state of unquenchable dissatisfaction…

..If you’re an experienced developer speaking to someone stuck on a decision, try to help them simplify their options. It’s a freeing experience and may help narrow down their choices to something that doesn’t feel so daunting. Even taking a few off the potential list can give them an opportunity to get more clarity and choose something they can at least evaluate before making a final decision.

If you’ve followed my previous writing on speedy JavaScript frameworks, you’re seeing some of Addy’s influence coming through. He really inspires me to do well in this area and help promote a high performance web.

Selected writings and talks:

  • (conference talk)
  • (conference talk)

Twitter:

Evan You

Evan is the author of the wildly successful UI framework, Vue.js. At this writing, Vue is the third most used front end framework, and it has achieved this by a different path. Rather than having corporate backing, Vue is funded by donations from the community. I truly admire Evan for not only creating great software, but doing so solely with donations from the people that use his software, which is a hell of an achievement in itself.

Here’s a from Evan on how Vue differs from React and Angular. It offers some insight into the basic philosophy of the project:

On a framework level, we tried to build it with a very lean and minimal core, but as you build more complex applications, you naturally need to solve additional problems. For example routing, or how you handle cross component communication, share states in a bigger application, and then you also need these build tools to modularize your code base. How do you organize styles, and the different assets of your app? Many of the more complete frameworks like Ember or Angular, they try to be opinionated on all the problems you are going to run into and try to make everything built into the framework.

It’s a bit of a trade off. The more assumptions you make about the user’s use case then the less flexibility the framework will eventually be able to afford. Or leave everything to the ecosystem such as React — the React ecosystem is very, very vibrant. There are a lot of great ideas coming out, but there is also a lot of churn. Vue tries to pick the middle ground where the core is still exposed as a very minimal feature set, but we also offer these incrementally adoptable pieces, like a routing solution, a state management solution, a build toolchain, and the CLI. They are all officially maintained, well documented, designed to work together, but you don’t have to use them all. I think that’s probably the biggest thing that makes Vue as a framework, different from others.

Selected Talks:

Twitter:

Axel Rauschmayer

In my mind, Dr. Rauschmayer is a bit like Kyle Simpson — a super smart guy that has incredibly deep knowledge of the JavaScript language. He’s the author of , but he’s probably best known for the frequent posts on his which tends to focus on new features of the JavaScript language.

For some of his additional writing, see , a collection of freely available online books that deep dive into the latest JavaScript features and how to use them.

From Dr. Rauschmayer:

In almost all cases, the ergonomics of reading trumps the ergonomics of typing: code is only written once, read many times. ()

And…

The most beautiful programming language in the world is useless unless it allows you to write the program that you need. ()

Selected writing and talks:

  • (conference talk)

Twitter:

Sarah Drasner

Sarah is best known for her work with SVG animations. She’s recently had a book published on the topic, . That said, I think of her mostly in relation to Vue.js, where she’s a member of the core team. She’s also written a ton of great articles about the framework, mostly aimed at helping beginners get started.

From Sarah:

We lie to ourselves in myriad ways. We might spend the time writing a comment that could be better spent making the code cleaner to begin with. We might also tell ourselves we don't need to comment our code because our code is well-written, even if other people might not agree.

There are lazy crutches in both directions. Just do your best. Try not to rely on just one correct way and instead write your code, and then read it. Try to envision you are both the author and maintainer, or how that code might look to a younger you. What information would you need to be as productive as possible? ()

Also…

Animation is 10% learning browser specs, animation libraries, and motion theory and 90% sitting around adjusting timing until my eyes bleed. ()

Selected writing and talks:

  • (with Kent C. Dodds)
  • (conference talk)

Twitter:

André Staltz

One of the of reactive programming I’ve seen is by André. In addition to that write up, he created a that builds on the topic and delves into RxJS. He’s also the author of the functional, reactive JavaScript framework, .

But André makes my list because of his advocacy for an open web. Frequent targets of his criticism are Facebook and Google. He often reminds me of what’s at stake and why I should care deeply about those issues.

From André:

I actually have hope for the Web. There are legimately viable ways of preserving freedom on the Web while taking the platform forward and keeping it competitive against proprietary alternatives from tech giants. But it can only happen if the Web takes a courageous step towards its next level. If it stays in its current form, the Web has little chance of being relevant while America’s , the , and tech giants build their Web-less vision of the future. ()

Selected writings and talks:

  • (conference talk)

Twitter:

If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

Until next time, happy coding…