cfset application.MySQL5_connection = MySQL5.connect("jdbc:mysql://localhost:3306/opticalalert", props)>

Example #2

cfset application.update_mailinglist_remove = application.sqlserver_connection.prepareStatement("Update mailinglist SET email = ?, why = ?, Delivery = ? WHERE email = ?")>

CF 8.X only likes prepareStatements now so.

Is this still verbose? Then its just ….

Example #3
cfset application.update_mailinglist_remove.executeQuery()>

With the new Thread scope I am sure that would work even better or a threadpool scope.

I implemented it more as a proof of concept than an actual for-production-use framework. However, I was surprised at how utilitarian it was, what with only the Query object and native JS functionality. Extending the set of "callbacks" to CF is fairly simple; most of the bridge work is in place, so you only have to create your JS interface and implement it with the relevant CFML. The Query one is actually quite complex because of query parameters, and it doesn't support QofQs. Something like CFLDAP or CFHTTP would be quite a bit simpler to deal with.

However, to answer your question, I don't really have an intention of making it into something "real". I just wanted to see how it'd work, both from an implementation and a usage perspective. I have this sneaking suspicion that CF9 is going to have Tamarin (the AS3/ECMAScript 4 engine that Adobe donated to Mozilla and which backs Flash Player) embedded in it, and therefore have this sort of support available in the CF server directly.

I'm a little astonished by all the negative reactions in the comments.

I've been a ColdFusion developer for 8 years, and I love it dearly. Yay for cfquery and pound signs. But heck yeah, I want to write my business logic in Javascript while to leveraging the CF platform!

Javascript has syntax and features that appeal to millions of developers. It is being adopted as the scripting language of choice all over the place. It has a passionate developer community, and they are continually building better libraries and more sophisticated tools.

We dig JS. And we don't care if "dynamic binding is dangerous!" or "closures make give you warts!" I'll leave the philosophy of language design to others, and continue using JS quite happily, thank you very much.

If someone wants to write a CF runtime for Ruby, Dylan, Scheme, etc… rock on! Those languages are not for me, but I'm not about to rail (no pun intended) against their allegedly dangerous language features. That's like mocking someone for using an abacus or a slide rule instead of a calculator.

One last thought: cfscript is not Javascript. Not even in CF8 with its excellent C-style syntax. The list of things you can do in Javascript and not in cfscript is ridiculously long.

The typechecking is one of the reasons I'd love to have an ECMAScript 4 (e.g. ActionScript 3) interpreter instead of a ECMAScript 3 (e.g. JavaScript) interpreter. With the 4th edition, you get typing as well as default values for parameters (and therefore optional parameters). So you could write this:

function doIt(param1:UUID, param2:Array=[]):void {
}

[cffunction name="doIt" output="false"]
[cfargument name="param1" required="true" type="uuid" /]
[cfargument name="param2" required="false" type="array" default="#arrayNew(1)#" /]
[/cffunction]

Interesting post by the way!

While nothing you quote is factually incorrect, it's quite inflationary in nature. Looking at the page as a whole (from a community-edited Wiki), you see a rather fragmented collection of comments from a collection of authors with different viewpoints. To quote a rather more consistent source (the Google Maps API docs) "The Google Maps API encourages the use of function closures…".

Closures definitely have gotchas, but the same could be said for SQL databases, and no one runs away from those. You just have to know how to use them to best effect, avoid the pitfalls, and you'll be fine.

I don't understand your "cross-browser support" comment, however. All browsers support closures, and have since "forever". IE has memory leaks in certain cases, but they can be addressed without too much fuss, certainly more easily than you can address some of the rendering bugs that it has. This is also a non-issue on the server side.

It's even advised against in the Core Javascript Reference:

A closure preserves the arguments and variables in all scopes it contains. Since each call provides potentially different arguments, a closure must be created for each call to the outer function. In other words, each call to outside creates a closure. For this reason, closures can use up a lot of memory. The memory can be freed only when the returned inside is no longer accessible. In this case, the closure of inside is stored in result. Since result is in the global scope, the closure will remain until the script is unloaded (in a browser, this would happen when the page containing the script is closed).

Because of this inefficiency, avoid closures whenever possible, i.e. avoid nesting functions whenever possible.

And what about cross-browser support?