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:
- Rollup - an ES6 module bundler most often used in libraries
- Svelte - an innovative front end framework that is super fast 🚀
Here’s one quote from Rich that gives a sense of what he focuses on in his work:
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 another 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.
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.
- Frameworks without the framework: why didn't we think of this sooner?
- The zen of Just Writing CSS
- Sapper: Towards the ideal web app framework
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 quote 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:
- Asking Good Questions
- Beyond React 16 (video)
- Redux documentation (if you want your library to do well, write docs like Dan)
- You Might Not Need Redux
In addition to his books, Kyle has done a number of courses 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 quote 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 more…love this!
They say knowledge is power. I disagree. Knowledge is potential. Skill is what you do with knowledge. And that is power.
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. (ref)
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. (ref)
- The end of the beginning
- The traits of a proficient programmer
- Empathy: The key to a successful software project
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 quote 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.
Selected writings and talks:
- The Browser Hackers Guide To Instantly Loading Everything (conference talk)
- Fast By Default: Modern Loading Best Practices (conference talk)
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 quote 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.
From Dr. Rauschmayer:
In almost all cases, the ergonomics of reading trumps the ergonomics of typing: code is only written once, read many times. (ref)
The most beautiful programming language in the world is useless unless it allows you to write the program that you need. (ref)
Selected writing and talks:
Sarah is best known for her work with SVG animations. She’s recently had a book published on the topic, SVG Animations: From Common UX Implementations to Complex Responsive Animation. 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.
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? (ref)
Animation is 10% learning browser specs, animation libraries, and motion theory and 90% sitting around adjusting timing until my eyes bleed. (ref)
Selected writing and talks:
- An Open Source Etiquette Guidebook (with Kent C. Dodds)
- The Art of Comments
- Intro to Vue.js: Rendering, Directives and Events
- SVG Can Do That? (conference talk)
- Replacing jQuery With Vue.js: No Build Step Necessary
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.
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 FCC kills Net Neutrality rules, the W3C favors DRM, and tech giants build their Web-less vision of the future. (ref)
Selected writings and talks:
- The Web began dying in 2014, here's how
- A plan to rescue the Web from the Internet
- Cycle.js and functional reactive user interfaces (conference talk)
Until next time, happy coding…