Choose Vanilla
In developer parlance, vanilla means the basic, unadorned version of a product or language. No sprinkles, no whipped cream; just plain ol’ vanilla.
When deciding to build this site, I chose the “hard way” — pure HTML, CSS, and JavaScript. No frameworks, no drag-and-drop builders, not even a static site generator. Back then, I didn’t even know what a static site generator was.
Why would anyone do that, especially with so many shortcuts available today?
I like the easy way - who wouldn’t? Thing is, building from scratch taught me more than any shortcut ever could. I wanted to learn. More than that, I needed to. I had a hunch this path would force me to grapple with the fundamentals — but I didn’t yet know how far that would take me.
So I followed my gut, and jumped right in.
Baby Steps
I started immediately, jogging through tutorials, pasting code, breaking things and refreshing endlessly. After a few hours I took a screenshot of my first site and sent it to my brother. It was a blindingly mint green page with 3 lines of text and a button in the upper left corner. When you clicked it, a pop-up appeared: “Hi!”
It was suuuper basic. And I couldn’t have been prouder - my own slice of the internet, right there!
Why Not WordPress?
Seeing that a few lines of text took me hours, it was going to take days to get something presentable. Which begs the question - why not just use the tools already out there?
Fair question. If all I wanted was a blog, I could have cooked it up on WordPress or Squarespace and been done before lunch. But I had that hunch I’d use site-building skills for more than a blog. A blog was just a great place to start. Plus, if I built on someone else’s platform, it wouldn’t really be mine.
For me, it’s about the pride of craftsmanship and having complete control. Frameworks and pay-to-post sites just can’t provide that. And, if I stop paying or don’t own the source code, the whole thing is subject to the whims of someone else’s platform.
The goal was clear: this will only be the beginning of my foray into development. So I kept going.
Repetition, Frustration, & Discovery
Treating this site as a training ground, I gave myself permission to struggle through the basics. The early days were full of discoveries: learning typography concepts like padding and margin, seeing how different browsers rendered things, and even getting a glimpse into the history of website design and the early internet.
It was amazing to be a beginner again, soaking in new information and deploying it as fast as I could. Every day I was tweaking, refining, & making small improvements that felt huge at the time.
Every improvement came with a cost, however; I’d copy my template across few pages, then realize the navigation bar needed a change. Suddenly, I had to revisit every page and make the same fix by hand.
If you’ve ever built something yourself, you know how this goes. The more it grew, the heavier each little change became. Before long, the fun, creative spark was fizzling, and most of my energy got swallowed into backtracking and untangling problems I’d created for myself.
As an aside, I would take breaks by diving into the early internet and indulging in the simpler times. I highly recommend tripping through nostalgia lane on this wild page that captures the glory of old GeoCities archives from the late 90’s and early 2000’s. Stuff like this inspired me to keep going, and build something that was truly mine, even if it’s super wacky: www.cameronsworld.net
No one wakes up thinking, “I’d love to invent a static site generator today.” Those things are born because developers, just like me, get tired of copy-pasting the same header and navigation across dozens of pages. We need a way to update a template once and have it ripple everywhere. Same thing with CSS frameworks. I ended up making my own version of both.
That’s the beauty of starting vanilla: the frustration teaches you the why behind the tools. Tools are built to solve specific problems. If you never face the problems yourself, you don’t really understand what’s being solved.
Picking Up Power Tools
Starting with vanilla HTML, CSS, and JavaScript was like learning to use a screwdriver to assemble furniture. It was slow, sometimes frustrating, but every turn taught me something about the mechanics of the craft. I learned what worked, what didn’t, and how the pieces fit together.
Once I got a grasp of the basics, I reached for the power tools. For me, that’s where large language models came in. These aren’t a replacement for understanding; they’re force multipliers. LLMs have been trained on mountains of vanilla HTML, CSS, and JavaScript. When you prompt them, they often start from these fundamentals, building on the same foundation you’re learning.
Used well, they amplify your work, letting you experiment, iterate, and scale faster than you could by hand alone. Used without a grasp of the basics, they can be frustrating, confusing, and even counterproductive.
The lesson is simple: start with the fundamentals. Struggle through the copy-pasting, the margin tweaks, the line-height experiments. Learn what it really means to build something from the ground up. Only then will the power tools truly make you unstoppable.
Starting with the fundamentals means that once you’ve struggled through them, you can build anything.
Choose Vanilla
So here’s the takeaway: don’t rush for the shiny tools. Start with the basics. Build something by hand, mess it up, fix it, and feel it in your hands. When you graduate to power tools — LLMs, frameworks, whatever comes next — you’ll wield them with purpose, understanding, and control. That’s when building becomes not just faster, but smarter. Choose vanilla. Master the fundamentals. And then, go make something that’s truly yours.
Ashton