In our incessant rush to move quickly, everything is ephemeral. Technology moves so quickly that today’s strong favorite is outdated in a matter of years. We slurp up notifications and are fascinated by the next thing before we even fully understand the current thing. The web stack du jour has changed countless times since the first web page went online in 1991, but the fundamental web stack is as reliable today as it was when that first web page went online. You don’t even need a compiler.
Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.
Regardless of the pace of improvement, we’re never satisfied. We over-engineer, create a web of dependencies, and make the web less approachable and more brittle than ever, and for what? Because learning and understanding CSS, semantic markup, and accessibility is challenging?
…it always seems to boil down to the fact that CSS is simultaneously too easy to bother with, yet so hard it needs to be wrapped up in a ball of JavaScript…
Innovation and pushing the boundaries moves us forward, but longevity, accessibility, approachability, and reliability tend to win in the long-run. More often than not, the new technologies don’t only address shortcomings. They bring shortcomings of their own or fail to use the underlying technologies appropriately. And for every new dependency you introduce, you also introduce maintenance, security risks, and other distractions.
And this isn’t new. It’s history repeating itself. In 2007, David Heinemeier Hansson wrote
The majority of web sites and applications still suck. And if most developers and designers can’t make a clean run with the training wheels and constricted playground of HTML, then we probably are in no rush to start playing with a Ducati on the Autobahn.
Several years later in 2014, Jonas Downey shared similar thoughts
Who knows who will take over the site in the future. I’ll hang with it for a while, but someday someone else might have to work on it. It would surely be easier to do that with 8 simple, straightforward HTML files than with some custom WordPress installation that’s several versions out of date. So what if I have to repeat the navigation markup 8 separate times? it’s not that hard. We used to do it for much larger sites!
Even more recently in 2018, Frank Chimero shared his experience that everything easy is hard again.
So much of how we build websites and software comes down to how we think. The churn of tools, methods, and abstractions also signify the replacement of ideology. A person must usually think in a way similar to the people who created the tools to successfully use them. It’s not as simple as putting down a screwdriver and picking up a wrench. A person needs to revise their whole frame of thinking; they must change their mind.
Recently, as I got back into front-end development, I felt the same as Frank. SASS, JavaScript dialects, NPM, and build tools solve some shortcomings with front-end technologies, but at what cost? I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.
In the meantime, like Jonas, I could have broken out any text editor and FTP program and built a full site with plain HTML and CSS in the time it took me to get it all running. And the site would have been easier to maintain in the long-run. I’ve started to question their net-productivity in my workflow, and I expect we’ll see more people moving on from things like SASS in the coming years as web standards become increasingly capable.
There’s no doubt that these modern tools and frameworks bring benefits, but too often we neglect to recognize the drawbacks. The web is forgiving by design. That flexibility is what enables learning. It shortens the distance from “I wrote this” to “it works!” The barrier to entry for programming is high, but for your first web page, it’s as low as it can be—unless you try to embrace modern tools. The learning curve is steeper, and the maintenance costs are higher.
The approachability of web development is key. It’s what separates web development from any other form of writing code. Markup and CSS may not technically be programming, but I’d argue that’s a good thing. There are no gatekeepers. There’s nothing to install. And there’s no need to string together a convoluted build process.
So many technologies have come and gone. Many more will do the same. Many of them even paved the way for functionality that eventually made its way into browsers, but with hindsight, modern web technologies have continued to outlast all of them precisely because they’re open, connected, and approachable.
Jeremy Keith, In his book “Going Offline”, touches on this:
The history of the web starts to sound like an endless retelling of the fable of the tortoise and the hare. CD-ROMs, Flash, and native apps outshine the web in the short term, but the web always seems to win the day somehow.
If you’ve spent any significant time on the web, you can likely feel how a website is built from the moment you open a page. Does it load quickly? Is anything broken? Does it work well with your password manager? Is it readable? You likely make a dozen judgments in a split second. If you’re like me, you may even get a sinking feeling in your stomach when it’s a site you have to deal with but you immediately know it’s built poorly. You know you’re going to struggle to even get it to work. Or you know when you’re going to have to open a browser you don’t enjoy using because they couldn’t be bothered to use standards or test across different platforms.
On the other hand, you know the moment you open a site that was built well. Everything just works. The people who built it took care with their markup and CSS to take full advantage of the power and built-in features of those languages. Links use anchor tags instead of event handlers on a div tag. Labels are selectable and focus on the corresponding input fields. Keyboard navigation works.
These differences aren’t arbitrary. They’re the difference between a team that embraces and understands the web with all of its quirks and a team that scoffs at it and its constraints. But when constraints disappear, so does consideration. Forward progress is important, but we should take more time to consider the digital detritus that’s left behind. Bloated web pages. Sites that barely load.
Yet, so many things don’t change. Typography. Information architecture. Readability. Writing. Understanding and appreciating these things is a skill unto itself. A developer dismissing any of these as unimportant would seem uninformed. Technology can make these easier, but it can’t abstract away the importance of doing these well. Well-written HTML and CSS is just as important as well-written backend code. To dismiss it as inconvenient or unimportant is no different than saying the same of visual design, information architecture, or any of dozens of other skills that individuals can spend a lifetime learning and refining.
There’s no such thing as perfection. At best, you can have the pursuit of perfection, but everything carries tradeoffs. Web standards aren’t perfect, but neither are the technical solutions that attempt to address and remove their shortcomings. It’s merely sweeping the shortcomings of web standards under the rug in favor of layers of obfuscation and abstraction.
As with creating anything, the medium matters. Whether oil painting, watercolor, metal working, carpentry, construction, native apps on mobile devices, or the web, if you don’t embrace the medium, you’ll always have to fight the current. However, in this case, while it may help you swim upstream faster, the current still usually wins.
You can build a robust, reliable, and fully responsive web application today using only semantic HTML on the front-end. No images. No CSS. No JavaScript. It’s entirely possible. It will work in every modern browser. It will be straightforward to maintain. It may not fit the standard definition of beauty as far as web experiences go, but it will work. In many cases, it will be more usable and accessible than those built with modern front-end frameworks.
That’s not to say that this is the best approach, but it’s a good reminder that the web works by default without all of our additional layers. When we add those additional layers, things break. Or, if we neglect good markup and CSS to begin with, we start out with something that’s already broken and then spend time trying to make it work again.
If I have to make a choice, I’m betting on web standards and a good solid working foundation. Open. Shareable. Universal. Flexible. Reliable. Approachable. It’s like the African proverb:
If you want to go fast, go alone. If you want to go far, go together.
The web is the quintessential definition of together. Web standards evolve slowly because they’re collaborative. They last because they’re scrutinized. New front-end frameworks and technologies try to circumvent or route around that process in the name of moving faster. Sometimes, they surface great ideas that make their way into browsers. But more often than not, they fade away.