Epilogue

Even though this book is about HTML5, the authors would rather work with compiled languages that produce applications running on virtual machines. Such software platforms are more productive for development and more predictable for deployment.

HTML5 Is Not a Rosy Place

While writing this book, we often argued about the pros and cons of switching to HTML5, and so far we are concerned that the HTML/JavaScript/CSS platform is not overly productive for developing enterprise applications just yet. We live in an era when amateurs feel comfortable creating websites, and HTML with a little JavaScript inserted provides the flexibility and customization that Microsoft Access and Excel provided in the good old PC times.

Until this day, Microsoft Excel remains the most popular application among business users in enterprises. They start Excel locally, and it has local storage that enables work in occasionally connected scenarios. Both the data and the code are physically located close to the user’s heart. Microsoft Excel makes it possible for users to have their own little pieces of data and amateurish-but-working code (a.k.a. formulas) very close and personal, right on the desktop. Fine print: until their computer crashes due to viruses or other problems. No need to ask those IT prima donnas for programming favors. Business users prefer not being dependent on connectivity or some mysterious servers being slow or down. The most advanced business users even learn how to operate MS Access databases to further lessen their dependency on the IT labor force.

But there is only so much you can do with primitive tools. Visual Basic was "JavaScript" of the '90s—it had similar problems, but nevertheless had huge followings. Now the same people are doing JavaScript. If we don’t break this cycle by adopting a VM common to all browsers, we are doomed to go through generation after generation of underpowered crap.

Recently, one of our clients from Wall Street sent us a list of issues to be fixed in a web application that we were developing by using the Adobe Flex framework (these applications run inside a Flash Player virtual machine). One of the requested fixes was "remove a random blink while a widget moves in the window and snaps to another one." We fixed it. What if that fix had to be implemented in HTML5 and tested in a dozen web browsers? Dealing with a single VM is easier.

You can argue that a browser’s plug-in Flash Player (as well as Silverlight or a browser’s Java runtime) is going away; it was crashing browsers and had security holes. But the bar for the UI of Flash-based enterprise applications is set pretty high. Business users will ask for features or fixes they are accustomed to in desktop or VM-based applications. We hope that future enterprise web applications developed with support for future HTML 6 or 7 specifications will be able to accommodate user expectations in the UI area. The time will come when HTML widgets won’t blink in any of the major browsers.

We wrote this book to help people understand what HTML5 applications are about. But make no mistake: the world of HTML5 is not a peachy place in the future, preached about by educated and compassionate scientists, but rather a nasty past that is catching up and trying to transform into a usable instrument in the web application developer’s toolbox.

It’s the past and the future. The chances are slim that any particular vendor will win all or even 80 percent of the mobile device market. In competitive business, being able to make an application available to only 80% of the market is not good enough, so the chances that any particular native platform will dominate in web development are slim. HTML5 and related technologies will serve as a common denominator for mobile developers.

Check out one of the trading applications named tradeMonster. It has been developed by using HTML5 and uses the same code base for all mobile devices. The desktop version was built by using the Adobe Flex framework and runs in Flash Player’s VM. Yes, they have created native wrappers to offer tradeMonster in Apple’s or Google’s application stores, but it’s still an HTML5 application, nevertheless. Create a paper trading account (no money needed) and test their application. If you like it, consider developing in HTML5.

Enterprise IT managers need a cross-platform development and deployment platform, which HTML5 is promising to become. But take with a grain of salt all the promises of being 100 percent cross-platform made by any HTML5 framework vendor: "With our HTML5 framework, you won’t need to worry about differences in web browsers." Yeah, right! HTML5 is not a magic bullet, and don’t expect it to be. But HTML5 is for real and might become the most practical development platform for your organization today.

Dart: A Promising Language

Unfortunately, developing an application in JavaScript is not overly productive. Some people use CoffeScript or TypeScript to be converted into JavaScript for deployment. We are closely watching the progress of Google’s new programming language called Dart, which is a compiled language with an elegant and terse syntax. Dart is easy to understand for anyone who knows Java or C#. Although the compiled version of Dart code requires Dartium VM, which is currently available only in the Chromium browser, Google created the dart2js compiler, which turns your application code into JavaScript in seconds, so it can run in all web browsers today. Google also offers the Dart IDE with debugger and autocomplete features. You can debug Dart code in the Dart Editor while running generated JavaScript in the browser.

Dart’s VM can communicate with JavaScript’s VM, so if you have a portion of your application written in JavaScript, it can peacefully coexist with the Dart code. You can literally have two buttons on the web page: one written in JavaScript and the other in Dart.

The World Wide Web Consortium (W3C) published a document called "Introduction to Web Components," which among other things defines recommendations on how to create custom HTML components. The existing implementation of the web UI package includes a number of UI components and facilitates defining new custom HTML elements in a declarative way. Here’s an example we borrowed from the Dart website:

  <element name="x-click-counter" constructor="CounterComponent" extends="div">
    <template>
      <button on-click="increment()">Click me</button>
      <span>(click count: {{count}})</span>
    </template>
    <script type="application/dart">
      import 'package:web_ui/web_ui.dart';

      class CounterComponent extends WebComponent {
        int count = 0;
        void increment(e) { count++; }
      }
    </script>
  </element>

This code extends the web UI element div and includes a template, which uses binding. The value of the variable count is bound to <span>, and as soon as a counter increases, the web page immediately reflects its new value without the need to write any other code. The web UI package will be replaced soon with the Polymer Stack built on top of web components.

Google has ported its popular JavaScript framework AngularJS into AngularDart. Farata Systems is working on Pint, which is an open source library of AngularDart components built on top of Semantic UI, a library of rich UI components for developing responsive web applications.

In 2014, the popularity of Dart should increase. In this case, we’ll send a new proposal to O’Reilly Media for a book titled Enterprise Web Development with Dart.

HTML5 Is in Demand Today

Having said that, we’d like you to know that at the time of this writing, the popular job search engine Indeed.com reports that HTML5 is the #1 job trend—the fastest growing keyword found in online job postings—ahead of iOS in third place, and Android in fourth place. We’ll be happy if our book helps you to master HTML5 and find an interesting and financially rewarding job!