Don’t call me DOM

28 April 2010

W3C Workshop on Privacy Challenges for advanced Web APIs

Filed under:
jceq5l6yly

13 April 2010

Native vs. Web applications

Filed under:

One of the recurrent topics on which I have been getting a lot of questions recently is the opposition (or perceived opposition) between native applications and Web applications — particularly on mobile phones where applications stores have gathered so much attention.

I participated last month in a barcamp where we tried to explore the various differences between the development of an installable application based on the a “native” programming language, and an application that lives in the Web browser.

A white paper from a GIA analyst shows some of the reasons why some service and content providers choose native applications in preference to Web applications, according to a survey they made:

Results of survey showing why some providers prefer native apps to Web apps

(the survey has plenty of other interesting results, e.g. on the higher retention rate of Web applications)

The top two reasons given are:

  • Ability to build a superior user interface,
  • Access to device hardware capabilities (e.g. accelerometer).

With the ongoing work in the HTML, CSS and SVG Working Groups, the Web is going to catch up quickly with the ability to build a superior user interface — and maybe even going to take the lead given the broad number of experimentations and sharing that the Web enables.

For advanced hardware integration, the WebApps, Device APIs and Policy, and Geolocation Working Groups are bringing a wealth of JavaScript APIs that will hopefully reduce that advantage of native applications in the coming months and years.

Native apps: bring it on!

Determining the user’s language in JavaScript

Filed under:

When one wants to use JavaScript to add language-specific content to a page (for instance, for localization), the only cross-browser property available is navigator.language, which unfortunately represents the browser’s language, not the user’s preferred language — that browsers often make configurable.

This makes navigator.language pretty much inappropriate as a base for a solid localization effort.

While the browser sends the preferred language with each request to any server through the Accept-Language HTTP header, the client-side JavaScript engine doesn’t have access to the value of that header, and so cannot even try to parse it to determine the user’s preferred language.

Picture of Dominique Hazael-MassieuxDominique Hazaël-Massieux (dom@w3.org) is part of the World Wide Web Consortium (W3C) Staff; his interests cover a number of Web technologies, as well as the usage of open source software in a distributed work environment.