Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Archive for the ‘Conferences’ Category

MerbCamp

Just a reminder folks: MerbCamp is October 11-12.

The conference is going to feature a large number of short talks about various features of Merb, as well as keynotes by Ezra Zygmuntowicz, who originally wrote Merb, and me. I’ll be giving the closing keynote about the future of Merb, as well as short talks on testing and jQuery.

This is going to be the biggest gathering of Merb folks thus far, but tickets are selling out fast. Register today!

Files from my talk at @media

I have uploaded the files that I will use for my demonstration at @media. The slides will come later today after my talk. The easiest way to browse the files are via github. You can either browse the files online, get them via git, or download a tarball of the entire thing.

If you’re at @media, feel free to download the files and follow along.

RailsConf Europe Slides

Hey guys!

My RailsConf Europe slides are up :)

http://yehudakatz.com/wp-content/uploads/2008/09/rce-jquery.pdf

If you were at my talk, please log into your account at O’reilly and rate it. Thanks!

Rails is a Pre-Fab House

At RailsConf, I had the opportunity to speak to a lot of people about Merb. I also listened to DHH’s keynote, which touched on some related concepts.

People coming from a Rails background, and are looking at Merb for the first time, wonder why they should throw away the phenomenal efficiency improvements they got from switching off of error-prone, tedious configuration scripts for another set of configuration when Rails makes all the decisions for them. DHH made this point fairly explicitly in his keynote. To sum up, he argued that people only think they want to make decisions; instead, they really want to be given a fully working, homogeneous solution so they can get on with their business.

Believe it or not, I agree.

The devil, as they say, is in the details.

In the real world of software applications, the monolithic solution doesn’t always fit your needs perfectly. That’s why Rails implemented, very early, a plugin architecture, which immediately reduces homogeneity.

You see, Rails is like a pre-fab house. For people who have gone through the pain of constructing a house before, pre-fab houses are very appealing. Suddenly, there’s no need to spend time with architects, contractors, or painters. You just place an order and you get a house. It seems great. You can get the furniture you want, or even repaint it.

And when you need to bring in a contractor for routine maintenance, you can have your pick of contractors. Because your house is the same as every other house they worked with. But soon you decide you want a window. Unfortunately, your house is pre-fab, so you pick up a hacksaw and hack away. Everything seems great until the first time it rains. And the water starts coming in.

Undaunted, you pick up the phone and call all those contractors you worked with before. When they get there, they take one look and let out a sigh. They have no idea how to deal with the glaring mess you have made for yourself. After paying a hefty bill to get everything fixed, you tell yourself that it’s still worth it. After all, you’re still ahead on time compared to Andy down the block who had to do everything from scratch.

But you see, there’s another option.

At a builder’s show, you see a shiny booth run by a new company called Mer Builders. They have put together a house kit that allows you to put together your house quickly and efficiently. And when you want a new window, you just pull out one of the wall blocks and replace it with a window block. Quick and easy.

But wait, you are probably thinking. I still need to put together the house. That smacks of all the pain of building a house from scratch. It’s not as bad, but I’ll still need to decide what pieces I want, figure out how they hook up, hire someone who knows how to put everything together, and more. Who wants that. A pre-fab house will do just fine, thank you very much.

As you turn to leave, the Mer Builders salesperson calls after you. You see, it turns out that they understand that you’d rather not have to make all those decisions yourself. And they’ve put together a starter kit that looks kind of like the pre-fab house. You can order it today and have it delivered tomorrow. But when you want to replace a window, their network of certified Mer engineers will simply and easily swap out a wall block for a window block.

Heck, soon enough you’ll probably be doing all sorts of customizations on your own.

The moral of the story is… Use Mer Buil… er… Merb!

RailsConf Slides

Hey guys,

My talks at RailsConf were a ton of fun. The first night I did talks on Merb and jQuery which were completely packed, and the first day of the conference I did a talk on DataMapper which seemed to be well received as well.

While it was nice to hear that so many people wanted to see the DataMapper talk that some people were turned away, it sucks that some people got turned away. Without further ado, go check out my Merb and DataMapper slides at Slideshare:

I’ll try and get up the jQuery slides shortly as well. Enjoy!

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.

Archives

Categories

Meta