<cfclient>

G'day:
CFSummit 2013 started today - I'm quite jealous of everyone who's there btw - and Adobe opened with a variation on their keynote they used at cf.Objective(), SotR and CFCamp, which covers some of the new stuff in ColdFusion 11. And, naturally, they spent some time on <cfclient>. And then if I'm reading my Twitter feed and the schedule correctly, after the keynote they did another presentation looking more closely at the technical side of new features, including some <cfclient> code. And there was an eruption of Twitter traffic on the topic of <cfclient>. Personally, I think the whole idea of <cfclient> is a blight on CFML, and demonstrates Adobe have learned very little since those "heady" days of <cflayoutarea> and <cfpod>.


There's very little material out there on <cfclient> as yet. ColdFusion 11 is still in closed pre-release, and all the stuff I've seen at conferences has been on the overhead screen, and hasn't made it back into documents I can point you at to have a look at. I've seen some of its code close up, but not in a way I can share, unfortunately. But basically how it works is this:

<cfclient>
// mishmash of a subset of CFML interspersed with Javascript here
</cfclient>

 And via some sort of compilation mechanism (I've never been clear on this bit, and people at CFSummit will have more idea than I do now), all of that ends up being mobile-friendly mark-up and JS.

So it's basically <cfform> for mobile sites.

I'm selling it slightly short there because instead of just form-specific subtags like <cfinput> and <cftextarea> and that sort of crap, one actually writes code in this neither-fish-nor-fowl combination of CFML & JS. So there's flexibility there. But... seriously... WhyTF?

The problem is that this is not 2002 any more, and JavaScript is not the impenetrable monster it used to seem to be. The language and the community have matured, so it's a more coherent language; browser support is more uniform; the community have documented and written and blogged from the most basic parts of the language through to the most complicated; and there are so many libraries like JQuery and Angular andf Backbone and the like out there that to achieve really good, scalable, manageable, enjoyable stuff with Javascript, that there simply is no need for some half-arsed mechanism to try to make it "easy". It's already easy.

And Adobe seemed to have missed this. Part of the reason is - I think - because the Adobe ColdFusion developers... aren't web developers. They're Java developers. They don't do this stuff for a living day in and day out so perhaps it's all a bit of a dark art to them (and if they're doing Java they're probably a reasonable way behind the technology curve anyhow).

Another reason is Adobe is very cynically marketing to enterprise IT managers who probably isn't very "technically discerning" (ahem), but know a good buzzword when they hear one so "ColdFusion does Mobile" will tick one of their little buzzword bingo boxes. And they'll re-up their licences or buy new ones without consulting their technical people (or the technical people won't investigate thoroughly), and then not until later realise "ColdFusion does Mobile" means: <cfclient>. And - like most of the bolt-on features Adobe plugs into ColdFusion - it'll do a fine proof of concept, but simply won't cut it as far as a production solution goes.

Business marketing aside, let's go back to the supposed compelling reasons for a developer to want this crap. The position is that perhaps if you already know JS & client/server-side code interplay really well then you'll not really benefit from <cfclient>. But it's for all those people out there who aren't experts. The people who know CF, but only passingly know JS.

First thing: how incredibly patronising. And especially coming from a team of people who themselves wouldn't know one end of a web app from the other.

Next: if you're a CFML developer and you're not comfortable with JavaScript... learn. You're letting yourself down. And you're letting the community down a bit too, because it's this kind of developer that gives CFML a bad name. Also you're not doing yourself any favours by instead of learning JavaScript, learning some weirdo dialect of CFMLJS to achieve the same ends as you would if you just learned JS. Knowing JS looks good on your CV. Saying you can use <cfform> and <cfclient> to do JS stuff will just make you look crap. More crap than the people who claim to know JS but what they really mean is they use JQuery a bit. Knowing the "wizard" tags in CFML is not a helpful career move. Shun them.

Third. If you don't know JavaScript... you're still not gonna get very far with <cfclient> anyhow. Because it's not a case of writing this:

<cfclient>
    <cfmakemobilewebsiteplease>
</cfclient>

<cfform> kinda works that way, but <cfclient> - because it needs to do a lot more than just make a form - is going to require an awful lot of coding on your part. And not just JS. And not just CFML. But this weirdo mashup of the two which is neither fish nor fowl.

What's more, from the code I've seen, you actually will need to be quite an adept CFML developer to really get it. There are a lot of CFML developers out there - "five taggers" - who this is sort of aimed at I think, who aren't comfortable with arrays (and certainly not structs! They'll use multi-dimensional arrays instead), have probably never used a CFC and aren't sure why they would, and are basically in the middle of the learning curve. Now there's nothing wrong with that. Not everyone does CFML all day every day, is a hobbyist and has their own github open source projects and the like. This is fine. However... if that's where you're at... the code you will need to write is going to be beyond your current skill levels in both CFML and JavaScript. And it's not going to be as well documented, there's not going to be 15yrs of blog articles, tutorials, books, videos, courses etc to learn from. There's going to probably be three pages on learn.adobe.com website, and a few blog articles. Although I seriously don't think there'll be too many blog articles as most of the vocal people in the CFML community pretty much don't want to have anything to do with this technology. I'm not going to be blogging anything positive about <cfclient> (unless there's a hat-eating exercise because Adobe have so gratuitously misrepresented it, and it is actually good) because I just won't. I'm not going to encourage people to use this by helping them learn it. Far from it: I've asked Adobe to consider removing it from ColdFusion 11 I feel so strongly that it's a complete misfire for the language (they obviously didn't listen to me). And I know other popular bloggers (I mean the other ones... the bloggers who are popular ;-) think the same way.

Lastly... Adobe will almost certainly do a... erm... "less than ideal" job of this. From a technical point of view the Java source code to implement the tag will be fine, I'm sure: the Adobe ColdFusion team are good java developers. And the inner workings of the interpreter which will convert the CFMLJS into something a mobile can use will also be just fine. But take a look at the markup, JS and CSS they produce when <cfform> processes. Or <cfdump>. It's awful. Now they might have lifted their game with this new work. And to be fair on them, I'm kinda prejudging them here. But on the face of the decade-plus of evidence in front of us... they're not going to do a good job here. There's simply no evidence to suggest they will. Because they're not web developers. So no-one can expect them to turn out good web-based code. This is no real slight on them as no-one ought to expect them to be good web developers either: they're Java developers. So to all those people who don't know Javascript... nor will <cfclient>. It will probably not being doing a much better job than you would... except you've still got to write the code anyhow.

Update:
Nick Kwiatkowski made a very good point in the comments below that I forgot to mention in the first take of this article. And it's such an important consideration I'm elevating it up to here because people should not miss it.

Nick added:

One thing I wish you would have touched on is how stale the tooling will get with this solution as well.

Lets face it, by the time Adobe ships "CF11" to the marketplace, their libraries to convert HTML/JS into an app will be, lets say 6 - 9 months old. They won't change them in fear of QA, and after CF11 is out in the wild they can't change it easily because people will then rely on the quirks of their implementation.

6 months later Apple changes some API or comes out with a new iOS version which is incompatible with the tooling that Adobe is shipping with. Apple expects developers to be up to speed with their tooling and won't tolerate apps submitted with SDKs that are even weeks old.

The feature then becomes useless. Adobe may update the SDK or tooling in an updater -- or they may wait until CF12. If they do, they may opt for some crazy work-around because people relied on their quirks to do special feature X. Regardless, in between the time of this SDK update and when the fix comes into place, the feature is completely broken for those that try and use it. BROKEN. CAN'T BE USED AT ALL FOR NEW APPS. CAN'T BE USED FOR UPDATES TO EXISTING APPS.

This is no different than FlashForms (based on Flex 1.5/AS2), and the wide variety of Java based implementations. Hell, even the PDF and HTML->PDF features of old were stuck in this situation (did I really read that they introduced another NEW tag to do what the old one did and is now failing to do?!?). And don't get me started on the Reporting capabilities... I think the only thing they did halfway right in the past few years was to switch out the search engine -- and even that they had to do because they couldn't afford the old one anymore.

This is a valid point. And, as Nick points out, is borne out by every endeavour into this sort of thing that Adobe (or Marcomedia) have undertaken in the past. They just don't have the "lifecycle freedom" to keep this sort of thing up to date. They can be glacially slow with the lifecycle of their own code, but this approach just doesn't work when interacting with the rest of the code community who - for the most part - have embraced a more rapid lifecycle. So given Adobe can't or won't keep pace here, they mustn't make their community victim of this. And the community mustn't make themselves victim of this by using anything that goes into ColdFusion that will be in this situation.


It's just a lose-lose situation for anyone who thinks <cfclient> might be a good fit for them.

If you don't know anything about mobile dev, this is fine. You should use CFML for your back end, and just use one of the many existing JS libraries out there to help you with your front end (I don't do mobile dev myself, hence sounding vague here. Hit Ray up for advice on that!).

If you don't know JS... don't worry about it. Learn it. It's easy! I mean you won't become an expert over night - same as with CFML really - but you'll be surprised how quickly you become productive. And if you go to Code School there are tonnes of courses, and you'll come out with excellent things to put on your CV like JQuery, node.js, Backbone, AngularJS. All good stuff. All stuff that will further your career and give you good skills. Much better than being able to say you can use <cfclient>.

So to sum up - in case I didn't get my point across here - don't use <cfclient>. Don't encourage Adobe to put stuff like this into CFML. Enrich your own skillset by learning Javascript, and also hone your own CFML skills.

And if yer at CFSummit... have a beer for me!

Cheers.

--
Adam