FunctionSource, Your Source for Developer News

Reg Braithwaite has brought up the desire to enable fluent software easier in JavaScript.

There is a common meme in software. On a particular platform someone finds a good way to do something and does that said good thing in an API. Others look at it and think “I want to be using that API…. it is so great!” and then they start to emulate the API.

There are many obvious examples. One is Spring. The POJO/dependency injection engine kicked in and from that simple pattern people wanted to write J2EE apps “that way”. A large company grew. A great exit happened…. all from a very simple (but timely) idea.

We saw something similar in the JavaScript world with jQuery. It wasn’t the first Ajax library by far. There were great libraries such as Prototype, MooTools, and Dojo around… but jQuery came out of nowhere. It turned out that that most people wanted a great API to sprinkle Ajax on their sites, and they really wanted a CSS/DOM DSL.

You can see when these trends happen because everyone suddenly wants to wrap (or rewrite;) a low level library in the new given style, hence: jQuery plugins.

There are a few other trends like this happening right now. One is solving the asynchronous / callback problem. This is happening throughout the industry… from Closure to Scala/Akka to our own node community. Many of us want to solve “Callback-hell”. Some think that a solution like Fibers is the ticket. Others want simpler async modules. It still feels like we have more to experiment with.

At the same time, we have the rise of CoffeeScript and friends. The fact that we have an easy way to work with language sugar means that we can bypass API solutions and go straight to language changes themselves. Don’t fix in an API what should be fixed in the language and platform.

Back to Reg, and his discussion on baking method chaining type APIs into the language itself. We shouldn’t have to write shim libs that are basically “make library X method chaining style”:

My suggestion is that “chaining” method calls is a syntax issue and not a function issue, and that writing functions to return a certain thing just to cater to how you like to write programs is hacking around a missing language feature.

One thing that expressive languages like Ruby, Smalltalk, and Lisp teach us is that many ‘design patterns’ are actually language smells. The ‘fluent interface’ design patterns is just that: A sign that a language is missing a cascading message feature.

This feature can easily be added to CoffeeScript, without a new operator, by simply making whitespace more significant.

CoffeeScript is perfect for the challenge, but JavaScript is too. There has been talk of using simple sugar so that:

obj.{
call()
call2()
call3()
}

becomes:

obj.call()
obj.call2()
obj.call3()

Love it all.