The Lean Web Approach: An Interview with Chris Ferdinandi
JavaScript has taken over the web but it’s not all good. Chris Ferdinandi aka the vanilla JS guy, explains how simplifying front-end development practices can help us build a faster, more resilient web
If he tried it today, Chris Ferdinandi isn’t sure he would be able to make the jump into web development. He taught himself to code and transitioned from a career in HR when responsive design, HTML5 and CSS3 were the hot new things. As everyone wanted developers with JavaScript experience, Chris also started learning jQuery and plain JavaScript in order to land himself a job.
These days, however, he’d be completely overwhelmed. He believes that the web has become a bloated, over-engineered mess and that many of our modern best practices are actually making the web worse. Now Chris has written an ebook, The Lean Web, to share some ideas on how to fix it and explore a new set of principles for a simpler and faster web.
“If I had to sum up what modern web development has evolved into, it would be ‘JavaScript all the things’,” he explains. “JavaScript is at the heart of how so many folks build for the web today. It manifests itself in things like JavaScript frameworks but also module bundlers, single-page apps and CSS-in-JS. It’s complicated and it’s exhausting.”
The impact of an over-reliance on JavaScript
JavaScript-heavy tooling and processes can have negative consequences. Chris says they make it harder for new developers to get into the profession and they exclude people without JavaScript expertise from the process (for example, UX, CSS and accessibility experts). Most importantly, however, the over-reliance on JavaScript makes the experience worse for the user:
“JavaScript is the most expensive and most fragile part of the stack,” Chris points out. “We have at our disposal the most powerful internet browsing devices and fastest connections that have ever existed but they’re not evenly distributed. For a lot of people the web is painfully slow or not usable at all because of all the JavaScript dependencies. You end up with this really delicate house of cards — if any one piece falls out of whack, the whole thing comes crashing down around you!”
One of the causes behind this evolution is that, as an industry, we’re obsessed with bright and shiny new things. It makes it exciting and we constantly chase new tools and techniques. It’s important to realise, however, that the problems big companies face are not necessarily the same problems that smaller companies face.
“Some of the tools were created to answer or address real problems that a certain segment of developers have but they then get used for cases they weren’t really intended for,” Chris cautions . “For example, a tool like React makes sense for an app of the size and scale of Facebook. It improves front-end performance and makes it easier for the massively distributed team to collaborate. But then a team of five at an agency starts using it for everything and they ship 30 kilobytes of JavaScript down the wire for a use case that React wasn’t really built for. Most of us don’t build apps that big, most of the things we build will never get that big and still we use tools designed to solve problems we don’t actually have. We’re inheriting solutions to other people’s problems, not ours.”
Chris also thinks that JavaScript developers are often more valued within an organisation and have the most influence on how apps and sites are built, which leads to even more JavaScript. “If you’re a hammer, everything looks like a nail. When the people who make the front-end design decisions specialise in JavaScript, they will use it to solve all the problems because it’s the tool they know best when really another part of the stack may be more appropriate. Module bundlers, for example, are designed to help address some of the challenges around shipping so much JavaScript in the first place because it’s bad for performance. So we invent tools that help you more efficiently load JavaScript but we’ve created a problem with JavaScript and then we attempt to solve it by slapping on top even more JavaScript, which feels a little bit silly.”
Less is more: The Lean Web
A lot of the issues that these tools aim to address could be solved more simply and elegantly with techniques that lean a little more heavily on core concepts, HTML and CSS and only on JavaScript when necessary, Chris believes. The ethos of the term ‘the lean web’ – coined by Thomas Fuchs – resonated with him and so he started compiling his thoughts into a central resource.
“The Lean Web is an approach to web development that focuses on simplicity, performance and the user over the developer experience,” he explains. “In many ways, it’s a little bit like becoming a developer dinosaur: you’re going to end up relying on some older techniques and maybe chasing the bright and shiny stuff less. I’m not saying you should never use new techniques but I want to encourage folks to be a little bit more thoughtful about the tools they use and why.”
Chris summarises The Lean Web with three principles. The first one is to embrace the platform and everything it provides out of the box. “Modern browsers are incredibly capable tools,” Chris says. “They give you so much for free and still we recreate a lot of it with JavaScript. Rather than using dependencies or libraries, use HTML, CSS and native JavaScript methods and browser APIs – vanilla JavaScript – whenever you can.”
Secondly, instead of reaching for large multipurpose tools, Chris recommends using small, modular tools that do just one thing well. “We tend to go for the pocket knife that does 24 different things but maybe all we need is a pair of scissors. For example, instead of downloading all 27 kilobytes of Lodash, when you only need one or two helper functions, you can extract those or use a small helper function that does exactly the same thing at a fraction of the size. There are also some substantially smaller alternatives to frameworks like React and Vue that shed a lot of the tools that were designed for Facebook- and Twitter-sized apps. Svelte comes to mind or Preact, which uses the same API as React, but is only three instead of 30 kilobytes.”
The final principle is remembering that the web is for everyone. Chris points out that we break experiences when we only focus on the latest browsers and devices and neglect to take into account users on lower incomes, slower networks and those with diverse abilities.
Building websites like it’s 2005
To prove that some well-known companies actually build sites and apps the ‘lean web way’, Chris used to maintain a list of organisations at vanillaJSlist.com. “GitHub removed jQuery from their app last year,” Chris explains. “Instead of replacing it with a modern framework, they opted for native browser methods and custom web components. Internally, they have a motto to build websites like it’s 2005, so whether you have JavaScript turned off, it fails or you’re on a slow connection, you can still perform all the primary tasks. Netflix ripped React out of their default front-end page load last year and saw big performance improvements. They still use React server-side for templating but initially you get just HTML, CSS and vanilla JavaScript. As a result their load time and time-to-interactive decreased by 50 per cent!”
The Lean Web, also a conference talk, is a culmination of spending a lot of time evangelising for the use of vanilla JavaScript instead of libraries and frameworks. On top of this, Chris writes short pocket guides and creates video courses covering vanilla JS for beginners, puts together real projects for people to build for a deeper learning-by-doing dive and runs a 10-week online training programme called the Vanilla JS Academy, designed to help beginners solve problems and think in JavaScript. “Every other day you get one or two short lessons followed by a project to work on,” Chris says.
“On the in-between days, I share my approach to the project and some common challenges and ‘gotchas’ that students run into. There’s also video office hours every few weeks for people to ask questions. This is the fifth time I’m running this programme and it’s the most successful one yet with the most engaged students. They help each other out and analyse each other’s code. It’s my favourite thing: I love helping people learn.”
Modern web development doesn’t need to be complex
Chris also hosts a podcast and every weekday sends out a short email with a developer tip or trick, code snippets, tools, techniques or just something interesting he found on the web. The list has grown to more than 7,500 subscribers – a massive jump from when it was a weekly newsletter.
“Two years ago I had just 38 subscribers and I was struggling to grow it,” Chris remembers. “But then a business coach I was working with challenged me to write every day, which I thought was going to be complete madness at first. I didn’t think I could keep up with that cadence and that no one would want to read that many emails from me. But I came up with 28 ideas for articles in 10 minutes and just started writing. Then this crazy thing happened: people started asking questions back, which made it really easy to write more emails. Within three or four months the list had grown to a few hundred people, after a year it was up to 3,000 subscribers and then it doubled again over the last year. Now I have a back catalogue of 99 articles that I want to write.”
Whatever the learning resource Chris is working on (next he’s going to update some of his pocket guides and add more self-paced projects), the aim is always to demonstrate that modern web development doesn’t need to be complex and that we’re using too much JavaScript, which is hurting the web. A simpler, saner and more resilient method of building engaging, cutting-edge sites and apps without all the cruft really is possible.
This article originally appeared in issue 327 of net magazine in 2020 and has been reviewed by Chris Ferdinandi prior to republication.
