Have you heard? HTML5 apps are going to change everything, probably next year. At least that's what one side of the debate about HTML5 versus native apps has been saying for a while. It's a message that makes its way to the limelight every now and then, and it's going to be that way forever. Or at least until it actually happens and all the best apps are HTML5 apps. It's not unusual to see developers have these sorts of debates and proponents of each side explaining how their version is the better version, but when things go beyond a developer discussion and into the mainstream where you and I hear them, they can make us numb. Should we really care about what we're hearing?
In this case, yes. While the utopia where every app is written in HTML5 and every user has the same experience is still a good ways off if it ever happens, HTML5 in a hybrid form is already a pretty big deal. We should know and understand anything that's a pretty big deal.
What is an HTML5 app?
The first time most people heard HTML5 being mentioned was when Steve Jobs told us all it would be the future of the web and Flash wouldn't. His statement was made true partially because Apple blocked access to any sort of Flash player on iOS, but it didn't take a visionary of any sort to know this was coming because HTML5 has a lot more going for it than Flash ever did. And it just so happens that the future of the web is also a pretty good way to code applications.
HTML stands for HyperText Markup Language, and we're at the 5th revision of the standard. But when you hear the term HTML5 app, whether that means a web app or an app you can install on your phone, you're really dealing with three types of code.
- HTML provides a framework where developers can put their code and an application can turn it into something we can see and interact with.
- CSS provides a way to layout how individual bits of code will look once they are rendered and displayed on our screen.
- JavaScript is what makes it all interactive and be able to "do" anything.
What makes HTML5 great is that everything is understood by one application that an app developer doesn't need to maintain and it all works on any device with a screen that has its own version of that app. We're talking about a web browser, but not the web browser app itself. The component of a web browser that can take all this code and render it into something we can use on the fly is fairly portable and a part of a lot of apps you already use as a web view.
A Mozilla engineer once said "Code once run anywhere doesn't mean to run away. Optimization is the key." Smart guys, those Mozilla engineers.
What this means is that a developer can write his or her code and fine tune it, then deploy it everywhere. That's a lot different than writing separate code for Android, iOS, macOS, Windows, and HTML for webOS and BlackBerry 10. A developer can write code using whatever development environment they choose, whether that be Notepad or something complex like Visual Studio or Adobe Dreamweaver, debug and fine tune it in whatever browser they choose, and it still just works everywhere.
That includes your phone, too. We've all seen HTML5 apps being used as a web page. Places like Twitter or the mobile version of Gmail are excellent examples of HTML5 at work. But since HTML5 can be rendered by a web view component, dropping a window inside a basic app frame to create an app you actually install on your phone is simple and fast. There are even third-party tools that do all the work for you, like Apache Cordova. This helps new developers bring their ideas to everyone as well as seasoned developers who now have time to dream up things we've not seen before. HTML5 embedded in a native app can run the code and use assets it gets from the internet, but a developer can also install these locally and point the code there for honest-to-goodness offline native apps.
But not everything is great about HTML5.
The reality of HTML5 apps
Here's where things can get confusing. When we think of a web page, we often forget that a web page only sends its code to a browser engine and it's our device that does the work. That means things like geolocation, real-time audio and video chat, 3D accelerated graphics, and a lot more are not only possible but simple for a developer to implement using HTML5. That's because a standards body has said: "Hey guys, we all need to do this certain thing this particular way, and a developer can ask us to do it like this."
That's the goal, anyway. Reality can be a bit different, and we only need to look at video playback for a great example of why. Every browser you would want to use supports HTML5: Chrome, Opera, Internet Explorer, Edge, Firefox, and Safari are HTML5 browsers and support video playback once a developer types in just a few words that point to a video. Any type of portable web view component these apps have will do the same thing because they use the same rendering engine.
When you don't enforce rules they become suggestions; ones that nobody wants to follow.
But they don't all support the same type of video because HTML5 is cross-platform, open, and not proprietary, so nobody is forcing them to support all the formats. Ogg Theora is a popular video format that every browser supports except for Internet Explorer, which happens to be the default browser on a lot of computers. H.264 is even more popular, but it's not open or free to use so Firefox doesn't support it. VP8 and WebM are free to use and open and every browser engine supports them, but Internet Explorer and Safari require the user to fetch and install support. Technically, HTML5 supports HD video playback and is super easy for a developer to implement it. In the real world, only the right type of video is supported.
YouTube plays all video with HTML5 because Google has the money to convert the videos you upload.
HTML5 also depends on the hardware in use and how proficient the developer is when it comes to writing the code. Choosing the wrong JavaScript library may still produce the same result, but it can also lead to memory leaks, and handling DOM Manipulation (Document Object Model — created when a page or app loads, and includes every element on the page or in the app as a separate "document") poorly can make an HTML5 app frustratingly slow on even the best hardware. On phones that aren't as capable, it quickly leads to users uninstalling your app.
That's not the only issue. When you build an HTML5 app that pulls everything from the internet you have to deal with loading times. That adds a user's connection speed into the list of things that can make your app run slowly, along with the physical capabilities of the hardware (many phones use processors that aren't exactly speedy) and code optimization. If it takes one second to display your code on a users device and 10 seconds to fetch it from the internet, you're going to have a lot of unhappy users.
The Facebook app is an example of what's wrong with HTML5 just as the Instagram is an example of what's right.
There's an excellent example of this available, and its one almost all of us have been unhappy with no matter what type of phone we use: the Facebook app. The Facebook app is basically a web view embedded into a frame that holds the buttons and helps manage your account credentials or push messages in a way the operating system approves of. All the stuff that happens inside the app is done with HTML5, and it's just too much for it to handle once you factor in fetching all its data from the internet.Developers keep adding more and more to Facebook, users are posting large files hosted at places outside of Facebook, and there are millions and millions of people hitting Facebook's servers all at once, 24/7. That makes the apps slow to refresh, very power hungry, and the subject of a lot of complaints.
Facebook's mobile website is also written in HTML5, but it's designed to be lite on resources because it's for mobile use. That makes it faster to load the content you want to see even if all that content isn't displayed quite as nice as it is on the full view. It's also why the mobile site and Facebook "lite" apps that reference it works so much better than Facebook's official app. And this isn't just a Facebook problem — there are plenty of apps that would have all their features supported using HTML5 but are just as complex (a nice word for bloated because they have been around a while and are constantly changing) as Facebook and would act the same way.
So do I want to see more HTML5 apps or not?
Yes! But not all apps.
HTML5 is really good at a lot of things and is a great way for a developer to use his or her time to think of creative ideas instead of rooting through an Objective-C or C++ reference manual. But sometimes, the rigid structure of development languages that force a developer to do things a certain way is what makes the end result work better on our phones.
HTML5 apps can be a nightmare like we see from the Facebook app or they can be pretty awesome like we see from the mobile Gmail site. Or Uber. Or Instagram. Or any of the hundreds of HTML5 apps we use every day. That's not a thing we should have to worry about, but it's totally a thing for developers to endlessly debate. And now while they are debating and trying to convince you which is better, you know a little bit about why they are saying the things they are saying.
