ColdFusion 11: cfclient ports a lot of CFML functions to JS

Question

G'day:
I am reposting this from my blog ("ColdFusion 11: cfclient ports a lot of CFML functions to JS") at the suggestion of Adobe support:
@dacCfml @ColdFusion Can you post your queries at http://t.co/8UF4uCajTC for all cfclient and mobile queries.— Anit Kumar Panda (@anitkumar85) April 29, 2014
I have edited this in places to remove language that will be deemed inappropriate by the censors here. Changes I have made are in [square brackets]. The forums software here has broken some of the styling, but so be it. There are comments back against the original article - linked to above - which are worth reading too.
G'day:
I will start this article - which won't be a long one - by stating I am an adequate JavaScript developer, but I am by no means an expert. I'm at that stage wherein I'm au fait with the syntax and the nuts and bolts of writing OO-esque JS, but I don't spend enough time doing it to know the minutiae of "best practice" and don't automatically know the differences between the "best" way of doing something, and just "a way of doing something". Hence this article asks a question, rather than making any concrete statements.
A few days ago I wrote my first <cfclient> hello world (or in my case "G'day World") example. I'm not compiling it to a mobile app as I'm not really testing the ColdFusion Builder app packagings stuff (I simply don't care about that), I'm only interested in how <cfclient> performs / works in the context of a tag in the CFML language. See this article for more on that: "ColdFusion 11: <cfclient> in the context of the CFML language, not the tooling".
One thing I noticed in my "G'day World" code, is that to output those 11 bytes on the screen, <cfclient> loads around 128kB of data, in the form of various tracts of line code and external libraries. Describing this as "egregious" is an understatement.
One of the libraries particularly caught my interest, as it's called "cffunctions.js", and - as the name suggests - contains a port of alla lot of CFML's built-in functions to JS.
My first observation is its inclusion is completely unnecessary as I'm not using any functions in my code, and it would be reasonable to think that the <cfclient> CFML to JS compiler might notice that and save people a download. Secondly... it's a single, monolithic 106kB file. Let's have a look at it:
Well actually when I suggest we should have a look at it, I am actually inviting the JavaScript aficionados amongst us to offer their input. I'm not going to be able to lend much expert analysis to it.
Observations I will make:
as I said above: including this file when it's not necessary seems wrong.
Every single function is just slapped into one huge file. This to me seems equivalent to having a CFC called AllMyCode.cfc, containing... everything, including kitchen sinks and family pets.
Connected to that: the functions are all declared straight in the global scope, which seems a bit "pollute-y" to me. I can't help but think they ought to be grouped together in a CF namespace, within that some sort of type-centric namespace like CF.List.listAppend(), CF.Math.abs() etc?
A lot of the code seems rather "longhand", eg: someVar = SomeVar+1 instead of perhaps someVar++; using an indexed for() loop to loop over arrays etc.
The file's not minified: this would almost halve its size. I dunno if this is such a consideration these days with responses being GZipped?
Is there anything else you've spotted?
I might sound a bit nit-picky here (hey: it would not be the first time, and someone needs to ask these questions), but equally if I want someone writing a wizard to write my JS for me, then I want to know that person actually knows what they're doing. And if I can raise code-quality questions... I suspect the answer is I don't want this person writing my JS for me.
But I completely accept that perhaps there's not an issue to answer here... this article is more soliciting other - more expert - people's opinions.
What do you think?
Adam

Answer 1

The functions defined in the cffunctions.js are not namespaced. If it is namespaced, you would have to add the namespace while using a function inside cfclient.
These functions are not namespaced, so that you can use the same syntax for using a function inside and outside the cfclient block.
This is indicative of everyone's concern that you guys would just implement / encourage poor practice in your <cfclient> implementation.
How is it - given you're "compiling" the CFML anyway - you cannot translate source code that says "listlen()" into "compiled" JS that is CF.listLen() or something? Thus good CFML can be translated into good JS.
You seem to think that there's a one-to-one mapping between what the CFML says and what the resultant JS needs to be.
You've basically written a mechanism for a CFML developer to write bad JavaScript.
Well done.
Adam