This is the second post in a two part series promoting the use of HTML5 for app development. This section focuses on the features unique to "websites" that are often neglected in the performance-focused native-vs-web discussion (Part 1).
Our argument is threefold:
We explore these arguments in depth below.
A key concept that lead to the initial explosion of the web is hypertext, the ability for documents (even those created by different authors) to link to each other through contextual hyperlinks. The URL (or URI) serves as a unique identifier that facilitates this capability. With a URL, it is possible to point others to a specific piece of content, even if that content is buried deep within another application.
As discussed in Part 1, there are certainly performance benefits that come when users can interact with an application without requiring a network request for every state change. However, these benefits can be achieved without throwing away the power of URLs. A simple way to do this is to use the
History.pushState API to update the browser URL as the user navigates, and (importantly) to make app URLs actually work whenever they are hit directly. This can be achieved by using the progressive enhancement principles discussed in the next section.
One of the common frustrations web developers experience is the plethora of browsers to support. What works in Chrome might not work in Firefox, and what works in Chrome and Firefox probably doesn't work in Internet Explorer. Particularly in the context of mobile development, it is tempting to reduce the complexity by focusing solely on the WebKit family of browsers, which incidentally includes the native browsers on both iOS and Android.
While this frustration is understandable, it is also rooted in a certain level of smug superiority. There is little to be gained by expecting everyone to use the same web browser or mobile platform. After all, much of the power of the web comes from the diverse perspectives each participant brings. It is unfair (and unwise) to exclude any particular user group simply because they don't happen to use your technology of choice. It is important to remember that part of what made your technology "better" in the first place was competition with other technologies in the free marketplace of ideas. Ubiquitous platforms stagnate.
This is an argument against single-platform native apps, but also against developing applications that only work on the newest versions of certain browsers. There are certainly occasions where users need to be encouraged to upgrade, and it is not always possible to support every last browser. However, it is easier than many developers think.
The important point is that by learning d3.js, you learn SVG (and HTML). The SVG specification is just as useful as the d3 documentation in determining what capabilities are available and how to leverage them. If a better library ever comes along in the future, the general knowledge gained about SVG can be re-used, even if the d3 specifics cannot. This cannot be said about other visualization and charting libraries.
Similarly, jQuery Mobile is relatively unique among mobile app libraries in that its widgets are specified by regular HTML tags (with a few
data- attributes for configuration). jQuery Mobile also actively encourages its users to learn CSS3 to customize their interface and support multiple screen sizes through responsive design. This valuable knowledge about HTML and CSS can be re-used for other projects.