HTML 5 makes the browser smarter

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.

Microsoft wake up to smell the coffee

Another month, another confusing set of stories relating to Microsoft’s web framework Silverlight and the next generation mark-up language HTML5.

I wrote about the relationship previously, referring to Internet Explorer general manager Dean Hachamovitch’s suggestion that the future of the web is HTML5. More specifically, I questioned whether Microsoft’s support for HTML5 left Silverlight out in the cloud.

The answer for a few weeks, at least according to the team in Redmond, was at the centre of the next generation web. In a blog posting (see further reading, below), Microsoft’s director of product management for developer platforms Brad Becker stated that Microsoft remained committed to Silverlight – and that the framework extends the web by enabling scenarios that HTML does not cover.

That comment, in itself, was not surprising. HTML5 remains a work in progress, with developments on various platforms continuing to be developed. Silverlight, as Becker states in his own posting, is already installed on 600,000,000 desktops and devices.

But success is not just about numbers. Take the related area of mobile operating systems, where Symbian remains the leading mobile OS with about 40% of the market, according to analyst Gartner (see further reading).

Those figures, however, include the legacy of Nokia’s previous success. The smart phone market is leading to the ever-increasing growth – and inevitably the dominance – of Research in Motion, Apple and Android.

The same will be true in web development. Do not assume people will use a specific platform just because a provider has a ready-made user base. More to the point, Microsoft seems to be coming round to that way of thinking.

Bob Muglia, Microsoft’s head of servers and tools division, gave an interview at the company’s Professional Developers Conference and said that Silverlight was still “core” to Microsoft but the company was looking to other technologies to allow people to access online services (see further reading).

Muglia attempted to cool the situation in a blog posting (see further reading), suggesting his comment that the company’s Silverlight strategy had shifted was simply a comment on how the industry had changed. It was a suggestion that, rather then cool the situation, helped to add petrol to an already well-stoked fire.

Developers rounded on Muglia, posting comments on his blog which suggested they felt hurt and that Silverlight’s reputation had been left damaged: “The effort needed to restore our confidence in Silverlight is tantamount to unringing a bell,” suggested one poster.

HTML5 is a work in progress, but its progress is also startling. Non-believers – even at Microsoft’s Redmond HQ – are beginning to wake up and smell the coffee. Confusion reigns but sense, and HTML5, will win out in the end. Now somebody needs to pass the coffee cup to Adobe !

Further reading:

http://team.silverlight.net/announcement/the-future-of-silverlight/?utm_source=timheuer

http://www.eweek.com/c/a/Midmarket/Sony-Ericsson-Drops-Symbian-OS-for-Android-OS-107191/

http://www.bbc.co.uk/news/technology-11673384

 http://team.silverlight.net/announcement/pdc-and-silverlight/

Client Side Session Management…

Ok this is an old hobby horse I’ve reeled out many times, and now that I’ve got round to starting a blog what better place to find a permanent home for this old equidae.

The traditional way of managing sessions is on the server with the application container managing session keys/data. As a front end developer your job is simply to populate the session data as it is capatured on screen, the application container does the rest for you. The application container should offer different mechanisms for replicating session data across servers, thus providing session failover. It should also optimise the storage of the data itself, and manage the session keys with it’s own policies for clearing out dead sessions.

The problem with this model is that it is simply not that easy. Some of the issues that need further consideration are: Memory optimisation, Long vs Short Running sessions, Server Redundancy:

When storing data in sessions, the data element is normally given a name, generally this is something meaningful that a developer can use to make code more readable. However these name themselve take up memory. Whilst this may not seem a huge issue with the amount of memory in servers these days, we’ll see later in the post why optimising memory for sessions is necessary. So one improvment you can make is to implement hashing to reduce lengths of names used in code. Another technique would be to use compression for the actual session data especially for large free text fields.

Generally there are two types of sessions long running or short sessions. Typically internal applications such as call centres will have users that log-in in the morning use an application all day, and log-off at the end of the day. Such applications if not designed efficiently often do not release session data during the session, this can have the issue of builiding up huge memory requirements per user of the application. Prior to memory depletion, performance degradation will be the first issue as memory is swapped in/out of disk, followed by out of memory server crashes. Hence developers need to consider what memory should be held and when to release this memory. Short running sessions with mass users e.g. shopping sites, tend to have less per user storage requirements but many more users, creating a large memory requirement overall. In this scenario identifying dead sessions is paramount to reduce memory redundancy. Other optimisations include identifying session data that is used not per user but globally across all sessions, and caching one instance of that data rather than load it per user.

So it is for reasons like the above why client side session handling make so much sense, if only it was supported as standard by the browser rather than having to use hidden fields. Quite simply client side session management is a means of keeping data in the browser rather than on the server, therefore reducing the memory requirements and extra processing that an application container has. It would not only reduce the cost of the server you’d need it would also improve performance of the client application also, more so than the use of Ajax.

I can’t think of any downsides to this approach whilst the upsides are huge. What do you think?