Are you nostalgic for a way of building websites gone by?

You’ll hear people say they miss the Movable Type days. Or that Adobe should have never killed off Fireworks. Or in their heart they are still a MooTools stan. Or that their good ol’ days were Backbone and Lodash. Laying out sprites was their heyday. Table-based layout still makes the most sense to them. Every image should open in a lightbox.

Some people are nostalgic for period of web development gone by.

Has it gone by, though?

I was thinking of this during a recent episode of Jake and Surma’s new show Off The Main Thread where they were talking about build tools. Passingly, they mentioned that if there is some past way of making websites, well, you can actually still do that if you want to.

There are some notable exceptions like Flash, which no longer works in web browsers, but as far as direct web technology is concerned, the web is nearly perfectly backwards compatible, and as long as you’re shipping the browser things it understands. If you’re shipping HTML, CSS, JavaScript, and media formats it understands, it will work now just like it did in whatever period you were nostalgic for. Probably better.

You don’t have to use new frameworks and libraries. You don’t have to use new build tools or bundlers. You don’t have to wire up a fancy CI/CD pipeline. For the record, frontendmasters.com is built in vanilla JavaScript, so arguments that only small and simple sites can be done that way can be suspended.

If you loved Movable Type, that’s still a thing. Need an RSS feed? You can just write one by hand, I remember Jeremy Keith saying that’s what he did for the narration of the Web History series, which he made into a podcast by virtue of hand-crafting the XML file. No tooling needed. Annoyed with Photoshop that makes you have a subscription? Try Acorn, it’s pretty good.

The root point about constructing websites is especially true: if you could do it, then you can do it now.

When I asked around about nostalgic ways of building websites, I got a lot of replies about doing things the vanilla way. Just… write the code. That’s always an option. It’s a good option. It’s the option that isn’t fragile and will break over time as it doesn’t have any dependencies other than a way to edit text. It also has a side effect of being extremely portable. Raw HTML, CSS, and JavaScript can be served by any ol’ web server.

The other thing I found people interestingly nostalgic for is FTP. Changes to a file? You upload them very directly to your server over FTP, File Transfer Protocol, that is. There is something very raw and direct about that that appeals to some people. Perhaps it is that this process can be so heavily abstracted these days that when things go wrong, they miss the old days when almost nothing can go wrong with FTP.

Before you think I’m some new technology eschewing luddite, I actually quite like new technology. For the most part, I think the way we build websites now is largely better. I think source control (likely: Git) is near-vital for teams working on code together. It’s not viable for a team working on a large piece of software to have no idea what is changing. And using that source control as a home base for more detailed communication, testing, deployment, and everything else just makes good sense. Build processes that take our human-authored code and make it better and more efficient for users also makes good sense, so long as we take care to make sure the value tradeoff between increasing complexity and fragility via tooling and providing value to ourselves and users ends up a net benefit.

It’s never “too late” to roll back complexity, knowing that the raw languages that power the web are still essentially viable to author by hand, or at least by less tooling.

There is more to this story though, and I bet some of you, if you’ve made it this far, are frothing at the mouth to tell me. I’ll oblige: jobs.

If you aren’t a top-decision maker at your place of employ, or perhaps are looking for that place of employ, you may not get to make choices about what technology you use to build websites at all. Whatever you are nostalgic for, or deeply wish for, might be entirely off the table. You can always make your case. Paint a picture of what value might come from a simpler approach. But there is no guarantee that you’ll win — and in fact — you might not even be right. I’ve made the mistake of having too much bravado in my rightness of opinion when, looking back, I wasn’t even right.

So you might have to build websites based how you’re told to build websites. That’s just the way of the world. So if you need to build a website using React, a package.json with 90 dependencies, a 90-minute deploy processes, and god knows what else, well, that’s just what’s up right now, and the next step on your journey might be different, especially if you want it to be. I’d even advocate that you learn whatever you need to learn to get and stay employed, as your life and stability is worth a hell of a lot more then some theoretical purity of website construction.

That all said, I have also always thought there was room in the world for an agency that produces entirely vanilla websites. So many agencies ultimately produce one-off pages. A landing page for a marketing campaign, for instance. I think it would be rad to always make those sites with zero dependencies, making that part of your marketing. Simple, fast, secure, easily portable, etc. Just a thought!

Good luck — and embrace the best parts of your nostalgia!