A question emerged out of my boredom on my flight yesterday.  Which is faster, implicit vs explicit conversion.  Most javascript developers use implicit conversion out of habit. For example:

!!x; instead of Boolean( x ); and x + “”; instead of String( x);. 

I decided to try an experiment for myself and record the performance of casting a number to a Boolean or String on my Windows box in Safari 3, Firefox 2, Opera 9 and IE 7.

The Verdict:

Implicit conversion wins handily, demonstrating over a 7 fold performance increase in one test. Overall, the performance gain for using implicit conversion averaged out to 53% across browsers after 10 tests.

The Numbers:

You can find the code I used after the jump.

Keep reading →

I know what you’re thinking, mobile aps run on cellphones and smartphones, not PC’s. Mobile sites are one of the most important and pervasive aspects of this hybrid web ecosystem. Unlike desktops and laptops, mobile sites can assume that the cellular device they are displayed on will have a persistent and portable net connection. Because of this benefit, mobile sites can be viewed as intermediaries to be used with a user may not have access to a traditional internet connection.

Unfortunately, mobile platforms are and always will be limited devices. There simply is no way to put all of the screen real estate of even the smallest monitor into a device that will fit into someones pocket without resorting to origami voodoo. Higher screen resolutions help the situation, but there are limits to the human visual system and 6pt font is almost as eligible on paper as it is on any digital screen.

Other restrictions abound surrounding the mobile platform. From a user interface perspective it’s still a bit of the wild west and mobile browsers have tended to be flaky, inconsistent and underpowered. Safari, Opera and Minimo make significant strides towards eliminating these issues and providing a much richer platform on which to develop. Many cellphones also provide API’s to enable mobile aps to look consistent with, act like and interface with the underlying device.

The inconsistencies across platforms still make mobile devices a difficult nut to crack in terms of development. As browsers, bandwidth and processing power improves, expect developing for them to increasingly less frustrating and in higher demand from users.

IBM Developer Works has released an excellent article on AJAX interface development with a focus on best practices and a recomended work flow.

Check it out here:

http://www.ibm.com/developerworks/web/library/wa-aj-frontend/index.html?ca=drs-tp4207

Organizational standards are wonderful things.  They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project.  At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape.  How do you strike a balance between flexibility and consistency?

Keep reading →

While jQuery is many powerful things, Selectors are quite possibly its most capable and useful feature. So here’s the jQuery Selector crash course.

The Ground Rules:

1. Selectors work just like CSS (1-3) selectors # for ID’s, . for classes p, div, ul, li etc.
2. XPath an also be used.
3. CSS & XPATH selectors can be combined

The $ wrapper.

Selectors + $ = jQuery Nirvana. The $() function accepts any selector and returns an object that can be manipulated.
Filters 

jQuery filters enhance jQuery Selectors by providing additional logic.  Here’s a list of supported filters:

• Not (selector)
•  first
• last
• even
• odd
• eq( index) matches an elements index in returned array
• gt( index) matches all elements after given index in an array
• lt( index ) matches all elements before given index in an array
• header matches all h elements (h1 h2 h3 etc)
• animated (matches all elements that are currently being animated)
• contains( text) matches all elements which contain given text
• empty matches all empty elements
• has(selector) matches all elements containing an element that matches the given selector
• parent matches all elements that are parents / have child element. (opposite of empty)
• hidden matches all elements of type hidden
• visible (opposite of hidden)

Dustin Diaz recently posted about Rolling out your own javascript interface in his blog.

http://www.dustindiaz.com/roll-out-your-own-interface/ 

While his code is nice and clean and it does provide what he was hoping to achieve:

There are times when using a JavaScript library is called for. Building large web applications that use a wide array of utility functions that help aid in developing multi-tiered class systems, advanced UI components, complex event models, and heavy use of DOM scripting helpers. Yep. Those are all great.
However, there are other times when you don’t need all that. And often what we end up doing is just importing a few of our favorite functions as globals, and work off those. But what ends up happening in this case is that we lose the particular style that these libraries offer.

In essence, he’s offering a light weight solution to the fundamental issue persistent to all javascript development: (”javascript sucks”). His solution is to coble together a light weight version of prototype containing only what he needs.

My questions are three fold:

1. Is rolling your own framework worth it? The new generation of code profilers for the various toolkits can dramatically decrease download size and focus on the functionality needed.
2. Is there sufficient demand for a new ultra light weight toolkit to address these issues?
3. Why not use full toolkits:  Many of them are small enough in compressed form not to make a noticeable difference in load times.

Menu widgets: Every toolkit’s got one or more and they sure are easy to use & impressive so the temptation is there to just slap them everywhere. After all, you’re already pushing the toolkit to the client anyway, why not make the most of it.

Before you do, tho I encourage you to consider the following & ask yourself if the javascript solution is really appropriate.

Keep reading →