HTML5: The Good, The Bad, and The Ugly

November 18, 2019

Hypertext Markup Language (HTML) is the standard markup language for documents designed to be displayed in a web browser. It can be assisted by technologies such as Cascading Style Sheets (CSS) and scripting languages such as Javascript.

HTML has been around pretty much since the inception of the internet, and it is used by anyone who wishes to create web pages.

At the beginning, HTML really didn’t do much besides coloring text, changing font sizes, displaying images, animate gifs, etc… In retrospect, the early version of HTML produced some pretty boring web pages.

However, as technology’s capacity increased and an understanding of how to use HTML in conjunction with other coding techniques, we’ve gotten to a place where HTML can create some pretty impressive websites.

The slaying of the Flash dragon by the Gods of Cupertino gave HTML a huge push, and HTML5 is now being touted as the latest golden ticket that will solve all of the computing world’s problem, including the vexing problem of developing software for any type of operating system at a minimal cost. But is it really all it’s cracked up to be? HTML5 is impressive, no doubt, but if you ask me, it falls short of that ideal target. 

The thing is that HTML5 is just like any other platform, and it has good parts, bard parts, and really ugly parts.

The good part about HTML5 is that it does actually provide a new set of tools that enable the delivery of high-quality app like features via a web page, and some of these web pages can now do some pretty impressive processing without doing a postback. The postback occurs when you initially load a web page, when you refresh it, or when you click on a button. It produces this really annoying ‘flashing’ that I have to admit can be nerve-wracking over time. So HTML5 is definitely a thumbs up in this department.

The bad part of HTML5 is that it’s a really ‘tedious’ platform to work with, and if you don’t believe me, do a ‘view source’ on any web page, and you’re going to see that the back end of a web page consists of massive amounts of text, even for a simple web page. The more a developer has to sift through, the longer it takes to develop an application, and therefore, the cost goes up.

But even this particular part can be mitigated to a certain extent by acquiring a decent Integrated Development Tool (IDE).

One aspect of HTML5 that is really bad is that anyone can look up the javascript code that makes a web page tick. You just have to know where to look. Software developers earn a living by writing code that does something useful, and if the program is really good, you probably don’t want your competition to see what you’re doing and how you’re doing it. Typically, programs (as opposed to a web page) are compiled, and it’s pretty difficult to see the code. You actually need a lot of knowledge in order to extract the code form a compiled file. Not so with a web page – your javascript code is there for the world to see. Of course, there are ways to make it more difficult to see, but even these ways are fairly easy to circumvent. For this reason alone, I’m not enthusiastic about using HTML5 as my development platform of choice.

This tediousness can be mitigated to a certain extent by using external libraries. Some of them are pretty good in that they really do reduce the tediousness, and therefore they help in speeding up the development process.

My biggest reservation about the whole HTML5 movement is not HTML5 per se. My reservation has to do with the browsers, and the browsers are the ugly part of HTML5.

Traditional programs are executed and interpreted by the Operating System (OS). So, a program written in .NET will function and be executed the same way whether it is run on a windows server, a windows workstation or laptop, or a windows tablet. Same thing with the iOS. A program written in objective C will function on any Mac device running the iOS. In other words, you get consistency. The problem with this approach though, is that if you wish to develop a program for iOS, Android, and Windows, you will end up writing the code for the application three times, one for each platform. The reason behind is that there is no programming language or platform that will easily compile a program for each platform. Obviously this runs the cost up and increases the development time. 

So, how do you get around this particular problem? One approach is to develop what’s called a Progressive Web Application. Essentially, a Progressive Web Application is an application delivered through a web browser, developed using HTML5. It’s a seductive approach because, in theory, the web page will function the same on all devices that have a browser. Then there’s the added bonus of not having to download anything to get the latest and greatest version of the app. In instances like this, the browser is responsible for interpreting the code as opposed to leaving that work to the OS. 

And this is where things start to get ugly. Really ugly. 

The browser component of the HTML5 ecosystem is what I consider to be the really ugly part of HTML5. There are many browsers available: Safari for the MAC, Internet Explorer/Edge for Microsoft, Firefox, Chrome, Opera, etc…. Although they’re all supposed to interpret HTML5 code the same, the reality is that they don’t. For example, we use a development called RD3 (Rapid Design, Development, and Deployment) for CBT type rating courses. RD3 is a database application that basically dynamically assemble online course screens on the fly. Being data-centric in nature, it takes some time to load the data when you select a particular project to work on. When a web page takes some time to load, you need to give the end-user something to do. Otherwise, the impatient types will start clicking repeatedly on a button (or worse yet, refresh the page) because they expect an instantaneous response. Typically, this ‘something to do’ boils down to displaying the standard-issue – one each rotating circle. We’re currently in the process of doing a makeover of the RD3 system, so we decided to give the user a load bar to look at.

This loading bar is actually pretty neat – basically, the server is executing code to fetch data and organize it, and the server-based code is actually feeding back progress information to the loading bar. The change in the percentage of completion of the process as well as the width of the tape provides reassurance to the user that the application is not stuck on something.

Unfortunately, this loading bar is not displayed in a Safari browser due to a bug in the browser code. It did work at one point in time, but then something changed in Safari that caused this component to fail. If and when it gets fixed depends on Apple.

This is what’s called a Browser compatibility issue, and unfortunately, there’s still too many of them. These compatibility issues affect not only Javascript but HTML and CSS as well. To be fair to the browser industry, there is genuine effort to fix these issues, but the fact is that code needs to be developed now, not at some point in the future, at the convenience of the industry.

Because of these compatibilities, a serious developer will test the web app in the different browsers, and unfortunately, there’s a lot of them: Internet Explorer, Microsoft Edge, Chrome, Firefox, Safari, and Opera are the most popular. However, there are also issues with the platform – a tablet versus a workstation. What works in Safari desktop may not necessarily work in Safari iPad or iPhone. As you can see, the time saved in developing with HTML5 is counterbalanced by the time it takes to test in the various browsers.

Broadly speaking, there are a few principles to keep in mind when developing web applications:

1. What works today may not necessarily work next week. These browsers are constantly evolving, and just recently, Google announced that Chrome will remove the ability of scripts to perform synchronous requests during the before unload and unload events of a page. This is particularly significant for online courses because it means that you will no longer be able to send SCORM data when you close the course page using the ‘X’ button.  
2. What works in one browser may not necessarily work in another browser, so the developer ends up having to fork code in order to accommodate the plethora of browsers. This obviously complicates the code. 
3. What doesn’t work universally today may work universally next week. Once again, these browsers are constantly evolving, so, if this occurs, you end up going back through your code to try to simplify it.
4. What is supported by all browsers may not always work as expected. For example, the onUnload event is supported by all browsers. It occurs when the user navigates away from the page (by clicking on a link, submitting a form, closing the browser window, etc.). However, if you go look at the web page for this event at the w3schools.com web site, they have this footnote: Note: Due to different browser settings, this event may not always work as expected.

HTML5 may be the touted golden ticket, but with this many issues affecting such a wide breadth of cases, I encourage people to do their work, understand the limitations, and be prepared to offer alternative solutions where it makes sense.