Its been very recent that I’m seriously looking into Javascript – and trust me, there is no dearth of stuff that can be achieved with purely client side code (HTML/CSS/JS). With the modern browsers churning out best of the breed in JS environments (both headed & headless), everything is going to come to a browser near you! Its just a matter of time!

Anyways, on more subtle issues, while writing a purely client side JS app using Backbone.js & jQuery Mobile I came across jQuery.proxy method – something that I’ve really started using almost everywhere.. The method is so useful that sometimes I wonder – why jQuery did not implement it in callback mechanism by default.

A quick overview about the problem…

When a new object of FBNotificationWatcher is created, all goes well. this.getNotifications gets the JSON & this.processNotifications processes it. However, when setTimeout’s occurs and this.getNotifications is called again, the context of “this” is set to the “window” object. And because of this, the code breaks in this.getNotifications method.

Now this is very frustrating – as you just lost the object you were operating within.

Solution? jQuery.proxy comes to rescue!

If we setup the setTimeout call like this, jQuery will guarantee that the context of “this” when this.getNotifications gets executed, will always be set to the original FBNotificationWatcher object which had setup the timer. The second argument to jQuery.proxy defines the context you want to get back when the setTimeout callback gets executed.

This concept can be used anywhere you want your callbacks to retain their context.

Read more about the method at jQuery API docs.

Related posts:

1. Kickass MCV for your Javascript Apps Very recently, I had an opportunity to work on a...
2. How to commission developer machines in an agile way? During the past year – working at AdoMado, I’ve seen myself...

Related posts brought to you by Yet Another Related Posts Plugin.

Faster HTML and CSS: Layout Engine Internals for Web Developers (@GoogleTechTalks)

I think I never cared about these – but the way David Baron from Mozilla describes these, I think I will now.
The points he was making started seeming so crucial that I jotted them down as if taking notes – something I never did with previous videos.

The things which I picked up from this video are…

From fetching the DOM over the wire to displaying it, following steps take place in order…
(1) Compute => (2) Compute Style => (3) Construct the DOM frame => (4) Layout => (5) Paint

The further Left (towards (1)) you push the browser’s rendering engine via your DOM/JS/CSS, the slower the browser would get.

Hence…

Use as specific CSS tags as possible. The more generic tag, the higher performance hit while searching the DOM. For example, a “#some-id {}” is way way faster than “body > div p {}” – as in the second tag, a larger portion of DOM is parsed to check which elements are affected by the selector. You push the browser to start from stage (2).

“:hover” style hits the browser pretty badly – as it pushes the browser back to stage (2). Coupled with the above mentioned CSS selectors problem, it can lead to real slow computation. Use it with CSS selectors which are very very specific in nature.

Programmatic scrolling of tags (some of which might have overflow property) via javascript – as that does not causes re-computation of style (stage 2). While if you do it with CSS magic, you push your browser back to stage (2).

Mozilla’s rendering tree, while building itself – does not takes any element with with CSS property “display:none” into account – it just skips it. So when this property is flipped, it triggers a full re-computation of the tree – which is expensive. However if we use the style “visibility:hidden” – the rendering tree picks up the related element while building itself. Hence when visibility is flipped, its much faster as there is no re-calculation of the rendering tree.

An old one – when javascripts are being downloaded, the browser stops itself from any other processing and waits for the script to download and execute (as script can modify the DOM anyhow it likes). During this time, the precious time is lost – which could have been used in downloading other content – like images, DOM, CSS, etc. Hence – keep the javascripts as further in the DOM as possible. Use caching is possible.

Learn more about speeding up your website at – Yahoo’s best practices (YSlow stuff) – some of which we regularly follow at AdoMado.com

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Ever since we implemented content filtering mechanisms at AdoMado, our own site was being blocked – and this made me heck curious – why??

Today morning, using Rubular (which is an excellent online regex tool) – I discovered the culprit.
And it couldn’t have been more hilarious )

Fixing this… )

PS – a valid bug.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Link: www.vimeo.com

Rails 3 Update by Yehuda Katz from Wind City Rails 2009

You just can’t ignore his style of explaining things!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Problem Scenario
I migrated my blog from makuchaku.info to makuchaku.in – and wanted everyone who was linking to my “.info” domain, automagically gets linked to my “.in” domain. Ofcourse, I cannot change all the possible places from where my .info blog is linked.

Challenges

1. I want “.in/” to be served when “.info/” is cliked
2. I want “.in/blog/this-is-a-post” to be served when “.info/blog/this-is-a-post” is clicked.

Ofcourse, Challenge 1 is very east and straight forward. Just put up a redirection at .info domain and you’r done. Challenge 2 is interesting.

Solution
Goto your theme editor (old wordpress blog) and edit the template for which you want to setup redirection. For me, it was all posts and all pages. Next, insert this javascript code at the top of template code…

Thats it. Now whenever you’ll hit http://makuchaku.info/blog/why-makuchaku – you will be redirected to http://makuchaku.in/blog/why-makuchaku – sweet!

Assumptions
This solution assumes that your new blog is a mirror replica of your old blog.

Please Digg this post if it helped. Thanks.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Okay, to start off – I really wanted Firefox to come on the top… I’ve been a dedicated firefox user ever since and simply love the product. The fact that it has addons for any conceivable functionality – makes it r0ck even more!

However, to my surprise Google’s Chrome beats it hands down when it comes to speed of the javascript engine each of the browser deploys. Google has V8 tucked under Chrome’s (v4.0.213.1) belt, while my shiny new (nightly updated) Mozilla Firefox Minefield 3.7a1pre has TraceMonkey.

So why am I this sad today? Well… check this out…

Peacekeeper JS test – Chrome was nearly 59% faster here!

SunSpider test – Chrome was almost 76% faster

Chrome vs Firefox – SunSpider test, merged view.

I purposely ran the tests in side-by-side browser windows, launching Firefox tests just about a second before the Chrome’s tests – and to my surprise, I could actually (visually) see Chrome finishing faster – it was that fast!
Afterall… 59% or 76% actually does seems a pretty huge boost, whatever functionality it might be in.

Here are by browser versions… (both are stock builds as provided by repositories/online).

and  

Well… to me, this is healthy competition. Talk about the times when Chrome wasn’t there, Firefox used to make IE look timid. Come Chrome and now Firefox is doing the catch-up. Whoever wins, we – the end users – get the best of all the worlds.

That is like – have your cake & eat it too

However, I seriously hope that by the time Firefox 4.0 launches, its javascript engine is at par with Google Chrome’s.
And by the time Google Chrome matures, I wish it should start sporting the same plethora of addons as does Firefox.

From UI’s perspective, Chrome also packs an extra bit of punch, which I really like and would like to blog about. But thats for a later post.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.