Some weeks ago, when it was still wintry in one half of U.S.A. and anything but in the other half, I encountered the following Tweet:
The old man seemed lost and friendless. “I miss static HTML,” he said.
— Jeffrey Zeldman (@zeldman) March 12, 2015
I’m grateful to call Jeffrey Zeldman a friend, seeing as he’s a terrific guy in addition to being one of the foremost doyens of web design. In that sentiment and with the wish to call attention to his lament, I replied:
@zeldman Story of my last five years, that. When did simplification & removal of dependencies become subversive?
— Ben Henick (@bhenick) March 12, 2015
…And now I get to unpack all of that, as briefly as possible.
Subtract tedium, add normalization, yield ignorance
From without, the web appears to be a place where stuff just happens, as a rule — click a button, wait a few shakes, and you get your information. Few novices recognize that there are myriad ways to solve any problem, or that those who insist on creating solo solutions inevitably make things stick together with chewing gum and baling wire. Messes are tedious to clean up, and antiquated sites tedious to maintain.
Today’s web-app development environment provides tools that allow us to treat tedium as an indulgence, something to relish if you ate too big a lunch and need to be physically at your desk but can’t hope to bring your brain back with you from the cafeteria.
That’s the good news.
The bad news is that we’re getting away from some fundamentals that we shouldn’t foreclose just yet. Where there is a platform, many people only see the popular frameworks that lie atop that platform.
Many of you have heard of, and used, the Open Source “MEAN stack”: MongoDB, ExpressJS, AngularJS, and Node.js. MongoDB serves data and node.js runs the guts of your service, while Angular handles the client side, and Express glues everything together. This stack has the catchiest name, but does not stand-alone; it and its cousins make wonderful alternatives to thick, unwieldy slices of custom PHP (or Python) around a MySQL sandwich, certainly a tolerable state of affairs…
…But it’s not an ideal solution, at least not yet.
An awful lot of people are missing the point. When I hear people talk, the conversation is always about the frameworks and never about the underlying technologies, much less the results intended by their use. The same is true of CSS preprocessors, which have narrower application but address the same general use case as their JavaScript-driven cousins.
Create the Web instead of colonizing it
JavaScript is stubbornly obtuse on its best day. Everything’s an object; functions can be anonymous; wise scoping is difficult-to-impossible in the browser; typing is so loose that gaps sometimes show; and don’t even get me started on the subject of passing values by reference.
The features I describe immediately above are all learnable, and all critical to the design of the language. They also go ignored by men and women who fancy themselves serious software developers, notwithstanding efforts of Doug Crockford and others to the contrary.
Instead, they keep going on about the frameworks. HTML, CSS, and the various web APIs lie completely unremarked, as does the principal strength of frameworks: the manner in which they pave over the differences between implementations. In effect, the same programmers who for years brayed about the web platform being no better than a toy have colonized it into something they can recognize and take seriously, but at the cost of rendering it opaque.
Once cast in that light, the disasters of the recent past — the ongoing prognostications that the web will wither before the onslaught of mobile apps; the healthcare.gov fiasco1; the seemingly weekly reports of intrusions and customer data theft; and the complete failure of site operators to recognize that mobile browsing is often constrained by data caps — should come as no surprise.
All of that and more can be laid at the feet of people who believe that software in particular is the end-all-be-all of the web, along with their companions in management who are too ignorant to have any hope of knowing better.
For 20 years I’ve made a routine out of making magic with the bare minimum — I believe passionately in the KISS Principle, and besides, fewer parts means fewer parts that can break — so of course I’m horrified by this state of affairs.
You should be, too.
A choice between short dramas and long farces
There are a lot perfectly human — and thus imperfect — reasons for the state of affairs I describe. Many of those reasons actually offer their share of virtue:
- Reduced testing requirements (compared to the alternatives)
- A shared software development vocabulary across applications, teams, and shops
- Ideal conditions for code modularization, distribution, and reuse
- Intrinsically improved conditions for avoiding technology burden and low-bus-factor challenges
- …And reduced tedium, as described above
At the risk of repeating myself, let me line up the tradeoffs:
- Increased overhead for all transactions (e.g. HTTP requests) in production, with corresponding time penalties2
- Incentive to provide documentation reduced below its already abysmal level3
- Perverse incentive to ignore priorities under- or unsupported by the tools in use, particularly those with bearing on application security
- Reinforcement of the stakeholder belief that we’re all just pushing pixels in our cellars, and voilá!
- Inevitable reliance upon outsized and/or additional dependencies, which can yield black box code
There’s one more tradeoff: abstraction can be a wonderful thing, but it has its limits. What happens after you’ve dialed in a toolset and a team on the basis of workflow rather than capability?
If the hiring process didn’t devalue general platform experience from the start, skills become atrophied, and in all cases fault recovery becomes a long farce instead of a brief drama. The knowledge that makes it possible to recognize the box — much less think outside of it — diminishes at the institutional level, rapidly in proportion to the tightness with which developers are dialed into a single toolset.
Death by a thousand cuts?
The obsession with frameworks feeds the impulses that have always made bad web sites bad.
Don’t make the existing features more stable; create new ones! Don’t document the work; it’ll just be thrown out and replaced in six months anyway! Don’t bother with wireframing or user testing; those will just draw out the time to wait until we get the last tranche of the fee! It looks broken to you, but not to me; don’t fix it!
The only way those stories end differently is when middle managers and salespeople magically begin to take advice that previously they rejected out of hand. As a rule, developers will always need to be smarter than the people who purport to manage them, and that starts with knowing our tools — all of them.4
Are the main planks in the web platform — HTML, CSS, JavaScript, and JSON — enough? Can we hope that universal, de-facto-standard JavaScript interfaces with HTTP and NoSQL will mature enough to be baked into other platforms and general-purpose tools, as eventually came to pass with the Document Object Model API?
…Maybe someday. Until then, we have many dangers against which we must guard, knowing that the price of failure is to inflict death by a thousand cuts upon a medium that practically defines civilization as we know it.
I imagine that eventually, we will answer the two questions above “no” and “yes”, respectively. In the meantime, we have the opportunity to simplify and speed web application development with tools that used to lie within the preserve of libraries, each unique to a shop, each taking years to assemble.
That’s a good, even wonderful thing…
…But it’s most wonderful if we know our tools well enough to appreciate when we need to find — or create — better ones.
-
I’ve bleated previously (and elsewhere) about the fact that healthcare.gov was initially implosive because accountability was diluted beyond recognition during development. I pose here that it’s more difficult to dilute accountability after you concede that tools are not automagical.↩
-
Cycles need to be spent on rendering somewhere, and matters can end badly if those cycles are spent by a potentially malware-laden, perpetually abused client system.↩
-
Shops that place high value on fault-tolerance and -recovery don’t suffer this problem, but most shops are underpaid or under-resourced — if not both — relative to the scale at which they’re expected to deliver.↩
-
“MacGyver’d” solutions aren’t always intrinsically bad, but they’re impossible unless you’re intimately familiar with the finer details not necessarily included in the SOPs. That familiarization requires time — the same time that management is hoping to save by relying upon off-the-shelf widgets. (You can’t have it both ways.)↩
Editor’s note: Ben Henick’s HTML & CSS: The Good Parts is worth checking out if you spend a lot of time with markup and want to break free of outdated, confusing, and unnecessary HTML hacks and workarounds.