Skip to content
Courses CSS Nouveau Vanilla Has Never Tasted So Hot Introduction (aka Fasten Your Taste Buds)

Introduction (aka Fasten Your Taste Buds)

2025 Update: #

📣 A word before we begin. A lot has changed in the two years since I published this course. Not so much the technology of the web itself—in fact, I’d argue the principles in this course are still extremely applicable (and in fact some of my complaints regarding the Tailwind CSS framework have been resolved in version 4…huzzah!).

Rather, the ethos surrounding web development has changed. We’re now fully in the midst of the Generative AI hype cycle, and in some respects frontend web development has been hit the hardest. People are “vibe coding” their way into building new UIs and launching products, presumably. It’s tough to maintain your values and your commitment to doing things “the hard way” as in actually caring about your craft and your ability to express yourself in code sans the slop machines.

The good news for today is I’m releasing this entire course for free. AI isn’t the only reason, but I can honestly say it’s a big reason. Extremely long-time successful educators have been struggling with monetizing their experience when Claude is simply a click away, and we’ve already had quite a difficult time on our hands building strong programming communities post-Covid. (In my own town of Portland, Oregon, the “tech scene” here by and large simply dried up.)

All that to say, I remain extremely proud of this course and all that it can teach you. I hope it helps you along your journey towards maintainable and enjoyable “vanilla” frontend development, and as per usual, I too am simply a click away (on Mastodon at least!).

Enjoy! ✌️

The Rebirth of Vanilla #

A funny thing happened on the way to the year 2023.

Cascading Style Sheets (CSS) got good. Like, really, really good.

Some said it could never be done. Others said you could only really take advantage of it with clever build tools and abstractions placed on top of it. Still others shouted we should just burn it all down and start over.

Thankfully, we can say with confidence those days are over.

It’s very possible to be a skilled, confident web developer and author real, honest-to-goodness CSS.

Without hacks.

Without vendor prefixes.

Without “proprietary” abstractions and non-standard syntaxes.

Without worrying if everything’s going to break in the next browser update.

And without biting your nails that “append-only” “spaghetti code” stylesheets will render your software architecture brittle, unmaintainable, and slow.

Folks, we’ve finally arrived at the promised land.

And it’s glorious.

Wait, No More Hacks? Really?? #

It feels like nearly the entire time we’ve had HTML & CSS as a technology stack in web development, we’ve understood it as sort of a pile of hacks.

You couldn’t just “imagine” a layout and swiftly apply that layout in a completely straightforward manner using proper semantics and object-oriented-like programming logic. You were forced to ingest volumes of esoteric knowledge and offer up choice sacrifices to the gods just to get the basics done right (and even then it was rife with compromise).

No wonder backend and frontend developers have looked askance at each other. CSS was as mystical and gnostic a technology as the gnarliest stored procedure in a crufty ol’ SQL database.

The bad old days of “float-based layouts” was the most obvious example of this, but even after flexbox came on the scene, it took some time for the spec to shake out and people to wrap their heads around how flexbox essentially meant that <div>-based row/column markup had become obsolete. The native CSS grid spec itself similarly went through multiple fits and starts before it finally solidified across all major browsers…and even after that it’s taken some time to percolate through the minds of frontend devs everywhere.

Remember when installing a “grid CSS framework” was a necessity for projects of any real size? Those days are simply gone now.

Gone!

Whether you’re talking about layout, design system tokens, typography, animation, and even scoped components, HTML/CSS has solid answers for nearly all of it. (And the few remaining “nasty bits” are getting resolved at a jaw-dropping rate…)

At long last, it feels like all the low-hanging fruit has been addressed. Now we can get on to the really wild stuff. Container style queries anyone? 😏

Modern CSS is Almost Unrecognizable to a 2007-era Mindset #

In a relatively short amount of time, we’ve seen:

In short, the CSS of today is almost unrecognizable as compared to its 16-year-old counterpart. It’s a different technology altogether. It’s BONKERS.

The reason I want to focus on 2007 as a point of comparison is because—sadly—much of our industry mindset of “this is how you write CSS” still has its roots in that era. I mean, the introduction of BEM (Block-Element-Modifier) for naming classes and structuring stylesheets happened in 2005. That’s, like, a bajillion years ago!

And sometimes when you see push back against authoring stylesheets in the form of “best practices don’t actually work”, the kind and texture of vanilla CSS (often BEM in particular) being railed against remains barely unchanged from this vintage timeframe. Geez!

(The funny thing is, I probably do agree that “best practices don’t actually work”—if those practices don’t factor in all the amazing advances in modern CSS!)

We should be very wary of toolchains which are really nothing more than a regurgitation of concepts forged well over a decade ago. Whenever you see the phrase “modern web development” in these sorts of marketing materials, think “modern to a 2007-era mindset” because, often, there’s just not much very modern about it.

Ultimately It’s Not About Legacy vs. Modern, It’s About Web Standards vs. Weird Toolchains #

Listen, normally I don’t have a beef with proven tech that’s not considered “modern”. I often do champion ideas pioneered in the past and caution people not to assume “modern” automatically equals “awesome”.

However, I have a big problem when real-world modern web standards are fabulous, yet get sloughed off by tool vendors offering questionable alternatives in a bid to grow a “viral” and conceptually “proprietary” ecosystem.

I believe every frontend tool’s ultimate desire should be to become obsolete. In an ideal world, everything you require for essential website architecture would just be standardized and built into the browser or the web server you use.

With CSS, we’re nearly there. And as more time passes where the “type” of vanilla CSS being forcefully rejected is not even representative of what’s currently possible, the more my nose starts to twitch. You deserve a clearer and more honest appraisal of the current state of affairs.

YAGNAFA (You Ain’t Gonna Need A Framework Anymore!) #

In my view, the response to this unprecedented level of progress is conclusive. For most projects, most of the time, YAGNAFA. Yes that’s right, I’m pronouncing the end of an era. The great frameworks of a past age served their purposes well…Bootstrap, Foundation, Bulma. We salute you. Thank you for your service. Tailwind…that was a hell of a thing. 😂

Point is, we live in a whole new world now. What took 50 lines of code before now take two. What took 20 lines of horrible hack code before now take…nothing, because we can use another technique entirely. Take everything you thought you once knew about CSS and cast it aside. Some of it is still entirely valid and legit. Yet other aspects of it are not only unwise today, they are actually harmful to legitimately modern, vanilla-first architectures.

Good news if you’re somewhat new to CSS altogether. You are in for a real treat! Vanilla CSS is *chef’s kiss*. 🧑🏽‍🍳💋 (Consider yourself fortunate you have no idea the pain and the misery us old timers once had to endure…)

What if we need better branding than Vanilla? Maybe Strawberry! Or Mediterranean Sea Salt Caramel! 😆 #

Perhaps we should rename “vanilla” to something else. I prefer strawberrry ice cream myself. Or maybe cherry. “I deploy Cherry Style Sheets with a dash of whipped cream.” I like the sound of that. 😋

Seriously though, while it’s true that the brand cachet of “vanilla” has gotten much better in recent years, I feel like we still need to ratchet up the momentum here. Many, many developers both long-time and new still think their job requires the use of a framework, or Sass, or whatever extra heaps of build tooling. (Heck, I admit I still use PostCSS for a thin layer of syntactical sugar…)

Now don’t get me wrong: if your job necessitates that you use a framework in your course of business, then use it! Sometimes the particular needs of a particular project leads to a particular course of action for which tools are best to use.

BUT…

And this is a BIG BUT… (I cannot lie)

We need to adjust our default thinking in this area.

As an industry, we must begin to assume any new web project can start out as close to the metal as possible, since that metal has gotten so insanely capable. Then, if you really need to reach for something additional, you have the ability to do so (while fully understanding and articulating the reasons why, as well as all the potential downsides because there are often Very Real Downsides™️ to pulling in opinionated dependencies).

Even then, you still get extra brownie points if those additional tools have a bent towards integrating easily with the concepts of existing and near-future web standards.

Append-Only Stylesheets: Yep, Real Problem! The Real Solution: Object-Oriented Views #

A common complaint I hear from people who are skeptical of vanilla CSS is the problem of “append-only” stylesheets. In other words, as your project grows, you just keep adding more and more style rules to your “global” stylesheets, eventually arriving at a time when you have monstrously large files with dozens or even hundreds of “special cases” for random screens and pages scattered across your codebase.

Oh, if only you’d been able to stuff a bunch of utility classes into your HTML directly or plop blocks of CSS-like directives into JavaScript component files…problem solved, right?

LOL 😆

All you’re doing is hiding away what in the end is the same amount of complexity. Sure, you don’t have monstrously large CSS files anymore. But you do have monstrously large, complex, confusing, and WET (Write Every Time) templates.

Hate to break it to ya, but I find it personally offensive to open up a file containing HTML and have to wade through line after line of <div>s and <span> s stuffed with a cornucopia of pt-4 and md:inline-flex and decoration-dotted…WTF is all this noise doing in here? Or see a blob of sort-of CSS interpolated with a bunch of JavaScript theme data.

What’s wild about all this is true native web architecture, conceptually, is a lot less complicated than folks make out. It’s comprised of three parts (aka programming languages):

You can think about this as the three legs of a stool. Mess up any single leg, and the stool becomes wobbly and eventually falls over. Seasoned developers will also be familiar with the battle-tested principle of progressive enhancement. Because HTML is the least brittle and JavaScript is the most brittle of the three languages, you should:

The important innovation in more recent years around all this stuff isn’t that you can muddy the waters and mix your HTML into your JS code and your styling into your HTML and your complex build tools into your <div> tag soup.

It’s that you can co-locate all three languages—HTML, CSS, and JavaScript—into modular, reusable packages called components.

Components aren’t a panacea, but they offer an exciting path forward on all but the simplest of web projects because they let you apply OOP (Object-Oriented Programming) principles like encapsulation and documented public/private APIs as well as DRY (Don’t Repeat Yourself) thinking to the frontend of the web. These are the same principles we’ve used to tame complexity and enable large-yet-maintainable systems in other programming contexts for decades.

Unfortunately, “components” often arise in conversation as the sole domain of trendy user-land view libraries such as React. Need to write components for your web project? Use React! Or Vue! Or Svelte!

Here’s the thing: you don’t need any of that to build components.

All you need is a tool that can:

and then pass that along to the browser. And what’s really pretty freaking cool is that the browser already has a way to associate co-located HTML + CSS + JavaScript together. It’s called (drumroll please 🥁):

Custom Elements 🎉

We’ll dive deeply into custom elements (also known as web components) later on in the course, but suffice it to say, if your backend can render custom elements, you are golden—with minimal (if any) custom frontend tooling.

What You Need is a Design System. Migrate Away from Globals! Banish Them! #

It’s time to stop thinking of your website markup as a bunch of globally-scoped streams of text & media, and start thinking of your website as a graph of objects: discrete building blocks you can easily construct and re-use across your project many times over. In other words, these would be the “views” as articulated by the MVC (Model-View-Controller) pattern.

Need a bespoke design on a particular screen? Try as hard as possible to implement that design using the existing building blocks you’ve already constructed, rather than invent new ones out of thin air.

Yes, I’m talking about the buzzword-du-jour: design system. And yes, I’m talking about “atoms” and other components within that design system. It’s wise to be skeptical of hype in our field of endeavor, but I firmly believe all the energy around how to define and implement design systems is well-warranted.

Here’s some good news to shout Hallelujah! about: due to recent advances in HTML & CSS, we can now implement design systems using browser-native platform technologies! And this “new CSS” gives us numerous features which are perfect for object-oriented, design systems thinking. How cool is that?!

And because we can use the browser-native web platform, we can scale up or down as project requirements & team dynamics indicate. Are you a solo dev, working on a small project? Your design system can be small and straightforward…in fact, you might not even need any build tooling!

But perhaps you work with a whole frontend team on a large company project. You can still take advantage of the web platform, but now you can also invest a little more on the tooling front as well as invest in advanced techniques around modular design and layered architecture to “scale up” your design system.

Either way, the web has got you covered.

Vanilla, cherry, strawberry…whatever we’re calling this awesome new world, it’s time to dive in and see what’s possible. In the next episode, we’ll start at the very beginning and evaluate what—if anything!—we actually need to “reset” as we set up a greenfield CSS project.

Let us begin.

Next Episode:
The New CSS Reset…