Ext, an awesome JS toolkit

This post is for people making a fat web client. If you are going to be doing something small and a little more sane, then this post isn't for you. Turn around now. If you've considered creating a web app with flash, keep reading.

Ext is a toolkit for creating a web gui with javascript. It's for creating something like yahoo's new mail app. You create accordion panels, forms, fields, everything from javascript. You can use markup, but that will actually make more work for you. It's best just to let the library work it's magic and accept what it's got.

And, man, does it have a lot. It's got client side validations, data readers (more about them in a second), grid controls with built in searching and column sorting. Really, if you've thought about making an actual web application then I highly suggest you look at Ext.

Data readers are where it's at in Ext. Say you prototype out a simple contacts search. You might have a form where you can search by their first name, last name, or zip code. You send up your search query and get back a chunk of code that has the matching contact information. Prototyping that can be difficult if you are using static HTML but if you and Ext DataReader you can put in test data that your form will be populated with once the search is completed. This DataReader object will accept data in several formats including XML and JSON.

It gets better. The DataReader object can also take a url. So it is possible to prototype out your view and test it with the exact object and type of data it would normally use. Then, when you have your controller serving up the data in the format you need, you point your DataReader to the correct url and you're done.

This is great when you want a clear separation from your models and your views. This is exactly what I blogged about earlier. This lets your front end developers not have to worry about the back end and let's your programers do what they are good at: coding. 

A Great Smurfing Idea

Just to show that this blog isn't all about doom and gloom, here is a much lighter post.

Sitting around with some work friends we started talking about compilers and writing a language. We somehow stumbled upon creating a computer language based off of the smurfs. Hear me out:

Threading would be built in by default. You application would be the Smurf_Village and each thread pool would a Smurf_Mushroom. This seems to lend itself to a message passing system between Smurf_Mushrooms. So each Smurf_Mushroom, and perhaps Smurf_Village, could talk to one another by Smurf_Letter.

The language would be object oriented. Every object would inherit from the root object, Papa_Smurf. New objects would be named based on what they do. So you could have Jokey_Smurf, Brainy_Smurf, Miner_Smurf, etc. So what/who would create all these other Smurfs? Why, Smurfette of course. She would be in charge of creating new Smurfs and putting them in their Smurf_Mushroom.

At some point you need to join your threads and get a result. Azrael would wrangle up all the Smurfs to supply the answer. At some point your Smurfs will need to die and the memory re-allocated. Gargamel would be the Smurf garbage collector.

What do you guys think? What's missing from this Smurf language?