All of them work seamlessly on webkit browsers, which are the most broadly used ones, but only a few take into account Internet Explorer, Opera Mobile or Firefox.

The current status of modern mobile browsers

Although there is a vast diversity of mobile devices, I will focus on those running on smartphones and tablets, which normally have a quite good support of HTML5 features and provide a native DOM selector through document.querySelector function.

There are nice sites showing comparison of different Javascript libraries for mobile, i.e Markus Falk’s.

In my case I would like to find a library that works across all devices that support HTML5. I have been using zepto.js for some time. It is quite small and it has a jQuery-ish syntax. However, it lacks support of some HTML5 compliant browsers:

Zepto supports Safari, Chrome, Firefox and Opera and any mobile WebKit-based browser, including iOS Mobile Safari, Android browser, HP webOS browser, Blackberry Tablet OS browser and others. Zepto does not support Internet Explorer.

You are the only one who knows better what platforms your products are targeted to and what browsers your visitors are using to reach your site. Just keep in mind that there are more players apart from webkit.

Windows Phone 7

Not supporting Internet Explorer, Zepto doesn’t support Windows Phone 7 devices. WP7′s browser is an Internet Explorer version for mobile, that at least in its latest version 9 supports widely HTML5 features. At least from a mobile-targeted JS library point of view, it provides document.querySelectorAll and it is compatible with the standard way to add, for instance, an event using element.addEventListener.

Microsoft is working hard in order to provide Windows Phone 7 devices with a top browser that mobile specific libraries seem to ignore.

Firefox for Mobile (aka Fennec)

By only supporting webkit devices, Mozilla’s Firefox for Mobile is put aside, even though they are working hard on adding promising HTML5 APIs. Recently, I got the chance to play around with the Battery API, the Camera API and the Vibrator API checking out John Hammink’s demos using a nightly version of this browser on an Android phone.

Opera Mobile

Opera Mobile, being powered by a Presto engine, is also disregarded by webkit-only frameworks. And it seems they are doing a great job supporting HTML5 functionality. Seeing how they are performing in the Android Market with increasing download rates and good reviews, we should keep an eye on it.

A tip for mobile JS libraries developers

It is clear that supporting more platforms means having to deal with specific browser’s issues that may lead to more work to be done in order to maintain the library. Moreover, these libraries have a small size as one of its main constraints.

However, take into account that most recent versions of Internet Explorer and Opera Mobile have a similar feature set to the webkit’s one, and adding support to them could be quite easy.

Having a look at their source code, I have seen that some libraries rely on non-standard features, like proprietary property __proto__, to provide a chain-able API and add custom functions like addClass or removeClass to an element, or ready to a document.

Take zepto.js as an example:

function Z(dom, selector){
    dom = dom || emptyArray;
    dom.__proto__ = Z.prototype;
    dom.selector = selector || '';
    return dom;
}

The usage of __proto__ to extend the DOM element by modifying the prototype chain doesn’t work on IE or Opera, as a user already pointed out.

This is an approach to avoid extending the DOM, defining every helper method in every retrieved DOM element, or implementing a wrapper around an HTMLElement like jQuery does with its jQuery object, but only supporting Gecko and Webkit browsers.

A tip for webapps developers

I would like to tell developers that they should try to go the extra mile and consider supporting non-webkit mobile browsers. Definitely, manufacturers like Nokia are betting on WP7 (you only have to see their Lumia 800 ad campaign) and we could see an increase in IE mobile share. In addition, as browsers other than the default one can be installed on some devices like Android ones, opening the door to Opera Mobile and Firefox, we can’t be sure that an Android user will be using a webkit browser.

Since I joined Tuenti on February, I have been able to explore mobile web site development in depth, facing a world of devices and different capabilities that makes programming a real challenge. As the use of mobile devices is growing, so we are making an effort to adapt Tuenti mobile site to offer the best possible user experience.

If you are around Barcelona and you are interested in mobile development don’t hesitate to attend the conference.

Tuenti will be represented also by Diego Kartones (@kartones) who will be speaking about Tuenti release workflow and there will also be a talk about security.

Here you can find a nice explanation, and you can give it a try by visiting this Server-sent Event Demo from a capable browser.

How iOS devices react to Server Sent Events

SSE will fire on iOS even if the page is not active

Having a look at how iPhone behaves when using Server Sent Events I realized that even if the tab showing a page using SSE is not the active one, Server Sent Events are processed. In short, events are processed as long as that page is loaded in any tab, no matter if it focused or not, and even after Safari is closed using Home button or the device is locked using the top button. The difference is that only when using Safari, a loading spinner is shown on top.

The behaviuor of iPad is quite similar. It also processes SSE when it is locked or when a different tab is active, but it won’t process them when closing Safari.

Is this how iPhone and iPad should behave? According to W3C, yes. They state:

The “push proxy” service uses a technology such as OMA push to convey the event to the mobile device, which wakes only enough to process the event and then returns to sleep.

But I can’t find how this can be useful at all. If only a notification system was available, a chat application could be implemented and notify the user whenever other person in the chat mentions him. But currently there’s no way a non-active page can react to a server sent event, thus no useful event processing.

I am trying to collect information about implementation details for every innovative functionality that makes Google+ push the limits of web development.

Meanwhile I am trying to get useful conclusions by seeing their CSS and JavaScript code and the flow of HTTP requests. Until now I haven’t seen especial things involving static resources like images (not using WebP), CSS or JavaScript files. I can only say that CSS and JavaScript files are greatly minified, squishing their content to the last byte.

Feedback system

Google Plus feedback system is brilliant. It is very easy to use for low-tech users thanks to their highlight / black out feature and area selection, and useful for Google due to the information they retrieve from the browser, HTML structure and javascript log.

Creating a feedback message in Google+, blacking out and highlighting certain areas

I find it very interesting how they are taking a screenshot of the web page when you preview the feedback message:

Preview of a feedback message in Google+, showing a screenshot of the web page

There exist tools like html2canvas that allows the creation of screenshots by reading the DOM tree and applying CSS rules.

More info:

• How does the Screenshot part of the Google+ Feedback system work?

Google Circle animation

It is nice how fluid the interface is when creating circles and dragging people into them. The animations are very smooth and it is a pleasure to use it, making something that was tedious a fun experience.

More info:

• Is the Google+ circle animation implemented in JavaScript or Flash?

Google Hangout

This is a feature that extends Google Talk video chat to make it possible to video chat with up to 10 people. This represents a big effort in terms of bandwidth and lag avoidance.

More info:

• The technology behind Google+ Hangouts

Accessibility

The use of ARIA attributes in the HTML code (aria-haspopup, aria-owns, aria-owner) makes me thing they have take accessibility as a priority. This is in line with their effort for spreading the word about  developing accessible websites, as they explained in their talk Creating Accessible Interactive Web Apps using HTML5 in the recent Google I/O 2011 conference.

JSON responses forcing AJAX calls

If you inspect the JSON responses content, you will see that they start with

)]}’

This seems a way to force requests to be made using Ajax calls and avoid retrieving data using script tags, that would result in a error being thrown. This is similar as how facebook adds an infinite loop to their JSON responses using

for (;;);

More info:

• Strange JSON response in Google Plus

Indexability

Try to disable JavaScript and you’ll see that you can’t even log in Google+. However, public profiles (make a basic search for site:plus.google.com) work quite well when disabling JavaScript. Tabs link to pages where content is loaded correctly, except for Photos and Videos tabs, so that search engines can view and index the most important part of the profile information.

Google has even add a parameter to look for Google+ profile pages.

Tools used to implement Google+

Google+ has been implemented using a set of tools that are mostly open source. In the server side, they use Java Servlets, BigTable and Colossus. Google+ seems to be using GSE (Google Servlet Engine) according to the ‘Server’ response header when requesting the root page.

And in the client side, they use Closure.

More info:

• Google+ is Built Using Tools You Can Use Too: Closure, Java Servlets, JavaScript, BigTable, Colossus, Quick Turnaround
• I’m a technical lead on the Google+ team. Ask me anything.
• Google+ social network in depth

Have you come across some Google+ implementation detail that should be highlighted? Don’t hesitate to comment to this post!

When clicking a link for ajax navigation on iPhone and iPod Touch, the navigation bar slides down and up for every link, even when they are enhanced to support ajax navigation and its click event is captured and we load content using XMLHttpRequest instead.

This is a bit annoying and some developers have already tried to solve it. See these links:

• Can iPhone Safari be prevented from showing the navigation bar during an AJAX call?
• iOS urlbar shows then hides when clicking internal link
• Stopping the url bar from dropping down – I discovered a workaround
• How do i stop mobile safari from dropping down its URL/Loading bar whenever i submit an ajax request?

The fact of having an anchor with an href attribute is enough for Safari Mobile to show the bar unless the address is preceded by the hash sign. It is not the fact of changing the URL, because if you preventDefault() the click on the link and avoid the navigation, the bar is shown anyway.

I realized that Facebook, among others sites with iPhone adapted versions (see jQtouch, Sencha Touch or Twitter), didn’t show that bar dropping from the top of the screen.

Looking at Facebook’s mobile site code, I found out that they made a workaround. They attach to the touchend event, which is fired before the click event fires, and then replace the value of the href attribute:

JX.install("MLinkHack", {initialize:function() {
  if(!JX.MTouchClick.hasTouchEvents()) {
    return
  }
  JX.Stratcom.listen("touchend", "tag:a", function(a) {
    var c = a.getNode("tag:a");
    if(c.getAttribute("target") == "_blank") {
      return
    }
    var b = c.getAttribute("href");
    if(!b || b.indexOf("#") === 0) {
      return
    }
    var d = JX.$U(b).getProtocol();
    if(d && d !== "http" && d !== "https") {
      return
    }
    JX.MLinkHack.add(c)
  })
}, statics:{_hack:"#!", add:function(a) {
  a.setAttribute("href", JX.MLinkHack._hack + a.getAttribute("href"))
}, remove:function(b) {
  var a = b.getAttribute("href");
  a = a.indexOf(JX.MLinkHack._hack) === 0 ? a.substr(2) : a;
  b.setAttribute("href", a)
}}});

Later, the href value is set back to its original value, calling to the JX.MLinkHack.remove() method:

JX.behavior("m-link", function() {
  ...
  JX.Stratcom.listen("click", "tag:a", function(event) {
    if(JX.Stratcom.pass()) {
      return
    }
    try {
      var e = event.getRawEvent();
      var link = event.getNode("tag:a");
      if(link.getAttribute("onclick") || (e.which || e.button) >= 2) {
        return
      }
      if(window.FW_BFF_ENABLED) {
        event.kill();
        FWBff.send("/fb/onclick", [link.getAttribute("href"), link.getAttribute("target")]);
        return
      }
      if(window.user_action) {
        user_action(link, "a", e)
      }
      JX.MLinkHack.remove(link);
      var href = link.getAttribute("href");
      ...
});

As we see, this is only done for touch devices. Non-touch devices see normal links, so we can provide the default navigation for the rest of devices. That is nice for our progressive enhancement approach.

This workaround works nice when applied to a hash based ajax navigation. In addition, if we want to use History API, then we could call to history.pushState() in the click event, once we have replaced the href to its original value. That way we would use the hash as a temporary hack to prevent Safari browser from showing the bar.

I will try to check the techniques that other sites have implemented to solve this, but they might be similar to this one.

And I find this less hacky than using a ‘link’ attribute instead of ‘href’ attribute in anchors, or replace anchors by buttons, as I’ve read in some place.

Want to see it in action? See the demo.

EDIT: It seems that jQuery Mobile has managed to implement this in their beta 1.0

Though now I am focused on PHP, in my previous job we decided to migrate to Razor as soon as possible since it is a more convenient way to implement ASP.NET MVC views, while you can keep your models and controllers code the same.

However, Razor does not behave well with the proposed BigPipe solution due to its way of managing the partial views code. You can’t write to the output in your inner views using Response.Write() nor flush because Razor renders pages from inside out. Thus, the inner most view is rendered and written to a buffer, and then the partial view / content place holder where it is defined, and so, until the outer most layout is reached. Then, the content of the buffer is written and flushed to the browser.

This provides the developer interesting new patterns. For instance, you can import JavaScript or CSS files depending on the content rendered in the views, and import them in the head section of your page, since when the layout is reached, we already know which dependencies to load to provide the functionality needed by the different elements of the page.

Some days ago I received a meesage from James Hull (@bigfellahull on twitter) explaining a way to achieve BigPipe using Razor.

Pagelets containers

The way to define a pagelet container is the same. Just write the container out to the buffer and all is well.

helper.ViewContext.Writer.Write("div id=\"" + pagelet.Container + "\"</div>");

Early flushing

However, to perform the early flush and flushing each pagelet required a little thinking. James has been looking for a solution and he found out that the best approach is to manually write the buffer to the response.

So, in the layout (master) page, we can cast the ViewContext.Writer buffer to a string writer and then get the underlining string builder. Then you can write this string builder to the response, flush it and set the string builder’s length to 0. This seems to be what razor does under the covers so we are just doing it a little earlier.

var sb = ((StringWriter)ViewContext.Writer).GetStringBuilder();
Response.Write(sb);
Response.Flush();
sb.Length = 0;
Html.ExecutePagelets();

We can do the same with the pagelets,

lock (_locker) {
  helper.ViewContext.Writer.Write(pagelet.Serialise());
  var sb = ((StringWriter)helper.ViewContext.Writer).GetStringBuilder();
  helper.ViewContext.HttpContext.Response.Write(sb);
  helper.ViewContext.HttpContext.Response.Flush();
  sb.Length = 0;
}

And now it works fine in razor!

I am really happy that James (@bigfellahull) has been researching a way to port this technique to Razor, that is called to be the de facto ASP.Net view engine.

Working at Signum Software I have met a group of very professional people and I learnt a lot from them. It is a pleasure to work at a company that takes care of their own products, always trying to improve them. And for a developer it’s even better when that product is a complete framework that optimizes and makes your work easier.

If you are willing to carry out a .Net project, you’d better have a look at Signum Framework. Version 2 will be soon released, and lots of new features will be presented. You can follow them on twitter @signumframework to get last news, and extendend documentation is available on signumframework.com. For a quick overview you can read Wikipedia’s article about Signum Framework.

I wish Signum the best of luck, and I hope more developers realize how Signum Framework can improve their projects development, manageability and maintainability.

We had about 1MB of JS on the homepage

They realized they had a problem with so much JS code and they worked at different levels to shrink it.

Haste

Haste is a package and dependy manager for CSS and JS files. In each file they specify the name of the package provided by the file and those files that are required to run the file. Thus, Haste can manage what files are needed to run a certain script.

This helps managing how files are requested and even which sets of files should be merged. This system was further explained by Xiaoliang “David” Wei at his talk about Static resource management & optimization that took place on December 2010 at Velocity China.

Bootloader

This consists of a JS library that helps loading and unloading static resources on demand. Not too far of RequireJS or LabJS. It uses dynamic script injection and executes a callback function once the resource is loaded.

The good point is that you can even suggest static resources that are not inmediately needed but could be prefetched at background.

Primer

Makinde Adeagbo already talked about Primer at JSConf 2010 (slides).

A waterfall analysis showed that CSS resources where requested quite at the bottom and a lot of javascript on the head. Moving Javascript code to the bottom showed that the user interface would freeze while downloading/parsing/executing this code and that would provide a bad user experience. In some way, this is quite similar to what Yahoo! also found out, and I explained on my The not so good performance tips post.

They decided to rewrite their JS code so that they could load a small file at the top that would provide the common functionality needed (about 80% of the interactions). And they moved Javascript client code to PHP code on the server. Instead of calling to a function like this one:

Javascript code to build a dialog

they rewrote dialogs as anchors with a rel=”dialog” attribute:

Javascript code to build a dialog”]

Simplified code to mark a link as a dialog

Basically they embraced progressive enhancement. This dialog links would be ajaxified later using a common Javascript code:

Adding a listener to manage click events on links marked as dialogs

And instead of letting Javascript set the title, content and the rest of dialog properties, it is the server the one that serves the dialog formatted as needed.

PHP chainable code to create a dialog and set different properties

It is like converting a jQuery widget plugin into an ajax call and let the server generate the widget content.

They used this same approach to replace chunks of similar Javascript code. In async calls that retrieved html to replace existing markup, they are now generating javascript code (using PHP) on the server side and executing it in the async response. And if the url that should be requested when clicking an ajaxified link is a different one, they specify it using a custom ajaxify attribute. They also use this ajaxify attribute to specify that a form should be ajaxified.

Like Makindo says,

if you are writing a site with tons and tons of Javascript it is very easy to forget about actual forms

All this common interactions are shown in the comments form:

An example of common interactions that in their comment form

The top red arrow indicates that Comment is a label, so clicking on it focuses the comment textarea.

Some sample Javascript code is available on https://gist.github.com/376039.

They managed to not only reduce Javascript size, but loading CSS aton the top and being able to load Javascript at the bottom in an async mode.

This talk shows that sometimes it is necessary to return to the basic elements and build interactions from there, trying to find common functionality to reduce the code needed, and embracing progressive enhancement as a way to achieve it.

1) Put scripts at the bottom (slide 37)
Or at least that is what Yahoo recommends, and it contributes as one of the indicators to calculate YSlow score. But they found out that page would stay frozen while fetching, executing and parsing Javascript and this was worse over slow connections.

The solution was loading Javascript using dynamic script tags. This solution is better applied when using progressive enhancement because users can try to perform actions that are provided by this non-blocking javascript.

2) Flush after head (slide 51)
This is another recommended practice by Yahoo. They found out that the best solution was to flush at different points, especially when a block of a considerable size had been output. They also recommend to avoid having a big external div containing the different sections, and place directly the sections as body children.

In conclusion, the best you can do is test the different alternatives, especially when trying to find the one the provides the best user’s preception page load time.

Today I have come across a feature that has been around since ASP.Net MVC 2 and that allows Asynchronous processing of controller actions. It is nicely explained on Using an Asynchronous Controller in ASP.NET MVC on MSDN website.

It is very useful on long-running requests, since it avoids thread-blocking while the request is being processed. In addition, it exposes AsyncManager, that can be used to increase parallelism in an action by splitting the execution of independent operations.