Navigation timing API

Introduction

This specification defines an interface for web applications to access timing information related to navigation and elements.

The API will allow web application to gather performance metrics about various factors such as page redirect, DNS lookup, connection & secure connection statistics, request/response time, various events, etc. that were not possible with API script before.

Following is the graphical representations of a typical HTTP request response cycle for a web page.

Use case

Performance measurement has always been a bottleneck for web applications. The traditional way to calculate page load time is to write JavaScript to measure page load time. But in majority of cases they are unable to provide exact figures for user latency as in case of below script. It calculates the time it takes to load the page after the first bit of JavaScript in the head is executed, but it does not give any information about the time it takes to get the page from the server.

var start = new Date().getTime();

function onLoad() {

  var now = new Date().getTime();

  var latency = now - start;

  alert("page loading time: " + latency);

}

Examples

The previous example can be modified to measure a user's perceived page load time.

function onLoad() {

  var now = new Date().getTime();

  var page_load_time = now - performance.timing.navigationStart;

  alert("User-perceived page loading time: " + page_load_time);

}

Good question to ask is that the ‘Date’ object will rely on system date time set on user machine which can be easily tampered between the performance measurements. To resolve this, browsers will record monotonic time by recording system date time while starting performance calculation.

All new knockout JS will certainly knock you out!

Recently while I was going through my linked in news feeds I happen to come across a post from one of my friend which briefly mentioned knockout JS, my curiosity took me to its website.

Watching the 20 minute video from the founder; completely knocked me out. I must say I fell in love with this amazing JS library. 

Here are few interesting features that knockout JS provides, you would read the same on its website

1.  Declarative Binding
2.  Automatic UI refresh
3.  Dependency tracking
4.  Templating

With these features in place; and a strong MVVM design patter knockout JS stands out from other JS libraries.  

Apart from this, Knockout JS also has an excellent community support, which generally lacks with most of the libraries that hosted publicly.

Where do I go from here?

For more details, examples, source, and downloads, see the project’s homepage at http://knockoutjs.com

The Messaging API

Introduction

This specification defines an API that provides access to messaging functionality in the device, including SMS, MMS and email. It includes APIs to create and send messages. These APIs complement what sms:, mms:, and mailto: URI schemes provide with:

• the possibility to attach files to messages,
• A callback on success / error when a message is sent.

Use case

To describe use case, first I would say many browser today already support messaging by supporting frequently used ‘mailto’, and not so frequently used ‘sms’ URIs. While the API certainly addresses a different use case (access from scripting code), it would be very useful to describe how the URI-initiated messaging is different or equivalent to the API-initiated messaging. For example, should browsers make sure that the user experience is always consistent across these two methods of messaging? Or is it acceptable if URI-based messaging uses an external user agent whereas API-based messaging uses a browser's internal capabilities?

At the very least, it would be useful to point out that URI-based messaging exists, and that page authors have the option of using URIs instead of having to write scripting code. in terms of accessibility and platform robustness, it will be quite a while until page authors could rely on the API alone; at least as a fallback solution, messaging URIs probably always are a good idea.

Since not all devices will have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only e-mail) there is a need to indicate that implementations need only expose available functionality.

Examples

The following code extracts illustrate how to create and send messages. Sending an MMS with an attached picture, if device supports it.

function successCB() {

   alert("The Message has been sent successfully");

}

function errorCB(error) {

   alert("The Message could not be sent " + error.code);

}

if (navigator.device.sendMessage) {

   picture = document.getElementById('attachment').files[0];

   navigator.device.sendMessage("mms:+460000000001?body=Welcome%20%to%Atlantis", [picture], successCB, errorCB);