Never underestimate HTML

by Lara Aigmüller published on

“HTML is easy.”, “Frontend development is easier than backend development.”, “Updating the UI should be a simple task once the backend is ready.”—these and other similar statements reached my ears time and again during my career as a web developer.

Very often, these made me sad. 🥲

The reason is that I spend most of my working hours writing frontend code including HTML, CSS, and JavaScript (JS) (actually, TypeScript most of the time). When somebody tells me, that my job is “easy”, I feel like my skills are nothing special and another developer could replace me anytime…

What follows now is an article about thoughts that came to my mind in the last couple of years when working together with different people from different teams with different backgrounds in HTML and frontend technologies in general. This is an article about the many “whys” in my head and possible answers…

Why do people think HTML is easy?

What is meant by “easy” anyway? Whether something is easy or not is usually in the eye of the beholder. When I know a technology or programming language well, it’s easier for me than somebody new to the field and inexperienced.

Some people tend to make assumptions about the complexity of frontend development and in my experience those people are the ones not working with frontend technologies and especially HTML on a daily basis. Here are a few reasons I can think of why this happens:

  • The HTML syntax is not that hard to learn. Put together some angle brackets, tag names and key-value pairs (a.k.a. attributes) and you’re good to go!
  • The HTML syntax is machine and human readable, which was one of the ideas behind XML-like languages.
  • Once you’ve written a couple of lines of code in a .html file, no compilation or build steps are required to see the result of your work immediately when you open the same file in a browser.
  • HTML has a low barrier of entry. In some WYSIWYG editors there is an option to switch to the “code” view, and you can fiddle around with the HTML version of your text, no matter if you know what you’re doing or not. (You have a preview available, what could possibly go wrong?)
  • Browsers are great and forgive a lot of mistakes (J. David Eisenberg described this in a pretty old article about “forgiving” browsers, that contains some thoughts that are still valid today.). When you open a syntactically broken HTML page the chances are high that the browser still renders something. You forgot to close a tag? No problem. You added an unknown tag or attribute? The browser just ignores it. Compared to a programming language where the whole app crashes because of a missing semicolon, yes, this feels “easy”.

Let’s go one step further and think about why people tend to compare web technologies or contrast frontend with backend development.

Why do people think frontend development is easy?

Programming the backend of a website or application is the hard part, creating the frontend an easy one. Right? Sometimes, it feels to me that this is the common opinion among many developers.

And again, I’m looking for the answers to the “why” and came up with the following thoughts:

Users and project stakeholders are often not confronted with the business logic and backend code at all, but only with the user interface (UI). Adding thoughts about where to put which button or piece of information and how the UI should work in general is easier because it’s just more tangible than complex database queries or nested for-loops and if-statements. The backend is a black box that does its magic and spits out data for the frontend. The frontend developer “just” needs to display this data, add colors, and build a layout (using CSS) and the work is done.

Luckily, there are many frontend component libraries that can be used. Put together some (predefined) views, fill the data in there, and you don’t even need to think about colors and layouts anymore – isn’t that great? So, with this amount of help, almost anyone can build great frontends without too much HTML/CSS knowledge!

</sarcasm>

Frontend built by “non-frontend” developers

I made the experience that people who thought programming the frontend was the easy part of web development (and would never call themselves “frontend developer” but rather “full-stack developer”) made the biggest mistakes in their frontend code (even with help of frameworks and libraries).

Heydon addressed this topic in “Reluctant Gatekeeping: The Problem With Full Stack” where he wrote:

[...] if you put someone in charge of all of these things and more [...] it’s highly likely they are going to be much weaker in some areas than others. [...] In my experience, men especially earn kudos for their knowledge of JavaScript or Python, but little from CSS skills. CSS, which makes things look ‘pretty’, is considered feminine.

Some of the mistakes mentioned above were actual syntax errors, others were problems with semantics, performance, accessibility, etc. In prototype presentations or during testing, often they aren’t noticed because the browser forgives them (see above), performance is usually good on the developer’s machine, no accessibility tests are being made… The result is: it works, the browser displays what’s expected, everything seems to work fine and can be shipped to production.

Why is broken HTML code a problem?

Once the code is deployed to production, the first problems might come up. Users who were not part of the development process interact with the product for the first time and run into issues, some of which may be caused by broken HTML code, impairing the user experience.

Bad user experience

Let’s have a look at problems based on bad HTML code the end-user might stumble upon:

  • frustrating forms (here’s an article of mine about bad user experience when using forms on the web with some examples)
  • performance problems (here’s a talk on YouTube by Harry Roberts about what can go wrong in your HTML document’s “head” – Get your “head” straight)
  • wrong usage of headlines (h1-h6) or missing text alternatives for non-text content, which is bad for people using a screen reader
  • wrong/no usage of interactive elements (“A div is not a button!”) or a confusing tab order of elements, which is bad for people using the keyboard for interaction
  • basically everything you can find on htmhell.dev
  • broken HTML code which leads to broken JavaScript and thus broken functionality

Bad developer experience

Not only the users of your sites and applications might have a hard time using your product when the HTML/frontend code isn’t correct, also your fellow developers could have their “facepalm moments”, because…

  • …when HTML code is badly structured, it’s harder to write good CSS code for it. To put it differently: HTML code often has to be adjusted once CSS comes into play. When you have experience in writing both languages, the chances are high that your HTML and your CSS code turn out great and maintainable.
  • …when HTML code of your project’s UI components isn’t flexible, you might not be able to reuse them or scale the project at all without required refactoring when a new feature is requested.
  • …when developers are not working with the platform but try to reinvent the wheel and not taking browsers’ capabilities into account (like using JavaScript to navigate from one page to another instead of just using a link), bugs might be more likely and fixing them without breaking another part of the application gets harder.

Why should we care?

As mentioned above, browsers are great and forgive a lot of mistakes; websites might work for many people, even if they are not accessible or performant or even if parts of them break. Maintaining these websites might also be done by good-hearted/ill-fated developers who don’t mind working on a smelly codebase.

But I’m sure we can do better. 💪

The goal should be that websites (and web applications) work for most, no, for all people browsing the web and we as developers should build products respecting the needs of all our (potential) users. Writing scalable and maintainable code leads not only to accessible, fast, and usable websites but also to happy developers.

It’s not only about writing HTML

I’ve met people who started learning web development by diving head-first into the newest frameworks and then built a simple website using Angular without learning the basics first. The problem: without basic HTML (or CSS or JS) knowledge, the most popular framework doesn’t help you succeed; on the contrary. You’re using a sledgehammer to crack a nut. No matter which tools you use, the code that gets shipped to the browser is HTML, CSS, and JavaScript and knowing how these languages work is required to build great applications—no matter which newfangled technology you’re throwing at your problems.

Writing HTML in itself isn’t that hard, no.

But: building user interfaces by elegantly composing this language’s features with CSS, creating pleasant designs and user experiences worth remembering requires experience and skills that should not be underestimated. Neither should HTML; it’s one of the languages—if not the most important one of them all—that shape the web.

Related thoughts about the value of (expertise in) web frontend development were shared by

Let’s stop comparing web technologies and their values. Let’s not discuss what’s easier/harder to do or more/less important. Let’s work in teams, listen to and learn from people with expertise, no matter whether they shine in writing HTML, CSS, TypeScript, PHP, Python, {add-your-favorite-language-here}… let’s make the web a great place together and value people who work on the front of the frontend more!

P.S.: Thanks to Felix for always proofreading my articles and expanding my English vocabulary. Thanks to Manuel for maintaining HTMHell and creating this inspiring advent calendar.

About Lara Aigmüller

Lara is a software developer at scale.at always striving for great user experience. She wants to make the web a better place while constantly improving her knowledge about the ins and outs of HTML and CSS. Find more articles by Lara on the scale Blog and follow @scale_www on Mastodon.

scale Blog: scale.at/blog
Lara on Mastodon: Mastodon