Wednesday, 6 November 2013

ColdFusion: <cfclient>: from a pig's ear, a silk purse could rise?

G'day:
I've got two muses today: Dan Fredericks who had a go at me yesterday about being a big meany about <cfclient>: and Sean for giving me the "penny-drop" moment. I think the concept of <cfclient> is salvageable. Just the concept. Not the implementation. Nuh-uh.

Firstly Dan had a half-way decent point, as articulated on Twitter:


And the conversation went on from there (you'll need to look it up). In theory Dan is right: constructive criticism is better than criticism. However I really don't actually see anything that's good to a useful degree about <cfclient>. Otherwise I would have mentioned it. Here's the best constructive criticism I can muster for <cfclient>:

  • I can only continue to push Adobe to reconsider it, and remove it from the language. I know they won't, but when CF loses credibility for taking this sort of direction at least I'll be able to say "well I tried my bloody hardest, instead of just sitting around and watching". What's constructive in that? OK: not really "constructive criticism", but I'm trying to benefit CFML in my actions. I'm not simply doing this to make noise.
  • This just makes Railo look more and more professional all the time. Both the company and the product. It's clear from the features they add to CFML that they are in touch with web development and their community of developers.
Dan: it's very difficult to see the good in a train wreck. By all means... counter what I say here and on Twitter: demonstrate how what I - and various other people: I'm far from the only one - am saying about <cfclient> is wrong.You yourself ought to take your own advice: don't just bag me for taking an approach you personally don't like: do something about it.

But - good on you Dan - you did get me thinking.

And then Sean provided the thought.

Sean said this on the official Adobe ColdFusion blog this morning (well I read it this morning, I should say):

I think providing all the functionality as a pure JS library and documentation about the integration would have been a much better approach than this weird mix of CFML and JS.
Bloody hell... yes. Yes! Now that is a good idea.

What Adobe should return to the idea of CFaaS, and flesh it out more thoroughly as a REST-oriented thing, and extending it to cover far more CFML functionality than just the handful they started with, and then complement that with a JavaScript library which exposes client-side access to those services in a JS-friendly and simplified way. Basically like how <cfajaxproxy> bridges between JavaScript code and CFCs, but for core CFML functionality instead.

So instead of this sort of shite that <cfclient> will currently encourage:

<cfset $(document).ready(on_ready)>

Which everyone except for Adobe can see is just... wrong... we'd have this sort of thing:

var records = $cf.query({
    datasource    : "dsn",
    sql            : "SELECT col FROM tbl WHERE filter = ?"
    parameters    : ["foo"]
});

And perhaps for our own code, we could just do:

var person = new $cf.componentProxy({
    component    : "me.adamcameron.myapp.Person",
    initArgs    : {id: 1}
});


var personService = $cf.scopeProxy({
    scope        : "application",
    variable    : "personService"
});

(I'm making this up as I go along, so dunno if I'm suggesting a good approach here).

In my opinion (which I probably don't need to prefix things with on this blog: it's kind of a given), this would be:
  1. a far better approach to solving the challenge that <cfclient> is addressing;
  2. actually pretty bloody handy!
Writing JS with CFML is not a good use of Adobe's time, nor is it a good thing for a developer to then be engaging in. If you want JS... write JS. Do not write <cfset jsHere()>, and have <cfclient> turn that into JS for you.

However writing a bridge between JavaScript and ColdFusion so that we can interoperate between the client and the server more smoothly is a really good idea in my books. Leave it to JavaScript to do the client side code; leave it to CFML to do the server side stuff... just make it easier to bridge in between.

I think the Adobe ColdFusion Team's problem has been when they addressed this "do something with ColdFusion and mobile" edict that came down from above, they have looked around and have realised they only know about hammers (CFML), so they just decide "well it's obvious that's not a nail, but f*** it I'll just hit it with my hammer anyhow". However facilitating integration between client side apps (be they mobile or web-based) and ColdFusion is not a nail looking to be hammered, and most of us can see this. When the bosses came to the Adobe ColdFusion team and said "we need to do something with mobile", the CF team seem to have been a bit too literal (or just lacking in initiative) in their approach to solving it. In the process inventing an issue to address that didn't really exist ("ColdFusion developers want to write JS using CFML". No they bloody don't, guys; and stop trying to tell us we do. And even if some misguided CFML devs do want to write JS in CFML, don't bloody encourage them... help them to not want to do that. Facilitate them doing the job properly).

I also think they're hamstrung by the fact the only thing their guys know how to do is to write the CFML language, so instead of going "oh, we need different expertise here", they just go "more tags!". They're further hamstrung by simply being unaware of a CFML developer's requirements here, because they don't use CFML and they're not web developers.

It'd be slightly embarrassing for the CF Team, but I think it's not too late to bin <cfclient>. It was the wrong approach, and addressing a fictitious issue. People have been telling you this for a long time, and you need to listen. Bin it. Instead, put the hammer away, and consider what would actually be a useful way to approach this? And also maybe accept they don't have the technical (or even business-analytical ~, it seems) capabilities in-house to furnish the solution, so get some consultancy in to do they job.

I think if they'd taken the approach Sean suggested above, people would be going "hey, that's pretty bloody handy!" rather than "err... WTF?" and at best going "OK, looks a bit odd, but let's see how it turns out" (like how Dan seems to be approaching it).

Thoughts / observations?

--
Adam
Posted by at
Labels: , , ,