Trouble shooters .Com® and Web Workmanship Present:
Why Use HTML?
Copyright © 2022 by Steve Litt
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:
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?
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.
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:
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.
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.
"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, buick.com, 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.
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.
Here are some advantages of DHE over 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 (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.
A Web page falls into one of three rough categories:
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.
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.
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:
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 ]