cf.Objective() 2008 and the Future of ColdFusion
Well the conference has ended and I'm back in Raleigh trying to get back into the groove of work again. ;-) Overall the whole event was excellent, as expected.
I learned a lot at the conference sessions, but also as usual, I think I learned even more sitting at the bar talking for hours with heavy hitters like Chris Scott, Max Porges, Joe Rinehart, Peter Bell, Sean Corfield, Mark Mandel and many others. Some of these guys are just way too smart, but I wouldn't want it any other way.
I feel like my presentations went pretty well and that I'm finally comfortable with public speaking, which is good. I also had a chance to look at the new Swiz Flex framework that Chris created, and it looks really damn good. Hopefully we can move to Swiz from Cairngorm on our current Flex project during a future refactoring, since it is so much easier to deal with.
From talking to other folks in the community, it seems like CF is at something of a crossroads. One thing that kept coming up over and over again was how CF really starts to lose its glamor once you start using it as a back end for Flex. The benefits of CF really shine at the Controller and View layers, but for pure SOA architectures, we really have to jump through a lot of hoops to get true integration with Flex. This is mainly due to the limitations of CFC creation. The autotranslation of CFCs to ActionScript classes looks really sweet...until you have to send 1000 objects across the wire to Flex.
In fact, the dichotomy between the majority of people using CF (the "5 tag crowd", meaning people who just use cfif, cfoutput, cfloop, cfquery, and cfset) and the people who are really pushing the OO envelope became really apparent at the CF9 brainstorm session. Some people were asking for more features, but the core group of "thought leaders" in the CF world are proposing some far more radical changes.
The most compelling to me is the idea of dropping development on CFCs and allowing us to write server-side ActionScript, as well as dropping CFML as it is now and switching to a fully XML compliant markup like MXML. This would allow us to leverage tools like FlexBuilder, which quite frankly are a joy to work in. ActionScript is strongly typed, so this would be a big change, but it has dynamic elements as well such as the ObjectProxy class. And CFML is already nearly XML compliant, so switching over to that kind of synatx would be relatively simple.
Basically, I love all the great and easy features that CF gives us (obviously), but am really starting to hate the verbose syntax needed for CFC development, as well as the lack of proper IDE and tooling support. The built-in services are the reason why I don't "just switch to Java" for the Model. What I want is to be able to leverage all the great stuff CF provides, but do it in a more productive way.
It seems to me that CF9 would be a perfect chance for Adobe to make a clean break and really revolutionize how people use CF, as well as drawing in many new developers who are put off by the current way CFCs are built. There are a large number of odd language idiosyncrasies (arrays passed by value, arrays starting at 1, ListAppend returning the value while ArrayAppend does not, the list goes on) that have built up over the last 8 versions. I'll be blunt and say I think it's time to finally start again.
There is also a massive pool (millions) of people programming in ActionScript and JavaScript, and having a server-side language providing all the great things that CF does would be an extremely compelling draw. I think a bold change could trigger a huge influx of developers.
I realize that a large number of existing CF developers would probably not embrace this, at least not initially. I would argue that for them, they can keep on using CF8 and keep on doing what they are comfortable with. Adobe could offer patches and updates that would port the new AS/MXML features to the old CFML syntax (since the new stuff would be running on Java as well). The question would be whether alienating some of these folks is outweighed by the benefits of such a change and the influx of existing AS/JS developers it would trigger. Being able to use the same language on the client and the server, using a killer IDE, and leveraging a huge array of easy-to-use services would be a ridiculously compelling platform.
I still love CF and I'm only saying this as frank and honest suggestions. Using FlexBuilder really brings home the power of a great IDE. Looking at things like Groovy (with its Spring and Hibernate stack) shows just how easy working in Java has become, and what a difference it makes to really be able to do full-blown OO development instead of worrying about how many CFC instances we're creating.
All that said, I know that the odds are probably close to zero that such a change would actually be made. Still, one never knows. Adobe was listening to us at the conference and I'd like to hope that all options are on the table as they go forward. The fact that they let us talk directly to them and listen to our crazy ideas is one of the things that makes the CF team great. I just want to see CF continue to grow and shine, and as you can probably tell by now, I think a radical idea like this could really shake things up and push ColdFusion to even greater heights.
One of the truly great strengths of ColdFusion is that it has consistently maintained backward compatibility. Another is the low barrier to entry. if you sacrifice either of those, you risk destroying some of the real strength of the platform.
CFML itself would still be just as easy to use as always. In fact, it would be easier since you'd have all the tooling support that Adobe has already created around ActionScript and MXML. We'd still use tags for the View-related stuff, it wouldn't be much different than it is now. But we'd finally be able to really embrace full-on OOP development with gusto for Model-related stuff. If you've done any Flex development you'll know what I mean, since it allows both XML and ActionScript.
For now.
Brian your blog is one of my favorites - I just "get" everything you write. I've also watched some of your Connect presos, which are also excellent. Keep up the great work for the CF Community.
And I don't think we'd be alone.
My initial thoughts on any radical changes would be to leave CFML alone (mostly) and add ActionScript as an additional scripting option. I'm all for breaking changes that increase consistency across the board though (mostly) :)
You're saying that the language must be backwards compatible forever? Any mistakes or errors are stuck with us no matter what? If you think that switching to a server/platform combo that is "stable" means that you'll never have to refactor code in order to upgrade, you're in for a pretty nasty shock: it doesn't exist. Languages make clean breaks all the time. Try running C code through a C# compiler and see how far you get.
Microsoft made a lot of ASP people unhappy when they switched to ASP.NET. Far from losing market, their market has doubled many times over. Yes, such a big change would rock the boat. There would be unhappy people. Some people would even go to another language. But I don't think this number would be that large. And for every one who leaves there will be ten existing ActionScript and JavaScript programmers who will gladly rush in to fill the void.
I understand that you personally don't like the idea, but the fact that nearly every single top-level person in the community agrees with this to some degree might be reason enough for you to consider the option.
It was probably unintentional, but some of your post almost comes off as condescending: "they can keep on using CF8 and keep on doing what they are comfortable with" So I should be "stuck" on a version of CF because i like using tags? Hey, I'm all for CF developers being given more options, including server side AS, fully-scripted CFC's, a great IDE and all that stuff. But please, Adobe, keep CFML around and keep giving us great new tags. Who knows, maybe some day when I get more into Flex and if I ever become one of the "enlightened ones", I may feel differently ;-)
Since you mentioned the move from ASP to ASP.NET, I will say that I thought Joel Spolsky made some good observations about that:
http://www.joelonsoftware.com/articles/APIWar.html...
I have talked to several people who found it very appealing that ColdFusion maintained backward compatibility when Microsoft didn't.
I do think that the opinions of the ColdFusion elite are valuable, but the back corner of the room at that BOF session (where sat the elite folks), was fewer than 100 people. The vast majority of ColdFusion programmers (and buyers) aren't that advanced. Indeed, they weren't at cf.Objective() at all.
Most of Adobe's ColdFusion revenue will come from people who just want to add a few new features to their existing programs.
@Steve: That's an interesting link, but the date flags it as being posted in 2004 and clearly Joel's predictions were way off the mark, since .NET is booming in popularity.
I do see your point about the apparent gap between the "elite" (though that does have some negative connotations) and the bulk of CF users. This is what I was getting at in my discussion about that dichotomy, and is the main reason why I'd be surprised if Adobe actually went this route. However, the number of people moving towards more OO apps keeps getting bigger and bigger, so the issues that are being run into right now by a smaller group are going to be affecting more and more people, especially as folks adopt Flex.
Most of Adobe's revenue, for right now, does indeed come from people who just want to add a few new features. But since you were also at the BOF, you know that very, very few actual new features were proposed by the crowd. PDF Forms, video manipulation, etc. I mean, that's great, but really, CF has so many features at this point that it seems like the list of "blow me away" additions is getting pretty small.
They'll always be able to update things, add new features, and update existing ones (though it gets harder to do that and maintain backwards compatibility) and keep going along the same path that they have been. I just think that they could really mix things up, make CF even more powerful while maintaining ease of use, and draw in a huge number of converts with a more radical shift.
Heck, maybe there are even two products here: ColdFusion 9 and FlexServer 1.0. Many of the underlying Java services could probably be used across both.
Breaking compatibility would be (I predict) a major disaster.
Incidentally, I certainly had no negative connotation in my mind with the choice of the word "elite".
I agree that (other than Server-side ActionScript) none of the features suggested at the BOF were "blow me away" features. That doesn't mean none could be found. Even at that meeting, however, I thought we had some good feature suggestions. I suspect Adobe has some even better ideas (I don't have any knowledge of any, of course).
Very true on the topic of new featues. I know Adobe is talking to customers as well as developers, and they very likely have things up their sleeve.
I know breaking backward compatibility is probably not an option, I just wish they would if it means making the language XML compliant and fixing some of these odd language elements. If they could do it as a checkbox option in the administrator that would be great, but I imagine it would be quite difficult to maintain since it starts to mean creating two different versions of the language. Since that may well be too much, I'd rather they just do it and get it over with!
Just out of curiousity, what services do you find useful in the model layer? Where do you see the value-add of CF over Java+Spring+Hibernate?
BTW, I didn't have a problem with your use of the word "elite" either. The issue i had was this idea that some people should just stay on CF8. I'd like to think that Adobe will give CF developers of all levels (even the 5 tag crowd) reasons to upgrade to future versions.
@Tony: No worries! I knew it would be a controversial post when I made it, but I felt like it had to be said.
ActionScript even more than CFScript. (Considering the
CFScript is not feature complete would just top the list of
explaining that problem.)
Second on the list would be a consensus that it should be as
easy to communicate with Flex from CF as it is to communicate
with a database. Just adding ActionScript will not solve that
issue. That will have to be added if they use ActionScript or
if they complete CFScript.
? Have I missed any major points here?
I don't agree with Brian at all on this issue. CFML should continue to grow as a language and ColdFusion should continue to add features that make hard stuff easy. That's what makes ColdFusion such a powerful product.
I *do* think that cfscript should be enhanced - and so does Jason Delmore. Talk to him over a beer and he'll enthuse about the language enhancements in CF8 and the attributeCollection method of passing arguments so you can very easily mimic almost any tag for use in cfscript.
In the Adobe keynote, Jason had a slide that showed a CFC written entirely in cfscript. He said the slide was written by one of the engineers. I don't think the slide was entirely in jest so I would not be surprised to see some form of script-based CFCs in CF9.
What I'd *hoped* the BOF would cover was new features - not language tweaks. Tag-based CFML is not going away any time soon.
Though I still think that using AS on the server would be better...they have a great language already and the tools to support it, so why not try to leverage it? Regardless of how they do it, they need to come up with better ways to enable sending large collections of objects from CF to Flex, because CFCs become quickly become untenable due to their overhead. I'm speaking from experience here, as the effort of using AOP to manually generate typed structs becomes old really quickly. Have you run into any of these kinds of issues yourself?
The other issue still revolves around tooling and IDE support, which is another reason why the idea of using AS on the server is so compelling, at least to me. Adobe already has so much built up around ActionScript that it would seem to be a bit silly not to leverage it in some way.
What about the idea of moving CF to XML compliance, and fixing the language issues that have built up? Things like arrays being passed by value need to be rectified, and CF9 would seem like a great change to do these sorts of things.
I wouldn't view allowing server-side AS and XML tag syntax as CF failing to grow as a language, or failing to continue making hard stuff easy. Tag-based CFML wouldn't have to go away, there would still be tons of tags, they'd just be true XML (fixing cfelse), and would allow scripting against the tag-based elements just like Flex does. I'd say that such a move would be a huge growth for CF and make it even more powerful. The ease of use and simple abstractions that it offers wouldn't have to go away at all, I'd just like to see them work on some of these pain points and language idiosyncrasies and this seems like a very viable way to do it. My 2 cents of course, and I knew everyone wouldn't agree with me on this. But I think that getting people to talk about it is a good thing.
I agree that the BOF had few radical new ideas (aside from allowing AS). I know there are some very cool ideas floating around regarding what to add, but CF already does so much and is so feature-complete that I think folks are finding it hard to come up with very many new "jaw-dropping" ideas.
Look at at the web and HTML5, there is pretty much a trend away from XML, sometimes due to the strictness and sometimes for other reasons... But losing the flexibility (and simplicity) of CFML would definitely be a bad thing IMO.
I think you're right that the language needed some tweaks. If you talk to the Adobe guys they agree. I think for the good of the product that such language updates need to not break backwards compatibility. Hopefully you can force backwards compatibility at the application level.
I agree with previous comments that the group at cf.Objective is but a small, and probably not representative sample set of the ColdFusion user base. ColdFusion's success, under Adobe, relies on their ability to sell it. My, albeit limited, experience with pushing new versions is that people don't want to upgrade unless there are killer features for them. They don't want to upgrade if they have to rewrite to make it work. So breaking backwards compatibility while not adding significant new features is not really a successful combo for Coldfusion as it is now. And that's the reason why some of us pushed features instead of language enhancements.
We aren't just talking about one tag. For example, I never self-close any ColdFusion tags. For me, that makes the code harder to read.
If you enforce XML compliance, it breaks all of the code without self-closing tags. Although I think self-closing is common among the elite (I started with that term, I may as well be consistent), I still think that is the minority approach.
People are going to decide upgrades based on cost versus benefit. In order for someone to upgrade, the benefits have to be worth the cost of the product plus the trouble to upgrade. If the upgrade breaks code, then the cost is higher, which means the benefits must be even greater (to the majority, not the minority).
You're right in that I do close all my tags in XML syntax so I am in the minority here, in fact I'm in the minority on most of the ideas in this blog post! ;-) I knew I would be. I just want to be clear that I still love CF, I just think these ideas are very interesting and are worth serious consideration and frank discussion. Problems that the CF "elite" (still iffy on that word but anyway) are facing now are problems that the majority will probably be feeling in the not-so-distant future. So I think Adobe is wise to listen to the folks pushing the envelope even though they are currently in the minority, since more and more people will definitely be moving in that direction.
It's always been difficult for Adobe to balance the needs of the majority with the needs of the cutting-edge minority. CF users span such a massive spectrum of skill level and development approaches that pleasing everyone all of the time is going to be impossible. I certainly understand this, having used CF since 3.0 and watching my own development move from simple HTML and procedural CF to patterns, OOP, Flex, etc.
Maybe the answer is the scary prospect that I'm "outgrowing CF"? I don't want to think so. All of the wonderful abstractions like PDF generation, LDAP, mail, image manipulation, etc., are all a bear in other languages and I love that CF makes it so easy. It's just that these pain points I'm feeling right now have brought the issues I'm bringing up to the forefront and I felt compelled to bring them up. Especially since a number of other people I talked to at the conference are also dealing with the same issues.
Another possibility for Adobe is to actually create two products, as I alluded in a previous comment. Could it be that trying to please the entire spectrum of developers is becoming too hard as that continuum keeps getting broader? It seems that they might be able to leverage a great deal of the same underlying Java services across both servers. That would just mean that CF would keep going as it is now with no backward compatibility breaks and keep getting new features. But another, pure ActionScript and XML-based server language could also be created that is specifically optimized to power Flex applications. They'd both be quite similar in many ways, so people could use whichever one made the most sense. And the overlap in use cases would be quite small (basically limited to Flex work) so I don't think they would really be in competition with each other since the vast majority of CF'ers are building HTML and AJAX apps, or non-data-intensive Flex apps. Maybe that is an interesting alternative?
There would be a number of "normal" looking pieces of CFML code that wouldn't be allowed:
<cfset myObj = createObject(...) />
<cfif variables.something eq "foo" AND ... > ...
<cfif>...<cfelseif>...<cfelse>...</cfif>
Changing that stuff to somehow conform to the rules of welformed-ness would be a nightmare; ActionScript inside CDATA tags, ala Flex, would be the only real option - but that's not CFML at all! And you still can't mix this stuff with HTML4 because it won't be well formed, or even XHTML because you may then have nesting issues.
It's a huuuge can of worms as far as I can see :P
Besides, which other programming languages can you reliably run an XML parser on anyway? :)
In that light (and assuming there aren't plans to actually develop another server product focused on Flex/AS/MXML), I'd re-frame my requests to be that they allow server side AS and/or bulk up cfscript, and focus on a way to optimize sending objects to Flex. Though what that could be, I'm not sure. Another option might just be to allow even more seamless integration with Java/Hibernate, and make it really easy to move stuff to Flex straight from Java using more optimized Java objects based on CFCs instead of full-blown CFCs, or even just using actual Java objects. This is already possible to some degree, but it involves using JavaCast a lot and that can be annoying. If they could figure out ways to deal with some of these issues, that kind of option might well address the needs of the people who were "grinding axes" at cf.Objective().
As I've been moving away from doing HTML UI's, my perspective on CF has changed a good deal. While I think ColdFusion is top-notch for doing HTML UIs and the whole view/controller side of the equation, modeling applications in CFCs has become both a hassle (typing them kills me now that I'm used to other languages) and a liability (they're _still_ not terribly performant in comparison to raw Java, where I can still go dynamic via Groovy). Because a good deal of my work is now in Flex, I have less and less of a reason to use ColdFusion unless I need to render HTML - at which point it's simply the best tool for the job and definitely worth its price a few times over.
My main point (not an axe grinding) was that I think compiling AS3 to the JVM would be a smart move for Adobe. I'm not sure if it's technically possible, but I'd love to work server and client side in the same language. If it did work, though, I doubt many objects' source code wouldwork on both sides of the fence as many of us would hope - they're likely to rely on server-side Java objects or client-side-only AS3 objects. However, putting out a product that bundled server-side AS3 on top of a JPA solution like Hibernate would enable a lot of RIA developers to work on the server side as well as the client side: sort of like how CFML allowed many people used to client-side HTML to work with server-side services like databases.
Taken at face value, that idea may seem to have little to do with ColdFusion, which could be seen as a distraction in that BoF. I do think that this "server-side" AS product could help introduce RIA developers to CFML as a great way to do the "web sites" that wrap or support their RIAs. If AS3 compiled to the JVM for model purposes, and CFML is a stupid-easy way to write a presentation side that can use the model they've already written....it'd be a no brainer to choose CFML as the HTML complement to a RIA over its competition.
I guess I am looking at it from the point of view that if there is more than a well we can program AS3 over there, why can't we here.
In my 12 years of Coldfusion development, CFScript has got to have been one of the most exciting things that was introduced all those years ago. But it was also the biggest let down as well.
In my opinion, and I know it isn't that hard to do. As I am able to do it with openBD, would be to levergae of JSP type syntax. The engine is built ontop of java, it has this capability why had further complexity to the situation. I mean, how nice would it be to have a .cfml page running that could not only run its native language, but to also run jsp?
If anything I would have more liked to have seen AS3, really become more like the server sided language. But this went down that track because of Flash and keeping it more simple to learn.
I personally do not see any benefit to having AS3 on the server, other than the fact a user is not learning another language. But what about the Enterprise market, where there are more Java developers than AS3 developers, do you alienate those users just to please a small handful of designers?
I don't think so.
Surely you can't think that giving Java folks to code in AS3 would be any "more alienating" than asking them to code their model in tags? AS3 is very similar to Java in many ways, and I'd bet heavily that any Java developer would much, much rather write AS3 than write cfcomponent and cffunction tags. Am i misunderstanding what you're saying?
JSP is not about displaying pages, no more than Coldfusion is.
The difference is that Coldfusion doesn't technically have an abstraction layer that is noticeable like the Java world, where the servlets, EJB's etc are written in Java.
The point is that with JSP, you can leverage Java syntax and write Java code in the JSP's. Coldfusion compiles to Java, and I stronlgy believe that the language would be much faster if it didn't have to interperet a language, and compile this to java at runtime.
I mean if they are that similar then why push for AS3?
I would like to see speed enhancements to Coldfusion, and the biggest speed enhancement would be to remove as much work away from the interpreter and compiling to Java as much as possible.
What do you mean it is about the Model, do you mean that as in MVC?
If that is the case, then that is NOT a strong argument to adopt AS3 on server sided technology.
And for Coldfusion to further its market share, it really needs to be as optimised at runtime as possible. That is my argument against AS3, I see no pros for it to be apart of Coldfusion other than adding to the complexity of compilation time and that is not what we need to do with Coldfusion.
JSP is *only* about displaying pages. That is the entire point of scriptlets and JSP tag libraries. Anything related to Models is written in raw Java. Yes, I mean the M in MVC. CFML (and JSPs) excels at the View layer. CFML also is useful at the Controller layer. But when it comes to Model code, as in writing domain models, it is quite verbose. The same is true for Java: people write their display code as JSP, but they write their Models as Java classes. The two are definitely not the same thing.
The point is that regardless of whether they improve CFScript, or let us write AS3 classes, or even let us integrate more easily with Java classes, we need some better ways to build our Models. Why is wanting more concise scripting support a bad argument for wanting server-side AS3?
I guess you must not see opening up server-side development to the millions of people already coding in ECMA languages as a pro? Or that fact the AS3 would be much easier and faster to compile to Java than CFML, because the syntax is already so similar and AS3 is already strongly typed? We already *have* the complexity of runtime compilation and nothing is going to change that unless we drop the dynamic nature of the language entirely (which isn't going to happen). AS3 is a strongly typed dynamic language, so I think it offers a very nice bridge between the overhead of a totally dynamic, weakly typed language like CF and a statically typed language like Java.
I used jsp type syntax, because everyone is talking about cfscript becoming AS3. JSP syntax is loosley based on java.
If you want to talk about classes, and true OO objects then lets go back to the roots of the underlying engine, this will do a number of things. It will remove the need to interpret the language into Java, and will give us a speed increase.
I realise that I did mention JSP, but like you said you hadn't taken the whole thing in I guess.
I have had this discussion many times, everytime I hear about why can't we make it more like AS3. Flex and Coldfusion are 2 different products, I don't believe in making things any easier just because the people learning Flex can't be bothered to learn something new.
But I say that and I'll get flamed for it, but the reality is simple. Coldfusion is a server product, and has many more uses than just to have a backend solution to a front end product.
If anything, I would rather see Flex adopt the Java language. And I tell you know there are more benefits from doing that, than getting coldfusion to use AS3 as a scripting language. One right of the top of my head, is the ability to return a class, and not have to reproduce its methods in Flex.
Now that would have been more intuituive than discussing how Coldfusion should adopt AS3.
OK, so we know ColdFusion (as Joe has said) makes it "stupid-easy" to render HTML off of dynamic data. My approach has become to to let ColdFusion do what it does best, and no more. No AJAX generation or any of that silly UI stuff. Leave that to the AJAX frameworks, or Flex, or whatever your UI is going to be, that's what it was designed for, CF wasn't. Let CF focus on two things: Getting data into and out of RIA front-ends, and rendering HTML with dynamic data. Beyond that, let Java, .NET, or whatever do the work.
This approach solves much of what the "vocal minority" at the BOF were asking for. You get the best of both worlds. You get all of CF's ability to devlier data and render that static UI, plus kick-ass services: CFMAIL, CFPDF, etc that you cannot and never will be able to do easily in Java (my OO lang of choice), plus you get the things that Java does well: strong-typing, easy persistance (Hibernate), strong IOC utils (Spring), and a true OO language, plus a ton of other stuff that CFML just doesn't do well.
I think that there are some CFML developers who are not necessarily "outgrowing CFML" as Brian has put it, but learning that there are other tools in the toolbelt besides your favorite hammer. Is that so bad to realize and use those other tools? I don't think so. I think it's a natural progresison of the good developer to push themself to, occasionally, learn other languages and not be complacent with just one language.
My two cents.
CF will always have to be interpreted. There is no other way for it to work (unless you're saying the tag-based CFML language itself should be scrapped?). It already will let you call Java classes that you have created yourself. The main issue is in determining how to translate values from the dynamic, non-typed CFML language into Java values, which involves casting and all that fun stuff. The fact that AS3 has a lot of dynamic elements to it means it could be a very nice fit as a scripting language within CF.
I'm also lost here with "ColdFusion is a server product and has many more uses than just to have a backend solution to a front end product". While I'm sure there are people using CF for pure integration and nothing else, the vast, vast majority (99%+) are using CF as to feed data to a UI. That is reality. So I admit I don't really have any idea what you're getting at with this statement.
Clearly, given that there are already far more ActionScript and JavaScript developers than CFML developers, there is absolutely no way that Adobe is going to switch to Java for front-end development. That was already tried several times (Swing?) and has been a pretty dismal failure. Also, if they adopted AS3 on the server we would get the *exact same* benefit that you are talking about since the language would be the same on both ends. Having AS3 on the client and the server could open up some very nice options for eliminating code duplication if the two could be leveraged together.
You have to remeber that cfscript is not about CFC's, or is it about classes either. And I think that is where you are getting confused.
cfscript is much the same as
<% %> Is in JSP, thats what I refered to.
However, having said that I realise that something will need to change for Components. Or classes or whatever you want to call it, but whatever it will be something that is more than likely going to replace a few more things than your thinking about.
It has already being documented that there is talk about creating components with cfscript, so if that is the case then this becomes more like a JSP style syntax.
But again having said that, JSP is also Java based. What that means is that you can write java inline to your JSP, not that you would do it for your Model or Controller.
Whatever the road ahead, Coldfusion doesn't need AS3 in its arsenal. Look if Adobe wanted to release a library that allows you to CreateObject('AS3',some.as3.class) then so be it. But to look at replacing server sided code with another scripting language that is not Java is not even funny anymore.
As I stated I would rather see it more like Java, so that there is less runtime interpretation going on. The more Coldfusion is refactored for speed the happier a lot of people are going to be.
If the truth be known, Flex should have adopted the Java runtime syntax. The reason being is that I could as I do with webservices, return an object back to Flex and then use it as if it was created in Flex. This would also minimise the amount of code needed in AS3, and would also mean that Coldfusion could return true Java objects to Java applications as well.
One has to remember that the amount of Coldfusion web sites, currently outways it being used as a backend to Flex. So the logic would be to cater for the market that has been around the longest, and that is not Flex.
My biggest beef is that the Enterpriser market to Coldfusion is and has been an elusive market, there needs to be some serious changes there first before Adobe even contemplates the RIA market for Coldfusion.
Does that clear it up more.
Death to AS3 as a replacement to cfscript. It is not even funny anymore.
First of all we are primarily Java, and we don't use Coldfusion to do that.
And secondly there are more intranets, and other applications being used that are not feeding to RIA's. In fact 98% of the Coldfusion sites I visit are not feeding RIA content at all.
So where do you get those figures from?
What the hell do you mean by this "there is absolutely no way that Adobe is going to switch to Java for front-end development", Coldfusion is not for frontend development. It has always been server side code, and as for swing being a dismal failure. How can you claim that it has been a failure, in the Java world if you want to develop an application Swing was the only real way to get any type of UI. Swing was never designed for UI into a web page, due to the fact people did not really like java applets anyway.
Eclipse is based on swing design, so how can you claim it a failure?
The point of adopting AS3 on the server is not an issue, this is talk by Flex developers who are to lazy to learn server side coding. I mean you have a choice of php, java, .Net, grails, rails to name a few to integrate your backend with. The fact that Coldfusion is an Adobe product as well means nothing, cfscript sure needs work but to make it AS3 is a joke.
Like I stated in a previous post, coming from a server sided programing on my part. Maybe I should be petitioning Adobe to use java instead of AS3, I mean look at the benefits, not only do you get to use Coldfusion objects (provided they go with Java) as you would as an object returned via a webservice. But you can also use Java, then you can have a real choice as to what you need.
So the time as now come to make Flex AS3 die a horrible death, and to replace it with Java. I mean the amount of java guys would out way you Flex developers who have about 2-3% of the Coldfusion market.
Give me a break, let it be known AS3 might be better ECMA supported. But Coldfusion is Java to begin with now, and it is in its best interest to move with better integration into that rather than any other language it might use.
The next thing I would be talking to Microsoft and saying that 99%+ use .Net in Coldfusion so you need to give us better syntac so we can use it better *lol*
Sorry couldn't resist, but thats what this discussion is like.
They are 2 different products aimed at 2 different markets.
And there is maybe at best 5% of people who develop Flex, and use Coldfusion. There are more developers who use Coldfusion purely for websites, and intranets and that are not RIA applications. So you want to alienate 98% of the market because you think it is going to make your job better, what about the 98% that have been asking for better support in cfscript before Flex was a twinkle in someone's eye?
No you stated to feed data to a UI, UI is not HTML and there is a vast difference in what you first said to what you are now saying.
Your argument is based on RIA, not HTML. UI is more for RIA, and HTML is not for UI. HTML was designed for presenting of text, it has evolved over time. But as for RIA, that is left upto extJS, Dojo, jQuery, mootools, Flex to name a few.
Front end and Client side are 2 different things, and you are not going to get me to back down on 99% of people DO NOT feed to UI in Coldfusion.
I am sorry I will not budge on AS3 in Coldfusion, there is no need for that adoption into Coldfusion.
What I must not be getting across is that opening up server-side development to people who are already proficient in AS3 and JavaScript is going to create a huge flood of interest. Yes, of course they could learn PHP, Java, or .NET. But if they didn't have to, if they could leverage their existing skills with no effort, surely you can see how that would be an extremely compelling option for them? I promise you, it is no joke. My understanding is that an AS3-based server is already under very serious consideration at Adobe, for all of the reasons I have laid out. Whether it actually happens or not, or whether it ends up being a separate product or rolled into CF, remains to be seen.
Finally, to say that HTML is not a UI is also quite confusing to me. The majority of people using CF are using HTML as the UI. That is a fact. Whether you agree or not doesn't change the fact that when doing MVC work, the majority of people are using HTML as the View. This is an area where CF excels, since the tag-based markup compliments HTML so well. But when it comes to the MODEL, we need something easier to use. Whether that comes from CFScript enhancements, or from more seamless Java integration, or from AS3, or even from some combination, the point is that people are having issues with the current setup and are talking about ways to improve things. If you disagree that AS3 is the way to do this, that's fine. I respect your opinion. I would hope that you would respect mine.
Since your comments are becoming pretty hostile and we don't seem to be finding any common ground here, I'm going to go ahead and leave it at that. I'd rather get more input from other folks than keep this going and risk losing input from others who may have input but don't want to jump into this deteriorating thread. Thanks for your thoughts.
AS3 is translated to bytecode and interpreted by the AVM2 - ActionScript Virtual Machine (v2 - v1 runs AS2 and earlier). I don't believe the AVM does any translation to native code - which means AS3 is interpreted where CF is compiled.
(and I'm specifically talking about ColdFusion here - BlueDragon works differently, using a threaded-interpreted model like Forth, and I don't know how Railo or the other engines work).
My request for Abobe:
1.) no more white space. I've created web pages from other server languages which have little or no white spaces.
2.) Integrated IDE with Flex Builder.
3.) Better report builder.
4.) Better integration with the AJAX libraries.
5.) Total integration with Flex.