jQuery one point oh

It's out. jQuery 1.0 was just announced and it's HOT. The rollout is still in progress, as there's a ton of work that involves getting the API and documentation ready, test cases, screencasts, visual docs and supermodels ready.

Use it wisely. If you break it, pay for it. OR log a bug.

There's a LOT of new functionality in the new build so keep a close eye on the documentation as it comes out of the oven and consider joining the discussion list.

My three readers are wondering, "why are you making such a fuss over a library?" and I shall answer: I've seen plenty of libraries and yes, they are all nice. What I really like about this one is that its conventions delare almost a different language, in which it's not evident what all the possible uses of it might be. "How can this be? It's just JavaScript" I hear reader number 2 asking. JavaScript, like any other language, is both just an abstraction and a way to describe something, and yet, people keep finding new ways of using it. This library delivers a tremendous level of abstraction with insane eloquence, from which plugins and functionality pop out from like... popping corn. (Please suggest better metaphors in your comments so I can fix this one).

So no, it's not just a library, it's a language. Ok, not officially a language, but it might as well be. With it, many people are writing way cool plugins with little code. Exactly what we all need.

Seriously, what is jQuery?

It's a revolution.

Its creator, John Resig, calls it "New Wave JavaScript". Whatever. I know a revolution when I see one.

The whole concept is based on the undeniable premise of web design: “separate content, behavior and presentation”. This makes an emphasis on the markup-javascript separation and does an incredible job at it. Behind this whole concept is the fact that any behavior in a document can only be triggered by the user, and the user can only interact with the HTML document. There's no new DatePicker() inheriting from new Calendar. Everything is just a bunch of links, inputs and buttons. This concept dramatically simplifies development and maintainability, as it's clear that it won't change by the introduction of a new gadget-widget.

What about inheritance? what about OOP?

OOP is not the only way to reuse code. It's great, yes. It doesn't work well with JavaScript and the DOM because it's not supposed to deal with supers. What's the super of an input? Nothing. How do we reuse functionality across similar objects? I know how, I just don't know what it's called. Look up Decorator Pattern , Composite Pattern and Adapter Pattern and let me know if I'm close.

The idea is that there's a wrapper that goes around each and all DOM nodes (when you need it). Inputs, divs, spans, you name it. Then there's some functions that you can call on them just because they've been all wrapped. All of these functions take a collection of nodes and return the same collection, so you can even chain them one after the other and same some vars. Fancy? For an additional kapow, let's say you can get your nodes in an extemely eloquent way. Ok, you'll have to ramp up on CSS3, but you don't even have to. It's just that if you do, your code will be smaller.

The core is a library called jQuery. Its mailing list started in January 2006 and it has a significant amount of skilled javascripters as users. The jQuery project is very well organized with unit tests and documentation both in code and online. The library is also provided "packed" which makes it roughly 16kb in size (circa 2006; 31k circa 2012).

The appendages vary. Most of them are plugins for jQuery. What's special about them is that they follow a pattern, which is at the core of jQuery eloquence: you have to write them in a way that you always return the same object (the "jQuery" object) and iterate within your plugin. This means that you know exactly what to expect from the plugins. Another great advantage is that since jQuery is so eloquent, these plugins are very, very small, so if you or me don't like something... we rewrite it without breaking a sweat.

It is to be noted that the fact that everything is supposed to act on a collection of nodes, implicitly mandates that all plugins are all mix-and-match. If you want to encapsulate some of those behaviors into something more general, you go ahead and do so. But did you realize that you didn't have to create a class? Inherit from anything? What? OOP? Did you say something? Exactly.

There's obviously functionality that hasn't been written as a plugin. There might be libraries that already do what our code does, but no plugins for jQuery. So we write one of those, for example. Did I mention how fast this is? I'm talking at least one order of magnitude faster.

Ok, all this sounds fantastic. What's wrong with it? Hmm. Well, libraries are unlikely to have unit tests, although there's demo pages. Honestly, even if the libraries aren't tested by a QA department, they have been used, discussed and tested by a large amount of very good developers. You don't have to take my opinion for granted but I'll say I wish I could write code like a bunch of these guys. Worst case: If something craps out, we just have to replace a tiny part, thanks to the massive amount of modularity here. The plugins clearly define what each bit is supposed to do or not do, so changes are extremely localized. The conventions makes communication across modules a no-brainer.

We must spend our coding hours developing either more abstractions, or writing the specific rules for our specific feature. No more redoing monkey work. Enough is enough.

Programming metaphors

Writing a library is like creating a recipe.

• It takes a good amount of experience to write a good recipe.
• You make recipes out of recipes
• Once a recipe is written, it reduces the number of commands you have to give to create something.
• A recipe is perfected over time, and everyone reusing it benefits from it.
• If you want to make a recipe with other recipes, you should know what the other recipes have in them. This is not necessary if you are just following a recipe.

Libraries and recipes are abstractions. The difference is that you need people to understand and follow your recipes, while you only need computers that understand the language you used to define your libraries. Some particular browsers are what you'd call "whimsical cooks" but that's another story.

Writing an interface is like making a chair.

• It looks very easy. You just have to know how to cut and nail things, right?

There is a pervasive tendency to underestimate the amount of work and experience that goes into writing an interface. This ranges from writing markup and CSS to JavaScript and tying all this together.
There are rules you follow which are acquired by experience. Too many gotchas prevent you from doing it right the first time (or 100 times). UI design is not just putting strings in tables with images and colors, mmkay?

Extrinsic Motivation

In one of his latest posts, Joel mentions "intrinsic motivation" vs. "extrinsic motivation". To quote,

Intrinsic motivation is your own, natural desire to do things well. People usually start out with a lot of intrinsic motivation. They want to do a good job. They want to help people understand that it’s in their best interest [...]. They want to write less-buggy code.Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.Intrinsic motivation is much stronger than extrinsic motivation. People work much harder at things that they actually want to do. That’s not very controversial.

It makes me think of something I read elsewhere. To paraphrase, the "manager type" person is motivated by awards and stuff-on-the-wall because they tend to be more social. They want to show their achievements. Programmers, on the other hand, tend to be practical. They want faster machines, two monitors, a cool wireless desktop or bluetooth headphones.

I have to add that when management tries to add "fun" to a developer's work life it becomes "extrinsic motivation", and it can even become insulting. Not only can it be something that the developer will deem downright stupid, but most importantly it blatantly ignores what the developer is asking for.

My advice to management: listen. People complain all the time in different ways and degrees. Don't just shrug it off and say "don't come to me with a problem and no suggestions" because a manager's job is not just to "pick and choose". Granted, many people whine all the time but the point here is that people do say what they want. Don't insult their intelligence by giving them a smiley face sticker or overtly saying "let's have fun".

technorati tags:management