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 →

ParseInt is one of the handiest universal functions in javascript. Even though javascript’s ability to cast most any primitive to any other primitive on the fly is handy to say the least, sometimes we need to explicitly parse a string to make sure we have a legitimate number to work with.

ParseInt does this for us. What most developers don’t realize is that parseInt is base agnostic. While it typically assumes base ten, any base between 2 and 36 can be used and is indicated by the optional second argument.

Why is this a problem you might ask? Because octal numbers can be represented by a leading zero. In practice this can cause some interesting effects in your code.

For example:

var x = "010";

console.log( x );

console.log( x - 0 );

console.log( parseInt( x ) );

console.log( parseInt( x , 10 ) );

Returns:

"010"

10

8

10

Note: “010″ is equivalent to 10 in  “x - 0″!

Widget.Blender is a handy prototype class to smoothly animate a fade/morph transition between images

Features

• Start & Stop can be triggered by events
• Autosizing & Wrapping can be controlled
• Ability to set a standard base url / dir for all images
• Ability to start at any arbitrary image
• Ability to run arbitrary function before blend (Useful for setting caption to display along with image)
• Supported Browsers:
  • Firefox 2
  • Opera 9
  • IE 6
  • IE 7
  • Safari

Check out Widget.Blender at:

http://www.eternal.co.za/scripts/blender/index.html 

I recently discovered a fascinating prototype extension called LOAJAX. While the effect of the extension is a bit hard to describe, it’s immediately obvious when you try the demo’s with and without it. Basically, LOAJAX uses an iFrame crutch to make the browser display all of the interface elements associated with a page load.

How it works:

1. A normal AJAX XMLHttpRequest is triggered by the AJAX application.
2. LOAJAX creates a hidden iframe that points to a server script.
3. The browser displays loading behavior while the iframe loads its source.
4. The Server Script consists of a massive wait so the load never completes.
5. When the XMLHttpRequest is completed, LOAJAX stops the iframe load and removes it from the DOM.
6. The browser stops displaying page load indicators.

You can find more about LOAJAX and check out the demo here:

http://blog.loajax.com/

I covered the Prototype port of this plugin a while ago, but recently realized that I had neglected to cover the original version. jQuery corners is an excellent library for adding quick corner effects to your pages in a graceful and unobtrusive way.

Here are some highlights of the plugin’s capabilities:

• A whole slew of effects is available.
• The width and height of the adornment area can be changed to vary the effect.
• You can apply different effects to top and bottom corners, or apply an effect to specific corners.
• Boxes to be adorned are selected using the standard JQuery $() element selector function.
• No special markup is required; display falls back to unadorned corners when Javascript is off.
• You can define your own custom corner effects that the plugin will use.

Learn more about the plugin at
http://www.methvin.com/jquery/jq-corner.html

If you haven’t realized it yet, widgets are here to stay and definitely represent what is currently the most ubiquitous way in which the web has been brought to the desktop. Google Desktop’s Gadgets, Windows Sidebar, OSX’s Dashboard, Opera and the venerable Yahoo Widgets (previously konfabulator) all bring tiny, self contained web pages into the users desktop space. For most people, this is the first thing that comes to mind when you mention taking the web to the desktop.

Widgets, however, are a very small piece of the puzzle. While they overcome some of the limitations of the web by placing your site front and center inside the users normal computing environment and provide some level of escape from the omnipresent security sandbox, widgets just don’t provide much that transcends the traditional web environment.

Widgets do have a role to play in the emerging web ecosystem. They are a lightweight means of integration between sites and they do provide useful tools for the user. Unfortunately, while they do provide a level of convenience, they can also provide a pretty severe level of annoyance to users. Luckily, they are very easy for users to uninstall and users vote with their mice removing any widgets they deem too annoying.

So where do widgets fit in the hybrid web ecosystem? I’m not really sure. They are definitely a motivating force behind the creation of several robust api’s for enabling the integration of disparate platforms and sites. They can also do a great job of providing alternative light weight interfaces for traditional web sites by putting underused tools closer to the daily user experience.

In my mind, I can’t really rule them out for many of my projects. They’re kind of like the gravy at a holiday meal. Even if the turkey is as moist as a swamp in June, you still make it because someone may want it and it isn’t that much more work once you’ve gone to the trouble of cooking the bird.

I’m curious, how are you using Widgets in your projects?

I’m pleased to announce a preview release of Blueprint Layout Tool 0.4. This version marks the migration of BLT to its own site at http://www.blueprintlayouttool.com and a focus on dramatic improvements to the source view. Unfortunately, the current development version only supports Firefox, IE, Opera & Safari support will be coming soon.

Key Features:

• Improvements to style and polish of the interface
• Dramatic improvements to source view (Powered by CodePress & PHPTidy)
  • Generated Source is well formatted and polished
  • Generated Source is Syntax Highlighted
  • Generated Source is cleaned of most extraneous markup

Known Issues:

• Source View does not work in Safari and Opera
• Formatting is off in IE
• Generated source contains several Mozilla specific tags that still need to be cleaned.

I would also like to take a few moments and draw your attention to Christian Montoya’s Blueprint Constructor application. He takes a different approach to the interface and design of the Layout Tool and has created something quite useful and fun to use. We will be working together to try and achieve similar conventions between our apps.

Check out Constructor at http://lab.christianmontoya.com/construct/

You can read about his design process on his blog at http://www.christianmontoya.com/2007/12/08/construct-01-alpha/

Hi All, I will be scuba diving in Central America for the next week.  I’ve queued up some posts but won’t be around to respond to any comments.  Hope you all had a Happy New Year. 

Requests and responses make HTTP work; they are the yin and yang of Client / Server communications.  Last time, I covered some of the most common response codes and what they mean.  Today, I will be covering the different ways in which these communications can be called from the client.GET and POSTGET and POST are the 2 most common request methods.  GET is intended for the retrieval of information while POST is intended for the submission of information as a subordinate of the requested resource.When To Use GETGET should only be used when security is not an issue and all information can be included as part of the URL string.  GET has added the benefit in that it can be used with Cacheable data to reduce network usage.  Most server side environments allow you to include and process information included in the URI of the GET request.  This is generally a bad idea as all information included in the URI is transmitted in a form potentially visible to third parties.  Where security is not an issue that can be a more efficient way of getting information to a server.When To Use POST POST is ideally suited to transmitting dynamic information to the server.  Post supports the following benefits over GET for this purpose.

• Information is not included in public facing URI request.
• Larger quantities of data can be transmitted
• Request data is not cached

Other MethodsThere are several other methods supported by HTTP 1.1 that you may find useful at some point.  Not all of these are readily accessed from within the Browser environment, however.

• HEAD: Identical to GET except only the header and no body is returned
• PUT: Requests that the attached body be stored under the requested URI.  If the resource already exists, it should be overwritten by the new version.
• DELETE: Requests that the resource at the requested URI be deleted.
• TRACE: A Debugging method, it requests that the request (as received by the server) be transmitted back to the client in the entity body.
• CONNECT: A reserved name for future support for dynamically switching to tunnel proxies.

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.