document.ready with jQuery Mobile

One of the first hurdles I had with creating sites with jQuery Mobile was figuring out how to run my code when a page loads.  Since navigating to a new page no longer requires a postback, the standard $(document).ready approach isn't going to cut it.  I've come up with a solution that I think helps you modularize and isolate your code to prevent having one large unmaintainable lump of a javascript file.

Creating a Namespace

Now when I work on javascript heavy applications, I take care to modularize my javascript but I don't necessarily follow the pattern exactly.  I start out by creating a namespace object, and I usually place this in a file called core.js.

https://gist.github.com/1246402.js?file=ready.core

So, what we're doing here is creating a blank object (MYAPP) to "scope" our application objects.  We extend that object with some new objects to hold our pages and maybe even some options.  We would also maybe put some other stuff in here, but for this example we'll keep it mostly clean.

The Page Event Mapper

Now it's time to do some plumbing work to hook the new page objects we are going to create up to the jQuery Mobile navigation framework.  We want to pass the page events from jQuery Mobile to a page class that will handle the events.

https://gist.github.com/1246402.js?file=ready.navigation

Every page in jQuery mobile is wrapped in a div with a data-role attribute set to "page", so what we're doing here is handling the jQuery Mobile page events and passing them to our corresponding page.

A Page Class Example

Speaking of pages, let's take a look at what an example page looks like in my code.

https://gist.github.com/1246402.js?file=ready.homepage

As you can see, I've kept the code pretty simple.  This class will now be able to respond to init events (which get fired before the page is modified by jQuery Mobile) and the show event which gets fired every time the page is navigated to (even when it's cached and navigated back to).

But Don't Take My Word For It

If you want to give a try for yourself, head on over to the jsFiddle I set up with this example code already set up.

Now Playing: Nas - It Ain't Hard to Tell (Reading Rainbow Remix)

_

On Windows 8 Metro HTML Apps and the Web Developer Ethos

 

Ethos (noun): The characteristic spirit of a culture, era or community as seen in its beliefs and aspirations.

TL;DR: I hear a lot of people talk about the what the value of offering a way to create "Metro" style apps for Windows 8 using HTML and Javascript is, and I disagree.  I believe the common web developer has a different value system than what the Win 8 "Metro" environment encourages and as a result not many people will end up using the HTML options for creating "Metro" apps on Windows 8.

Current Web Development Values

 - Optimized javascript and css for fast page loading.

     - Combined, Minified JS and CSS

- Load from CDN, fallback to local

 - Simple, short javascript code

 - Reactive and Responsive to different devices.

 

I'll take some liberties and really just boil these down to the following:

 - Fast Page Loading

 - Simple Code

 - Platform Agnostic

Fast Page Loading 

As a web developer I have certain performance implications in mind when I organize my site and its resources.  I like to minify and combine all my script and css files for quicker loading along with loading certain libraries from CDN rather than locally to take advantage of Caching.  The examples I've seen so far tend to have about 87 obscure scripts loading in the head of the page and it makes my face twitch every time I see it.

Simple Code

The WinJS and WinRT namespaces are insanely long and ugly to use.  Again, the average to elite js developer has it ingrained to limit the size of their javascript files for performance.  Using something like WinJS.Class.define(...) or some of the other longer examples for subscribing to certain app events like startup is going to turn off developers to creating apps.  The good thing is that this could be fixed by someone just wrapping all that stuff up in a shorter namespace utility library ($win sounds good).

The javascript examples I've seen so far tend to degrade into this monolithic amount of JS in one file.  There needs to be a better story for architecting javascript heavy solutions.  I think the .Net world isn't used to this type of project yet and it would have been nice to see MS give some guidance about managing them in a responsible way.  I'd like to see a convention based solution that encourages a module + export pattern for managing the complexity of javascript code.

Platform Agnostic

I'll start out by saying that it's unfair when I see people comparing the Metro app development with developing a website.  This is a native app and as such will have a heavy reliance on the underlying platform.  The better comparison for development is that of a ChromeOS application.  On the other hand ChromeOS application doesn't have the same heavy importance on a radical theme/styling for apps like Metro apps will.

Host enforcement rules add an extra layer of security for "Metro" HTML apps by only allowing "safe" html and javascript references.  Host enforcement rules add an extra layer of security at the expense of clean and easy to implement javascript.  The fact is that most web sources are going to not have "safe" html (especially since most data- attributes are considered harmful).

That's all I have for now as far as notes, I'm sure I'll tidy this up a bit for a more official review later on when I've made a couple apps.

Now Playing: Mt Eden - Gambler

_