HTML5: The Good, The Bad, and The Ugly
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).
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.
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:
- 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.
- 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.
- 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.
- 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.