@Media WebDirections Conference : Day 1 - Sessions 3 and 4
The morning of Day 1 finished with a second presentation on JavaScript, however this one focused on the use of JavaScript on the server. Having not learnt from my experience in the morning I thought I would attend to learn more about this concept that I had heard of but never practiced.
Tom Hughes-Croucher
This presentation had a promising start. He was bright, breezy, humorous and excitable always a good combination in my opinion. Alas the presentation, for me, went steadily downhill. It became more and more complex, Tom lost his witt as he became more embroiled in the technicalities and I became steadily more and more detached from the proceedings. I am not saying it was a bad presentation because it was not it was just not a presentation for me (I had had a shower that morning and I had not yet achieved a level of geekiness that allowed my subconscious receptors to translate what was being said).
Here is the gist of the presentation:
The big advantage Server Side JavaScript (SSJS) has over Perl, Ruby etc is that people are already familiar with the syntax and are used to writing in it. A quick straw poll of the attendees demonstrated this when everyone said they had written JavaScript routines but only a few had experience of PHP, Perl or Ruby (no one asked about .net). Effectively JavaScript IS the language of the web.
In addition libraries are increasingly being made available that simplify complex tasks such as jQuery, Mootools and YUI.
But SSJS has been around for quite some time so why is now the right time to push it as a viable solution.
Professionalism. JavaScript coders are no longer seen as 2nd class citizens they are a respected part of the development community
Runtimes. There are a number of these available, they have been placed inside browsers for a start. They include V8, SpiderMonkey and Rhino.
Speed Placing these runtimes in browsers has resulted in a drive for fast execution. V8 (part of Chrome) is very fast. This is because leading browser manufacturers, like Google, are trying to make speed of execution a unique selling point.
Runtimes are not Browsers, there is no Document Object Model (DOM), there is no accessibility to specialised APIs. It is only the pure JavaScript implementation.
- Rhino is equivalent to JavaScript v1.7
- SpiderMonkey is equivalent to JavaScript 1.8
- V8 is equivalent to ECMAScript 3
Brendan Eich talked about Harmony which is currently in development this will be equivalent to ECMAScript 5.
This latter statement put into context much of the presentation given by Brendan in the fact that those new facilities being placed inside Harmony but not yet available in browsers (via their JavaScript runtimes) would be available on the server as part of a SSJS implementation based on Harmony.
Here is where Tom became quite animated. The speed and capability improvements discussed by Brendan and shown in the new runtimes means that Server Side JavaScript has real potential to deliver power and performance without the issues encountered by client side JavaScript. When combined with libraries such as Note.js it becomes a great way to deliver browser agnostic web pages with powerful capabilities.
Unfortunately Tom’s increased animation was demonstrated by an increasing willingness to go into code level detail most of which went over my head. It was clear that you need a linux server (no Microsoft Servers here today) and that you need a deeply technical mind to handle all the potential. I have neither of those at my disposal so it was an interesting presentation that will result in little to no difference in the way I work.
Jonathan Stark
Jonathan’s presentation was the complete opposite. I saw elements in this presentation that made me bubble with excitement and tremble with unequivable potential. Jonathan is a specialist in Mobile Application development he has previously focused on iPhone development but it increasingly moving cross platform. He is currently writing a book on Android and is hoping to look at other platforms like BlackBerry in the near future. He started his presentation with three clear statistics
- 4.6 Billion cellphones are identified as currently active today
- 15% of these are smartphones
- 56% of public wi-fi connections were made by smartphones
This, Jonathan says, means that the smartphone is here and it is a dominant methodology for viewing the Internet. These smartphones are able to be extended through custom applications that fall into the following categories:
- Native – Written for the specific device using languages like Java and Objective C
- Web – Browser based applications
- Command Line – often SMS based connectivity
Each of these types has its own challenges. Native development is very fragmented with no one technology/language capable of developing a solution for all devices. Web apps may be more consistent across devices but they are run in sandboxes and can not use many of the rich capabilities of the device such as camera, accelerator, compass. Lastly command line apps suffer from discoverability issues. How do you let people know about your service.
Although the above is the standard statement made for mobile development it does not give the entire picture.
Web development is done through standard web technologies such as HTML, CSS, JavaScript. Apps using this technology are the cheapest to build, the technologies used are the most standardized and the solutions are the easiest and most cost effective to distribute. If Web Apps could use the advanced technologies on the device, if they could provide a smoother user experience more in line with Native Applications they would probably be the best way to write an application.
jQuery
An extension of the jQuery initiative has been constructed by David Laneda. It is called jQuery Touch. Its purpose is to provide a more app orientated experience for a web based application. It can be added to any webpage and then used to introduce smartphone like interfaces that would usually take a long time to build and test. This includes the types of menu systems, buttons and transitions you would expect to see on a smartphone like the iPhone. Add to this the HTML 5 capability to cache web assets on the device so that they can be used offline and you have a web application that looks like a native one it just lacks a few features
PhoneGap
The developers at PhoneGap do not really want this technology to exist. They have built it because of the fragmentation of native app development. Their aim is to give developers a path to cross device development. PhoneGap gives a developer the ability to convert a web app into a native app. It works for:
- iPhone
- Android
- Symbian
- BlackBerry
During this conversion the developer is given access to device capabilities such as the phone and vibration through relatively easy mechanisms to implement. PhoneGap is only available on a Mac platform as the submission procedure for Apple is unchanged. It is written so that the developer ends up creating an Objective C solution that can then be submitted. It contains templates for each device delivery mechanism so that conversion/compiling process has to be done separately for each device type but this is still greatly reduced compared to the alternative process.
At the end of the presentation the inevitable question was asked regarding section 3.3.1 of the Apple terms and conditions. Jonathan stated that Apple have indicated that, at present, PhoneGap is not affected by this changes made to this section. There is no guarantee, however, that it will remain that way.
The presentation was good, there were clear examples of how to do the work, Jonathan built them on the fly showing the simplicity of the basic process. The results looked good and apart from the seemingly difficult installation process for PhoneGap, nothing seemed particularly arduous – especially compared to learning Objective C and Java.
The Missing Session
There was a fifth session to the day called Hot Topics. I believe it was supposed to be an open forum. As much as I would have liked to have attended this I was unable to.
