A Short Guide to Minimal Web Development

Published on September 25, 2018 (↻ July 14, 2023), filed under (RSS feed for all categories).

There’s an art and even a bit of magic around simple frontend code. I love researching such code, and keeping code simple. Well beyond the point of understandable-simple, then, instead not-so-understandable-simple but rather minimal-simple. For that reason have I enjoyed writing about “best templates” and suggested omitting optional tags and other technically unnecessary things like unneeded attribute quotes. But I have also contemplated writing a short book about the matter.

That book I started writing last year, but it didn’t assume the structure and size that I imagined for it. Or, I wasn’t quite sure about the material I ended up gathering. Maybe I turned lazy. And therefore (and not for the first time), instead of just writing another “little book” I decided to just publish what I so far collected. All to ponder, how could we learn, or could we teach, web development, quite off the current “web app and tool all the things” path.

Val and Aleta have been watching.

Figure: Oh, no. That’s something I know nothing about. (Copyright King Features Syndicate, Inc., distr. Bulls.)


  1. Master the Core Technologies
    1. Read the Specs
    2. Practice
    3. Publish
  2. Familiarize with Related Topics
    1. Primary Subjects
    2. Secondary Subjects
  3. Do It Yourself
    1. Recommended
    2. To Be Avoided
  4. Find the Shortest Way
    1. Keep It Simple
    2. Tailor
    3. Know Simple and Simple
  5. Automate
  6. Review

Master the Core Technologies

Beginners achieve simplicity because they don’t know about all the options and possibilities. (One could liken this to an inverted parabola.) But as professionals and experts, as this article wants it, we cannot approach minimalism from not knowing what’s there, and pat ourselves on the back when we wrote something simple just because we couldn’t produce anything else.

Read the Specs

The first step for mastering appears to come through a thorough look at the technical specifications. While the specs aren’t always kind in terms of how easy they are to understand, and while they’re not small in size, they offer the greatest degree of precision and detail. As the goal is mastery, precision and detail are more important than convenience.

Some of the specs to work through are:

Personally, I’ve never worked through any ECMAScript spec—and my scripts will show—but I wished to include them here for my own encouragement as well. Then, ES and WCAG only carry version numbers because these aren’t, at the moment, “living” specifications as are HTML and CSS. Pick the latest relevant versions of these standards.

Some important topics, like performance or maintainability, aren’t covered by particular standards and specifications, but are only accessible through literature. (A future edit of this article may cover recommendations.)


Not necessarily after but while familiarizing with the specs, it will be useful to put the knowledge into practice. That means: developing. Developing as much as possible.

One of the greatest aspects about web development is probably that the results show immediately—save an .html file, open it in a browser, test any content, structure, styling, scripting changes instantly.

This ease of trying things is an advantage. It allows us to be very fast in setting up test cases as well as entire sites and apps, and therefore to build up experience.

This practice seems important for every web developer. The following habits are of help:


Practice inevitably leads to the here final point of technology mastery: making one’s work public.

This exposure has several great side effects. The scrutiny it brings may seem a bit intimidating at first, but a novice need not fear but welcome scrutiny: It means great opportunities to become better, faster.

The benefit, then, should usually consist of great extra motivation: One wishes to present one’s work well, and hence focuses more on the output’s quality; and this focus comes as an asset for all one’s professional work. One takes the work more seriously and acquires the necessary caution. Very often, too, one enjoys one’s work more as well, because publishing means sharing, and shared work can be of use for others.

Publishing, as an important step for exposure, feedback, professionalism, also sets people up to build their portfolio: Every published work can add credibility to one’s professional claims. One can demonstrate far more easily what one can and does do. There’s a tremendous difference in perception of a web developer with a quality website compared to one without one (or a bad one).

❧ Reading the specs, practicing, and publishing: When exercised diligently—over the course of 6–12 months—, these make for a great basis, after which it’s time to look at some specifics.

Web development is not a small, isolated topic. For a web developer to become good at their work, and particularly to become excellent, they need to get a great grasp of what’s happening around them.

To give an impression of what topics and areas should be of interest, but also to convey that not everything is of equal import, one may categorize those other areas as “primary” and “secondary” topics to familiarize with.

The following topics all serve the “Big Picture,” and still, the two lists aren’t exhaustive.

For few of these topics is there a single main resource; the list may get amended to point to outstanding books on the matters. Some topics, like character sets and encodings to pick just one example, are not part of these lists because luckily, their situation seems so much under control that a web developer may not anymore in their career stumble into difficulties and issues related to them.

❧ At this point, what we’ve covered must appear more like maximal rather than minimal web development. The idea, however, is that we can only tell what’s really needed once we can tell what’s really important, and why it’s really important. For that it seems beneficial to thoroughly understand our field and its surroundings.

Do It Yourself

The call to “Practice” already meant the “Go” to work and—practice, but that practice needs a little more detail. Most of all, practice means to do it yourself—without any direct help, and without any tools that take over our tasks.

There’s the option to use tools for development, and tools are increasingly important—even critical in complex projects—, but they’re as useful to learn coding as it is to use ready-to-heat-up dough and buns to become a baker. That refers to tools that do things for us, of course, as editors are still as allowed as are ovens: We just don’t want the editor to auto-correct or auto-strip or auto-compress just yet, much as we wouldn’t want the oven to auto-blend and auto-spread and auto-check to assist the baker apprentice.

To practice and code by ourselves, what is allowed, and what isn’t?

These lists are neither ordered nor exhaustive.

❧ The benefits are as manifold, as the approach aims to

The goal here, after all, is to learn the craft of web development. Over time, and my suggestion is again to work like this for 6–12 months, we can add and play with tools; but as much as tools are important, and again critical in large-scale projects (really not so much in small ones), they’ll leave our story now.

Find the Shortest Way

After we’ve learned and practiced and published for a while it’s time to lock in on the primary goal of minimal web development: to find the shortest way, to determine the least amount of code possible to build whatever we set out to build.

This isn’t simple itself, and, as I’m explaining in CSS Optimization Basics, it’s the mindset that’s really interesting here. To quote:

The idea to keep it simple has a lazy touch, and yet it requires high skill. Keeping it simple really means focus, to know what’s important, and through that be efficient. Keeping it simple does not mean simply to do less; it means only to do what matters.

Keep It Simple

Focus, then, is at the heart of the idea of keeping it simple.

Yet contrary to the idea of simplicity that’s understable, here, in this post, this is all about simplicity that is minimal. Simplicity is not simplicity: When we push hard on the least amount of code possible, the results will certainly be minimal, but they usually suffer on the part of understanding. Hence the differentiation between minimal-simple and understandable-simple.

Normally we do want to find a balance (and balance is important in many matters web development)—but here the goal is to first go for what’s most minimal, what’s the minimum needed, what can achieve the result and do the job: the shortest way.

The task still requires understanding, but after one has thoroughly understood and pierced through the topic. To repeat the objective of this writing, emphasis is on learning minimal web development, and to take it from there.

Keeping it simple, therefore, is first leaving out what can be left out.


Keeping it simple then also demands for the notion of tailoring. Tailoring means to develop and cut everything to one’s precise needs. This translates quite well into the real world: an off-the-rack suit may happen to fit us, but it never quality-wise beats the bespoke one; and if we only have the option for something off the shelf, customizing it will also always look nicer on us.

The goal is quality, no: excellence; and that goal is important to keep in mind. If quality and excellence are not the goal, then clearly, a potato bag will make for a garment just as well as will Bootstrap serve the local church site. (Yes.)

If the goal is quality, however, and excellence, indeed, then tailoring is mandatory, and it brings up one important condition and one important practical point:

The condition is to know our needs, because otherwise we cannot develop nor even customize anything so to truly suit us.

The practical point is to be aware of customization, because yes, we need it for tailoring, but no, it’s also a burden on our resources, asking for development time. Most people respond by not customizing—a great example are the odd reset style sheets which are in 99.99% of all cases used without modification, precisely because that is work—, but: that comes at the price of (lower) quality.

Know Simple and Simple

The beginning of this post gave it away: minimal-simple was the goal rather than understandable-simple. The idea explained in more detail in a separate article, Understandable-Simple vs. Minimal-Simple Code, we’ll jump to its conclusion:

<!DOCTYPE html>

That, for example, is the absolute minimum for an HTML document. That is true minimalism. That is also true minimal-simple: for understandable-simple, it’s not, not for each and every developer.

The example shall remind us where we want to take minimalism, but also show a potential pitfall regarding the balance mentioned: It’s greatly instructive and impactful for us to explore the absolute minimum possible—that’s absolutely encouraged here—but there’s another dimension then in that later, once we managed to push all the way for minimalism, we use the experience we acquired to find those spots that allow, in our teams, the right amount of understanding and, with that, collaboration.

Minimal, yes, but not at all cost. Simple and simple.


The ambition to become a professional, an expert web developer who knows their craft so to find effective but simple solutions comes with another particular balance to strike. That balance is to automate as much as possible without, at least at the current stage of our field, getting too comfortable and neglecting the craft itself.

This may sound more obscure and difficult than it is.

First, the recommendation for the already knowledgeable developer is to automate: Any task repeated should be checked for automatability through scripts and tools. This sense and skill is useful to be developed and fine-tuned, and it makes for an invaluable asset especially in enterprises involving more than one person (the developer themselves).

Second, balancing needs to take place where either of the following is true:

  1. Automation costs more than keeping on doing the task manually (the factor is left to the judgment of the reader);
  2. The task can only be automated at a detriment to overall quality;
  3. The original task is of (even temporary) instructional value.

The first reason makes it economically unwise to automate; the second regards quality a greater priority than efficiency; and the third places higher value on the craft and teaching it than on the efficiency achieved through automation. These factors do all want to be considered when it is about automation.

What is there to automate? I came out ahead of myself here when simply saying that “any task” should be automated, and indeed one can generalize the matter and say that everything possible should be automated (unless balancing is important). In the original structure for book and post I had subdivided the matter into development, testing, and monitoring—each with extra considerations and possibly tools. A note for future reference.


There’s another—though probably not final—aspect to web development, which consists of reviewing. Reviewing our work—which never precludes understanding and contributing to others’ work—is the counterpart to the more chance-based opportunities for improvement we get through our peers, when they eventually (or not) comment and review and file bug reports against our work.

Reviewing, or auditing, or criticizing (as in analyzing) one’s work, is important: We want to acquire a habit of healthy self-reflection so to improve our work and its produce.

The ways are manifold, for there’s the option to review everything from code snippets to entire repositories; one can establish a practice of sanity checking code by oneself if there are no peers to review it; reviews can then be one-offs or scheduled to be repeated.

Automated tests, then, are part of the review process, too, and so are reviews through external experts. The idea is to constantly check and monitor the health and quality of our work—for while in practice, our businesses will depend on it, doing so also makes us experts, also makes us professionals.

❧ This is a sketch. A sketch about minimal web development, yes—what’s most important to it. But also a sketch about how to become a web developer, something that I’ve so far never truly desired to cover—the only attempts, they have been basal, or very different, like my May talk at beyond tellerrand.

As a sketch this lacks detail and is incomplete. Perhaps I’ll wish to add to it, perhaps you like to. In any case it contains some ideas on what to do if you want to become a web developer and want to focus not on the bare minimum, but on the minimum that is tailored and of quality. (This idea of web development I’ve always liked a lot.)

So what are the keys? In a nutshell: Understand the technologies by reading the standards and specifications, by practicing, and by publishing; familiarize with related topics; do it yourself; look for the shortest way by keeping things simple, by tailoring, and by telling simple and simple apart; automate; and review.

That may be one basic and perhaps a little different approach—to minimal web development.

Was this useful or interesting? Share (toot) this post, or support my work by buying one of my books (they’re affordable, and many receive updates). Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you want to do me a favor, interpret charitably (I speak three languages, and they can collide), yet be critical and give feedback for me to learn and improve. Thank you!