During last days I have been looking for a Javascript library targeted to recent mobile devices. Though I am familiar with jQuery, there is a lot of code that deals with browsers and issues that are specific to desktop browsers, but not to mobile ones, at least when working with browsers running on smartphones and tablets.
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.
I am happy to announce that my workmate Davide Mendolia (@davideme) will be offering a speech about Tuenti Mobile during the Barcelona Developers Conference 2011 on Saturday, November 19.
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.
You have probably heard about websockets, which promise to be a better alternative to short and long polling to achieve real time updated websites. But maybe you didn’t know about server sent events. They are nice to send information from server to client using the same server technology you probably have, using a lighter approach than polling.
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.
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.
We are all excited about the Google+ release, and this is a nice opportunity for web developers to find out how some of its more interesting features have been implemented.
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.
I find it very interesting how they are taking a screenshot of the web page when you preview the feedback message:
There exist tools like html2canvas that allows the creation of screenshots by reading the DOM tree and applying CSS rules.
More info:
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:
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 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.
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:
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.
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:
Have you come across some Google+ implementation detail that should be highlighted? Don’t hesitate to comment to this post!
You can find a demo showing the default behaviour and the one using Facebook’s technique. Use an iPhone or iPod Touch to see the effect.
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:
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
It’s been some time since I posted the tutorial to implement Facebook’s BigPipe using Microsoft ASP.Net MVC. And since then, Razor view engine has increased its presence for providing a way to implement cleaner views and make it easy to avoid ending up with spaguetti code.
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.
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>");
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.
This week I made a job change, from Signum Software to Tuenti Technologies.
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.
Yesterday I watched this Front End Tech Talk by Facebook. I found it very interesting because they explained how they faced the problem of having a lot of javascript code and how they managed to reduce it. I think this can be applied not only to a website of the size of Facebook’s, but also any other project where we could refactor existing code.
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 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.
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.
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:
they rewrote dialogs as anchors with a rel=”dialog” attribute:
Basically they embraced progressive enhancement. This dialog links would be ajaxified later using a common Javascript code:
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.
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:
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.
Yesterday I was reading Zakas’ Performance on the Yahoo! Homepage slideshare presentation, and I got very surprised when I saw that Yahoo had realized that two of the wide accepted tips for improving website performance had not work so well for them.
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.
I usually face asynchroronus WPO from the browser side, for instance making async requests to include Javascript files or AJAX-requesting any other content.
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.