These are good times for web development. It is moving from client side web development, to server side, then to mobile apps, and now as the top layer used to run all the applications of a typical phone. We need browsers and OS makers to push forward these technologies, implementing better Javascript engines, and making reality the latest HTML5 APIs. Continue reading…
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.
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.
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.
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. Continue reading…
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. Continue reading…
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.
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. Continue reading…
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. Continue reading…
I am happy to announce that my workmate Davide Mendolia (
