In today’s episode, I talk about what the Lean Web actually is.
- The Lean Web Club - https://leanwebclub.com
classListAPI - https://gomakethings.com/how-to-add-and-remove-classes-with-vanilla-js/
Today, I’m talking about what the Lean Web actually is. Let’s dig in.
One of the challenges here is that there’s, I think, some clear things that are definitely the Lean Web or not, and then there’s this whole gray area in between. And that’s what I wanted to explore on today’s episode. One of the big challenges here is that the Lean Web is a philosophy, not a tech stack.
It’s an approach to web development that focuses on fast, resilient experiences that work for everyone, but it’s not a tech stack. There are some tools and implementations that are pretty clearly Lean Web and some that are clearly not, but there’s a whole bunch of gray area in the middle, this it depends kind of stuff.
And so what exactly makes something Lean Web? There are a few core principles. The first one is to embrace the platform. So if there’s a browser-native feature that does the thing you need and does it excessively, prefer that over a third-party library.
For example, if you’re getting some elements on the page and just toggling some classes with them, use the query selector method and the class list API instead of jQuery. If you need to call an API, use the fetch method instead of a library like Axios.
If you want to animate scrolling to an anchor link, use the scrollBehaviourSmoothCSS property instead of intercepting clicks and using the scrollTo method. And I’ll drop some links to some of this stuff down in the show notes.
The web platform can do amazing things, and you should use it to your full advantage. Of course, there are times when the things you want to do aren’t supported, and that brings us to principle two, which is to favor small modular tools. The web platform is so powerful, but when it can’t do what you want out of the box, choose tools that are small and that are modular instead of these big, all-encompassing, dependency-requiring kind of libraries that seem so popular in our industry right now.
So for example, there are no native drop-down or toggle tab elements.
There’s no baked-in feature for DOM diffing. For these things and many more, you’re going to need to either write your own custom code or reach for a third-party tool. And when you do, you should favor tools that are small, modular, and dependency-free. For example, a library that just handles drop-down menus is better than one that requires React or Vue to work.
If you need state-based UI in your project, something like my own library, Reef, or Preact, or Solid.js are better choices than React or Vue. They’re a fraction of the size, have fewer abstractions, and render DOM updates faster too. Instead of multi-tools, opt for single-purpose tools that don’t lock you into a broader ecosystem.
And principle number three is to build a web for everyone. If a site isn’t accessible or only works in certain browsers or crashes on slow internet connections, it’s not the lean web. The lean web is for everyone, and the things we build must be too. Doing that means that you need to understand semantic HTML and how people with various disabilities navigate the web.
And this is a drum that I will just keep hammering on. The tools that we use make the development process easier for some people and keep a whole bunch of other people out of it.
And they also create tool chains that are frankly kind of a nightmare to maintain. Something we don’t talk about nearly enough is how simpler web development approaches are actually better for developers too. Cover that in a future episode. And this all brings us to the gray area.
There are some things that are clearly lean web and some things that are clearly not.
- A single page client-side React app, very much not.
There’s no question in my mind that the first thing is lean, the second thing is not. But because the lean web isn’t a tech stack, there’s a whole bunch of stuff in the middle where it gets murky.
- Is a WordPress site lean web? It could be. With good server-side caching, it can be really fast. You can rip out the default jQuery that gets loaded and serve mostly HTML and CSS.
- Can complex browser apps ever be lean web? I think so, but I’m not really sure where the line is that says one app is and another isn’t. As a generalization, I’d say rendering whatever you can with HTML and then progressively enhancing the interactive bits gets you in the right direction though.
So that’s just my opinion. What do you think? Are there any principles that you’d add and that you’d remove? Any hard lines that make something squarely lean web or not?
Feel free to send me an email over gomakethings.com. I just, I’d love to hear your perspectives on this or find me on Mastodon and we can chat about this more because it’s something I’ve been giving a lot of thought to and these lines are not always clear. So it’s just, I think a really interesting conversation that I’d love to talk about more.
And if you join today, it’s free. So you don’t wanna miss out on that. That’s it for today and I will see you next time. Cheers.