What I think, about CF 8
But while things seem to be calming down at work, things seems to be heating up lately as mxna is starting to see more and more feature requests for the next version of coldfusion, cf 8 code named scorpio. I've read several of these, simon's, brian's, brandon's and sean's take on it. I think all of these have merit, and while im not going to share my own opinions on what I would like to see in the next major version, at least in this blog post, I would like to comment on a couple of the things im seeing and hearing and just give my take.
First off I want to describe quickly where I am coming from as a developer just so we can get all my bias out in the open. I am a self taught developer, I have been using cf since early in version 5 and have been learning non-stop ever since. I contract for a fortune 500 company where I integrate cf with some massive data-servers (iseries as/400's, hundreds of them all across the country) and we build some very complicated apps with some very complicated business rules. But part time, at least until recently I have been keeping fairly busy freelancing regular plain-jane websites for businesses, non-profits and the like. So I would at least like to think I am well-rounded in my experience with the web.
Simon, being simon, has asked for lots of core features, lots of OO stuff, enterprise level things. While I think he's a little off on a few things, I think for the most part he is spot on with a lot of the things he askes for. We could go back and forth all day on constructors, interfaces and method overloading, but at the end of the day, there are a lot of us, and I would say that while we may still be a minority, we are growing rapidly, that are embraising OO and want to make our lives easier in that respect. The problem I see is that there are a lot of developers that are learning OO for the first time in CF and they are reaching the limits of what CF can handle for us and getting stuck. We'll come back to that in a minute though.
I have to say, I really like brandon's list. Enterprise management of CF is really a sorespot to a lot of people and any improvement there will be a blessing. I still would rather be with CF than any other comparable language in this regard, but there is still room for growth there. I also agree that for this release I would really really like to see adobe go back to the basics and fix a lot of core things in the language. Upgrade those java libraries, get us at least on java 1.5 but hopefully past that, and upgrade those third-party sources as well.
Brian has taken a different approach arguing that we shouldn't focus so much on the backend of things as the presentation layer. He thinks that we are trying to shoe-horn cf into a java mold, one that we will never fit into. While I think he is right on some level (cf will never be java, and it doesn't need to be!), I don't really agree completely. Here is my thoughts on the matter:
I dont really agree that a lot of the things we are asking for in the relm of OO capabilities are really going to turn cf into "java lite", but if even if that is true, what is really wrong with that?
There are thousands of businesses and corporations around the country and around the world that see java as a very respectable language, a very powerful language. On many fronts, there are cf'ers out there that are fighting a battle with their management on whether to use java or cf, especially for the web. The fact that cf is built on java, and the fact that cf has much of the same power as java behind it is a great boon to us as a developer. No, we do not need to try to compete, on any level really with java, it won't happen. But there are many many cases, where CF can be your RAD method of java, and like sean says, we can dip into java for the hard stuff. Does giving developers constructors or interfaces change that? Not really. It just means that we are able to do a few more things in cf that we couldn't do before. We have workarounds for constructors, and interfaces, well, thats a whole different oprah. Long and short is, if I need these OO constructs that several developers are asking for right now, am I going to drop into java to do it? Of course not, im going to make do, for now.
There is the whole strict-typing / loose-typing conversation still going on since well before cf.objective too, and I agree with Hal on this. We need to embrace loose-typing and play to its strengths. Is it perfect in every situation? No. Is it better for a RAD language to be loosely typed? I sure think so.
See, the thing with the presentation layer though is that thats where it gets hard. Coming back to flash forms and flex in a minute, lets start with the dhtml, css, and js/ajax stuff. Spry is great from what I have heard, and while I haven't had a chance to look at it yet I definatly plan to. But any web developer that has any experience is going to tell you, javascript, ajax, css and all of that stuff that is evaluated by the browser (shoot, html/xhtml for that matter!) is hard. Its different with every single browser, and even with different versions of the same browser it can be a nightmare. (I can't believe im really doing this, but even Dvorak, the kook that he is even brought this up, and its a good point, although horribly argued as usual).
Take a for-instance. Look at what cfform generates for html. Through that in an xhtml page and try to validate. Its been improved big-time from previous versions but its still a beast. But they dont have a choice, they have to generate code that is going to to work in all the current browsers, all past browsers, and all of the hopefully future browsers into the forseeable future. Thats just basic html and javascript. Start throwing ajax stuff in there and see what you get. Sure, spry can make this easier, but whatever the case, you are never going to be completely happy with the output.
Now, flash forms / flex makes this a little easier. Its one of the best things about flash, write it once, it works everywhere I seem to remember another language / platform shooting for that at one point.... what was it... oh, thats right, java. (No, this point is unrelated to the java talk at the top). Flash has succeeded at everything that java was inspired to be. We run the same flash application in IE, or Firefox or opera, on a pc and soon mac, and even eventually linux and it all works and looks the same. And I applaud macromedia and adobe on this, they did a hell-of-a job.
But the long and short of it is this. Flash-forms have too many restrictions to really be usable. The size restrictions and long wait times are really just too much for a decent sized form. While I realize that the current implementation of flash-forms that we have were built on flex 1.5 and that surely flex 2 would bring some much needed improvements in this area, some of these restrictions were imposed by macromedia on us. They didn't have to limit the size. Im sure part of this was a limitation in flex 1.5 and if we were able to make forms much bigger than this we really would have been complaining about the wait times, I think part of it was that if we wanted to build a better presentation layer, they wanted to steer us toward flex. And I think thats what they are going to do again. They are going to wet our whistle a little bit more with the flash-forms, but at the end of the day, if you want to make real RIA's, youre going to need to build a flex app. And with the great price on flex 2 (free really) and the remoting that you can do, there really isn't a reason not to.
So here is where I am at. I belive we should keep CF presentation agnostic. If we send adobe running around trying to keep up with all the differnent browsers they wont have time to tie their shoelaces. Lets leverage the tools they are giving us for the presentation layer, flex in the flash 9 player and soon to be apollo (cant wait!) and use coldfusion for what its really good at. Being a server sided language.
Sure, RoR is great, it makes it really easy to throw together a script.aculo.us ajaxified application, but from everything I have read, when you sit down and try to do some real heavy lifiting in it, you're going to get back into the grit and grime of ruby. I think we need to take a page from Rail's book and make RAD a priority, but I also think making the language cleaner and more powerful as a whole only helps to darken that bottom line.
As web-developers, we are required to have an intimate knowledge of many many languages, and at least a working knowlege of even more. Lets make the most of what we have. Play to the strengths of each. We struggle with it every day at work. We can write this query to where most of the work is handled by the db, or we can write it for colfusion to take care of. We always decide based on who is more apt for the job. Same thing with cf and java. Same thing with html and flex.
Back on the java / cf comparison, right now, we are seen as java's RAD son, we have all of its powers and few of its weaknesses, and if we run into trouble, we can run to dad and get him to pick up the slack. I think we need to continue and mature in this respect and embrace what papa java has to teach us about software development, while throwing our own new spin at it. Or, we could chase the presentation layer, and while we may have all the tattoos and sharp clothes, we can't really do all that much real work.
At the end of the day, if I have to choose between CF becoming "java lite" or "watered down java / Rails wannabe", I know what im going to choose.
------------------------------------------------------------
Whew. That was a long one! Guess I've been saving it up for a while. Simon, Brian, Brandon, and Sean, I would have commented on your posts themselves, but didn't want to write a book on your blog. I don't think I've got all the right answers, these are just how I see things at the moment, and are of course subject to change. Think im wrong? Please, by all means, change my mind in the comments!

First, everyone can stop with the justifications for why additional OO capabilities would be useful to certain people. There is no doubt of this. Interfaces serve a valid purpose (though in a runtime-compiled language like CF I personally feel the benfits of interfaces are close to zero. All interfaces will get you is a different runtime error message, period.) The question isn't whether such additions would be beneficial, especially to advanced CF developers. They absolutely would be used, though by a very small subset of CF'ers.
The question is, when given the choice to divide their development resources up for work on CF8, where should Adobe focus the majority of those resources? I'm arguing, or at least asking, if it wouldn't be smart for them to focus the majority of their resources on making CF the application server with vastly superior presentation layer capabilities.
With regard to your thoughts about how there is some sort of "danger" in bringing AJAX, UI, or DHTML capabilities to CF becuase there are challenges in supporting different browsers: as far as I'm concerned, this is just one more area screaming for someone to step in and fill the void. Again, look at Backbase, a stunning AJAX and DHTML UI component library. Backbase is a commercial product. Backbase works with all current browsers. Apparantly this company, with vastly fewer resources at its disposal than Adobe, is perfectly capable of handling this challenge. I want Adobe to not only give me all that power, but let me use it with a set of simple CFML tags.
Flash forms do have restrictions, which is why I don't want Flash Forms, I want real Flex. I want the full power of Flex available within my CF applications. I'll leave it to Adobe to decide the best way to make that work, but doing this would really drop jaws and compel CF and non-CF developers alike to leverage that power.
The ideal situation, in my mind is that CF 8 provides:
- incredible AJAX and Flex integration
- amazing DHTML UI components
- even better, the ability to switch between DHTML or Flex interfaces with a single tag attribute
- the most seamless Java integration they can come up with, including passing CFCs into Java classes, passing Java classes into CFCs, and in general letting the two work together with no translation issues (let use use JavaCast() to cast any Java type).
If after that they can also fit in the addition of the extra OO features like static methods or interfaces, I say that's great! I'd probably use them! I just think the other features should be given priority. :-)