HTML5 for Rich Web Enterprise Applications

Itzik Spitzen, Visual WebGui developer, VP R&D Gizmox

There seems to be a consensus of opinion that HTML5 will be the next generation web platform to be embraced by all the major players, including Microsoft. Recent announcements indicate that Microsoft is on the route to de-emphasize its Silverlight solution in favor of HTML5. This is reinforced by a recent Windows 8 preview, which conveyed a very clear message as to the direction that Microsoft is taking.

As a result, HTML5 seems to have captured the attention of a sizeable proportion of the development community, including enterprise development departments. We are witnessing more and more organizations adopting an HTML5 strategy with their development decisions, and what's really amazing is that not one single browser yet supports HTML5 fully. Current overall browser support for HTML5, as reported by caniuse.com in June 2011 puts Chrome 12.0 in the lead with 89% compatibility, followed by Firefox 5.0 (84%), Opera 11.1 (74%), Safari 5.0 (73%) and IE 8.0 at the bottom with an overall supported function set of just 26%. IE 9.0 narrows the gap with a compatibility of 57%.

The mobile browsers are a little behind but not by far, with Opera 11.0 Mobile and Android 3.0 already on 69%.

So why are business application developers and enterprises taking HTML5 so seriously? And what tools are available to implement data-intensive HTML5 applications? All you have to do is look on any web dev magazine or development tools site and HTML5 will be right there in the spotlight.

What's So Good About HTML5?

HTML5 addresses several major issues of interest to business application developers, the most outstanding being:

• We're all using "finger touch" input on mobiles and tablets in our free time with more devices becoming available every month; we are getting to like its convenience, and history proves that once we get to like something out of work hours, we want to use it at work as well. The "finger touch" experience requires HTML5 and JavaScript.
• Cross platform unity. An area of contention from the beginning of the web, but now bigger than ever due to the far more scattered and competitive browser and operating system landscape that includes mobile and tablet formats. This is illustrated in the approach taken by a growing number of enterprises that are encouraging workers to use their own mobiles and tablets in the workplace.
• Components that provide a 'native' way (i.e. naturally built into HTML) to achieve a RIA (Rich Internet Application) with less dependency on JavaScript and being completely independent of foreign components like plug-ins.

Yet, despite its enhancements, HTML5 is still just a markup language with stronger user interface features. It needs a developer to integrate it into the business application.

Having adopted the strategic goal of incorporating HTML5's new capabilities, the question that arises is how to do it in the most efficient and cost-effective way possible.

The Challenges Facing Developers in Implementing Rich Web Enterprise Applications

The benefits of a browser based front end for a data-centric, cloud-based, AJAX-rich application as opposed to other information system architectures needn't be mentioned here. It's sufficient to recognize that, that's the trend and it's not going away; in fact it's getting stronger, with all major vendors lining up to support it and rightly so. But it is worth revisiting the challenges of web and web-based cloud applications; because they are the reason the different development frameworks look like they do. A brief summary follows:

1. Web apps are a multi-platform, multiple-protocol architecture

A web application is client/server architecture where the application and the interface reside in different worlds - different countries, different languages, different operating systems and different browsers - many different browser vendors and versions, connected by a communications channel. Yet they need to appear and behave as if they were one unified body.

This point is at the root of all others listed below.

2. Security

The security issue of AJAX rich web applications is really quite simple to describe, if somewhat less so to achieve. The application running on the server must control the application running on the browser while not allowing the browser application, or any other person, program or anything else to maliciously influence the application code or database using exposed client end points.

3. State

A close second to security in the developer's list of concerns is the issue of application state. Every business application must exercise dynamic changes in state because if nothing dynamically changes, there are no processes and without processes, you have no information system. These dynamic changes are the substance of business and they include things like the execution of credit card transactions, changing status of subscribers and updating prices. The problem is the synchronization of state between server application and browser, without which you would be able to make a transaction in the browser that the server would never know about.

4. Performance

Performance issues stem from the very nature of the distributed computing architecture that bridges different locations through a network, thus introducing latency. They are amplified still further when trying to solve the security and state challenges.

5. Cross Platform Compatibility

One application must serve clients running on at least 4 major operating systems, tens of browser types and versions, numerous display configurations and new devices every day.

6. RIA

Rich Internet Application. That means user-friendly controls, fast response time to make the GUI work for the AJAX rich web, like it did in the past for the desktop.

HTML5 to the Rescue and a New Challenge of Implementing It

HTML5 doesn't address all of the AJAX rich web developer's woes. However, it does offer performance benefits by using native features, a RIA user experience and, above all, compatibility over multiple browsers.

Instead of creating a new proprietary standard, HTML5 presents a native extension to classic web browser development. It adds native elements like date picker and slide bar and some very powerful capabilities such as canvas, animations, vector graphics and plug-in-free media playing. In addition, it complements some major capabilities lacking in today's browsers such as the ability to maintain constant communication with the server (TCP style) and persistent client-side storage.

That is reason enough to develop HTML5 web pages, but since the announcement in June 2011 by Microsoft that the upcoming Windows 8 (slated for release at the end of 2012) will feature a developer platform based on HTML5 and JavaScript, that makes HTML5 look that bit more worth taking note of.

And it's not just talk. IE 9.0, which incorporates HTML5 to more than twice the degree of IE 8.0, builds on top of the Direct2D 2D graphics API and the result is fast running HTML5 on IE 9.0.

While HTML5 helps meet the needs of business application development, it also introduces additional challenges. These can be outlined at follows:

1. How well the development framework can be made to produce HTML5 code.
2. Use of available development personnel skills, the efficiency of the IDE and the cost of the learning curve in terms of time and costs.
3. The handling of the screen size, layout and style.
4. Correctly putting together the JS and HTML5 code needed to enable finger touch app operation.

We will take a look at the available application frameworks and see how easily they integrate with HTML5.

Which of the existing frameworks is Best for HTML5 Data Centric Applications?

Without going into the intricacies of the different frameworks, we will look at the options available and the relative advantages of each approach from the point of view of HTML5 development.

Server-Based Frameworks

While not the only one around, Google's GWT is the most prominent server-based HTML5-compliant framework in use today. The coding is done is pure Java and this is processed to generate JavaScript which runs in the browser in an AJAX framework. The web page design is done separately by client-side programmers.

Advantages: Object-oriented development, good debugging tools at the Java stage, optimized for HTML5, reasonable data binding capabilities, plug-in free.

Disadvantages: Multiple programming skills required, security vulnerabilities, no separation of business logic from webpages, complex and error-prone data binding between server and client, debugging difficulties in run-time, cannot handle state.

Suitability: Good for non-LOB applications; security complexities with data centric LOB applications.

Client-Based Ajax Frameworks

These are frameworks based around writing code to run on the client. Development is pure JavaScript / HTML5. Database access and update is commonly done through stateless web-services or other types of stateless dynamic backend (i.e. active server pages).

Advantages: Developer-written HTML5 code for maximum HTML5 usability, native client debugging, handles state, plug-in free.

Disadvantages: Security vulnerabilities, no separation of business logic from webpages, complex and error-prone data binding between server and client, transmission of all variable page content due to the stateless nature of the server, thus increasing server load.

Suitability: Good for static websites and non LOB applications; insecure for data centric LOB applications.

Client-Based Plug-In Frameworks

There are 3 solutions of this kind - Microsoft's Silverlight, Adobe's Flash/Flex combination and the now largely defunct Java Applet. The application code is compiled to a runtime module and this is run in the browser by the appropriate installed runtime environment known as the plug-in. Database access and update is commonly done through stateless web-services or other types of stateless dynamic backend (i.e. active server pages).

Advantages: Object oriented development, (Java for Flex and applets, .Net for Silverlight), free from browser incompatibilities, good debugging capabilities, availability of Java and .NET developers, management of state on the client, capacity to implement permissions with relative ease, some degree of access provided to local devices.

Disadvantages: Dependency on the user to download and install the plug-in (and the fact that not all do), load time overhead, high bandwidth requirements due multiple threads of activity creating a run-time overhead, competes with pure HTML5, which is gaining increasing support, cannot handle server-side state, questionable IP and data security, performance limits when serving large numbers of users simultaneously, largely due to the stateless server.

Suitability: A useable, but far from perfect solution for data centric LOB applications. Excellent for non- data centric apps such as games, media, editors, local tools etc.

The Server-Driven, Thin Client Hybrid

When looked at in a broad perspective, neither the client-based or server-based solutions offer all of the following in a single package:

• Uncompromised security
• Automatic HTML5 code generation
• Cross-browser compatibility
• Maximum use of current enterprise developer skills (with .NET and Java expertise)
• Strong debugging capabilities
• A visualized component-oriented development process
• Visualized data binding at design time
• Efficient run time data interactions
• Maintaining high performance for a large number of users in an enterprise-sized organization

A new approach has recently appeared on the HTML5 landscape that takes a little from all the above to produce a comprehensive solution incorporating all of the above requirements. The solution is strictly server driven so as not to put the application or data in jeopardy by allowing distributed clients to have even a hint of a chance of interfering with the intended application flow or data content. The client layer is pure display without any hidden identifiers; every action taken or piece of data entered is expected in advance and controlled by the server application.

Up to now, the above definition sounds much like classic server driven dynamic HTML non-AJAX web pages. But add the purpose-built static client code - AJAX / HTML5 - that acts as an ultra-thin but highly flexible, desktop-like client, containing no identifiers, but rather 'serving the server'. The static nature of the code block is major factor in making the application secure at the browser side and facilitates debugging too.

Add to that a single communication channel to handle all browser-server requests for a session, so, the client speaks only to the application server and the server speaks to any other services required.

Add all that together and you receive a kind of server-client hybrid, something that resembles .NET, but on web architecture instead of client/server.

The server-driven, thin client hybrid approach has promoted a creative thought process among dev tool vendors and is generating interest from companies wishing to develop high-reach, data-centric business applications for enterprises.

There is a pretty varied selection of tools already out there answering the needs of those seeking to create or migrate to HTML5 and they have more promises in the pipeline for the months ahead. They differ from each other in character including their approach to virtualization, security, performance, maintainability and risk. Some are more suited to the creation of cool browser gadgets, others to data centric enterprise applications. One way or the other, these solutions ensure that no one gets left behind with the new web standards.

Conclusion

In this article we've discussed how HTML5 introduces markup-level functionality for rich graphics, animation and web multimedia and supports a richer functionality for web applications through:

• Native UI application controls like drag and drop and touch screen
• Independence of proprietary plug-ins
• Geo location tags
• Built-in support for multiple clients - desktop, mobile and tablet, and the ability to support exciting new formats that might be waiting round the corner

However whilst there are still limits to HTML5 such as standardization issues (like different browsers supporting different video formats) and its dependency on CSS and JavaScript (both having their own compatibility problems), people are becoming more mobile and require the ability to access programs across a wider range of devices. It's clear that HTML5 will be the next web platform to be embraced by all, including Microsoft.

HTML5 ensures we can move away from a world of plug-ins and enables us to create RIA's without the need for foreign components. This article has looked at HTML5 from the web programmer's point of view and briefly explored and analyzed some of the available development methodologies. Over the coming months we will be seeing the browser war heat-up and more and more devices being released with browsing capabilities. With all of the hype surrounding HTML5 the important thing to remember is that HTML5 is the start of the journey to make one code fit all, a journey that will benefit developers and end-users in the long run.

---

Click here to view the complete list of archived articles

This article was originally published in the Fall 2011 issue of Methods & Tools