This new access to motion data opens up developers to do so much more, besides the obvious usage in games, we can create user interactions based on motion. Thats where I decided to use it, my thought was to use it for tab navigation, but more in that in a minute.

An Overwhelmed Browser

Needless to say, this ‘devicemotion’ event being fired so often can eat up resources so I needed to wrap all the logic that is executed each time the event is fired in a simple modulus check, which will reduce the overhead of logic being run to every n times. With a case like this, where the event is fired 50 times a second, a modulus of 10 will be enough to reduce the overhead – of course we can increase this number if things still seem sluggish, or decrease it if we have resources left and want a little more resolution to our readings. Honestly, handsets don’t have much in the way of CPU to begin with, so always play it safe.

…<br /> window.addEventListener(“devicemotion”,<br /> Ext.createDelegate(this.deviceMotion,this), true);<br /> …<br /> deviceMotion: function(event) {<br /> if (this.dmcnt % this.pollmod && event.acceleration){<br /> // do stuff<br /> }<br /> }<br /> …

There is another way to accomplish this same thing, by writing the events arguments to a static variable somewhere, and setting up a timer to poll that variable every n milliseconds. This method works pretty much the same in this case, though I prefer the modulus method, which accounts for the event actually being fired. If for some reason the phone is set on a solid surface and no longer firing the event (ha! not gonna happen in this case) then the modulus method stops using resources, whereas the polling method is always using the same amount of resources.

…<br /> window.addEventListener(“devicemotion”,<br /> Ext.createDelegate(this.deviceMotion,this), true);<br /> window.setInterval(Ext.createDelegate(this.deviceMotionFire,this), 200);<br /> …<br /> deviceMotion: function(event) {<br /> this.devicemotion<br /> }<br /> …<br /> deviceMotionFire: function() {<br /> //do stuff (using this.devicemotion)<br /> }

Eaither way works fine in this case, however I’m sticking with my old standard modulus check. Let’s move on.

The Concept

As soon as found out that accelerometer data was available, I knew exactly what I wanted to do. Why not flick the device left or right to move between sections of our app – the user already thinks of the interaction of swiping between sections with their finger on the screen, so why not flick as well?

The Plugin (for Sencha Touch)

The culmination of all of this has been rolled into a simple Plugin for Sencha Touch TabPanels, which is available on my Github account. Right now there are no configuration options, just add the plugin to a TabPanel like so:

{<br /> xtype: ‘tabpanel’,<br /> …,<br /> plugins: [new Ext.ux.touch.AccelerometerTabs()],<br /> …<br /> }

As always, feel free to fork it and make changes or use it as you wish. Enjoy!

https://github.com/VinylFox/Ext.ux.touch.AccelerometerTabs

LIVE DEMO (only works on devices w/hardware): http://www.codetick.com/demos/tabs/index.html

NOTE: I wrote this plugin on a whim almost 8 months ago, and have not written a blog post on it till now Oh the joy of having too much work to do! I would love to see someone code a “swirl refresh” plugin where you move the phone in a circular motion to refresh a listview.

Be Gone Refresh Button!

A simple thing we can do to get rid of extra button clutter is get rid of that “Refresh” button that is eating up space and ugifying the top right corner of our toolbar. Luckily someone has already come up with a UX to deal with this problem, the “Pull to Refresh” interaction pioneered by Loren Brichter of Tweetie fame. I just needed to implement it into Sencha Touch.

Pull to Refresh

The solution to this UX problem is quite simple, make a plugin that monitors scroll and adds the appropriate visual indicators, but I wanted to see how others implemented it first and follow that same pattern. This way whatever I developed would follow the exact same interaction as other established implementations and not confuse users.

What I found was the EGOTableViewPullRefresh , a JAVA implementation developed by enormego and used by Facebook for their Android mobile app, this provided me with the appropriate logic, styling and interaction to match the current widely accepted user interaction.

After careful examination (the code is actually quite small) I found that there are three stages to the “Pull to Refresh” concept:

• Normal
• Pulling
• Loading

The “Normal” state is when the user is pulling down on the list, but has not yet reached the required distance pulling the list to cause a refresh if released.

The “Pulling” state is when the user has pulled down on the list past the required distance, and releasing it would cause a refresh. If the user were to pull the list back up past the required distance and release it would return to the Normal state and a refresh would not be triggered – this is the “escape” for users that do not want to refresh.

The “Loading” state is quite self explanatory, it’s when the user has released the list from the “Pulling” state and a refresh has been triggered, but data has not yet been re-populated. Also, a last updated date is updated when this happens.

With all of this laid out now, I can write the code needed to make it happen, and create the styles to mimic what currently exists.

The plugin

The first thing I had to do was add the HTML element to the top of the scrolling list that would provide feedback to the user when they pulled the list. After that, monitoring the ‘offsetchange’ event of the scroller element of the list is where the logic of when to show the feedback HTML elements is handled.

this.cmp.scroller.on('offsetchange', this.handlePull, this);

The handlePull method is where the logic went for determining which of the three states we were in. Take a look at my code on Github for all the details – all said and done it’s only 125 lines.

I hope this code proves useful to you in your mobile development projects. This code is available to the public at my Github repository.

https://github.com/VinylFox/Ext.ux.touch.ListPullRefresh

Using the plugin is quite simple, just listen for the ‘released’ event on the plugin and reload your data.

{
    xtype: 'list',
    ...,
    plugins: [new Ext.ux.touch.ListPullRefresh({
      listeners: {
         'released': function(plugin,list){
           // call the plugins processComplete method to hide the 'loading' indicator
           your_store.on('load', plugin.processComplete, plugin, {single:true});
           // do whatever needs to happen for reload
           your_store.load();
         }
      }
    })],
    ...
}

DEMO (Must be viewed on phone): http://www.codetick.com/demos/refresh/index.html

Enjoy!

Trimming The Fat

The default CSS that ships with Sencha Touch is roughly 133KB, which is honestly quite enormous. One way to trim some of the fat is to exclude styles for components, parts of components, or UI features that we’re not using. There are a ton of variables built in that we can set to exclude certain things – some of these can be found in the ‘resources/themes/stylesheets/sencha-touch/default/_variables.scss’ file, and others will have to be tracked down by examining the other SCSS files in the widgets folder. Some of the standard ones include:

$include-form-sliders: false;
$include-floating-panels: false;

Let’s go ahead and modify the ‘_variables.scss’ file to set the two above variables to false, removing the ‘!default‘ flag as well, since we’re going to override this default value with our own. If we poke around in the other SCSS files in the widgets folder, we will will find many more of these variables, such as:

$include-top-tabs: false;
$include-bottom-tabs: true !default;

Adding these variables to the ‘_variables.scss’ file will let us override these settings in a central location. For my usage, im excluding the ‘top-tabs’ by setting the value to false. I’m not using top tabs in my mobile app, so I wont miss them. Now that we’re done with those changes, let’s move on to generating the new CSS.

Generating The CSS

We have made some changes to our SCSS, now we need to generate the new CSS file that Sencha Touch needs by using Ruby, Compass & SASS. I’m not going to get into detail about how to install these things, but I will say that you need to first install Ruby so that it can be used from the command line, then install rubygems and use rubygems to install the compass and haml gems (haml is a dependency of compass, so it’s installed for you).

Generating the CSS from our SCSS files is a simple one line command that is executed from within the resources folder:

D:\Workspace\SpeckleMobile\src\resources>compass compile sass
   exists sass/../css
  compile sass/android.scss
overwrite sass/../css/android.css
  compile sass/apple.scss
overwrite sass/../css/apple.css
  compile sass/sencha-touch.scss
overwrite sass/../css/sencha-touch.css

I have included the successful output as well, which has generated the new CSS and placed it in the ‘css’ folder within our current directory. This will replace the existing ‘sencha-touch.css’ with our newly generated one. There will be no visible change in our app yet, however the file size will decrease. Poking around in the SCSS files in the widgets folder will reveal many more variables that can be set to reduce file size by excluding unused features. Let’s next take a look at altering the color scheme.

Shiny Colors

This is the point where we can really make some drastic styling changes with minimal effort. The ‘_variables.scss’ file has a few options for changing color, but one main color can be used and the rest of the colors are extrapolated from it by altering the saturation and darkening or lightening the color. This main color is aptly named ‘base-color’ – go figure. I’m going to change it to a nice minty green.

$base-color: #8bc531;

After compiling the SASS again, we end up with a very different looking application. We can change the look of the app by modifying this single color and achieve a wide variety of color schemes.

If we go with a very light color then the active color will become so light that it starts to blend with the surrounding colors. To counteract this over-lightening we can adjust the ‘active-color’ variable in the ‘_variables.scss’ file by either setting it to a color we prefer, or adjusting the saturation and darkness.

$base-color: #e2f0cc;
$active-color: darken(saturate($base-color, 55%), 90%);
// $active-color: #212325;

There are also variables to set the active color to an exact color, such as ‘tabs-light-active’ – these can be found by looking at the ‘_tabs.scss’ file located in the widgets folder. A little exploration can reveal a ton of variables we can use to change the styling of our app (I can’t stress this enough). Next, let’s take a look at removing some more bloat by including only the icons we need in our app.

Icons, aka Pictos

The default CSS comes with a couple dozen icons, many of which we will not need in our app. First we need to add a setting to the ‘_variables.scss’ file that excludes this default set of icons.

$include-default-icons: false;

This leaves us with no icons included, so if we we’re to compile the new CSS at this point, all of the icons just show up as square boxes with a gradient in them – notice the generated css file is almost half the size now. Now let’s figure out which icons we need and add them back in one at a time. Take the following steps:

1. Add a scss file to the ‘default’ folder called ‘_my.scss’
2. Edit the file adding ‘@import ‘my/pictos’;’
3. Add a folder in the ‘default’ folder called ‘my’
4. Add a scss file to the ‘default/my’ folder called ‘_pictos.scss’
5. Edit the ‘_all.scss’ file in the ‘default’ folder, adding ‘@import ‘my’;’

That sets up our custom SCSS includes where we can place our extra styling and icons. Edit the ‘default/my/_pictos.scss’ file and add our icons using the ‘pictos-iconmask’ mixin.

@include pictos-iconmask('search');
@include pictos-iconmask('bookmarks');
@include pictos-iconmask('time');
@include pictos-iconmask('favorites');
@include pictos-iconmask('settings');

After compiling our CSS again, we will have our icons back, but only the icons we specifically imported, which brings our CSS file down to 88KB - almost half of the original CSS file size.

Set Forth and Conquer

I hope that leaves you with enough information to get started hacking around in the SCSS files and creating some really cool color schemes and custom styling. Not to mention, trimming some of the bulk off the default CSS files included in the Sencha Touch SDK download.

Let me know in the comments what interesting variables you have found in the Sencha Touch SCSS files.

Enjoy!

This book marks the 2nd book for me, and the 2nd book in the Learning Ext JS series by Packt Publishing. With every page updated, and new pages and chapters added, this book should be an excellent companion to anyone wanting to learn the Ext JS library from scratch.

Updated Content

All of us involved in the first version of this book, Learning Ext JS, returned to update our content based on user feedback, errata, changes in the library, and our own observations. What we ended up with is a very refined book that guides new users through the learning process involved in creating Ext JS web applications. Plus we added some more witty comments and catchy section headings. I just can’t get enough of those.

We were also lucky enough this time to have an amazing technical reviewer Nigel White (Animal) who we brought in as an author to fill in additional sections and clarify technical content. His in-depth knowledge and years of experience with Ext JS have been a great help in making this book as technically accurate as possible.

New Chapters

Probably the most exciting part about updating the book was being able to add in new chapters, three total, for an additional 140 pages of learning power:

• Charting
• Plugins
• Ext Direct

The Charting chapter covers the introduction of charts into the 3.x line of the Ext JS library, implementing commonly used charts in a few key situations, such as Pie, Bar, Column and Line all tied to a data store.

With the Plugins chapter, we go over how Plugin structure works, how they interact with their host component, and create a simple search filter plugin that can be used in any Grid.

In the Ext Direct chapter, we cover how to setup Direct, build the API, route requests and make the API available to client side scripts.

Enjoy!

If your new to Ext JS 3.x and want to get a better understanding of how to use it and how it works, I hope this book finds it’s way into your hands, as I have no doubt it will make your life easier. Drop me a line if you enjoyed it, post a review on Amazon, or just hit me up on Twitter.

There are also a couple of free chapters on the publishers web site, Menus, Toolbars, and Buttons in Ext JS 3.2 and Displaying Data with Grids in Ext JS.

Enjoy! (again)

• Shea Frederick – @VinylFox, VinylFox.com
• Colin Ramsay – @ColinRamsay, ColinRamsay.co.uk
• Steve ‘Cutter’ Blades – @CutterBL, CuttersCrossing.com
• Nigel White – Anti-social, but always accessible on the forums

Call & Scope

So as it turns out, the simple answer is no. The each method uses the call method of the Function constructor to apply scope to the function executed on each pass of the loop. When no scope is provided to the each method, it uses the current item as the scope – which is kinda strange, but whatever.

No Scope

Here is my smart idea – don’t use the call method if there is no scope provided. Simple, and it seems like it would help speed things up, so let’s give it a shot.

Ext.each = function(array, fn, scope){<br /> if(Ext.isEmpty(array, true)){<br /> return;<br /> }<br /> if(!Ext.isIterable(array) || Ext.isPrimitive(array)){<br /> array = [array];<br /> }<br /> for(var i = 0, len = array.length; i < len; i++){<br /> if((scope) ? fn.call(scope, array[i], i, array) : fn(array[i], i, array) === false){<br /> return i;<br /> }<br /> }<br /> };

The basic change here is on line 9 where I check to see if scope was passed in, and decide to either call the function to apply scope or just execute it directly.

// original<br /> fn.call(scope || array[i], array[i], i, array)<br /> // my version<br /> (scope) ? fn.call(scope, array[i], i, array) : fn(array[i], i, array)

Using my current web app as the guinea pig, this version ran between 5-18% faster in Firefox than it’s non scope checking predecessor. Internet Explorer’s results were so far scattered across the board that I could not draw a conclusion – in some tests 50% faster, in others 350% slower. As usual, IE left me confused, so im just going to ignore that for now.

Can We Do Better?

The next thing that caught my eye was the fact that when a single item is passed into the each method, it is shoved into an array and sent through the for loop – this seemed like a place for improvement.

Ext.each = function(array, fn, scope){<br /> if(Ext.isEmpty(array, true)){<br /> return;<br /> }<br /> if (!Ext.isIterable(array) || Ext.isPrimitive(array)) {<br /> if ((scope) ? fn.call(scope, array, 0, array) : fn(array, 0, array) === false) {<br /> return 0;<br /> }<br /> } else {<br /> for (var i = 0, len = array.length; i < len; i++) {<br /> if ((scope) ? fn.call(scope, array[i], i, array) : fn(array[i], i, array) === false) {<br /> return i;<br /> }<br /> }<br /> }<br /> };

In this case I have simply taken any single non array item that is passed in and executed the function immediately, bypassing the for loop. Results of this change were not noticeable, and matched almost identically with my previous version. Upon closer inspection, it turns out that this case is never reached, in other words, there is always an array passed in. Go figure.

Summary

The moral of the story here is to think simple when trying to optimize code, otherwise we end up going to far into optimizing and actually make the code more complex and likely slower, but this does not mean that the code with the fewest characters or lines will be the quickest. Experimenting is fun, so I would encourage everyone to try things like this just to see how they work and in turn gain a better understanding of how the methods you use every day actually work. Priceless.

Code for these tests can be downloaded from my Ext.ux.Misc Git repo on Github.

My next step is to test each loop “unrolling” to see what the effect is…let me know what you have tried on your own, and how it has worked out for you.

These Overrides are a way for us to change the way the base library works, usually because of a defect, but sometimes just because we don’t like or agree with the way something works. Here we are going to cover how to write a basic Override that ‘fixes’ or adds a feature to something in the library.

Why?

The last thing we want to do is edit any of the Ext JS distribution files, such as ext-all.js or ext-core.js, we want to instead apply our changes into the library without touching the library files directly, using the library itself to overwrite specific functions where needed. Editing the library files directly would make upgrading nearly impossible. This is where the Override method comes in to help.

Downfall

Overriding a base function causes an extra maintenance responsibility – a shift of responsibility – simple as that. Though less of a problem than say, editing the ext-all.js file. Every upgrade of the base library (Ext JS) we make requires that we re-examine all of our Overrides to make sure they still sync up with code from the base library, and that the problem were overriding has not been fixed by the Ext JS development team.

Override

Were going to start with an override that adds a feature to the library that we desperately need! Or at least that’s what our boss tells us.

We are adding an option to cascade the placement of new windows based on the position of the previous window. The reason I am adding this as an Override instead of a Plugin or Extension is because im lobbying to get it added as a feature to the library (not really) and when it gets added to the library and I upgrade, I will be able to simply remove my override and continue with life.

The goal is to end up with an no Overrides in your application, by reporting bugs and enhancements to the Ext JS team, and following through so they get fixed in the library.

The Override method of the Ext JS library will take the function(s) we pass to it and overwrite functions of the same name within the component specified. The previously defined function that were replacing are completely removed, and the new ones put in their place.

Two arguments are accepted for the Override method, the first is the class that we are overriding, and the second is an object with the methods we are overriding.

Ext.override(/*CLASS*/, /*METHODS OBJECT*/{<br /> /*METHOD NAME*/:function(){<br /> /*DO IT!*/<br /> },<br /> /*ANOTHER METHOD NAME*/:function(){<br /> /*DO IT MORE!*/<br /> }<br /> });

The Code

We start by copying the source of the original method from the Ext JS source files that come with the SDK download (located in the src folder), in this case it’s the beforeShow method of Ext.Window (in Window.js). Using the source as a starting point, we can modify the function to do what we need.

Ext.override(Ext.Window, {<br /> beforeShow : function(){<br /> delete this.el.lastXY;<br /> delete this.el.lastLT;<br /> if(this.x === undefined || this.y === undefined){<br /> var xy = this.el.getAlignToXY(this.container, ‘c-c’),<br /> pos = this.el.translatePoints(xy[0], xy[1]);<br /> if(this.position === ‘cascade’){<br /> this.x = Ext.winPosx = (Ext.winPosx)? Ext.winPosx+20 : pos.left;<br /> this.y = Ext.winPosy = (Ext.winPosy)? Ext.winPosy+20 : pos.top;<br /> }else{<br /> this.x = this.x === undefined? pos.left : this.x;<br /> this.y = this.y === undefined? pos.top : this.y;<br /> }<br /> }<br /> this.el.setLeftTop(this.x, this.y);<br /> if(this.expandOnShow){<br /> this.expand(false);<br /> }<br /> if(this.modal){<br /> Ext.getBody().addClass(‘x-body-masked’);<br /> this.mask.setSize(Ext.lib.Dom.getViewWidth(true), Ext.lib.Dom.getViewHeight(true));<br /> this.mask.show();<br /> }<br /> }<br /> });

NOTE: Find the source on my Github ExtJS.Patterns repo.

Here it has been modified to add an if statement that looks at our new position config to see if its been set to ‘cascade’. From there we can add 20 pixels to both the x and y axis of the previous window position to place it cascaded. The previous window position has been stored in the winPosx/y properties of the Ext object. The else simply runs the original window position code.

This is all overwriting the original beforeShow method of the Window, which simply placed the window in the center of it’s container. This change applies to every single window that is created, even windows that might be extended from the base window class, it’s essentially changing the source code of the Ext JS library, without touching the source files.

How About Fixes

Fixes are really the same thing, if were adding new features or fixing problems it’s all the same as far as Overrides are concerned, though most of the time an Override would be used to fix a bug. Need I say more?

Summary

Overrides are great for adding features or fixes to the library code without disturbing the source files. Keep this in mind when you run into a bug in the library and need to ‘patch’ it to get things working, or have required features that should be part of the base library. The goal should be having NO overrides at all, which can be achieved by reporting bugs and posting feature requests. Enjoy!

Scenario (our use case)

Our goal here is to create a ‘required’ indicator on all form fields by setting a required flag on the configuration object of each component – in our case, form fields. The code base (the web app) is already in place, so this is a web application that has been completed and is in use.

We have a few options available to make this happen:

• Override
• Extend
• Intercept/Sequence

Lets take a look at the benefits and problems imposed by these methods.

Override

Of course one way to get what we want is to override a particular method in the component were using. If were lucky, there is a stub function in place that we can use, but more often than not, this is not the case. What were left with is having to copy code from the library source files and modify it to fit our needs – not the optimal solution. This means that each time the Ext JS codebase is updated, we need to check the changes against our overridden copy. This is a maintenance nightmare, though there are cases where this is the optimal solution.

Extend (new Component)

The better of our two options is the Extend method. This way creates a copy of the component that we can modify to fit our needs. Not a bad solution all and all. The two problems here are that any components that inherit from our extended component will not get our new functionality, and we now have a copy of the component with a new name, so each place we use that component needs to use our updated component name, ie: ‘mysupertextfield’ instead of ‘textfield’. Again, not a big deal, but if I already have a complete web app, and im adding a bit of functionality to a common component, I don’t want to have to run a find/replace on the entirety of my code.

Meet intercept/sequence

My personal favorite in this situation is to add our functionality either before or after an existing method. The intercept method of Ext JS takes whatever function you provide and executes it right before whatever method in the component you specify. The function we define is also executed in the same scope as the method were intercepting.

Ext.intercept(Ext.form.Field.prototype, ‘initComponent’, function() {<br /> var fl = this.fieldLabel, ab = this.allowBlank;<br /> if (ab === false && fl) {<br /> this.fieldLabel = ‘<span style="color:red;">*</span> ‘+fl;<br /> } else if (ab === true && fl) {<br /> this.fieldLabel = ‘  ‘+fl;<br /> }<br /> });

NOTE: Find the source on my Github ExtJS.Patterns repo.

With this override, we can use the existing allowBlank flag to trigger the required indicator

…<br /> {<br /> fieldLabel: ‘Last Name’,<br /> allowBlank: false,<br /> name: ‘last’<br /> },{<br /> fieldLabel: ‘Company’,<br /> allowBlank: true,<br /> name: ‘company’<br /> }<br /> …

In this case, intercept seems to be the perfect fit, allowing us to add a visual required indicator to each component that is extended from the Field base class. The one downside I see here is that this code is executed every single time a field is created, so be sure to make it lean.

We could also use Sequence to achieve this, which uses the same syntax and concept as Intercept, but executes after the method we define has executed instead of before. The order of execution is like this:

• Intercept
• Method (ie: initComponent)
• Sequence

Summary

I hope this has helped. Over the next few weeks I will be blogging about the many Ext JS patterns available, their pros and cons, and practical usage. Each one will have code paired with it on Github.

DC Meetup Videos

We held the first in a series of meetups that will happen in the DC/NoVA area last week, a sprout of our Baltimore area Meetup for our southern friends, and I have to say that it was a huge hit. The meetups are going to be managed by Pat Sheridan from Three Pillar Global, and we are hoping it will be a way to get JavaScript developers from the DC area more involved in the community. Jay was kind enough to bring video equipment and record our presentations, along with editing the videos and posting them to the intertubes.

There are some photos and other information about the event on its meetup page.

If you are in the Baltimore area and into JavaScript with a fury, you should visit our Meetup that happens the first Wednesday of each month at 6:30PM in the Beehive Baltimore. This month’s meetup has a presentation from Paul Barry about Node.js – it’s gonna be bad ass.

Speed Testing

My little addiction I like to call speed testing has rolled into full swing. Now that I have the tools in place to create and launch tests, along with run reporting on the results with ease, I can pretty much just sit down and spend 30 minutes or so to design and launch the test. I have two tests currently gathering data, one is testing the speed of rendering an image with and without a data URL, the other has to do with the speed of code wrapped in a try catch statement. Should be some interesting results, which I will be posting a summary on soon. My first test was for JSON decoding speed, which I posted results for a couple of weeks ago.

HtmlEditor Plugins

The Ext JS team has expressed an interest in including my HtmlEditor Plugins as a UX in the SDK. This will mark the third development of mine that has become part of the Ext JS SDK download, first it was the GMapPanel UX, then the Grid Filter backend PHP code, now it seems that the Ext JS SDK will finally come with a more robust HtmlEditor example. A few updates have been committed recently that add the option to change the language in these plugins, along with some general code cleanup. Also starting to move my code over to Github as suggested by many.

Books

Soon we will have Jay Garcia’s Ext JS in Action book released in print, and the 2nd edition of Learning Ext JS should be released later this year, titled “Learning Ext JS 3.0″. Cutter, Colin and I got together to update the book, fix some errors, and add new chapters to take advantage of new features in Ext JS 3.0. It’s gonna be an awesome resource for anyone just getting started with Ext JS.

JSConf

Again, JSConf is being held in the DC area, which makes it incredibly cheap for me to attend, but this year I decided to try my hand at submitting a talk proposal. I can’t wait to find out if I will be chosen. My submission was for an introduction to rapid application prototyping using the Ext JS library. Here is my submission:

{<br /> “name”:”Shea Frederick”,<br /> “email”:”________@________.com”,<br /> “twitter”:”VinylFox”,<br /> “location”:”Baltimore, MD”,<br /> “topic_title”:”Rapid Web Application Development with Ext JS”,<br /> “topic_description”:”Discuss general principles of the Ext JS library<br /> and show how easy it can be to rapidly prototype a web application<br /> using the library.”,<br /> “claim_to_fame”:”One of the core contributors to the Ext JS library<br /> along with other Open Source JavaScript projects. Author of<br /> ‘Learning Ext JS’ published in December 2008. Observed ‘Talk Like<br /> a Pirate Day’. Maintain a Blog of JavaScript fun at<br /> http://www.vinylfox.com”<br /> }

Did I mention that all submissions have to be in the form of valid JSON? Yeah, geeky, but good – very good. With any luck, I will find out later this week if ive been accepted.

Now that our new buddy Karl has been properly introduced, lets move on to the boring stuff. I have been trying to optimize decoding of a large chunk of JSON data by testing decoding speeds between the three main methods of decoding JSON and how that applied to the type of data that was being decoded, along with the environment, ie: the browser. My data has been gathering for over a month now, and has run on 3500 unique clients, so I feel like I can come to a decent conclusion.

The Decoded Data

I figured for my testing purposes that there were five main types of data that would be commonly decoded.

• Empty Array
• Empty Object
• Array Data Only
• Object Data Only
• Mixed Array and Object Data

The Decoding Methods

Generally speaking, you will find three methods of decoding JSON used in the wild, though eval is by far the most common. I am not using any decoding/encoding libraries because I don’t want to taint the results with any browser targeted workarounds that might be present in them, I just want to know what the actual browser does.

o = eval( “(” + testData + “)” );

eval – This is the old standard for decoding JSON, which is considered dangerous to use because of its ability to create functions.

o = JSON.parse( testData );

native – The latest and greatest method of decoding JSON, recent browsers include this built in feature. The ‘safe’ way to decode data.

o = new Function( “return ” + testData )();

new function – This method is essentially the same as eval, but uses the evaluating mechanism of the Function constructor to decode data.

In The Wild

I wanted my testing to represent actual usage in the wild, so I used a tool that allowed my tests to run in the browsers of unsuspecting internet surfers. So the results I have can be considered an accurate depiction of what will actually be encountered on the intertubes. If you’re creating intranet sites targeted to a particular browser, then these results should be interpreted differently. Any browser that cannot handle all three methods of decoding JSON was not included in the test, so you IE6/7 guys are out of luck. Also, any browser that has an active console (console object present) was excluded due to the overhead of debuggers (ie: FireBug).

The Outcome

The results are quite interesting, and confusing in some cases. Im guessing there is room for some browsers to optimize their JSON decoding routines here. This first chart shows results grouped by browser make. The X axis in all of the following results shows milliseconds per 1000 repetitions, so smaller is better. Legend colors used in the first graph will continue through all graphs.

This is all good and fine if your a browser vendor and want to know how you’re browser stacks up against others, but in web development we don’t have the option of picking our clients browser. What we want to see is what programming techniques we can use to take advantage of browser efficiency across the board. Which leads us to the next chart, showing results grouped by decoding method

That’s more like it, I now have a clearer idea of how the methods themselves stack up against each other, the red line indicates the average of all the data types.

The Conclusion

Even though the results seem to indicate that native JSON decoding is only mildly faster than eval, its actually a bit faster if you exclude the strange handling of empty objects in Firefox. For the purpose of choosing a method, I think we can draw the conclusion that native JSON decoding is the clear winner here, followed closely by eval, and the function constructor being a general bad idea.

Comparing the browsers for native decoding, Safari is a clear winner here, with our new buddy Chrome losing the race by quite a lot.

Quirks

By far the biggest quirk is Firefox‘s slowness in decoding an empty Object natively, which skews the results, making it appear that native JSON decoding is only mildly faster than eval.

Another interesting result was decoding using eval ran 500% slower with FireBug enabled, while native decoding suffered no degradation at all when FireBug was enabled.

Safari apparently does not handle the function constructor very efficiently.

As a general rule of thumb the straight array data decoded the slowest, so when considering system design, array data should only be used when there is a clear benefit to it.

Feedback

If there are any particular ways you would like to see the data broken out, just let me know in the comments and ill see what I can do.

At 6:30PM on 1/19/2010, Three Pillar Global will be hosting a gathering of industry leading minds in the metro DC area to discuss and share development practices, ideas, tips and tricks revolving around the Ext JS framework. There will be four presentations that are jam-packed with information that can aid to your success in developing applications with the Ext JS framework

About the presentations:

Patrick Sheridan will kick off the meeting, where he will explain how analysis-driven development can aid in the success of your application construction, reducing time from conception to production. Shea Frederick will be guiding us through advanced JavaScript debugging techniques, demonstrating some of the best tricks for the latest and greatest JavaScript development tools. Jonathan Julian is going to share and elaborate on five areas to improve your Ext JS applications, which range from defining your own components to properly overriding the framework. Lastly, Jay Garcia will discuss how to build extensible applications using a two-tiered approach with Ext JS.

Food and refreshments to be provided. We look forward to seeing you there!

About the presenters:

Pat Sheridan is a successful Ext JS developer that leverages his user experience background to accelerate successful development with RIA JavaScript frameworks, including Ext JS. With success stories such as the complete rewrite of the U.S. Treasury’s Pay.gov website and the production of four large RIA applications for the Financial Regulatory Authority (FINRA), he continues to dominate this space with a progressive thought process that enhances the development and user experience alike. He demonstrated his UX leadership with the release of an Ext JS 2.0 OmniGraffle template that has garnered over 50,000 downloads world wide.

Shea Frederick is an active community member for ExtJS. His expertise is drawn from community forum participation, work with the core development team, and his own experience as the architect of several large ExtJS-based web applications. Shea is also an author for JavaScript Magazine, his own blog (http://vinylfox.com), and the Ext JS blog. He is the lead author of the Learning Ext JS book and is the organizer for the Baltimore JavaScript developers meetup group.

While not very well known in the Ext JS community, Jonathan Julian is successful independent web developer specializing in Rails and Ext JS applications with extensive experience in Java and related technologies. He occasionally blogs about software and web development at jonathanjulian.com and tweets as @jonathanjulian. He has presented at the Baltimore JavaScript developers meetup group.

Jay Garcia, author of the up and coming book, Ext JS in Action (http://extjsinaction.com/), provides daily support on the Ext JS forums as well as free extensions and widgets to the library. He is an author for JSMagazine, the Ext JS blog and his own blog at http://tdg-i.com. He’s developed enterprise-level applications using Ext JS since early 2006, when it was known as “yui-ext” and has continued to support and assist in the expansion of the product ever since.