Checklist: Deciding When to Develop with HTML5 and JavaScript

If there is one truism in software development it is that there are no silver bullets. There is no "perfect" platform that should be used to tackle every software challenge.

Not HTML5/JavaScript.
Not XAML/.NET.
Not Flash/AIR.
Not anything yet invented.

As long as different software projects have different requirements, there will remain a need for different platforms. And that's a good thing. Choice and competition is healthy in any market, and in the software industry, we consistently see how competing software platforms or applications make the entire industry better (and how the lack of competition is very bad…ahem…IE6).

That means that HTML5 and JavaScript are not the right choice for every project. But they are a great choice for the right projects where the requirements align with the platform benefits.

Sites and Apps

As we move in to the next era of HTML development, it's increasingly less accurate to cast HTML as "web development." True, the web is regularly used as a delivery platform for HTML and JavaScript, but HTML development is evolving in to something useful for much more than traditional browser-bound websites.

With the rise of modern mobile devices and on-the-go computing (where active Internet connections are not a guarantee), HTML is being pushed to do more. It's about software development, not web development. It's about building application front-ends that can be delivered over the web in a browser, packaged and delivered through an app store, or even cached and used offline when the Internet is not available.

This has an important impact on HTML development techniques.

For the better part of the last decade, HTML development has depended heavily on interaction with server-side frameworks. Technologies like PHP, Rails, and ASP.NET have helped developers create "HTML applications" where much of the front-end work and HTML rendering still happens on the server.

This approach works, but it is severely limiting when you want to create a "self-contained" application or something that will remain useful when the Internet is not available.

To overcome these limits, we need a new way of doing HTML development. We need the new HTML + JavaScript model that relies much less on an active connection to the server for a functional front-end experience, instead using the server primarily to serve and persist data. With this approach, we can cut the (full-time) cord to the server and build apps and sites capable of being packaged, installed, or simply used offline in a browser.

When to Build Sites with HTML5 and JavaScript

This is a bit of a trick question.

Websites are traditionally built with HTML and JavaScript. This doesn't change with HTML5 and JavaScript. If your goal is to produce a website (or "web app") that is deployed and accessed through the browser, HTML and JavaScript are the obvious choice.

So perhaps the better question for sites is when to transition more of your front-end development to JavaScript from the server.

Considering the "limits" of server-side HTML discussed previously, the decision to use JavaScript should be made when you want to achieve any of the following with your sites:

• Offline Support - If you want your site to be usable without the Internet, you need a UI that works without a server. HTML5 provides that in browsers.
• More Responsive UI - Server round-trips only make a site feel slower. Moving processing to the client makes feedback instant and more intuitive for users.
• Improved Performance - With less HTML being sent over the wire, pages can load more quickly, especially when combined with async (Ajax) updates.
• Reduce Server Dependencies - Don't want a front-end tightly bound to a specific server technology? Build an HTML5/JavaScript front-end and work with any RESTful service layer backed by any server technology.

When to Build Apps with HTML5 and JavaScript

When we transition to say "apps" instead of "sites," now we're talking about "packaged" experiences. Software that can be "installed" (or at least accessed outside of the browser - or maybe in the browser without an Internet connection, in the case of Chrome "Web Apps").

Choosing JavaScript and HTML for app development has a number of advantages versus traditional server-side HTML programming:

• Offline Support - While a convenience for sites, this is a must for apps. The app must load and be minimally functional when the Internet is absent.
• Native-like Responsiveness - Again, while more responsive UI is a "nice to have" for sites, it's a "must have" for apps. Users don't care what technology you use to build apps, but they have higher expectations for installed software than web-based sites.
• App Store Support - With a HTML/JS front-end that can work without a server, you now have code that can be packaged and deployed via modern app stores (with supporting tools like PhoneGap).

None of these benefits is achievable with server-side HTML development.

With apps, though, you must also consider the native options. Choosing HTML/JS means making a decision between a "universal" reach platform and something that is probably less universal, less "standard," but probably more focused on a rich experience where it is available. For example, maybe you're considering:

• Flash/Flex/Air
• XAML (Silverlight, WPF)/.NET
• Windows Forms
• Java (including Android)
• Cocoa/Objective-C (including iOS)

Native platforms definitely have advantages, and they're well documented. For the richest experience on a PC, Mac, or mobile device, native platforms are always the winner.

The primary reason to choose HTML/JS over a native platform technology is reach.

If you want to build one app that can target multiple devices and operating systems, HTML/JS is your best choice. It helps you reach the most people with the least amount of duplicated effort. And when combined with tools like PhoneGap (for mobile - new tools for desktop packaging will likely emerge in the near future), HTML/JS apps have nearly all of the benefits of native apps, including:

• App store distribution
• Access to device APIs and sensors
• Support for online/offline running modes
• Native device look-and-feel

No more server?

Before I wrap-up this post, it's worth addressing this common misconception.

HTML5 and JavaScript development does not mean server-side development is dead. Instead, it means server-side development is different.

Where today you may use server-side technologies to handle much of your front-end UI rendering and behavior, with a pure HTML/JS app or site, the server reduces its role to focusing more exclusively on data. The server continues to play the role of serving application data, persisting data changes, and running business rules against user supplied input (such as login security). All that changes with the HTML/JS shift is a reduction in the role the server plays with the front-end UI.

Security is the same (SSL + server authentication).
Dynamic page templates are the same.
Data persistence is the same.

Kendo UI for Sites and Apps

Clearly, at the end of this process is Kendo UI. If your site or app has the requirements that dictate JavaScript and HTML5 as your best choice platform, Kendo UI is the framework to help you quickly get to the business of creating your site or app instead of wasting time assembling a hodge-podge framework composed of unsupported JavaScript libraries. Kendo UI has everything you need for professional HTML5 and JavaScript development in a single, compact package, from data binding to templates to UI widgets.

Is Kendo UI right for every software project? No. Neither is HTML5 and JavaScript.

But if HTML5 and JavaScript are in your future, you don't want to miss Kendo UI. Download the beta today and help us continue to evolve the universal framework for sites and apps!