Forem: Jens Oliver Meiert

On the Need for Neutral Maintained Minifier Metrics

Jens Oliver Meiert — Tue, 27 Jan 2026 09:34:16 +0000

To improve production performance, we use minifiers. For HTML, there are several HTML minifiers, with most being capable of minifying CSS and JavaScript as well.

While we can measure how effective and fast these minifiers are, there are two problems:

As they’re not all based on the same languages and don’t all offer the same interfaces, minifiers don’t all work the same. That is, they can be tricky to compare 1:1.
While interestingly, pretty much every minifier provides metrics on how they compare (see the original HTML Minifier, HTML Minifier Terser, HTML Minifier Next, htmlnano, minify-html, &c.), these metrics are often inaccurate: Assuming no bias, they’re not always based on the latest minifier version and their latest capabilities.

What you can tell from this is that problem 1) is a general challenge—one that has led Jens to several reviews and improvements to the benchmarks shared with HMN, and that Kirill knows with his benchmarks overview as well—, and that 2) is an actual problem.

2) is a problem because unmaintained benchmarks don’t offer an accurate picture of the minifier landscape. Accordingly, they don’t actually enable you to make good decisions.

The Call for Neutral and Maintained Minifier Benchmarks

What we believe we need is this:

A neutral steward—person or organization—who regularly publishes updated minifier benchmarks.
- Minifier maintainers could support this steward by informing about new features. (Assuming automated dependency management, that’s not necessary for general minifier updates.)
The benchmarks should
- be open and include as many HTML minifiers as possible
- include a large and diverse range of sites to be tested
- cover minification results and processing time
- in the case of HTML minifiers, consider comparing both HTML minification and “full” minification (enabling all other minification options these minifiers come with)
- be updated at least every month

This is probably not all: As a community, we can all contribute to making this process better.

The point is that as developers and minifier providers, we believe neutral, maintained minifier metrics are necessary when we’re actually in the great position of having several maintained minifiers that, excitingly, also apply different philosophies.

Even if minifier maintainers do their best to provide unbiased, up-to-date comparisons, having a steward who takes care of this could provide a lot more value to all of us.

Would this steward be you? Comment here or contact Jens or Kirill so that we’re aware and can help you get something started!

HTML Semantics: The Short Descriptions of All 113 Elements

Jens Oliver Meiert — Wed, 10 Dec 2025 10:39:39 +0000

When you look at HTML overviews (e.g., take the HTML elements index or my free ebook listing all HTML elements and attributes), you get a quick sense of what HTML elements mean (i.e., their semantics).

But when you have a closer look, you may actually need more than “heading” or “hyperlink” to understand what an element represents.

To provide a comprehensive semantics overview, here are the HTML spec’s first paragraphs for all the 113 HTML elements (that is, not including MathML and SVG):

a: If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents. If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element’s contents.
abbr: The abbr element represents an abbreviation or acronym, optionally with its expansion. The title attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must contain an expansion of the abbreviation, and nothing else.
address: The address element represents the contact information for its nearest article or body element ancestor. If that is the body element, then the contact information applies to the document as a whole.
area: The area element represents either a hyperlink with some text and a corresponding area on an image map, or a dead area on an image map.
article: The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.
aside: The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
audio: An audio element represents a sound or audio stream.
b: The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.
base: The base element allows authors to specify the document base URL for the purposes of parsing URLs, and the name of the default navigable for the purposes of following hyperlinks. The element does not represent any content beyond this information.
bdi: The bdi element represents a span of text that is to be isolated from its surroundings for the purposes of bidirectional text formatting.
bdo: The bdo element represents explicit text directionality formatting control for its children. It allows authors to override the Unicode bidirectional algorithm by explicitly specifying a direction override.
blockquote: The blockquote element represents a section that is quoted from another source.
body: The body element represents the contents of the document.
br: The br element represents a line break.
button: The button element represents a button labeled by its contents.
canvas: The button element represents a button labeled by its contents.
caption: The caption element represents the title of the table that is its parent, if it has a parent and that is a table element.
cite: The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc.). This can be a work that is being quoted or referenced in detail (i.e., a citation), or it can just be a work that is mentioned in passing. A person’s name is not the title of a work—even if people call that person a piece of work—and the element must therefore not be used to mark up people’s names.
code: The code element represents a fragment of computer code. This could be an XML element name, a filename, a computer program, or any other string that a computer would recognize.
col: If a col element has a parent and that is a colgroup element that itself has a parent that is a table element, then the col element represents one or more columns in the column group represented by that colgroup.
colgroup: The colgroup element represents a group of one or more columns in the table that is its parent, if it has a parent and that is a table element.
data: The data element represents its contents, along with a machine-readable form of those contents in the value attribute.
datalist: The datalist element represents a set of option elements that represent predefined options for other controls. In the rendering, the datalist element represents nothing and it, along with its children, should be hidden.
dd: The dd element represents the description, definition, or value, part of a term-description group in a description list (dl element).
del: The del element represents a removal from the document.
details: The details element represents a disclosure widget from which the user can obtain additional information or controls.
dfn: The dfn element represents the defining instance of a term. The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.
dialog: The dialog element represents a transitory part of an application, in the form of a small window (“dialog box”), which the user interacts with to perform a task or gather information. Once the user is done, the dialog can be automatically closed by the application, or manually closed by the user.
div: The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements. It can also be used in a dl element, wrapping groups of dt and dd elements.
dl: The dl element represents an association list consisting of zero or more name-value groups (a description list). A name-value group consists of one or more names (dt elements, possibly as children of a div element child) followed by one or more values (dd elements, possibly as children of a div element child), ignoring any nodes other than dt and dd element children, and dt and dd elements that are children of div element children. Within a single dl element, there should not be more than one dt element for each name.
dt: The dt element represents the term, or name, part of a term-description group in a description list (dl element).
em: The em element represents stress emphasis of its contents.
embed: The embed element provides an integration point for an external application or interactive content.
fieldset: The fieldset element represents a set of form controls (or other content) grouped together, optionally with a caption. The caption is given by the first legend element that is a child of the fieldset element, if any. The remainder of the descendants form the group.
figcaption: The figcaption element represents a caption or legend for the rest of the contents of the figcaption element’s parent figure element, if any.
figure: The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.
footer: The footer element represents a footer for its nearest ancestor sectioning content element, or for the body element if there is no such ancestor. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. When the footer element contains entire sections, they represent appendices, indices, long colophons, verbose license agreements, and other such content.
form: The form element represents a hyperlink that can be manipulated through a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.
h1: [This element represents a heading for its section.]
h2: [This element represents a heading for its section.]
h3: [This element represents a heading for its section.]
h4: [This element represents a heading for its section.]
h5: [This element represents a heading for its section.]
h6: [This element represents a heading for its section.]
head: The head element represents a collection of metadata for the Document.
header: The header element represents a group of introductory or navigational aids.
hgroup: The hgroup element represents a heading and related content. The element may be used to group an h1–h6 element with one or more p elements containing content representing a subheading, alternative title, or tagline.
hr: The hr element represents a paragraph-level thematic break, e.g., a scene change in a story, or a transition to another topic within a section of a reference book; alternatively, it represents a separator between a set of options of a select element.
html: The html element represents the root of an HTML document.
i: The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.
iframe: The iframe element represents its content navigable.
img: An img element represents an image.
input: The input element represents a typed data field, usually with a form control to allow the user to edit the data.
ins: The ins element represents an addition to the document.
kbd: The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).
label: The label element represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element’s labeled control, either using the for attribute, or by putting the form control inside the label element itself.
legend: The legend element represents a caption for the rest of the contents of the legend element’s parent fieldset element, if any. Otherwise, if the legend has a parent optgroup element, then the legend represents the optgroup’s label.
li: The li element represents a list item. If its parent element is an ol, ul, or menu element, then the element is an item of the parent element’s list, as defined for those elements. Otherwise, the list item has no defined list-related relationship to any other li element.
link: The link element allows authors to link their document to other resources.
main: The main element represents the dominant contents of the document.
map: The map element, in conjunction with an img element and any area element descendants, defines an image map. The element represents its children.
mark: The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader’s attention to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user’s current activity.
menu: The menu element represents a toolbar consisting of its contents, in the form of an unordered list of items (represented by li elements), each of which represents a command that the user can perform or activate.
meta: The meta element represents various kinds of metadata that cannot be expressed using the title, base, link, style, and script elements.
meter: The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.
nav: The nav element represents a section of a page that links to other pages or to parts within the page; a section with navigation links.
noscript: The noscript element represents nothing if scripting is enabled, and represents its children if scripting is disabled. It is used to present different markup to user agents that support scripting and those that don’t support scripting, by affecting how the document is parsed.
object: The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image or as a child navigable.
ol: The ol element represents a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document.
optgroup: The optgroup element represents a group of option elements with a common label.
option: The option element represents an option in a select element or as part of a list of suggestions in a datalist element.
output: The output element represents the result of a calculation performed by the application, or the result of a user action.
p: The p element represents a paragraph.
picture: The picture element is a container which provides multiple sources to its contained img element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors. It represents its children.
pre: The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements.
progress: The progress element represents the completion progress of a task. The progress is either indeterminate, indicating that progress is being made but that it is not clear how much more work remains to be done before the task is complete (e.g. because the task is waiting for a remote host to respond), or the progress is a number in the range zero to a maximum, giving the fraction of work that has so far been completed.
q: The q element represents some phrasing content quoted from another source.
rp: The rp element can be used to provide parentheses or other content around a ruby text component of a ruby annotation, to be shown by user agents that don’t support ruby annotations.
rt: The rt element marks the ruby text component of a ruby annotation. When it is the child of a ruby element, it doesn’t represent anything itself, but the ruby element uses it as part of determining what it represents.
ruby: The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana.
s: The s element represents contents that are no longer accurate or no longer relevant.
samp: The samp element represents sample or quoted output from another program or computing system.
script: The script element allows authors to include dynamic script, instructions to the user agent, and data blocks in their documents. The element does not represent content for the user.
search: The search element represents a part of a document or application that contains a set of form controls or other content related to performing a search or filtering operation. This could be a search of the web site or application; a way of searching or filtering search results on the current web page; or a global or Internet-wide search function.
section: The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
select: The select element represents a control for selecting amongst a set of options.
selectedcontent: The selectedcontent element reflects the contents of a select element’s currently selected option element. selectedcontent elements can be used to declaratively show the selected option element’s contents within the select element’s first child button element.
slot: The slot element defines a slot. It is typically used in a shadow tree. A slot element represents its assigned nodes, if any, and its contents otherwise.
small: The small element represents side comments such as small print.
source: The source element allows authors to specify multiple alternative source sets for img elements or multiple alternative media resources for media elements. It does not represent anything on its own.
span: The span element doesn’t mean anything on its own, but can be useful when used together with the global attributes, e.g. class, lang, or dir. It represents its children.
strong: The strong element represents strong importance, seriousness, or urgency for its contents.
style: The style element allows authors to embed CSS style sheets in their documents. The style element is one of several inputs to the styling processing model. The element does not represent content for the user.
sub: ~~[…]~~ the sub element represents a subscript.
summary: The summary element represents a summary, caption, or legend for the rest of the contents of the summary element’s parent details element, if any.
sup: The sup element represents a superscript ~~[…]~~.
table: The table element represents data with more than one dimension, in the form of a table.
tbody: The tbody element represents a block of rows that consist of a body of data for the parent table element, if the tbody element has a parent and it is a table.
td: The td element represents a data cell in a table.
template: The template element is used to declare fragments of HTML that can be cloned and inserted in the document by script. In a rendering, the template element represents nothing.
textarea: The textarea element represents a multiline plain text edit control for the element’s raw value. The contents of the control represent the control’s default value.
tfoot: The tfoot element represents the block of rows that consist of the column summaries (footers) for the parent table element, if the tfoot element has a parent and it is a table.
th: The th element represents a header cell in a table.
thead: The thead element represents the block of rows that consist of the column labels (headers) and any ancillary non-header cells for the parent table element, if the thead element has a parent and it is a table.
time: The time element represents its contents, along with a machine-readable form of those contents in the datetime attribute. The kind of content is limited to various kinds of dates, times, time-zone offsets, and durations, as described below.
title: The title element represents the document’s title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user’s history or bookmarks, or in search results. The document’s title is often different from its first heading, since the first heading does not have to stand alone when taken out of context.
tr: The tr element represents a row of cells in a table.
track: The track element allows authors to specify explicit external timed text tracks for media elements. It does not represent anything on its own.
u: The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.
ul: The ul element represents a list of items, where the order of the items is not important—that is, where changing the order would not materially change the meaning of the document.
var: The var element represents a variable. This could be an actual variable in a mathematical expression or programming context, an identifier representing a constant, a symbol identifying a physical quantity, a function parameter, or just be a term used as a placeholder in prose.
video: A video element is used for playing videos or movies, and audio files with captions.
wbr: The wbr element represents a line break opportunity.

Still brief, but significantly more useful, no? HTML is a journey.

All definitions as per the HTML Living Standard, unchanged, licensed under CC BY 4.0.

Web Development: On the Size and Output of and the Growth Opportunities Within the Field

Jens Oliver Meiert — Tue, 18 Nov 2025 16:13:31 +0000

The field of web development is huge. Everyone in it knows that.

A lot happens in our field, too. Web development is a field of constant change. You can literally watch the web platform grow.

In this vast sea of change, we change, too. We acquire new knowledge, we adapt to evolving practices, we gain more experience.

As actors in the field, we all have a sense for the size and output of and our growth within the field. You don’t need me to tell where you stand in relation to it.

However, in my work I’m very close to some of the indicators of just how big the field is, how much it puts out, and how we change as part of it.

1. An Indicator for the Size of Our Field

The Web Development Glossary—fundamentally a book, but also a website—is the largest collection of terms and concepts related to our field.

The upcoming new edition of the book will feature more than 4,500 references with more than 3,000 definitions. No glossary can claim completeness, but the Web Development Glossary gives one of the stronger indicators for the enormity of the field.

(Is there a resource that gives an even better indication? Would you say MDN, although with a smaller, differently organized glossary, is more accessible in this regard? Please comment!)

2. An Indicator for the Output of Our Field

For 2024, Frontend Dogma has so far documented more than 3,200 articles and videos from across the field. For 2025, it’s almost 3,000 already. While these ~9 articles daily mean a small fraction of the field’s output in terms of knowledge shared, it does give an idea of much going on.

As with any resource, Frontend Dogma will never be complete, and the challenge to gather all the field’s relevant material is even larger than that of a glossary. And yet, it is one resource where we get a taste for how much the field is in motion.

(Now this is a resource I’m sharing because I’m commenting on the experience from my own work. What would you call out? Which resources show our output as well and better?)

3. An Indicator for Individual Growth in Our Field

Like other web developers, and probably like you, I’m both developing and writing about development. In 2015, I bundled up the writings of the previous 10 years to publish On Web Development. 10 years later, this year, I did the same again, releasing On Web Development II.

Now I’m obviously sharing this because I'm not opposed to you and others taking an interest in these writings. But I’m also sharing this because these collections are good indicators, to myself but perhaps even more to others, how we change and grow within the field.

(Did you publish a collection like this, too? What was your experience? And, are there similar collections of other web developers that you recommend? Please share them!)

—As a developer and writer, and as the maintainer of a web development news archive and a tech glossary, I hope this gives another sense, another taste just for how big, productive, and transformative web development is.

HTML—the Most Difficult Programming Language in the World

Jens Oliver Meiert — Wed, 22 Oct 2025 22:00:00 +0000

Years ago, the web development community discussed and declared on Twitter that HTML was not just a document language, but a programming language.

Meanwhile, virtually no HTML page is error-free. In HTML parlance, almost no page is conformant, compliant, valid, or “validates.” (Cf. validation data from 2021 through 2025.)

If HTML is a programming language, yet virtually no one writes error-free HTML code, there can be only one conclusion:

HTML is the most difficult programming language in the world.

This is tongue-in-cheek, but the underlying point isn't: If you’re a professional who puts HTML on your resume, ship valid HTML. This is the minimum to be expected of our work, even when our manager or our client doesn’t ask for it. It’s not that hard.

Why and How to Write Minimal and Valid HTML, a Link Guide

Jens Oliver Meiert — Wed, 15 Oct 2025 17:37:47 +0000

If you’re interested in writing HTML that is as compact as possible for a payload as small as possible, and in writing HTML that is error-free and conforms to the HTML standard, then this is a link guide for you. Specializing in minimal and valid HTML, it refers to some of my writings about these subjects.

Why Minimal HTML

How to Write Minimal HTML

Why Valid HTML

2025: 0 of the Global Top 200 Websites Use Valid HTML—to illustrate the pervasiveness of HTML non-conformance (i.e., of invalid HTML)
The Two Great Things About Validation (and Conformance)
The 3-Second Frontend Developer Test
We Need to Talk More About Conformance, if We Want to Stop Fantasy HTML
- How Often Should We Speak About HTML Conformance?
On the Uniting Power of a Commitment to HTML Conformance

How to Write Valid HTML

HTML Conformance: A Comparison of 6.5 npm Validator Packages (With 1.5 Recommendations)

(You can find more articles about minimalism and conformance on Frontend Dogma.)

What Else to Consider for HTML Optimization

Enjoy writing minimal and valid HTML!

HTML Minifier Next (a Maintained Fork of HTML Minifier)

Jens Oliver Meiert — Mon, 14 Jul 2025 06:11:40 +0000

TL;DR: If you prefer a maintained version of HTML Minifier, use HTML Minifier Next.

HTML Minifier is critical web tooling just like the Nu Html Checker [sic] that, for living HTML, supports the W3C validator.

Alas, both tools suffer from maintenance issues. While the validator needs more hands-on contributions (I clarified after asking how the community could help), HTML Minifier is for all practical purposes unmaintained. This is bad because even security-related PRs aren’t being handled.

This is now similar for a fork of HTML Minifier, html-minifier-terser. It is slightly more up-to-date and I suggested using it in a recent episode of “Website Optimization Measures,” but after waiting for months to hear back on a few mails, and seeing issues and PRs not being handled, either, this must likewise be consider unmaintained.

As HTML Minifier is so useful, I decided to release an updated fork, HTML Minifier Next (source, web version). You can use it like HTML Minifier (instructions).

I forked, optimized, and am now announcing HTML Minifier Next with reasonable optimism that, in the worst case, I could maintain the project alone. However, this is still easier if the community contributes. If you want to get involved, especially around new features, please join and help keep HTML Minifier—critical web tooling—up-to-date. Thanks!

The HTML History and Optimization Cheat Sheet

Jens Oliver Meiert — Wed, 18 Sep 2024 17:02:18 +0000

If you’re interested in HTML history and optimization, then this may be useful to you:

Figure: The HTML History and Optimization Cheat Sheet.

After the launch of the free Rote Learning HTML & CSS ebook (which may be of interest, too) this information available is now available for free as well, and it complements the HTML elements index, where you can find an overview of all HTML elements over all the major specifications.

Enjoy writing HTML ✌️

Learn HTML and CSS, the Hard Way (Free Ebook)

Jens Oliver Meiert — Tue, 27 Aug 2024 09:08:10 +0000

If you’re a frontend developer, you’re working with HTML and CSS.

And yet, you may not…

…have all the HTML elements in mind, and their meanings

…know all the void elements

…know all the elements with optional start or end tags (and use that to write HTML–HTML)

…know the element categories

…know all HTML attributes

…be clear about all global attributes

…know which elements have what attributes

You may also not…

…know all CSS selectors

…be aware of all properties and where they’ve last been specified (okay, this is setting quite some expectations now)

…know all the at-rules

Of course, you can find (and should review) this information in the HTML and CSS specifications.

Yet there’s also free ebook bundling all of this information:

Rote Learning HTML & CSS (by yours truly).

Before you get the book, be advised:

This is not a beginner book.

This is not an explainer book.

This is not an exciting book.

It is, in fact, quite literally the most boring book you will have ever read.

Its use is equally literally to facilitate one thing—rote learning, memorization, of the fundamental parts of HTML and CSS.

Nothing more—and nothing less.

We Need to Talk More About Conformance, If We Want to Stop Fantasy HTML

Jens Oliver Meiert — Tue, 28 May 2024 14:24:56 +0000

Conformant and valid HTML is the exception when it comes to HTML used on websites and in apps. This is particularly visible on popular websites, where at the moment, none of the Top 100 sites worldwide uses valid HTML.

It’s easy to argue that conformant and valid output is the mark of a professional web developer. It takes nothing to write a document that contains HTML errors. To reuse a past metaphor, put a houseplant on the keyboard, store the result as a file with an “html” extension, and you have an invalid HTML document.

To stop houseplant and fantasy HTML, however, we need to raise awareness for HTML conformance and validation—we need to talk about HTML conformance and validation.

That happens not nearly as often as it should happen (and it should not always be done by the same people).

Surveys like State of HTML are an excellent opportunity to inquire about authors’ validation practices (one that, sadly, was missed last year). Even if the result confirms what we can measure on people’s websites—that authors don’t pay attention to using actual, valid HTML code—, asking plants a seed.

Whether you’re a frontend developer, lead, or manager, reconsider your expectations and practices if you haven’t yet chosen not to ship erroneous HTML. The more of us decide to talk about using actual HTML on our sites and in our apps, and lead by example, the better for our users and clients, and the better for our craft and profession. On the engineering side of web development, it’s HTML first—if it is HTML.

14 Tips for Becoming an Indie Author

Jens Oliver Meiert — Thu, 09 Nov 2023 16:47:56 +0000

You’re thinking about writing and publishing a book by yourself? And, you’re wondering about the process, and may be concerned about missing something?

I’ve written 5 books with my publisher, O’Reilly, and 15 as an independent author, recently with my own publishing outlet, Frontend Dogma. I’m still learning about the publishing business, every day, but there are a few things I have learned (I hope). Let me share these things, if it can help you get started.

The first tip right here: Just do it. You can produce a decent-quality book. And despite a changing market with fewer books sold in 2022, more people than not do read.

Start With an Ebook

Despite the convenience of ebooks, more print books are being bought than ebooks. While this means a smaller market for publishers, ebooks are easier and cheaper to create than print books. Start with an ebook.

Let me underscore this both as a reader and as an author—ebooks have many advantages over print books.

Choose a Comfortable Writing Setup

While you don’t have to write hours on end (more on that in a second), you do want to be comfortable when writing. As such, play with different word processors and text editors, as well as work environments, to find what’s to your liking. There’s nothing definite here as it’s precisely the point that you try out various settings to tell what works well for you.

For me, I do most of my writing in a text editor (BBEdit), in my IDE (WebStorm), or in Google Docs. I don’t care too much about the work environment, but as my post-pandemic life is still less eventful than it used to be, that’s largely at home, at my desktop machine, at a standing desk.

Write Regularly (by Establishing a Routine)

A key to writing is—writing. While that’s obvious, what’s not obvious is that it’s not about the amount you write, but how regularly you write. For this purpose, consider writing with a well-defined frequency—say, every day, or every work day, or every Saturday, or whatever cadence you prefer. To get yourself started, consider setting yourself reminders.

Don’t Feel Obliged to Write Much

At the same time, re-set your expectations on how much to write each session. Set them low, very low—say, a sentence, or perhaps just anything (if only a word). It’s easier and likely more effective to write just a little every n days, than vast runs of text every other intervals.

I’ve worked successfully with “write every day, but however much you like,” and moved to a lesser-defined frequency today, after I’ve built more experience and rely on some other techniques mentioned in this post. Like the next one:

Use Inspiration and Flow

While you can push yourself into writing (a quality one can acquire, but that I wouldn’t emphasize here), it’s much more efficient to use inspiration as well as flow (“the zone”) you have in the moment.

That is, in moments when you seem to be overflowing with ideas, or when you can write without effort, stay in these moments—cherish and use them.

In such moments, I’m driving my partner nuts, because I tend to forget time, and push back on obligations where possible—that’s how much I value these opportunities. You get so much more done in a moment of flow, that it saves you hours of time elsewhere.

Don’t Use AI Tools

Don’t use ChatGPT or other AI tooling to write for you. While AI may seem helpful to quickly generate some content, it’s likely to read soulless (as per one of my editors) and contain issues that require much more editing. That will help you improve as an editor—but not as a writer. Working with AI will for that reason also not feel like you wrote the book.

I’ve written a book with AI (The Problems With All the Good Things), but quite deliberately and transparently as I did so to make a particular point. You may find similar use cases. For purposes of starting out as an author or writer, however, I recommend to begin with a different project.

Work With an Editor

Even as an indie author, you need an editor. While you can ask friends and peers for help, it pays off to hire a professional. One good platform for this is Upwork—while you may need to try working with different editors (maybe you want to invest in more experience, or prefer a different work style), any editor is better than no editor.

I used to be nervous about my editors (for my first books for O’Reilly), then I skimped on this (for my first indie books), then I had hits and misses, and now I’m glad I’ve acquired some pool of editors to work with, and a sense for their approach. It’s useful to understand that the “tougher” an editor may seem—which can be quite uncomfortable at first—, the better it usually is for our work.

Hire a Cover Designer

Unless you’ve had some design training, hire a cover designer, too. (Don’t try to save on it, as may be the case with platforms like Fiverr, so try Upwork for a designer, too.)

In my work as an indie author and publisher, I’ve probably done more covers myself than I hired cover designers for. I’ve done some pretty bad ones, but also some that work okay. Would this contradict my advice? No—I’ve had some training, and my recommendation holds. But, a nice segue for the next point, it’s your call, and you could also:

Experiment

Don’t be afraid. (Though easier said than done, that’s generally good advice.) Work with a mindset of trying things out, of experimenting. This works better if you can detach yourself from that “one perfect book” you’re going to produce, and if you grant yourself room for errors—and improvements. Here you’ll particularly benefit from starting with ebooks, as you can update the manuscript as well as the cover once you shipped. Embrace it.

Be Kind to Yourself

Then, important: Don’t be hard, be kind to yourself. Especially when starting out, writing a book can be intimidating. (Your own expectations may be intimidating!) Trust the process, of slowly but surely adding to your book, of being able to course-correct and make future updates, of having professional help.

I remember my first book project, for O’Reilly, and signing my contract with them. The book outline and size of the manuscript were defined before one word was written—and with, if I recall correctly, a 250-page target this left me with a mountain to climb. Back then I took this with an attitude of “just do it,” and relying on the O’Reilly team; 20 titles later, my attitude is one of building on experience, trusting a network of professionals, and making constant improvements (“living books”).

Distribute Widely

As an indie author and publisher, you may start with one platform—Amazon’s KDP, Lulu, or maybe Leanpub. You may develop the appetite to publish your next title on that platform, too. That can be fine and actually quite useful—but even with Amazon being the ebook platform, increase your reach, and sell on additional platforms.

My standard set of sites I’m selling my books on include the following (in descending order of perceived reach):

I also have cooperations with magazines like SitePoint, who make my technical titles available as part of their Premium program. This is something worth mentioning as for your own books, you may find niche sites that can help you distribute your work, too.

For my first three indie books, I had put everything in the Amazon basket. While that worked well enough to sell a good number of them, a later pivot to Leanpub as my “main” platform (they are fantastic to generate books from Markdown pulled from GitHub) was the first and most impactful step for me to increase reach. I made books available on other platforms soon after, and apart from Payhip, which I can’t make good use of yet, they all—paid off.

Keep on Learning

Experiment with your writing and your output, but also learn more about writing and publishing. One of the most excellent books I’ve read is Roy Peter Clark’s Writing Tools. (I also love William Strunk Jr.’s classic, The Elements of Style, on the editing side.) You’ll find other books, as well as videos and courses, that help your indie author journey.

Write More

Once you’ve completed your first book, consider continuing. The hard part is done, as every additional book will be easier and easier to write and publish. If you aren’t already working with other formats, like articles or blog posts, consider doing that as well. It will provide you with a broader perspective, additional experience, and perhaps marketing opportunities. (If you’re doing this on your own website, even better—there are many advantages to that).

Promote as You Please

A final tip coming from someone who’s still learning about marketing: If you’re interested in and enjoy promoting and marketing your book(s), do it. If you don’t, don’t sweat it. Now, if you approach writing with the ambition of selling millions of copies in dozens of languages, this will not satisfy you—but you may already have ideas about your marketing as well. (Go for it.) But if writing and publishing are the priority for you, don’t bend over backwards to promote it. Or—look for someone who has been successful doing that by themselves. (I think Adam Clarke sketched some useful starting points with his SEO book, but I need to review.)

❧ The Web is amazing when it comes to the opportunities it provides us with, including that it makes it easy and affordable to publish books. The Web also makes it easy to make little out of these opportunities, both in terms of the output as well as our growth. These tips sketch ways to use the opportunities so that the output is solid, and that some growth as a author and publisher is assured. If these tips have helped you, please share this article—or check out one of my own indie books. (Thanks!)

On the Uniting Power of a Commitment to HTML Conformance

Jens Oliver Meiert — Mon, 23 Oct 2023 18:42:10 +0000

HTML is the language of the Web. No matter what other languages are being used, in the end it all boils down to the content or functionality being represented by HTML.

Unfortunately, our field, the field of web and frontend development, doesn’t commit to any quality standard—that is, expectation—for HTML.

It’s not that no such standard existed—arguably, the baseline is conformance with the HTML specification—, it’s that this standard is being ignored.

This isn’t hyperbole: When you validate—check on conformance—the most popular websites, none (0) uses valid and conformant HTML.

It’s similar for websites for frontend documentation, tools, and starter projects.

Even when you turn to the websites of web developers, it’s the exception, and not the rule, that there would be no conformance issues.

The reason for this misery is not the point of this article—some of our peers as well as myself have hypothesized and written about this in other fora.

The point is also not that we miss what this lack of a quality standard means for the value of our field—that instead of increasing it, we deflate it.

The point is that we miss an exceptional opportunity to unite behind it.

Imagine, just for a moment, if we as web and frontend developers would all produce conformant websites, and all ran conformant websites.

“This document was successfully checked as HTML,” as the W3C validator says.

This, for once, could be uniting; it could get us from indifferent or apologetic ignorance to mutual respect and healthy pride of being a member of our field.

It could allow us to tackle more serious challenges—like advancing accessibility—with collective vigor.

That unity, that feeling, is something our field has always lacked. Can we finally change this? Can we finally convince our peers? (Are you on board?)

Together, we could lead by example, together we could establish our field’s first quality standard—an objective and proven, a light but robust foundation that we, as professional frontend developers, can build on.

Commit to HTML conformance. Make sure your HTML output is actual, error-free HTML. Make use of validators and validation packages and validate.

200 Web-Based, Must-Try Web Design and Development Tools

Jens Oliver Meiert — Tue, 08 Aug 2023 19:52:32 +0000

Let’s get right into it: Here are not 10, not 50, not 100, but—200 web-based and free tools that make your web design and web development life easier. (It’s true.)

This is it. 200 amazing tools.

But.

Lists like this—of which there are tons—often amount to somewhat weird, somewhat nonsensical clickbait. There are dedicated, curated, and maintained collections for this, providing more choice of higher quality.

One is Frontend Dogma’s list of web-based development tools (by tag). Yes, disclosure, that’s a collection I maintain, and it’s not the only one of its kind—there is Tiny Helpers, run by Stefan Judis, and there are others, certainly including some “Awesome Lists,” buried under hyped one-off posts of fractions of the value.

Given these dedicated sites, it’s also easy to take a snapshot of them and present a giga-post like this one. But in many and perhaps most cases, doing so subverts the commitment that goes into maintaining such collections over time. (In Frontend Dogma’s case, whose resources were based on UITest.com, over nearly 20 years.)

If you’re a fan of link lists like this one, consider looking for (and contributing to) dedicated sites and collections, like Frontend Dogma or Tiny Helpers or a proven Awesome List.

And if you’re someone who likes to set up and market your own mini-lists (as you’re here, we know that they draw attention), consider supporting and giving back to collections you may get your inspiration from.

With kudos and compliments to everyone out there who provides and maintains web-based tools—and tool collections.