Trouble shooters .Com® and Web Workmanship Present:

Why Use HTML?

See the Troubleshooters.Com Bookstore.



You might be asking yourself "There are so many faster, easier and more modern alternatives to coding in HTML. Why should I code in HTML?"

It's a fair question that deserves a thoughtful answer. Read on...


A little jargon used on this page:

Learn HTML, Understand the Rest

The most important reason to learn HTML and CSS from the ground up is to understand exactly what you're doing, regardless of what tools you're using. Many people make a good living making websites, without ever coding HTML. I'd recommend these people learn HTML and CSS, and learn them well, because without knowing HTML and CSS, your tools are just FM (Fantastic Magic). And when tools-only web developers encounter a requirement not easily done by their tools, the first step is web research. And there's where things can get dicey.

A lot of answers and info on the Internet don't work. More harmful are answers that get the task done, but do it the wrong way, creating unpleasant side effects. The developer with thorough knowledge of HTML and CSS has the ability to recognize which answers are the real deal, and which are just kludges. Those without such knowledge, bad things can happen. On more thing: The developer with substantial HTML and CSS knowledge can often create or modify one CSS rule instead of doing four or five things with the tool.

And then there's this question: Can somebody accurately call themselves a full stack developer without a substantial understanding of HTML and CSS?

When Not to Use HTML/CSS Directly

If the web page you contemplate is wholly or mostly interactive, like Healthcare.Gov, Facebook, Twitter, Zoom, a Wordpress site, Jitsi, BigBlueButton, a blog with interactive comments, a shopping cart and the like, direct editing of HTML/CSS will be of limited value to you for that particular page. For such a page, use active tools. Active tools include Rails, Django, Bottle, Flask, PHP, Wordpress, Node.js, React, Vue, or probably 50 other tools devoted to creating interactive web pages. Using active tools, you'll get your page up and running much faster, and we all know time-to-market is the top priority. By putting prompts and explanations in the database, modifications will be simpler.

When Not to Use Active Tools

Static content is web content that doesn't change unless the developer or owner decide to modify the existing text. Some developers choose to put static content in a database. What could possibly go wrong?

Everything-in-the-database fans point out three benefits:

  1. Ability to control who writes/modifies what.
  2. Ability to upload content without rsync, sftp, or other tried and true techniques.
  3. Ability to edit the whole website

As far as controlling who writes/modifies what, this can be handled with OS permissions and groups or ACLs, or git.

The ability to upload content without rsync, sftp might be nice for the unknowledgeable, but how many web developers, even the kind who just put together words, images and video, are that unknowledgeable? And even if they are, learning rsync and sftp is a half-day's learning.

The ability to edit entire websites is a mixed bag. It's nice because it you set up a link from another page, a template pops up, you fill in the blanks, and you're done, and every page has the same look. That's the theory, but it's seldom that simple, is it? Each page has its little differences, you need to know where to place the code for the differences, and different people recommend different places to place the code. This is especially true using the MVC (Model View Controller) paradigm, which has several different definitions across the web. Full website active tools make the hard stuff easier, but also make the easy stuff as hard as the tool, which is usually pretty difficult compared to direct HTML editing (DHE). And of course, with all those pages open at once, it's pretty easy to type the wrong stuff into the wrong page.

Some pages are hybrids, with some active user interface, and some static text. My suggestion: If they're primarily static, use HTML and CSS plus enough Javascript to do the active tasks. If they're primarily active, use other tools.

Why Not Use Bootstrap

Bootstrap is an HTML/CSS/Javascript template set designed to make good looking, modern looking and responsive web pages without working extensively with HTML, CSS or Javascript. It's a configurable "one size fits all" tool with all the advantages and disadvantages of configurable "one size fits all" tools.


I'm not picking on Bootstrap in this section. Bootstrap can be pretty cool in the right situation. Bootstrap isn't the only static-web-page producing tool; there are plenty of others, all subject to what's said in this section. And in fact, sometimes it's easier to use one of these tools. But often times it isn't.

Most readers will look at Troubleshooters.Com's Web Workmanship subsite and ask "Why edit HTML in 2022? There are so many more modern, easy, full featured, mobile friendly ways to do it! This viewpoint definitely has merit, but I strongly believe that Direct HTML Editing, or DHE for short, is a valuable tool in many situations. This document explains why.

Let's discuss HTML validation first. Have you wondered why so many web pages look so dysfunctional, with text being covered up or garbled, or having to horizontal scroll to read each line? Or most important, having a web page that looks great on one browser and dysfunctional on another? You can lay the blame squarely on invalid HTML. About 99% of the web pages out there display errors (not warnings) when validated with the W3C validator.

All competent web browsers render valid HTML as the author intended, and they all render it very close to identically. The differences come to bear when each browser "helpfully" renders invalid HTML in its own way. So you can either join the 99% whose pages render differently on different browsers, or you can make your pages valid HTML and not have to worry about it. And, as discussed later in this document, making your pages valid HTML is easier than you think. However, it can be quite difficult to create a valid web page with Bootstrap created pages.

Bootstrap is a tool consisting of HTML, CSS and Javascript templates. It advertises itself as "the world’s most popular framework for building responsive, mobile-first sites, with jsDelivr and a template starter page." Let's delve into that...


"Responsive" is a buzzword meaning it works on both computer monitors and mobile devices. This is trivial to do with simple HTML and CSS. Just do the following:

Nothing on the preceding list is difficult or tricky. I can do them in my sleep. So can you. See the Web Workmanship's Responsive Design page.


"Mobile-First" is a buzzword. A web search reveals it to mean something like "design your web page for the mobile device before designing for a desktop." Well that's easy enough. Use a mobile device to look at what you're creating. Or view your website in Firefox's "responsive" tool frequently, and once in a while view it on a mobile device.


Chromium's responsive design facilities currently have some problems. Best to stick with Firefox, for responsive design work, as of May 2022.

Some define Mobile-First as designing a primary web page for mobile devices, and then make a separate auxiliary web page for desktop monitors, and use a media query, based on screen width, in the primary web page, to decide which web page to present. This is easy with roll-your-own HTML, always assuming you watch out for appearance jitter/oscillation at widths right near the media query width. Because mobile devices are very narrow (4 to 5 inches) and monitors are very wide (12 to 28 inches), this is seldom a problem.

Bottom line: You don't need Bootstrap or any other tool (except a mobile device to test with) to do Mobile-First design.


According to the jsDelivr website, jsDelivr is "A free CDN for Open Source. Fast, reliable, and automated." CDN stands for Content Delivery Network, which means your web pages are cached on servers across the world so your users can get the closest copy. It also gives you stats, failover, and RUM based load balancing. RUM stands for Real User Monitoring, and appears to be a stats package that not only reports, but also acts as a feedback mechanism to maximize speed of delivery. Nice!

Two things though: First, you don't need Bootstrap to get jsDelivr, because jsDelivr is a separate product, and it seems to be free to use. Second, if you write your web page through Direct HTML Editing and don't include large graphics, your page is likely to be so light weight that it will load semi-instantly on dialup, or across the world. For instance, my HTML/CSS/JS Quick Hacks web page in 863 milliseconds (so less than one second), without CDN, in Sydney, Australia (my ISP is in Florida), according to the Pingdom Website Speed Test tool. According to the same tool, my 14 photograph Cleaning a DE Filter page loaded in 2.86 seconds. Meanwhile,, which almost certainly makes use of CDN, loads in 4 seconds on my browser, and the website speed test had it at 2.61 seconds in Washington, DC, and a whopping 5.61 seconds in Sydney, Australia.

As they say, size matters. According to the website, speed test, Buick.Com is a 2.1 megabyte download. Troubleshooters.Com's Cleaning a DE Filter page, with its 14 paragraphs, weighs in at just under a half a megabyte. The HTML/CSS/JS Quick Hacks web page weighs in at 10.4 KILObytes.

Template starter page

Here's a template starter page useful in Direct HTML Editing (DHE):

./template.html. Feel free to download it with wget or curl or whatever, and use it to start a project: It's Expat License Free Software.

Other Advantages of Direct HTML Editing (DHE) Over Bootstrap

Here are some advantages of DHE over Bootstrap:

I'm Not Picking On Bootstrap

I'm not picking on Bootstrap. I'm just using as an example of the many tools, meant to make things easier, that have as big a learning curve as Direct HTML Editing.

Actually, Bootstrap is one of the better tools for mostly static HTML. There are people who make mostly static HTML pages using PHP. Think about that for a second.

All I'm saying is that for less learning and training than most of these "we save you from HTML" tools, you can learn Direct HTML Editing and be the master of your website's destiny, and using a template, you can do it pretty quickly. And your page will load quickly.

Direct HTML Editing Is Easier Than You Think

Direct HTML Editing (DHE) is much easier than most people think. When most people think of Direct HTML Editing, they think of 1995, using Microsoft Notepad, or the commercial product HotDog if you were a hot dog, flipping back and forth between the editor and articles on HTML syntax. HTML syntax was ugly and arbitrary in 1995, and due to the lack of CSS, you had to style every element in your web page. It - took - forever!

By the time all the major browsers handled CSS competently and people learned it, it was maybe 2002. CSS makes DHE much easier, but it was too late, because DHE got hijacked by the first "HTML not needed" tools...

Those first tools were the WYSIWYG web page editors. Ask your parents about them: MS Frontpage, Netscape Composer, Netscape Gold, Mozilla Composer, KDE Kompozer, eventually even MS Office and LibreOffice. Troubleshooters.Com still has some pages created with WYSIWYG editors. They render differently on different browsers. They're almost unmaintainable. As time goes on, I either delete them or rewrite them in HTML5 plus CSS.

People sick of typing no-CSS 1990's HTML on Notepad or Hotdog flocked to the WYSIWYG web editors, just because they saved time. So except for the pioneers, nobody edited HTML, and those pioneers told (accurate) tales of how time consuming it was to write 1990's HTML. Except they forgot to specify "1990's, so today the myth persists that modern Direct HTML Editing, with CSS, is difficult or time consuming.

Here's how you make DHE fast and easy:

Seriously, in 2022 Direct HTML Editing is fast and easy.

Read-Only, Interactive, and Hybrid Pages

A Web page falls into one of three rough categories:

  1. Read-Only (static)
  2. Interactive (dynamic)
  3. Part Read-Only, Part Interactive (hybrid)

If the web page you contemplate is wholly or mostly interactive, like Healthcare.Gov, Facebook, Twitter, Zoom, Jitsi, BigBlueButton, a blog with interactive comments, a shopping cart and the like, the Web Workmanship subsite's only value to you, for that particular page, is the general HTML/CSS knowledge to use a tool meant for interactive pages. For such a page, use Rails, Django, Bottle, Flask, PHP, Wordpress, Node.js, React, Vue, or probably 50 other tools devoted to creating interactive web pages. You'll get your page up and running much faster, and we all know time-to-market is the top priority.

Now let's discuss web pages that are entirely read-only, or perhaps mostly read-only, perhaps with a web form connected to a database on an otherwise read-only page. The first item to discuss about such pages is the possibility of storing unchanging (at least for weeks at a time) content in a database. I lot of people do, and a lot of people brag about doing it.

Trouble is, databases are less secure than HTML. They're harder to back up. They use a lot more resources. They require a whole level higher technical skill to create and keep running than simply editing HTML with an editor like VScode. And when they crash or your web host implodes, as companies are prone to do when sold or bankrupted, having your static content in databases makes it a whole lot harder to pick up the pieces. Troubleshooters.Com has had three web hosts implode, in each case removing access to our web content, but in each case, because Troubleshooters.Com is a tree of static or hybrid web pages, so moving from one to the other was only a tar -czvf, an sftp, an ssh, and a tar -xzvf away. This often took less time than changing the DNS record to point to the new direction.

Perhaps you host your websites in a VM or container on a cloud server like DigitalOcean, Linode, AWS, Azure, Google Compute Engine, Vultur, Hostwinds, or lots, lots more. You buy what you use, no more, no less, and as your business grows, you grow your remote virtual machine to match. Your VM is in a professionally managed data center with a huge and fast pipeline into the Internet. A lot of these virtual servers have tools you can use to build a web presence. And most of them are just fine with your SFTPing or rsyncing your static pages right up to your VM. You get the best of both worlds: You write your web pages locally, use that as your backup (and of course back up your local machine at frequent intervals), and then upload your pages when they're complete, or any time you change them. You have one image of your website on your VM (in the cloud in bizz-speak), and the other right there on your hard disk, suitable for backup to external hard drives or optical discs.

This is a good setup, because your cloud services vendor isn't a single point of failure. Tomorrow they can get bought, go bankrupt, kick you off for alleged violations, raise their prices obscenely, or just quit offering the cloud services you're using, and all you need to do is find another cloud services vendor, change your DNS, and SFTP or rsync your website up to the new vendor. As far as databases, you'll need to do frequent database backups to save the latest structure and data, but if you're using static HTML to exhibit your read-only content, the database needs will probably be relatively small.

But Direct HTML Authoring Is Soooo 1995!

This is a statement about fashion, not quality or ease of authoring. And the fashion involved is development, not what your web visitor sees. You can make just off the showroom floor modern looking web pages with Direct HTML Editing (DHE). Further information about this was given previously in the Direct HTML Editing Is Easier Than You Think section.

Handy Rebuttals

When you pick a technology, some folks go all-in with their personal and technological put-downs. In case you choose Direct HTML Editing (DHE), here are some inevitable anti-DHE assertions, followed by handy rebuttals for the inevitable:

  1. Don't reinvent the wheel.
  2. I'm not a programmer.
  3. My time's too valuable.
  4. HTML websites are soooo 1995.
  5. HTML websites are ugly.
  6. I need a responsive web page.
  7. My colleagues will think less of me.
  8. Use AWS.
  9. Use Drupal.
  10. Use a database even for static content.
  11. Use Wordpress.
  12. Use react/vue/node.js even for static content.
  13. Use Facebook.
  14. You're a greybeard!
  1. I'm not going to use other people's whole wheel when all I need is a spoke nipple I can quickly create. Voluminous complexity has its costs in training time, load time, maintainability, and sometimes security.
  2. And they're so proud proclaim that they're not a programmer. I guess programmers are the new ditch diggers. Anyway, HTML and CSS aren't programming, so they don't require a programmer. The Open Source vscode editor, available on all major operating systems, takes your hand and guides you though HTML and CSS creation.
  3. I can't argue with the "My time's too valuable" crowd, except to say that security, reasonable loading times, maintainable web "code", and not confusing the person reading the web page are also valuable, and heaven help these guys if their employers ever realize it. Also, Direct HTML Editing can be pretty quick too.
  4. Soooo 1995? I remember 1995 websites. "Best viewed with browser X". Gratuitous graphics (Oh wait, that's a thing again.). Frames. Inconsistent appearance because appearances were bolted onto elements instead of being defined in CSS. Not viewable on small devices. What's described in Web Workmanship yields web pages is nothing like 1995.
  5. HTML websites are ugly only if they're made to be ugly. An artistic web author can make a beautiful web page, as can a person who simply writes his or her CSS to mimic the look of a particularly attractive website. I made this page to somewhat resemble Amazon. And of course a lot of modern web pages are ugly and in many cases sub-functional.
  6. The techniques in Web Workmanship produce responsive web pages, meaning they can be viewed on all screen sizes, always assuming images and <pre> materials are handled intelligently.
  7. Many of my colleagues do think less of me because Troubleshooters.Com is mostly static HTML without helpers like Bootstrap and without AWS, Drupal, Wordpress, or Facebook. On the other hand, to quote a friend I respect very much, "Instead of making websites that do their job, i.e. inform clients or customers or potential customers, they are now platforms where website designers are just trying to show off to other website designers." Think of my friend's quote the next time you see a site where half the writing is covered by something else, and everything's jumping around, and it takes 20 seconds to completely load.
  8. AWS is a pretty inexpensive web server as a service, and can handle plain HTML just fine. For interactive pages, AWS gives you lots of extra tools.
  9. Drupal has its place for large websites with considerable interactivity, but not for mostly static websites, where a common CSS file can accomplish the needed uniformity.
  10. Using a database for static content lessens security, is more difficult to back up, is harder to restore when something goes wrong, requires much more thought and time to design, requires higher priced talent to create and maintain, and loads slower than HTML/CSS.
  11. By all means, use Wordpress for blogs. For mostly static web content, HTML plus CSS and maybe a tiny bit of Javascript produces a better result.
  12. Using react, vue.js or node.js for pages with mostly static content takes longer to create, longer to load, is not as maintainable, requires more expensive talent, and is harder to back up than HTML plus CSS and perhaps a little bit of Javascript.
  13. Facebook is great for quickly setting up a bi-directional web presence. It's not a great place to show substantial amounts of material, it's subject to hacking, it's extremely difficult to back up, and if Facebook decides to shut down your account, your hard-to-back-up web presence is gone for good.
  14. The greybeard thing. Yeah, they go there if they can't persuade you with logic. When they go there, you won the debate, but they're not aware enough to know it. The greybeard thing is an Ad Hominem logical fallacy.


Direct HTML Editing (DHE) was difficult and time consuming in 1995. Now, in 2022, it's easy and quick, and its learning curve is probably equal or less than those of the "We do the HTML for you" tools. And DHE produces small (in kilobytes) pages that load quickly, don't tax the HTTP server, and render almost identically on all competent browsers. If the desired page is read-only or read-only with a couple web forms or a little Javascript, DHE is the ideal way to make the page. Using the info in the Web Workmanship subsite, you can make web pages quickly, to your exact specifications.

Bootstrap is an outstanding tool for creating static or hybrid web pages, but often DHE produces better results quicker.

DHE can be used to create responsive web pages and mobile-first web pages. DHE development can be made even faster by using suitable simple templates.

Even if you never use DHE, knowledge of how to use DHE will make you a much better web developer, no matter which tools you use.

[ Training | Troubleshooters.Com | Email Steve Litt ]