Archive for January, 2012

HTML 5 makes the browser smarter

January 26, 2012

The unsung hero of the web has always been Javascript, without which the standards-based web would be completely static. Javascript enables functionality to be executed in the browser, and has been used to create all sorts of effects otherwise not possible with HTML alone.

In the early days, Javascript implementations weren’t entirely standard, requiring developers to have to write variants for different browsers; this isn’t really an issue any more.

For applications, developers will either use libraries or develop their own validation routines. This Javascript code adds significantly to the amount of code downloaded.

With HTML5, developers will need to write less Javascript, as the browser provides features to do things for itself rather than rely extra scripting.

Validation is the main area of improvement. HTML5 now provides a number of new validation features such as mandatory checking, type checking, range and field length validation. The validation is done within the browser, and developers can opt to decide how to process errors.

Obviously validation has to be repeated on the server for security, to ensure that data hasn’t been hacked in the browser or in transmission. This then means that validation has to be maintained in two places and kept in sync.

HTML5 also provides a number of new input field types such as tel, email, color, datetime. This empowers the browser, by applying it to display a date picker, or a colour chooser for example. More importantly for mobile applications it would allow the browser to show an appropriate keyboard layout e.g. a numeric layout for tel, and an alphabetic keyboard for email type.

There are also a number of new attributes which previously required Javascript such as autocomplete, placeholder and pattern which will prove very useful.

There will be some organisations that will not want the browser to affect their carefully designed user experience; for these people the answer is simple, just don’t use the new features.

For the rest, you will enjoy having to write less Javascript for HTML5 browsers, but of course you will still need to have backwards compatibility for non-HTML5 browsers which will rely on Javascript.

HTML5 Gets pushy

January 20, 2012

In the past there have been a number of clever approaches to get around the limitations of web technologies inability to allow servers to broadcast messages/data to clients. One of the more popular libraries for such capability has been Comet.

Whilst providing a solution where the standard lacked functionality, Comet is quite inefficient – both in terms of network bandwidth and performance.

Comet effectively posts a message to the server and the server replies if there is data waiting to go, if there is not the call is left waiting and if subsequently it times out the client is notified which in turn then makes another call. So it’s inefficiency is that it is constantly making calls to the server regardless of whether there is data to be sent back or not. Also it is using HTTP, so the requests are relatively large in size.

In a previous blog, I mentioned how the WebSockets API allows you to have bi-directional messaging between a browser and server. The use of WebSockets requires a Socket server to facilitate messaging using the socket protocol (which is far more efficient in terms of request size than HTTP). The most popular example of a good use of WebSockets is online chat.

However there is another option: Server Sent Events (SSE).

The main advantage of SSE is that no additional software is required, a standard web server can be used as it only relies on the HTTP protocol. However, the main downsides therefore are that SSE is uni-directional, server to client broadcast only and, because they use the HTTP protocol, the message requests are much larger than socket calls.

SSE also allows arbitrary events which even allows messages to be sent to different domains. Care needs to be taken as this can be open to abuse, so developers should check the domain from which the event has been generated is one that they are expecting.

This is a powerful capability, and for anyone looking at “lean portal” implementations, could be a way of creating functionality like “inter-portlet communication” without requiring a portal server to facilitate the sharing of data.

They are also relatively simple to implement which again gives them an advantage over WebSockets.

SSE will be most useful to applications like stock ticker’s, live news, weather updates, sports scores and any other applications where the server needs to push data to a client. So does this mean the end of Comet? No because to provide backwards compatibility with non-HTML5 browsers, Comet could be used as a polyfill.