Portland JavaScript Admirers

PDXjs February 2012 Meeting Recap

2012-02-23T00:00:00-08:00

At our February meeting, we went over some ideas for improving the PDXjs website, Howard Leis Ship gave a talk on CoffeeScript, the upcoming CouchConf Portland, 7 Databases in 7 weeks, promise libraries, EventReactor, and analysis of the recently popular Wat video.

PDXjs.com wishlist

A wishlist of possible updates to this site:

live editing for real-time meeting notes
meeting times (currently presented via Calagator widget, that may need some fixing up)
tomorrow’s winning lottery numbers
EtherPad Lite, implemented with node.js, could be used for meeting notes
notes from meetings

CoffeeScript

Howard Lewis Ship gave a talk on CoffeeScript

try-finally is broken in IE7
how does one debug CoffeeScript apps?

CouchConf PDX

CouchConf Portland is coming up on March 14, 2012.

7 Databases in 7 Weeks

The upcoming book, 7 Databases in 7 weeks was mentioned as a good introduction to various NoSQL databases and the reasons for choosing one over another.

Promises, Promises

What is the best promise library for Node.js?

futures.js was recommended
q is another option, with addons in qq
async is another
oath is yet another
EventReactor is another nice tool for working with async code in node and in the browser
stay tuned for a talk on promises at a future PDX.js meeting

Wat

Ryan Munro explained the JS segment from the Wat - the destroy all software video.

{} represents an empty block syntax
Ryan demoed a trick for strengthening the js type system, setting the valueOf function for various JavaScript built-in types to undefined

Other Weirdness

~ is bitwise “not”. -~n can be used to increment a number n that may be undefined

From after the meeting:

Thorax is a framework on top of Backbone
Node-Inspector could be really handy for debugging node.js apps.

Cappuccino

2009-11-08T00:00:00-08:00

This month we had a great detailed talk on Cappuccino, given by Howard Lewis Ship. Cappuccino is a JavaScript framework for creating rich graphical interfaces in the browser. It is an effort by some former Apple engineers and is the flagship product of their company, 280 North. They essentially re-created OS X’s Cocoa library and adapted it to run on Objective-J, a dialect on top of JavaScript that is designed to be similar to Objective-C. The advantage of using Objective-J instead of pure JavaScript is that you can use the Cappuccino libraries with pretty much the same API that you would use when building native Cocoa apps. Real live Cappuccino apps that you can try out are 280Slides by 280 North and almost.at, which is an independent effort.

One of the most impressive points that Howard brought up has to do with Cappuccino’s interoperability with Apple’s Xcode IDE. Xcode includes an Interface Builder tool which acts as a powerful WYSIWYG interface for building graphical interfaces. Interface Builder outputs an XML description of your design called a nib file. Cappuccino includes a tool that can automatically convert a nib file into its Cappuccino equivalent. So you can design your views in Interface Builder and run them in the web browser with Cappuccino in the same way you would expect from a native Cocoa app.

So far Interface Builder is the only component of Xcode that Cappuccino integrates with. But the 280 North team is working on better IDE support in the form of Atlas, their own IDE. Atlas is intended to be a cross-platform tool for building Cappuccino apps. It also happens to be written in Cappuccino. The web site hints that Atlas may include an option to create builds of Cappuccino-based web code that look and feel like desktop apps. It looks like 280 North is planning to use Atlas as their revenue stream since it will be a paid app. The Atlas Developer Beta Program will launch on November 15th.

Cappuccino will be most comfortable to to programmers who have experience with Objective-C and with Cocoa - or NeXTSTEP which is what Cocoa is based on. Howard mentioned that Cappuccino’s documentation can be unhelpful and incomplete. But because Cappuccino is modeled so closely after Cocoa you can generally use Cocoa reference materials instead, which are very complete. Similarly, developing Cappuccino apps will be easiest for Mac users with access to Xcode.

Objective-C was created as a way to bring some of the powerful features of Smalltalk to C programming. In the same way that Objective-C is a layer on top of raw C code, Objective-J is a layer on top of JavaScript. To use Cappuccino’s APIs your classes and methods will have to look like Objective-C code. But within your methods and in your support code you can use pure JavaScript. Objective-J compiles down to JavaScript when a Cappuccino app is compiled. Writing interfaces to Objective-J APIs from pure JavaScript takes a little work but is possible.

Objective-J makes some deviations from Objective-C in addition to its JavaScript foundation. Objective-J has no header files: all of the declarations you need are put straight into code files. And though Objective-J requires you to declare types in your method signatures and instance variables, it does not actually perform any type checking. One pitfall when coming from Objective-C is to try to declare local variables with a specific type. In fact you are required to declare all local variables with JavaScript’s native var keyword. There is also no syntactic distinction for pointers in Objective-J because all non-primitive values are passed by reference in JavaScript.

The advantage of Cappuccino is that you can use it to build very powerful, cross-browser, graphical interfaces quite easily. And you get the advantages of existing tools, like Xcode’s Interface Builder plus proven technologies of Cocoa and NeXTSTEP. If you have experience with those technologies you have a shot at a very smooth transition to building web applications. And unlike Cocoa, Cappuccino is completely open source.

The downsides are that Cappuccino’s documentation is not great, as is mentioned above. Debugging can be painful because the compiler errors that you see will often provide no information as to what the problem is - though Howard recommends using Safari for the least painful debugging experience possible. Because of its Mac roots Cappuccino development tends to be Mac-centric - at least until Atlas is released. Compiled Objective-J code does not appear to be optimized for performance; so Cappuccino apps might not perform quite as well as apps built on other frameworks. And there are some aspects of web programming that do not come up as much in desktop applications - in particular background server communication. Cocoa does not have much support for stuff like that, so you will have to use other tools or build your own solution.

The slides from this talk are online on Howard’s blog. Howard’s demo code is also online on Github.

If you have questions about Cappuccino feel free to post comments here or to send questions to our mailing list.

Sammy and Cross-Origin Resource Sharing

2009-08-02T00:00:00-07:00

Sammy

At our July meeting Scott Becker gave us a presentation on a wonderful tool called Sammy. Sammy is a framework inspired by the Ruby framework, Sinatra, for structuring web applications on the client side. It works on the idea that a rich application can have many different virtual pages in a single browser page. Sammy maps each virtual page to a URL using the fragment portion of the URL do distinguish between different virtual pages in the browser page. For example, example.com/app/#/main and example.com/app/#/subpage could represent two different virtual pages, or ‘actions’.

To use Sammy, you register a series of routes with a callback attached to each route. Routes can be literal strings, regular expressions, or paths with named parameters. Whenever the browser address changes Sammy automatically scans through the list of routes looking for the first one that matches the new page address. When it finds the match Sammy runs the associated callback.

var app = $.sammy(function() { with(this) {

    get('#/', function() { with(this) {
        $('#main').text('Welcome!');
    }});

    get('#/say-my-name/:name', function() { with(this) {
        $('#main').text('Hello, ' + params['name']);
    }});

    get('#/pastries/votes', function() { with(this) {
	$('#main').text('Please vote for the pastry you want at the next meeting.');
    }});

}});

$(document).ready(function() {
    app.run('#/');
}

Mapping URL fragments to different areas of the application means that your users can create bookmarks that go directly to those areas. It also means that the browser back and forward buttons will work as expected even when everything is technically running in a single page.

Sammy can intercept form posts, allowing your application to easily the data submitted without actually sending it to the server. When checking for a route match, Sammy checks the form’s submit method against the method used to register each route.

var app = $.sammy(function() { with(this) {

    ...

    post('#/pastries/votes', function() { with(this) {
        if (params.pastry_type == 'Glazed Donuts') {
            $('#main').text('Excellent choice!');
        } else {
            $('#main').text('Well, we\'ll see.');
        }
        return false
    }});

}});

Sammy even includes support for a templating system. Templates are hosted on the server as separate files. After a template is loaded once it is cached in the browser so that subsequent renderings of the same template will not produce more than one HTTP request.

Here is an example of templating in action from Scott’s slides:

var app = $.sammy(function() { with(this) {
    element_selector = '#main';

    get('#/tasks/:id', function() { with(this) {
        this.task = db.collection('tasks').get(params['id']).json();
        this.partial('/templates/task_details.html.erb');
    }});

}});

Here is what the corresponding template looks like:

<div id="task_<%= task.__id__ %>">
  <h3><%= task.entry %></h3>
</div>

As you can see, templates can come in ERB format where dynamic data is injected on the client side when the template is rendered. Usually ERB embeds Ruby code in a template. But in Sammy’s case it embeds JavaScript code instead. Templates can also be plain HTML if you prefer.

The slides from Scott’s talk are online on Scott’s blog.

Cross-Origin Resource Sharing

Jesse Hallett talked about Cross-Origin Resource Sharing. This is the term for an emerging standard for making cross-site Ajax requests natively, without the need for a proxy.

The recent crop of browsers allow cross-site XMLHttpRequests under certain conditions. Previous implementations of XMLHttpRequest did not allow cross-site requests to reduce the risks associated with cross-site request forgery and cross-site scripting attacks. In order to allow cross-site XHR without making web servers vulnerable to cross-site attacks, the W3C Access Control specification defines a protocol for web servers to speciffy cross-origin security policies.

When the browser sends a basic cross-site XHR request, it includes an Origin header specifying the host, port, and protocol that the request originated from. A compliant server will include an Access-Control-Allow-Origin header in the HTTP response. The content of the response header may be a wildcard, *, if the server accepts requests from any origin for that URL and request method. Or the header may give a whitelist of origins that are specifically allowed. Upon receiving the response the browser checks the Access-Control-Allow-Origin header and if the origin of the request does not match the server’s policy, then the browser blocks the response.

This simple exchange is used for GET requests and POST requests with content types of application/x-www-form-urlencoded, multipart/form-data, and text/plain. It is also required that requests not include any custom HTTP headers. Those are any headers that start with ‘X-‘. For XHR requests that do not meet these criteria a somewhat more complicated ‘preflight’ request is made to determine if a cross-site request is allowed. The browser sends an OPTIONS request to the server specifying the request method, content-type, and custom headers that are about to be sent. The server responds with access control headers specifying which request methods, content types, and custom request headers are allowed. If the server’s policy is compatible with the XHR request, then the browser sends the real request.

If a web server is hosting content on a given URL that is reasonably safe to server cross-site, then the maintainers of the web server may choose a liberal access policy. On the other hand content on a URL that would be dangerous to serve cross-site, such as content that is protected by cookie authentication, would be better protected by denying cross-site requests.

The Access Control protocol takes the approach of a conservative default. If the server does not include an Access-Control-Allow-Origin header in its responses then the browser assumes that cross-site requests are not allowed.

The latest release of jQuery does not support cross-site requests. Other libraries will probably have similar problems. But there is an example online demonstrating how to perform a cross-site request through the native DOM API.

There are thorough explanations of CORS from the Mozilla Developer Center and hacks.mozilla.org.

Firefox 3.5, Safari 4, and Google Chrome 2 implement CORS. Internet Explorer 8 has partial support; but uses a different API instead of extending XMLHttpRequest. It is unclear at this point when Opera will incorporate the standard.

Hopefully someday all browsers will support CORS. In the meantime we need fallbacks for the browsers that don’t. For that Jesse recommends flXHR, which is a client-side proxy implemented in Flash. Instead of using a server-side proxy, requests made in the browser are directed to an invisible Flash movie. The Flash code makes the actual HTTP request and proxies the response back to your JavaScript code.

There are several advantages to using flXHR over other methods for getting around the same origin policy. It is easier to run a client-side proxy than it is to maintain a server-side proxy on every domain you want to make cross-site requests from. Unlike JSONP and CSSHttpRequest which can only make GET requests, flXHR can make any type of request. Unline JSONP, flXHR does not require your application to blindly execute the response from another domain. And flXHR requires much less server-side setup than CSSHttpRequest does.

For the sake of security Flash respects server-side access policies when making cross-site requests in much the same way that CORS works. So to use flXHR you will need to set up an access policy on any servers you want to make requests to. But instead of declaring policy in HTTP headers you will need to serve a special crossdomain.xml document.

There are flXHR plugins available for several JavaScript frameworks - including one for jQuery. The plugin makes use of another jQuery plugin called XHR which provides a registry for pluggable backends for HTTP requests. To make requests through flXHR you will need to pass a transport parameter to jQuery’s ajax methods.

jQuery.ajax({
    url:'...',
    transport:'flXHRproxy',
    // ...
});

Someday soon it would be nice to see a plugin that will transparently make requests using CORS on browsers with the necessary support, and that will fall back to flXHR or something similar in other browsers.

Server-Side JavaScript and Graphics

We spent some time talking about server-side JavaScript for implementing web applications. It would be really great if somebody could give a talk on this subject at an upcoming meeting. But what we know so far is that the new kind on the block is Joyent’s Smart Platform. In addition to running JavaScript the smart platform automatically handles scaling and provisioning. And the platform is open source; so you can run it on your own machines.

There is a standardization going on to make server-side JavaScript code as interoperable as possible. The project behind that is called ServerJS. There seem to be several implementations in the works already.

Mike Leach brought up another server-side framework called Jaxer that allows you to mix server and client logic in a single code base.

We also had a discussion of the tools out there for rendering charts and graphics. Some of the names mentioned were RaphaelJS and ProcessingJS for graphics; and Bluff and Flot for graphs and plots.

PDXjs June Meeting Recap - Agile JavaScript Testing

2009-07-09T00:00:00-07:00

Our June meeting was the first meeting at Kongregate. This meeting was more free-form than most. But Scott Becker talked more about behavior-driven development in JavaScript. He brought up a lot of tools that he hadn’t covered in his previous talk.

Slides from Scott’s talk are online. Scott also drew up this list of links to various tools that are useful for testing JavaScript.

Stuff Mentioned in Presentation

Screw.Unit - BDD framework for JS, RSpec-like
Smoke - mocking and stubbing framework, RSpec-like
Blue Ridge - Rails plugin - tie in JS tests with the rest of your rails tests. Bundles Screw.Unit, Smoke, and env.js.
Rhino - JavaScript interpreter written in Java
env.js - JavaScript-based DOM implementation. Useful for automating tests.
js-test-driver - parallel cross-browser JS test server

Further possible exploration for JS / Browser level testing

JSpec - another BDD framework like Screw.Unit, with cleaner syntax
JSocka - mocking and stubbing, mocha-like
Selenium - browser-driven automated testing; complaints about brittleness of tests
Windmill - browser-driven automated testing
Watir - browser-driven automated testing
Johnson - Headless browser, uses ruby to load your html and execute your javascript. But I’m not sure how flexible / full featured this is.
Celerity - JRuby interface to HtmlUnit, a Java-based headless browser with JavaScript support
Culerity - A bridge between Cucumber and Celerity. Basically re-implementing the webrat helpers to drive Celerity.
Webrat - Selenium driver
FireUnit - JavaScript Unit Testing Extension for Firebug
TestSwarm - Distributed Continuous Integration for JavaScript

PDXjs May Meeting Recap

2009-07-08T00:00:00-07:00

At our May meeting the air was abuzz with preparations for Open Source Bridge. Scott Becker was preparing a topic on behavior-driven development in JavaScript with a focus on using Screw.Unit. Screw.Unit is a spec framework based on Ruby’s RSpec. Scott gave a preview of that talk for the JavaScript Admirers.

Notes from Scott’s talk at OSBridge are online on the OSBridge website.

I was also working on my own OSBridge talk on cluster analysis. Cluster analysis is a statistical analysis technique that is used to find patterns in a data set based on known similarities of elements in that set.

Code from my presentation and slides from my talk at OSBridge are available online.

PDXjs April Meeting Recap

2009-05-06T00:00:00-07:00

This month we heard talks about several new JavaScript features and techniques. Duncan Beevers started off with a talk titled JavaScript Packaging Strategies. He recommends using Sprockets to combine JavaScript files with smart dependency handling. And he says that YUI Compressor is a good way to reduce the file size of the resulting package. Though for best results you will want to combine YUI Compressor with gzip.

The slides from Duncan’s talk are available at http://docs.google.com/Presentation?id=d9nrbm4_80kvp92m5b and the code from his demo is available at http://github.com/duncanbeevers/packaging_javascript_demo/.

Duncan has a fork of Sprockets and a Rails plugin for packaging JavaScript files on Github.

Next up, Paul Point Pen demonstrated the many features of video and audio elements in HTML 5. The native JavaScript API for these elements allows for tremendous control over playback and playback events. For example, you can execute a callback function whenever the user moves the video progress slider. It is also possible to feed video into a canvas and manipulate the results pixel-by-pixel in real time for effects like live green-screening in a browser.

The slides from Paul’s talk are available online at http://html5.waytoocrowded.com/.

Video elements also integrate well with CSS 3 transforms, as you can see in this demo of a circular video element.

HTML 5 is still a work in progress. So browser support for video and audio elements is pretty inconsistent at this point. For example, different browsers do not support all of the same video and audio codects.

Unfortunately the batteries in our camera died part-way through Paul’s talk. So we do not have the very end recorded. I am sorry about that Paul. We will try to do better next time.

Leif Warner demonstrated E4X, which is a nifty new feature in JavaScript 1.6. XML elements can now be expressed as primitives in JavaScript, giving them the same status as strings and arrays. E4X also provides some very handy methods for navigating XML data structures using JavaScript syntax.

Most E4X implementations do not have a way to inject XML objects into the DOM, or to access DOM elements as E4X objects. So to interact with a web page using E4X you need to read in DOM elements as strings and convert them to E4X objects using the XML constructor:

domEl  = document.getElementById('main');
e4xObj = new XML(domEl.innerHTML);

And convert XML structures into strings before inserting them into the DOM:

domEl.innerHTML = e4xObj.toString();

Finally, I talked about one of my favorite JavaScript libraries, Functional JavaScript. JavaScript has all of the necessary features to make it a good language for functional programming - the most important feature being first-class functions. Functional JavaScript provides all of the functions you need to actually write functional programs comfortably. A lot of functions are included, but some of the highlights are map, reduce, curry, and uncurry.

Another feature that is included is the string lambda. Writing anonymous lambdas in JavaScript can get kind of ugly due to the verbosity of writing function(x,y) { return ...; } over and over again. String lambdas are meant to address this issue by creating a mini syntax just for writing small functions. You can write an adding function like this:

'x+y'.lambda();

You can get even more terse by leaving out arguments. The lambda method will assume that operators left out of a binary expression should be filled in with variables. So an add-one function could look like this:

'+1'.lambda();

If you want to do something trickier, you can always explicitly declare the arguments of the function. For example, here is how you could write a string lambda that accepts arguments in a different order than the order in which they appear in the function body:

'x,y -> y / x'.lambda();

All of the functions in Functional JavaScript implicitly call the lambda method on any arguments that are expected to be functions. So most of the time you can express functions as bare strings:

map('*2', [1,2,3,4]);

Check out the Functional JavaScript documentation for more about what string lambdas can do.

I have a fork of Functional JavaScript on Github with compatibility fixes for running in a standalone interpreter, such as the Spidermonkey shell. Here is how you can get Functional JavaScript going in a standalone shell:

$ js
js> load('to-function.js');
js> load('functional.js');
js> Functional.install();

I would like to thank Scott Becker for providing a video camera for us to use. It is a very nice camera, and I think the video quality came out great. Thanks to Scott all of the videos from this meeting are available in 720p HD.

I look forward to seeing everybody again at the May meeting!

PDXjs March Meeting Recap

2009-03-27T00:00:00-07:00

We started of the March meeting of the Portland JavaScript Admirers with a demonstration of ReverseHttp. This is a protocol that allows any HTTP client to act as an HTTP server by receiving requests on a public-facing subdomain. So it allows for a web server written in JavaScript to run in a normal web page.

A useful application of a web server in a page is that provides a flexible way to push data into a client side application. The client does not have to be specially set up for polling; and the program pushing the data does not have to be specially configured to support long-polling connections.

ReverseHttp works through a gateway server. The client code, referred to in a ReverseHttp documentation as the ‘application’, requests some URL space from the server. The URL space can be a path with a unique root, so that multiple applications can register URL space on the same host, or the URL space can be a unique subdomain.

The application next makes a long-polling request to the gateway server on a private URL. The server listens on the applications registered URL space and proxies an requests that come in to the application by embedding the request within the response to the application’s long-polling request. The application composes a response which it sends back to the gateway server embedded in another HTTP request. The gateway server finally extracts the application’s response and forwards it on to the original requestor.

So long-polling is used internally by ReverseHttp. But ReverseHttp has advantages over other solutions that do not require a third-party gateway. It can be used in many different applications to send or receive different kinds of data without any modification to the gateway server. And the data source does not have to be specially outfitted to support long-pulling connections. So you can catch data from a source that was not originally designed to push data to a client-side application.

I set up two demos to show off what ReverseHttp can do. One displays commit notifications from a Github repository in real time. The other is a chat application - a sort of a really stripped down reimplementation of Jabber. The demos are available at http://pdxjs.com:8000/.

Next we heard about Windows Script Host from Rainier Anacker. This is a feature of Windows that allows users to write scripts to automate functions of the operating system. By default scripts can be written in JScript or VBScript - but there are addons that allow scripts to be written in other languages.

When using JScript, operating system features are accessed through calls to the WScript.shell object. The API allows scripts to manipulate running programs, and to send keypresses and control sequences. For example, a script can open Notepad and enter “Hello world” into a new text file.

Rainier demonstrated how Script Host can be used to grab all of the links from a web page and to display them with indexes in a new document. He mentioned that he has also used Script Host to manipulate Excel documents, thus saving a lot of manual work. It was brought up that Script Host is a good tool for automated testing when developing applications on Windows.

For a good reference on how to use Script Host, see Windows 2000 Scripting Bible.

After that we talked a little about ways to get around JavaScript’s same-origin policy for HTTP requests. If you have control over the browsers that will be hosting your application, you can set up a direct socket to a server and expose an interface to that connection to the JavaScript interpreter. Otherwise your options are more limited. You can use workarounds like JSONP and HttpCssRequest - but those only allow GET requests and require server-side cooperation. You can use a server-side proxy to direct requests through. But you have to set up that proxy on your own domain.

Hopefully though the troubles caused by the same origin policy are temporary. Firefox 3.1 - soon to be renumbered Firefox 3.5 - includes cross-domain XMLHttpRequest support. And Internet Explorer 8 also allows cross-domain requests via a new API object called XDomainRequest. The new features in both browsers require servers to include an Access-Control-Allow-Origin HTTP header in certain responses to indicate that they accept cross-domain connections - as described in this W3C working draft. Hopefully similar features will appear in other browsers in the near future.

Finally we spent some time talking about neat things that can be done with HTML 5 and newer versions of the DOM API. We looked at Chrome Experiments, which is a Google-sponsored repository of JavaScript demos that push the limits of what JavaScript can do. We also looked at Raphaël, which Merlyn brought up as a cross-browser-compatible tool for rendering vector graphics. And we drooled a little over querySelector and querySelectorAll. querySelector and querySelectorAll These are new methods that are being added to the DOM API. They add jQuery-like selectors to the native API. For example,

document.querySelectorAll("#large:nth-child(even)");

querySelector and querySelectorAll are already included in Safari 4, Firefox 3.1/3.5, IE8, and Opera’s Acid 3 build.

All in all it was a fun meeting. I am already looking forward to the next one!

A Wanderer @ CubeSpace

2009-02-25T00:00:00-08:00

Portland JavaScript Admirers have convened for a second time. There’s a mailing list, a web site, plus you can follow on Calagator. We meet at CubeSpace, Portland’s geek HQS (for software – not competing with Free Geek). Ad: Women’s Networking Group meets in Roman on second Tuesdays. read more

PDXjs January Meeting Recap

2009-01-29T00:00:00-08:00

The inaugural meeting of the Portland JavaScript Admirers was a big success. We started off the evening with a round of introductions.

After that we listened to several talks on the fine language that is JavaScript. I pulled out my copy of JavaScript: The Good Parts by Douglas Crockford and went over some of the tips from the book on how to write great JavaScript code. I focused on how and why to avoid global variables - which can sneak up on your JavaScript code if you are not careful.

For example, you may know that variable declaration in JavaScript is optional. But did you know that variables that are not declared become global?

Another tricky case is the this keyword, which is used in method definitions to access attributes of the object that the method is attached to. But this is actually re-assigned every time the method is invoked. So if the method is invoked as a function instead of as a method, i.e.

var f = object.method; f();

instead of

object.method();

then this is assigned to the global object for the execution of f. So any attributes set on this then become global variables, and any attributes read from this are read from the global namespace instead of from object.

The code examples that I am pointing at in the video are online at http://gist.github.com/64478.

Scott Becker told us all about the features of SproutCore, which is an MVC framework for browser-side applications. Among other things, SproutCore allows you to set up models for your data, which can act as an intermediary to transfer data to and from a server, or that can store data locally using something like Google Gears. Changes made in the model data automatically update data in your views, and vice versa, through the use of Key-Value Coding. Instead of directly accessing attribute values, you use object.get(key) and object.set(key, value). This allows SproutCore to do all kinds of magical stuff for you.

Views in SproutCore are things like forms and form elements, buttons, file selectors, and content areas. Instead of using the browser’s form elements and buttons, SproutCore renders these as images to achieve a very slick-looking interface that is consistent across all browsers.

Using Key-Value Coding with views, you can do stuff like get input from your user via a form, and display a live preview of the content he enters that is updated in real time, with very little work on your part.

Unfortunately the batteries in our camera died partway through Scott’s talk. So there are a few minutes missing from the middle.

The slides from Scott’s talk are online at http://www.slideshare.net/joydivider/sproutcore-a-next-gen-javascript-framework.

I went over the new features in jQuery 1.3. Many speed improvements have been made in this release. For example, the selector engine is 49% faster. And HTML injection into the document is a blazing 6 times faster. The new, faster selector engine has been broken out into its own project called Sizzle.

This release also includes a complete rewrite of the event system. In addition to the bind method for binding event handlers, jQuery 1.3 supports the most excellent live method. Using live, your event handler will be bound to all elements on the page that match a given selector, and any elements that appear in the future that match the same selector.

jQuery events are now a self-contained system layered on top of native events. And the whole thing is compliant with W3C protocols for event handling.

I also gave an introduction to jQuery in general for those who are not familiar with it. And we had a lively group discussion on why people might prefer jQuery over alternative libraries, like Prototype.

Finally, J. Chris Anderson graciously jumped in to give us an introduction to CouchDB, a document-oriented database. CouchDB stores all of its data as JSON. There is no schema, and there are no tables. Queries are performed using the MapReduce pattern and can be written as stored JavaScript procedures.

Because it is schema-less, CouchDB is not a great choice when you need a lot of relational features, like joins. But in cases where you have been frustrated by SQL, CouchDB can be a great choice. It excels at serving up very large datasets with a high number of concurrent queries.

J. Chris is a CouchDB developer, and is one of the authors of CouchDB: Rough Cuts Version. We will hopefully be seeing another talk from him on using CouchDB to create pure-JavaScript applications.

At the end of the evening we retired to the Green Dragon for drinks. (Video suppressed.)

If you are having any trouble with audio syncing in the flash player, I suggest downloading the MP4s directly. Click on the title in any of the videos to go to its page on Vimeo. There you can find the file download link in the lower-right area.

Admiring Javascript

2009-01-28T00:00:00-08:00

I’m at the first Portland JavaScript Admirers, well attended, geeks cheering for CubeSpace. We’ve got lots of independent contractors, including my Hewlett-Packard friend from Pythoneers (how I’m logged in, wearing the fleece), whom I also invited to our Ruby meetings, first Tuesdays. read more