Is Java ready for HTML5?

How quickly will Java developers be able to develop HTML5-ready server-side applications?

Every new Apple mobile device and MacBook supports the latest HTML5 standard. Some of the biggest social networking sites, including Facebook, already use HTML5 in their content delivery. But senior Java application developers must still ask the question: Is the Java community ready for HTML5 development and integration efforts?

HTML5 is improving end-user experience by helping to provide more interactive content directly through the Web browser, simplifying rich content delivery and reducing the importance of proprietary technologies such as Adobe Flash and Microsoft’s Silverlight. In the rich content space, the only pure Java solution offered by Oracle would be JavaFX, which can be seen as both interoperable with HTML5 and also threatened by it.

At JavaOne in September of 2011, Cameron Purdy and Adam Messinger unveiled Project Avatar in an effort to help simplify the task of developing applications that leverage HTML5 technologies. “You can make an HTML5 client work with a Java back-end today, but it’s not that fun, it’s not that easy to use, and it’s not that easy for HTML folks to collaborate with Java folks,” says Adam Messinger with regards to the current state of HTML5 development with standard Java technologies.

Sadly, since the announcement, Adam Messinger has moved away from his position as vice president of Fusion Middleware at Oracle to work as Twitter’s vice president of Infrastructure Engineering. It has been six months after the first unveiling of Avatar, and there is very little mention of the project on Oracle’s website.

Of course, others in the Java community would argue that Java is in fact well prepared for HTML5 integration. For most enterprise applications, Java does its work on the server side, pushing content out to the Web client. This content is normally void of any reference to the fact that it was generated from byte-code running on a JVM. A model-view-controller approach to application development means that the Web layer (the view) should be developed in isolation from the control, data and business logic, which is written in Java.

With a separate Web layer, the job of moving from HTML4 to HTML5 is just a matter of throwing the Web developers into a training course or two, upgrading their development skills to include the new HTML5 features and having them begin writing code that takes advantage of things such as the HTML5 canvas, sliders and video. But as much as the Java community tries to believe that their application are designed with complete separation between view and logic layers, the fact is, many Web rendering technologies do indeed map quite tightly to the HTML4 specification.

For example, JavaServer Faces (JSF), the Java EE standard for the development of the UI layer for Web-based applications incorporates a variety of tags that map directly to the HTML4 specification. This tight coupling raises concerns that JSF may be forced into the HTML4 pigeonhole until a new version of the standard is released. But some experts expect the transition from HTML4 to HTML5 will be more quick and easy for JSF developers than they may expect.

Getting JSF ready for HTML5

The JSF specification separates its own logic and rendering layers, which means that simply replacing the renderer associated with a given JSF component allows for the adoption of new standards.

According to Max Katz, author of Practical RichFaces and the lead RIA strategist at Exadel about JSF and HTML5, “Changing to HTML5 is very simple, you just change the renderers. You update them – not even change. It's not like we've replaced HTML5 as a completely new thing; it's not. So you just update the renderers to include the HTML5 tags and it's a perfect match. And I believe for JSF2.x they're discussing supporting HTML5 tags. If you look at the rich component libraries, that’s even easier for them because they're not specifically tied to the implementation. They can just update their components with HTML5 tags and functionality and you're done.”

Furthermore, JSF was designed for infinite flexibility and customizability, and as such, it’s not surprising to see that many position documents already exist demonstrating how HTML5 drag-and-drop and inline editing capabilities can be embedded within a JSF component.

Of course, there does need to be motivation and impetus behind the people maintaining a given Java framework or project in order for someone to actually get the work done with regards to updating the code base in a timely manner. That’s why the health of the project and the activity of the contributor base is always an important consideration when choosing a framework. Application framework expert and Founder of AppFuse, Matt Raible, seems to be encouraged by active Web frameworks like Tapestry, along with their ability to keep up with HTML5.

 “The project health, I think, is important because if the framework isn't maintained and it's not improving, then chances are you're not going to like it in the long term. And you can see this with some frameworks today, for instance, Tapestry," says Raible. "I've started using Tapestry more and more, and you can see that project is focusing on a lot of the client-side capabilities and HTML5 stuff that's coming out.  And that's exciting, versus other frameworks that are kind of ignoring HTML5 and not really enhancing themselves for it. “

Java the technology is prepared in a variety of different ways for the adoption of HTML5 based technologies. If you’ve been developing in a way that embraces a Model-View-Controller design philosophy, then upgrading your view components to use new tags and attributes should be no harder than opening a JavaServer Page in a text editor and typing away. And if you’re using an active and healthy framework like Tapestry of JSF, the contributors and maintainers are already infusing those projects with HTM5 features.

How much time passes before we start to see HTML5 become more prevalent in applications developed by Java professionals will be decided by how motivated users will be in demanding the latest HTML5 based features in their applications and how quickly the Java development community can embrace the changes HTML5 has to offer.

Dig Deeper on Client framework

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.