Choose HTML for UI Development
On Sept. 10, 2015, Winston Kodogo writes:
Hey Chris, if you’re feeling happy enough to blog, how about a post giving us your current thoughts on UI development. A friend of mine has asked me for advice on moving an in-house app from VB6 to something he can find people to modify if he needs to, and I can’t for the life of me think of what to tell him. I have your most excellent books on Windows Forms and WPF, but what would the modern (!) equivalent be. Not WebJS, surely.
Thanks for the softball question, Winston. I do love to pontificate extemporaneously (although I have already given away the ending).
Pre-Windows
I started my Windows career as a Petzoldian Windows developer, but before that, I developed UIs in curses, Flavors Lisp and even voice-based UIs in a proprietary AT&T scripting language for which I no longer remember the name.
Windows
As a Windows developer, I programmed against 16 and 32-bit GDI and User, GDI+, MFC, WTL, Windows Forms, WPF, WinJS, Silverlight and Xamarin Forms. I’ve even written books, articles and presentations about many of these toolkits.
And even now, as I type this, I’m using a different framework, Markdown, to produce the UI you’re using now.
Transcend Windows
It’s this last fact that leads me to my pretty much universal recommendation for UI development: The UI framework with the most reach, the best tools, the most community support and the best staying power is, of course, HTML, with it’s kissing cousins, JavaScript and CSS.
There are good reasons to choose others, of course:
Are you building a mobile game? Use the iOS or Android APIs or, even better, Unity.
Do you love C# and .NET? Then some implementation of XAML may suit your needs.
Are you targeting developers with automation or specific integration needs? Then a command line interface is probably what you want.
But other than that, my default UI development advice is always always HTML.
HTML How
The beauty of an HTML-based UI framework is that it has grown steadily in capability, usage and ubiquity since it was introduced in 1993. It’s hard to find an environment where HTML doesn’t run:
Desktop Browser: This is where HTML was first shown and it arguably shows best here. There’s little you can’t do in this environment, including near native games using WebGL, Enscripten and asm.js (soon to become WebAssembly).
This is probably your best bet for any kind of internal app, e.g. the kind of thing that VB6 and WinForms are usually used for. Toolkits like Angular and React are popular for desktop browser apps because they provide the end-to-end developer story while still having rich extension libraries.
That said, if I were going to tackle a new web site or web app today, I’d probably use WebComponents (and Polymer) for the excellent reasons that Joe Gregorio lays out in his OSCON 2015 talk.
Mobile Browser: Today’s smartphone-based browsers are very capable and adapt to desktop-based web sites fairly well. However, I do recommend making sure your desktop web sites work well on mobile as well, if for no other reason than you want to make sure you don’t lose your ranking on Google, which now prefers mobile-friendly sites for mobile search results (and provides a tool to help you get your site ready).
With the modern enterprise moving towards mobile as fast now as they have been moving towards the web-based intranet over the last decade, I’d recommend making sure that your internal web sites/apps work well on mobile if you want to avoid the CTO stopping by your desk in the near future.
Desktop Stand-alone App: The new trend (with companies like GitHub and Microsoft on board) for building cross-platform, stand-alone desktop apps is to use HTML, but package it into an app, specifically using something like Electron. This is the new hotness, but this is what I’d do if I wanted to build a stand-alone desktop app today.
Mobile Store App: Most mobile apps today are built for the iOS and Google Play stores, although increasingly enterprises are building mobile apps for internal use and distributing them internally using private stores like Appaloosa.
Today, mobile apps are built overwelminging using the platform-specific native APIs, most often with two separate teams for each app, one for iOS and one for Android. However, as mobile becomes more of an enterprise platform, you want apps that are developed quickly, can be maintained easily and can be built with a smaller number of developers, which all boils down to one thing: you want to have a single codebase for your internal mobile apps instead of one codebase per platform.
Today, you have two viable alternatives when building mobile apps that target multiple platforms from a single source code base: Xamarin and Adobe PhoneGap. Xamarin is essentially cross-platform .NET with some UI controls and native compilation thrown in, whereas PhoneGap is a framework for hosting HTML on mobile platforms (as well as others, but no one does that) along with a platform-agnostic JavaScript API that maps to native functionality.
I’ve used both of these frameworks and they both have their pros and cons. Xamarin has a simple UI framework that changes it’s look ’n’ feel depending on the platform your app is running on, but PhoneGap does not. In that case, I’d also bring Ionic into the mix, which will let you write your app in HTML but give you the native UI as appropriate (and a beautiful one at that).
There has been much said about whether HTML is appropriate for building mobile apps and while it’s possible to build a bad app using any platform, in my experience, it’s not hard to get an app that’s built in HTML to look ’n’ feel just like a native app. When I did it, there were some tricks involved, but frameworks like Ionic pretty much take away the need for that these days. Of course there are always going to be apps that can’t be built this way, but as a percentage (leaving out twitch games), that number is getting smaller and smaller.
Where are we?
Of course, the best and worst part of the web platform is that the community changes it’s mind about how sites and apps should be built for the web platform about as often as I change my underwear, so the specific recommendations are merely appropriate for this point in time. The general guidance remains the same, however: choose HTML for your UI development unless you’ve got a darn good reason not to.