HOW HTML5 SAVED THE WORLD

by Dave Sweeton

It didn’t. It won’t. But if you believed the hype and buzz, you probably thought that it would replace all of your current development platforms, make cross-everything development happen magically and solve world peace to boot! Don’t get me wrong, HTML5 is cool and offers a lot of promise, but all of its promises come with caveats, addenda and gotchas.

The first thing to understand about the HTML5 standard is that it’s not a standard. W3C and other bodies tried for years to form a standard for the next generation of the Web, but…well the details are complex and messy and you probably don’t care. (I don’t!) The bottom line is that HTML5 is a “living standard,” which means it’s never finished and is always being updated and improved. That’s okay by me; it pretty much reflects the state of the Web as it’s always been, which is wild and woolly.

What this means is that there is no browser that implements “HTML5″ in all of its shining glory. Instead each browser implements parts here and there, sometimes correctly, sometimes not, and we stumble forward. As a developer, it can be hard to figure out the current state, but there’s a great Web site for this: www.caniuse.com.

The markup of HTML5 isn’t much changed. Some new tags have been added, like better input fields or tags that offer better semantics like the nav or footer tags. Semantics are well and good, but not very exciting.

HTML5 is also attempting to reduce the browser’s dependence on 3rd party plugins by providing native support for things like embedded video and audio. This is still a work in progress, as there’s no agreement on which audio and video codecs to implement. If you want to support a range of browsers, you end up with multiple encodings, and of course falling back to old style object tags for older browsers.

The more exciting part of HTML5 is that it’s an umbrella for JavaScript APIs that support building more advanced client-side applications. Here’s just a sampling:

• Canvas is a direct 2D drawing surface. Cool, but probably not something you’ll use in most business-oriented Web apps.

• Web Storage allows you to store data for pure client-side use (as opposed to cookies which get passed back and forth between the client and server). Useful for Web apps that need data cached locally, but it’s still limited in the amount of data you can store. That limit varies by implementation, but expect around 5 MB.
• If you need larger or more structured storage, then there’s Indexed DB (oops, hope you didn’t use Web SQL Database, as it’s been dropped from the standard).
• Support for Offline Web Applications. Boy, does that sound like a contradiction in terms! This basically involves the browser downloading a list of all of the resources used by your application and then caching them so that your Web Application is then available when there’s no network connection available. This is good progress, but in my limited experience there seems to be more work needed to support the mobile online/offline experience that people want.

Won’t HTML5 replace all of my current client-side development platforms? Of course not. It’s just one more tool in your kit, but it is one with growing importance. My personal feeling is that a Web app built on HTML5 will never have the same feel or power as a native app. But in many cases HTML5 can be good enough. I think Google has proved this more than anyone; Gmail is a functional and rich UI, and while I never thought a browser-based word processor would work, Google Docs (now Google Drive) has certainly proved me wrong.

On the desktop HTML5 got a boost recently due to the fact that you can use it (and JavaScript) to write Metro apps for Windows. The importance of that is tied to the success of Windows 8, however, since Microsoft won’t be porting Metro to older operating systems. For Windows-only development, a standard WPF/WinForms/Whatever application is probably a better bet, unless you actually want an “app” (i.e. something to put in the app store or the look and feel of a Metro app). For something that will run on Windows/Linux/Mac, HTML5 won’t help you build a cross platform native application; though of course you can use it to build a standard browser-based Web app if that meets your requirements.

For mobile development HTML5 has made some progress towards the holy grail of being able to write one app that will run on all major phone OSs. The only caveat is that if you want to use HTML5 for “native” app development, you’ll need a framework. One example is PhoneGap, which is free and open source, but requires recompiling your app for each target.

You can of course write browser-based Web apps for phones (which don’t need recompiling), but there are even more browser flavors to support than on the desktop. Without a framework, Javascript has no mechanism for accessing phone internals like cameras, though you can trigger phone calls and SMS messages via HTML URLs.

The bottom line is that HTML5 is an evolution not a revolution, but it does take big steps forward and will be of growing use as its features are more widely implemented.

Dave Sweeton is Stout’s Chief Technologist. He began his career as a software developer in the mid-1990s. Dave is responsible for numerous installations at major corporations throughout the United States.

DO YOU REVIEW?

by Peg Bogema

All I have to ask is, “Do you review?” to get the most amazing reactions. Usually it’s one of those sheepish, kicking-the-toe-in-the-dirt reactions accompanied by, “I know I should, but…”

Now think about it: would you prefer to work in a place where you know where you stand? How your performance is perceived? That if you get into the doghouse somehow you’ll have a way out? Or would you prefer a place where promotions, work assignments and job security are all a great mystery knowable only by the Gods?

Most computer professionals will tell you, if you ask, that they like to have an annual review—if it is constructive.

So what constitutes constructive?

Start with metrics. For a developer, the number of bugs found in his or her code, coupled with the difficulty of the code the developer writes, coupled with the length of time to remediate and close—yes, it has to be all three—can give you a great place to start on a review. If a person writes relatively simple code but throws a lot of bugs and takes a long time to close them, that’s a great place to start a review conversation. A target for the upcoming year would be reducing bug count and time-to-fix.

Move to personal goals. What would the computer professional like to do in the upcoming year? And what will it take to get there? If a topnotch developer would like to move into an architecture role, what is the way forward? Training? Mentoring?

End with soft skills. If you as a manager are trying to creating a certain team dynamic, what can be done to contribute to that? For many people, it’s a challenge to stop doing something. Stop being passionate about your point of view and raising your voice. Stop being a wallflower and failing to contribute during meetings. Most people find it easier to start doing something.

Let’s create an environment in which everyone feels like his or her voice should be heard will produce surprising ideas about how to bring that about.

The bottom line is that if you don’t review, you run the risk of losing both the good people and the people who could be good with a bit of help. So try it!

Peg Bogema is Stout’s Vice President of Operations. With Stout since 1997, her duties include the supervision of development projects and personnel, recruiting and accounts.