Archives

HTML5 i.e. HTML is a markup language. As such, without JavaScript, developers would be reduced to hand-rolling HTML or creating it dynamically server side – page view by page view. Being constrained by page views is something I fundamentally refuse to accept since I am not in the printing industry. I’m in the computer interface industry. I demand programable interfaces.

What comes to your mind when you think about a computer interface? No, really, let your imagination run wild. I think of Minority Report gestures and the latest Tron. It was made as a geeks wet dream. Now fly back down to page views. That’s a hard landing.

And for whatever reason, “the Internet” comes with Javascript today. How we got here is for historians. It is here now and it provides programatic control at client runtime. That’s the card that trumps them all.

To make a digression, my beloved ActionScript used to look a lot like JavaScript before we got all fancy with AS3 and haven’t looked back. And people created amazing things with it. Just like today people create mind-blowing things with JavaScript. For a decade I was basing arguments for Flash on Internet penetration percentages. Now we have rediscovered JavaScript that was here all the time.

What I’m missing in HTML5 today is developers time. The ones that are spending their time whining about JavaScript shortcomings. I miss you here and now building great things in JavaScript together with me. I miss you in making the Internet better.

Let me give you an example. SVG is supposed to be an Internet standard. Well, it really is but Microsoft didn’t find that important until recently, so we really don’t have complete browser compatibility. So what is a gal to do?

Should she:
a) Drop SVG altogether because IE doesn’t support it.
b) Create a fantastic JavaScript library and jump through a number of hoops and make SVG available for all browsers, popularizing it in that way in hope that one day it becomes a fully supported standard.

Dmitry Baranovskiy did the latter when he created RaphaelJS. You could start noting the shortcomings of his solution or you can simply recognize that Dmitry made it happen.

Go make something happen!

I love PureMVC because of the simple idea behind it. Have Model-Viewer-Controller pattern that can span languages and therefore time, as explained in this article by Clifford Hall. I started using it in the Flex world when it was competing with Cairngorm for that very reason. Cairngorm was Flex specific and PureMVC was language agnostic.

Coming form a mostly strict-typed MVC environment, it was very hard for me to even start thinking about big scale applications in JavaScript and HTML5 which were reserved for widget type implementations for a while.

As a natural progression of the idea behind PureMVC, it started being ported to JavaScript frameworks that emulate classes through an effort of great folks like Frederic Saunier, Justin Wilaby, Tony DeFusco and David Foley. Music to my ears! Heck, there is even an ongoing ‘native’ JavaScript port.

I decided to see if the story holds and lately I have had a great experience with the MooTools implementation of PureMVC. It feels very familiar. File structure is the same, meaning well organized with recognizable command, model and view folders that imitate packages. I use ANT to combine these files in two varieties. One just plain stacked for debugging and the other compressed using YUI Compressor for production.

There is also something magical about working with PureMVC. It feels far more like solving a workflow puzzle than coding by knowing that the same PureMVC based program can be fairly easily ported to another language and in that way have longevity. Kinda leads you to think that programing is most about managing workflows of user experience.

This setup is enough to make me feel comfortable as a programmer about big scale applications developed in JavaScript. Which begs a question: “Why would you want to develop big scale applications in JavaScript?”. Because I want to share the fun.

You can read about the PureMVC developments for JavaScript here.

With the release of Google’s Closure Tools comes the perennial misunderstanding of what a compiler is. When we have a compiler that takes in C or C++ code (pick your poison) and produces machine code for a particular chip, it’s clear that the output is not the same as the input. But when you have a JavaScript to JavaScript compiler that’ supposed to make the resulting code more “efficient,” it may be tempting to think of it as something just like a compressor, like Packer.

Google has release Closure Tools, the set of tools they used to write applications such as Gmail. What is it? It consists of three parts:

1. A compiler which is a “JavaScript optimizer that compiles web apps down into compact, high-performance JavaScript code. The compiler removes dead code, then rewrites and minimizes what’s left so that it will run fast on browsers’ JavaScript engines. The compiler also checks syntax, variable references, and types, and warns about other common JavaScript pitfalls. These checks and optimizations help you write apps that are less buggy and easier to maintain. You can use the compiler with Closure Inspector, a Firebug extension that makes debugging the obfuscated code almost as easy as debugging the human-readable source.”

   So it compiles JavaScript into JavaScript and makes it behave more like a statically typed language.

2. A library which contains both widgets and datastructures and algorithms. Sort of the standard library that JavaScript was always missing.
3. A templating system you can use to assemble a user interface.

Since this system has been in use at Google to develop real applications over a long period of time, I expect it to be a fairly robust system. In many ways it solves some of the same problems that GWT is trying to solve, but in a different way.

I’ll see if I can kick the tires over the weekend and post about it next week. So many cool tools and frameworks, so little time…

I had to dig into a production issue the other day that presented itself like this:
There was a piece of javascript code that iterated over some dom elements, gathered ids into 2 arrays, ran a validation check, and then flattened the arrays to add them to the url.

On firefox, opera, and chrome this was working correctly, and had been tested by the developers, but on IE 7 it isn’t working, and the problem wasn’t detected until it made it out to production. (Which raises a point about testing in IE during QA, which I’ll get to in a sec).

I started my investigation doing what I’d call “poor man’s debugging”, putting some alerts in, breaking up the code a bit to make it easier to inspect, etc. Normally I don’t do this when testing in Firefox, because I have Firebug, but in IE I always seem to start with the basics to get my bearings, then quickly move to a more pragmatic approach.

Then I started using firebug-lite, confirming that I can see the info I need, and I reverted my changes to the code so that I could verify that I hadn’t introduced any issues.

The Chicago JavaScript Meetup Group spurred more than 50 of its members to brave harsh weather Thursday night for the group’s fourth free get-together since its founding last October.

Organizer Vlad Didenko led the charge with an in-depth look at Firebug, while assistant organizer Justin Meyer contributed a discussion of Ajax fundamentals.

I’m as geeked about jQuery’s 1.3 release as the next developer. But I’m even more excited about the new API browser developed by Remy Sharp and available here.

For as long as I’ve been a jQuery user – going on 18 months now – I’ve been frustrated by the slow speed and sometimes intermittent availability of the jQuery documentation site. Now we’ve got a blazing-fast API browser that presents jQuery Core and jQuery UI side by side in the same cool interface. Better yet, it’s available as an Adobe AIR app for offline viewing. Sweet!

I could quibble about the lack of bookmarkable URLs and the occasionally sparse documentation of corner cases. Instead, I’ll just remain upbeat about this huge step in the right direction. No matter how intuitive jQuery’s API, it’s a powerful library whose roster of methods continues to grow. Nothing speeds up development faster than quick, persistent access to quality API documentation.

jQuery celebrated its third birthday Wednesday with the release of the brand-new 1.3 version. This latest release includes a bunch of cool new stuff which has already been discussed to death elsewhere. To me, however, the most interesting aspect of jQuery 1.3 is the movement of former plugin functionality to the core library.

Live events are a new twist on the venerable, and indispensable, Live Query plugin, while the upgraded, more granular effects queues were previously tackled by add-on authors. IMHO, this kind of migration is A Good Thing, providing greater parity with other core JavaScript and effects libraries (such as Scriptaculous’s FX queue) while offering compelling feature differentiation (event binding throughout the full lifecycle of an Ajax page).

If you’re using prototype (or rails, which uses prototype by default), you’ve probably seen this javascript error before:

handler is undefined

While not particularly threatening (no ill side effects seem to occur), the error causes a lot of noise and, quite frankly, is pretty annoying. Fortunately, there is a quick and painless patch to keep your error log free from this bane.

At Pathfinder we do a fair amount of desktop style development — iPhone/Cocoa, WebForms, Swing — and web application development — Grails, Rails, JSP, ASP.NET, etc., etc.. In the last two years we, like a lot of other software development shops, have experienced a convergence in our efforts. The web is coming to the desktop in the form of Air and the Desktop is coming to the web in the form of RIA’s. Now web MVC, which used to be a pretty benign pattern mostly concerned with app flow and validation, is starting to resemble desktop MVC, which has to deal with document-centric models and long lived views and all of the plumbing that requires.

So we recently had a powwow between all the different parties to talk about MVC and this convergence. With the exception of the insufferable Mac and iPhone developers and their disgustingly mature Cocoa framework, we all agreed it would be nice to have an application level MVC framework for each platform. We also agreed that Swing is a great example of what happens when the vendor doesn’t provide such a thing — spaghetti code that relies on component level MVC and hard wiring at the application level. There are a few MVC frameworks for Swing, such as TikeSwing and Spring Rich Client (soon to be superseded by Spring Desktop), but for every Swing app that has this sort of design, there are hundreds that are just a mess.