Archive for the 'Conferences' Category

Conferences, etc.

As some of you may know, I was at The Ajax Experience conference last week, along with the one-day mini-conference, jQueryCamp.

This was my third The Ajax Experience, and there were a lot of great people to see. Even more exciting though, was jQueryCamp, despite forgetting my t-shirt in Boston.. The accommodations were especially wonderful ;) (that’s code for… I crashed on John’s couch. Thanks John!)..

I met most of my fellow core team members, which I’d really been looking forward to, along with a slew of jQuery geeks and gurus. Karl, Jörn, Bradley, Marc, Paul, Rey, Richard — just to name a few. I hope to post more about jQuery camp — the talks, etc. — when things get a bit calmer… if ever they do.

(As a side bonus, there were a few Merb folks around — what more could I ask for?!)

There was a pleasantly enthusiastic response to jQuery in Action; lots of people with comments, reading the Early Access version, and lots of people looking forward to it. I’m feeling good about it!

I’ll be at RubyConf in NC this weekend. There are a lot of people I’m looking forward to meeting there, and talks of some Merb hacking.

There’s nothing like putting faces to the IRC folks I talk to every day, the blogs I read, etc. There are also some old friends I’m looking forward to seeing again. Stephen Bristol, ReinH, Evan Phoenix, Jeremy McAnally, Ezra Zygmuntowicz, Dr Nic Williams, and so on. Leah (the wife) will be joining me at RubyConf too, so that’s always a bonus — and I know there are lots of people she’s looking forward to seeing too.

Do drop me a line, or comment, if you’ll be around. Would love to see everyone. Safe travels!

Give JavaScript 2 a Look

Last week, I attended a talk on JavaScript 2 by John Resig. John wrote jQuery, and is now the JS evangelist for Mozilla, which is pushing JS2 along with Adobe and Opera.

Before the talk, I was fairly ambivalent about the new language. In the abstract, it has the ability to inflict pain on us humble JS developers if the upgrade path is too problematic, and there are a whole load of language features that aren’t obviously interesting (again in the abstract).

John’s presentation was, in effect, a Keynote version of the recently released Ecmascript 4 Language Overview Whitepaper, which was released by Adobe, Mozilla, and Opera, three members of the ECMA working group.

The presentation was incredibly code-heavy, and very interesting. As it currently stands, the EcmaScript 4 draft attempts to provide a class structure to EcmaScript 3 (ES3), without breaking backwards-compatibility with ES3, similar to the way C++ added classes to C while preserving back-compatibility.

Since one of the major goals of ES4 is to remain compatible with ES3, existing code will continue to run, and be progressively enhanced by using new features in ES4. The new classical system will exist side-by-side with the old prototypal system, and the new strongly typed system will exist side-by-side with the old weakly typed system.

Here are some examples:

Strict typing in ES3

function(x, y) {
  if(x.constructor != Number) throw TypeError();
  if(y.constructor != String) throw TypeError();
  // code
}

Strict typing in ES4

function(x:Number, y:String) {
  // code
}

The former pattern is extremely common in ES3, so the new feature will simply provide a language-supported way to do what you’re already able to do with functions. That said, the type system has some interesting features:

  • Union types: var x:(int, string)
  • Nullability: var x:int! only accepts an int, which cannot be null
  • *: var x:* is equivalent to the ES3 var x

Remaining variables in functions in ES3

function(x, y) {
  var rest = [].slice.call(arguments, 2);
  // code
}

Remaining variables in functions in ES4

function(x, y, ...rest) {
  // code
}

Again, ES4 simply makes a pattern that is extremely common in existing use simpler and more error-proof. And again, nothing stops your ES3 code from continuing to work.

The classical system

ES4 provides a new classical system, including real Classes, Inheritance, and Interfaces. The classes can be defined as dynamic (similar to ES3 classes, in that properties can be added after the fact), or non-dynamic, which throws an error if a programmer attempts to add a new property. A quick example:

class Foo {
	var bar;
	var baz = 7;
}
var x = new Foo;
x.bat = 12 #=> throws Error

But with a dynamic class:

dynamic class Foo {
	var bar;
	var baz = 7;
}
var x = new Foo;
x.bat = 12 #=> sets x

So you can use dynamic classes to give more structure to existing “classes”, and non-dynamic classes to lock down created classes from further change.

Inheritence

Inheritance in ES3 is done via the prototype chain. You might do something like this:

var Foo = function() { }
var Bar = function() { }
Bar.prototype = new Foo();

In ES4, inheritence is more explicit:

class Foo {}
class Bar extends Foo {}

Non-overridable functions

You can prevent classes from being inherited from, or methods in classes from being overridden using the final keyword, as follows:

final class Foo {}
class Bar extends Foo {} #=> throws Error
class Foo {
	final function bar() { }
}

class Bar extends Foo {
	function bar() { } #=> throws Error
}

Summary

I touched on only a few of the new features in ES4. For the most part, these features could be implemented using ES3 (and there are a number of examples above), but the ES3 counterparts are often verbose and repetitive. I encourage people who are interested in the language to read through the white paper. It’s surprisingly readable for a language spec, and describes a fair bit of motivation.

For people who currently write a fair bit of JavaScript code, I hope you’ll see the new features in ES4 as encapsulations of current, common patterns, and solutions to problems that arise when attempting to develop large systems using JavaScript.

Finally, the current draft is certainly not perfect, but it is a solid core for the next revision of the language. If there’s something you don’t like, feel free to join the ES4 discussion list and raise your concerns. A healthy discussion with more developers will help move the process forward, and away from the back-room politics that is currently miring it.

RailsConf Talk Recap

There was a great turnout at the jQuery talk at RailsConf yesterday (packed house!), mostly not jQuery users, but hungry for an alternative to Prototype.

At the session, I explained what I thought were some seminal differences about the way jQuery works as opposed to using built-in helpers:

  • jQuery prefers passing *data* — not code. In other words, a jQuery-friendly action will pass back JSON data, to be processed by a jQuery callback, while RJS (Rails’ preferred method), sends back code to be executed by the client. Sending back data makes for a skinnier pipe needed to accomplish the same thing
  • Unobtrusive thinking is incompatible with Rails helpers that are dumped in the middle of views. Even going the UJS4Rails route, requiring code to be inserted in the views that they refer to violates unobtrusive principles and mashes together behavior and content (even though the CLIENT sees the code separately, UJS is a design philosophy, not a compile-time philosophy).
  • Using server-side JavaScript (RJS) leads to a reliance on the server to maintain state (or at least, a reliance on the server to tell the client what to do), but many RJS’ers end up making extra trips to the server to compensate for their lack of client-side code
  • Rails works exactly the same as any other server-side framework from the perspective of the client. From that perspective, requests are made of the server (via Ajax) and responses are returned. Rails can make returning responses saner via respond_to and to_json but it’s fundamentally a communication that can be easily understood in a server-framework-agnostic way.
  • Last but not least, it’s worth your time to learn JavaScript even if you’ve been putting it off. Learning the basics of jQuery shouldn’t take more than an hour, but it’ll be an hour that’ll free you from having to worry about how someone else implemented a JavaScript helper and bring you closer to a saner design philosophy
  • Again, I’m really happy about the turnout at the session and I hope to be posting more about Rails as well as the release of jQuery on Rails real soon :).

jQuery on Rails: A Fresh Approach

My apologies for dropping off the face of the earth. I’ve been working hard at Procore, which I mentioned last time, and getting neck-deep in the specific problems that make working with jQuery and Rails at the same time so difficult.

Since I last publicly discussed jQuery on Rails, I’ve gone down a lot of avenues, and written a lot of code, and came to some conclusions:

  • jQuery and Unobtrusive JavaScript are fundamentally incompatible with an attempt to describe behavior inside markup, as Rails does via “JavaScript helpers.”
  • Attempts to fix the problem, specifically UJS for Rails, still require that you include your JS behaviors in your views, which are then marshalled into JavaScript files on the fly (and cached as appropriate). If you wanted to include the same JS behavior in multiple pages, you’d need to create custom helpers and call out to them.
  • jQuery is already the perfect mechanism for unobtrusive JavaScript, baked right into the library
  • The biggest problem faced by jQuery developers is not simplicity (which, again, you get for free in the library), but difficulty in including the correct jQuery “modules” in the Rails views that require them.

The most common problem with using jQuery with Rails in an app of moderate or higher complexity is the trade-off between including everything in a single application.js (which can lead to serious slowdowns in larger apps) and having multiple, modular files (which are a serious pain to include correctly as needed).

This is a problem for jQuery users who want to use Rails more than Rails users who are used to Prototype helpers and want to be able to use the jQuery library as a drop-in replacement. In the first release of jQuery on Rails, I will be targeting jQuery developers who want to work with Rails. In other words, jQuery on Rails is for you if you know jQuery or are willing to use jQuery.

This release of jQuery is not for you if you don’t want to learn jQuery, and want to program purely in Ruby. There will be a future release that will include some features for pure-Ruby developers, but I maintain that Unobtrusive JavaScript is fundamentally incompatible with that mode of thinking.

With all that said, what does jQuery on Rails actually do?

First up, it’s a Rails plugin, which you activate by adding <%= include_jquery %> in your application.rhtml. When your server is started, it’ll parse all of your JavaScript files, and identify selectors in those files. When include_jquery is called in your layout, it’ll get the rendered HTML and use Hpricot (which shares syntax with jQuery) to determine whether any instances of the selectors identified on server startup are present.

The JavaScript files that have selectors that are also present in your HTML will be loaded, and run as expected.

So in short:

  • Create your JavaScript files, using selectors as usual
  • Use include_jquery in your layout
  • You’re done

I’ll be demoing the code at RailsConf tonight and should be releasing the first beta version sometime in the next week. If you’re at RailsConf, check out the Birds of a Feather presentation at Room c122 at 9:30 pm tonight.