This is a follow-up post on "Source code of CFSummit2013 mobile application" . There has been a lot of discussion in the comments of that post, as well as on a number of social media channels. I saw that some of the reactions were based on incomplete understanding of these features.

But first things first - Mobile features in Splendor and Thunder are specifically targeted for mobile application development. If you are not doing any mobile development or do not plan to do so in the near future, then these features may not appeal to you.

ColdFusion Mobile features are not just about cfclient

A lost of discussion is happening around cfclient. It is being assumed that this is a complete feature. Well, it is not. It is a part of overall mobile development features of Splendor and Thunder. These features can be categorized in four broad areas - 


Writing mobile specific code. This is where cfclient plays a major part. You write code in CFML and our framework translates it to JS. I will come to why we had to implement this later.
CFBuilder also plays part in this by providing wizards for mobile projects, code assist for APIs and other editor features (like code hyperlink, code navigation, outline etc.).


If you have done HTML5 mobile development then you would know how difficult it is to debug HTML5 code running on a device (or for that matter in emulators/simulators). You either end up putting alerts in the code or run it with Ripple emulator and debug using Chrome debugger. 

But many times you would want to debug the code that is running on an actual device. There are no easy solutions available currently. We are trying to address this by providing a step debugger for the code written in cfclient.  You can set breakpoints in CFBuilder, step though the code and inspect variables. Again, all this works on HTML5 code running on devices (or emulators).

This is not possible only with CFBuilder. Server play a very important part of preparing code for debugging.


Weinre is a great tool for inspecting DOM. But it is not just useful for inspecting DOM. I find it very useful to see JS console log messages of an application running on a device. When an error occurs in JS code in an application running on a device, it is very difficult to see log messages. With Weinre you can do that. You can also inspect content of databases of an application running on a device using Weinre. All of this is useful for debugging too.

But Weinre requires you to inject JS code in every page. Splendor will be shipped with Weinre, which can be started/stopped from the administrator. It makes using Weinre very easy.

Both server and CFBuilder play part in injecting the JS code required for Weinre inspection. You can easily turn this on/off.


When your mobile project is ready for uploading to app stores, or directly on devices, you would want to package it first. You can very easily do that from CFBuilder by right clicking mobile project and selecting an option to package it. Of course you would have to configure a few things before you do that. But the process is very simple. We integrate with PhoneGap Build for packaging.

Again, CFBuilder and server work together to perform packaging. If cannot be done only in CFBuilder.

So, we are tageting all aspects of mobile application development with these features.

Why cfclient is necessary

This is the question many seem to be asking. Why we could not have just created JS libraries or provide REST Services? or Why we couldn't just create server side custom tags to implement these features? 

I will try to explain here why cfclient is required. But before that please understand that mobile features are also targeted for developing stand-alone mobile applications. You can categorize mobile applications as stand-alone (where code is executed on the mobile, but it might interact with servers for data or services) and web application (where pages are loaded from the server). I am not going to talk about native code, because that is not what we are targeting in ColdFusion. 

Mobile device can only execute HTML and JS (again I am going to ignore native development here). If you are developing mobile web application, then the server will generate HTML and JS code, just as CF generates HTML/JS output from CFML. But when you are creating standalone mobile app, CFML code is not going to work, unless you convert it to HTML and JS. That is what Splendor does - it takes all the code inside cfclient tag and generates JS code out of it.

But why write mobile code in CFML at all when we can do that in JavaScript

HTML5 mobile application development is largely asynchronous in nature, if you want to access device APIs, like client side database, camera, contacts, device file system etc. PhoneGap is a popular cross platform framework to write mobile applications that require access to device APIs. If you look at PhoneGap documentation, you will realize that most APIs are asynchronous - the way you write code is not sequential. You call an API function, provide success and error callback handlers. If operation is successful, then success callback handler is called, which is where you will write follow up code. 

ColdFusion developers, or for that matter many non-CF developers, are used to writing sequential code - except when a call is made from client to server. In the later case you don't know how long server will take to respond, so you don't want to block the UI of you application. So you call server function asynchronously. But device APIs are all executed locally and in most cases need to be called sequentially. Using asynchronous programming in such cases makes code difficult to read and maintain.

Let's take an example. CFSummit application reads session data from a file and populates local database. You can see this code in db_manager.cfc and sessions_mgr.cfc file in the source code.

I will take a small sub-set of this application and simplify it a bit. Let's say we want to create 'sessions' table, insert records into it and then fetch records. Fetching the same records from the table after inserting them may not make much sense, but you can imagine any other database operation like inserting or fetching speaker data.

If you have to do this entirely in JS, you might write the code something like this (I am trying to follow same code structure as in PhoneGap documentation here )

//It is not required to capture deviceready if you only want to acess database APIs.
//But I will go with the example given in the PhoneGap doc 
document.addEventListener("deviceready", onDeviceReady, false);

//global db object. Don't want to open DB multiple times
db = null;

//Following code first creates sessions table,  inserts records
//and then reads records from the same table. Notice how callbacks 
//are chained. 

function onDeviceReady() {
	db = window.openDatabase("cfsummit2013", "1.0", "CFSummit App	 DB", 1000000);
   	db.transaction(createSessionTable,errorCB, populateSessionTable);

function createSessionTable(tx)
	tx.executeSql("create table if not exists sessions (" + 
				"id integer, name text, session_info text, session_type text, speaker_name text,"+
				"start_time integer, end_time integer," +
				"room text, session_day text, my_session integer, survey_submitted integer)");

function populateSessionTable()
	var sessions = read_session_json();
	var callback = null;
	for (var i = 0; i < sessions.length; i++)
		//Read sessions only after adding the last session
		if (i == sessions.length -1)
			callback = getSessions;
		insertSession(sessions[i], callback);

function insertSession(session_vo, callback)
		tx.executeSql("insert into sessions (id,name,session_info,session_type," +
				"speaker_name,start_time,end_time,room,session_day) values (?,?,?,?,?," + 
				"time('" + session_vo.start_time + "')," + 
				"time('" + session_vo.end_time + "')," + 
	}, errorCB, callback);

function getSessions()
		t.executeSql("select * from sessions", [], 
			getSessionSuccess, errorCB);
	},errorCB, successCB);

function getSessionSuccess(tx, results)
	var len = results.rows.length;
	var sessions = [];
    for (var i = 0; i < len; i++){
    	 //skipping code to create array of session_vo objects from the result set
	//Retuning sessions from here is not going to be useful
	//because this function is executed asynchronously, so any
	//code that you want to exeucte after getting sessions has be 
	//be either in this function or called from this function.

// Transaction error callback
function errorCB(tx, err) {
        alert("Error processing SQL: "+err);

// Transaction success callback
function successCB() {

We wanted to simplify this. It would be much better if we could call device APIs one after the other, without chaining call back handlers. This could be done only be re-writing JS the code.

Now, we could have taken JS code that called device APIs in synchronous way, parsed it and generated asynchronous code, like above. But we decided to not do this using JS and decided to use CFML. The reason being - we are targeting this features for CF developers and they are most familiar with CFML. Also CFML has better syntax support for Object Oriented programming, database access, custom tags ( and in general writing HTML) than JavaScript. 

So that is why we implemented cfclient. Write mobile application code just as you would write desktop web applications using CFML (but adding device APIs to it) and we will take care of converting that to JS. This will make your mobile application code easy to write, read and maintain. The same above code could be written in cfclient as follows - 

<!--- It is not necessary to enable device APIs if you want to 
	access only data base APIs. But since we are comparing 
	this code with PhoneGap JS code, I will enable the APIs --->
<cfclientsettings enableDeviceAPI=true >

	dsName = "cfsummit2013";
			//create sessions table
			queryExecute("create table if not exists sessions (
					id integer, name text, session_info text, session_type text, speaker_name text,
					start_time integer, end_time integer,
					room text, session_day text, my_session integer, survey_submitted integer)		
			//read sessions data from JSON
			variables.sessions = read_session_json();
			//insert session data
			for (var i = 1; i <= arrayLen(variables.sessions); i++)
			//get all sessions now
			variables.sessions = getSessions();
		catch (any e)
		function insertSession (session_vo)
			queryExecute("insert into sessions (id,name,session_info,session_type,
				speaker_name,start_time,end_time,room,session_day) values (?,?,?,?,?," + 
				"time('" + session_vo.start_time + "')," + 
				"time('" + session_vo.end_time + "')," + 
		function getSessions ()
			queryExecute("select * from sessions ",
				[],{"datasource":this.ds_name, "name":"sessionsRS"});
			//result is in sessionsRS

			var len = arrayLen(sessionsRS);
			var sessions = [];
			for (var i = 1; i <= len; i++)
		    	 //skipping code to create array of session_vo objects from the result set
			return sessions;

As you can see, the above code is much easier to write, understand and maintain that equivalent JS code. And note that above code also generates asynchronous code - UI is not blocked.

Do you think creating JS library and REST calls to the server could do this? I don't think so.

Are we making CFML ugly?

This is another criticism I have seen about our mobile features. How are we making CFML ugly? We are not changing any syntax. Yes, there are a few deviations from server side CFML, but for the large part it is the same CFML that you are used to writing on the server side. 

One of the criticisms about source code of CFSummit app was with this statement - 

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

This statement was in a page, which called many custom tags. It made sense to write the entire code in the same style.

I could have created a <cfscript> or <script> block and called this function. But does it change anything? After all cfset is the syntax for calling functions in CFML. I am not mixing JavaScript language in CFML, but calling JavaScript API from CFML. If you had to call Java API from server side CFML, would you not use cfset (in the tag syntax)?

Are we discouraging people from learning JavaScript?

This is another point some of the CFML developers are making. JavaScript as a language is very similar to cfscript. How are we discouraging anyone from learning JavaScript. Just because we allow JavaScript APIs from CFML? As per this logic we must be discouraging people from learning Java also.

And note that client side CFML and JavaScript are totally interoperable. You can intermix client side CF APIs and JavaScript APIs - not languages.


Concerns regarding we may not do a good job of implementing these features are valid, but we are working very hard towards getting these features right.

So, after reading this post, I hope you take away following key points - 

  1. Mobile features in Splendor and Thunder are specifically targeted for CFML developers, who want to create mobile applications
  2. cfclient is not an entire solution/feature, but part of larger solution/feature which involves support for developing, debugging, testing and packaging mobile applications.
  3. cfclient does not generate any UI. You can use any JavaScript UI library with cfclient
  4. We could not have just created JS library and REST service to implement these features. Creating REST services is already supported in ColdFusion and can be very easily called from JavaScript. 
  5. cfclient is not a wrapper for any JS library.
I hope those who are skeptical about these features would give it a try when public builds are available and provide constructive feedback.


70 Comments to “ColdFusion mobile features are not just about cfclient, but it is necessary”

  1. existdissolve
  2. Brad Wood
    Thanks for the post Ram. This helps me understand the vision of cfclient better.
  3. Adam Cameron
  4. Andrew Scott
    OMG you can't be serious......

    I tried to be optimistic with what people had been saying about this new cfclient and I am sorry but you can't be serious.

    It is hard enough as it is now to educate people on the differences between server side and client side with so many people thinking that they can run CFML on the client side.

    And this...... OMG you can't be serious.....

    I can understand what you are trying to achieve, but I think you have seriously lost the ball on this one. In your thinking of not getting someone to learn a new language, so you get them to mix cfml and javascript which is going to make it so much worse.
  5. Jean Moniatte
    Not sure to understand what you are trying to achieve here. The only thing I know is that if it has to do with the HTML, JS, CSS produced by my application, I do not want the app server to have a word to say about it.

    And then it seems that you need CFBuilder to make this monster work. Can't a company like Adobe think of a less bloated solution? Please. You are on much better tracks with brackets (and it is OSS!).

    Are you sure to address a real need within the community with this? Or is it just to be able to put a "It does mobile too" sticker on the box?

    And finally, if it's about mobile, why isn't it called <cfmobile> ?

    You should listen to your community, drop the thing and focus on server side functionality. That is where ColdFusion makes a difference, not on the client side.
  6. Ram Kulkarni
    @Jean, CF mobile framework will not touch HTML and CSS that you have written. It will not even touch JS written in script block. But anything written in cfclient block will be translated to JS. I have already explained reasons behind it.

    The tag is called cfclient because it contains CFML that can run in any browser, though not necessarily all mobile related APIs would work.

    Would you be ok with tag generating JS code if we rename it to <cfmobile>?
  7. Michael Zock
  8. Jean Moniatte
    Sorry, I do not want the CFML server to generate/translate JS for me, regardless of the name of the tag. Too many ties, not enough flexibility.

    You are doing a very good job at answering comments, which is not easy when most of them are on the negative side. Thanks for that!
  9. Ram Kulkarni
    @Jean, yes I did not think you would use the tag if we rename it to <cfmobile>
  10. me
    I think some of the talk surrounding cfclient has been a bit hysterical.

    I also think more blog posts like this are useful, if not crucial, in helping people get their brains round what this new feature means.
  11. Jean Moniatte
    I will give it a try if you rename it <cfcrap> though :-)
  12. Ram Kulkarni
    @Jean, sure we will make a special build for you, only if you admit that is the kind of applications you build :).

    But seriously, I don't want to trivialize this conversation. Please give it a try whenever it is ready and then form your opinion.
  13. Miguel_F
    I still do not agree with the need for this functionality in ColdFusion either but I will give kudos to you Ram for being very responsive to everyone's comments. Thank you for that.

    The reason why I don't agree - I have been developing with ColdFusion for about 15 years. When I started I loved the included cfform tags that made things like client side validation easy. Back at this time the current set of JavaScript libraries did not exist. But after a short while of using these tags when I needed a bit more functionality/control out of those tags they did not support it. So I ended up having to write my own JavaScript code anyway.

    When I look at the cfform tags that are included in the most recent versions of ColdFusion they have not changed much in all of this time. Meanwhile, the rest of the world has come up with several JavaScript libraries that offer way more functionality and control.

    It seems these cfform tags were added to ColdFusion back in the day with the best of intentions. "Lets make client-side validation easier for our developers." Sound familiar? My fear is that these mobile features will suffer the same fate. They are not complete libraries (by your own admission) and they will never again be updated with subsequent releases. So anyone that begins their projects using these features will eventually need to switch away from using them as they need more functionality/control in the future.

    I will leave you with this blog entry from Adobe's own Ben Forta written last year. The title is misleading so be sure to read the article. (He is not advocating to no longer use ColdFusion, only it's builtin client-side support tags)

    When Using ColdFusion No Longer Makes Sense
  14. Ram Kulkarni
    @Miguel_F, I totally understand your concerns. But cfform and new mobile features are different. Language translator from CFML to JS does not use any third-party library. For device APIs we do use PhoneGap. But you can easily update it just by replacing JS files. And we use PhoneGap build for packaging, so whatever latest PhoneGap version that PGB supports will be supported by ColdFusion. When released, you will see that we have addressed your concerns. And if not, do tell us and we will be sure to fix it.
  15. Tim
    I think one of the biggest issues I've seen is CF has never had a great track record with the JS it generates. So it's a little scary to have a whole feature set to generating JS. Would you be willing to show the JS that get generated by cfclient in this example? I know that would put my mind at ease.
  16. Ram Kulkarni
    @Tim, we are still working on optimizing code generation. But when builds are available publicly, you can easily see the generated JS code.
  17. Shawn
    Really don't know what's with the shock and awe. In Flash it was Actionscript and it had to be compiled so Flash Player or the Mobile OS could understand it. So here its serverside and needs it be compiled to work client side, the only difference is you happen to understand the before and after languages.

    Sure there is a chance it could get dated, but they have been trying to curb that and mobile is very important piece for the product and core of Javascript changes so rarely that I think its unlikely to be dated.

    More importantly it acts as a bridge for the team to turn anything server side into client-side (assuming they are willing and able to include the libs), so when they build a new feature it will open the users machine's resources to do the work, and by coding it in one language it will be seemless and portable. Even existing features, today you want to do as much as possible on the client to maximize server resources. This is far underused by developers today. Some of that is security for being exposed to be fiddle with, but its also cause lack of robust abilities without extra effort, or sometimes its just personal preference. So CF is solving two of the three.

    ColdFusion cannot win marketshare being a server-side only product. It needs to be a web development product and that includes getting involved in client side and mobile devices.
  18. Tim

    I have to disagree with:
    "ColdFusion cannot win marketshare being a server-side only product."

    Why not? What if CF was just a really good (and focused) server side language? What other server side language is winning at this?

    I'm not saying it's an outright bad idea, just that it's no grail.

    Personally I'd prefer if it shipped with a JS library to give shortcuts to everything, making it easier for us to do it in JS, and interact with CFCs and server calls etc. So our CF can be CF, and our JS can be JS.. but helped along with libraries for both languages to act as a bridge.
  19. me
    It does seem attractive to be able to interact with client side databases as easily, and with the same code, that I can use server side databases.
  20. spills
    Thank you for taking the time to respond but, I have to say after reading this, I have even less confidence than I had before. You make it sound as if no one is able to remote step-debug a mobile app currently, which just not accurate and to say that somehow a HTML 5 app is hard to debug is silly.

    I am surprised that you think this is needed because, "...ColdFusion developers, or for that matter many non-CF developers, are used to writing sequential code - except when a call is made from client to server" just because CFML doesn't have "callbacks" or the the like, ignores the fact that AJAX has been used for a long time in web applications and being asynchronous there are accepted ways of dealing with this. If a developer is writing a HTML 5 app and does not understand this already, I think you have a larger issue.

    I have concerns with your ability to keep generated code updated with current releases of updated Cordova/Phonegap packages.

    Ultimately this idea may be useful for some CFML users but, as a separate tool and not part of the core of Coldfusion imho.I would rather you guys concentrate on improving server application packaging, allow me to use a non-hacked version of Tomcat, improve REST services, or have an enterprise testing framweowrk and debugger etc...

    Again thank you for responding.
  21. Ram Kulkarni
    @spills, I said HTML5 mobile application running on a device it difficult to debug. I did not say no one is able to do that. But I would be interested to know what tool you use to debug HTML5 application running on a device.

    Regarding AJAX, I have already said that when you want to fetch data from the server, asynchronous call makes sense. But when you have many asynchronous calls one after the other that are dependent on each other, it does make code difficult to maintain. Take a look at the small snippet of JS code using PhoneGap APIs that I have posted.

    And we have taken care of updating libraries easily.
  22. Carl Von Stetten
  23. spills
    @Ram We are currently testing an upcoming product that has specific adapters for Phonegap, but there are at least two other commercial products I am aware of at least for Android. Remote IOS 7 debugging is another issue all together but we have successfully done this with an adapter.

    Remote debugging aside, how do I unit-test your generated javascript?

  24. Ram Kulkarni
    @spills, generated code retains user defined function and variable names and overall logic of the code. You can call/use these functions/variables from pure JS code. So any JS specific unit-testing tool should work.
  25. spills
    @Ram You say "...when you have many asynchronous calls one after the other that are dependent on each other, it does make code difficult to maintain..." it can be, so what. I expect web developers to understand this, silly me. There are numerous ways of abstracting this complexity available if wanted. I think you guys have blinders on and are not looking at all the developers before you, that have already been there and have already created community supported tools/libraries and methodology to handle these issues in a best practices way.
  26. spills
    @Ram Thanks for your time this is my last post, promise! You say "... generated code retains user defined function and variable names and overall logic of the code..." what do you mean by "overall" as that implies something is changing/modifying my logic? I still don't see how I can write valid unit tests first and not be in control of the generated code to make the test cases be useful.

    Thank you for your energy and commitment to Coldfusion. The team does seem dedicated to CF's future but in this case not sure I agree with the use of time and money on this.
  27. Will S
    I also think Adobe guys have blinders on and are very adamant in trying to take the feedback that community is providing them.

    Adobe has mentioned this several times that this feature is not targeted to anyone who can learn JavaScript or knows JavaScript. Then it is fair to call this tag <cfcrap> because it will help create only crappy mobile applications.

    I will be interested to know how subtle issues around DOM, callbacks and execution order will be handled while mixing CF generated JavaScript and user provided JavaScript.

    The comparison with CFML generating Java and Cfclient generating JS is misleading. There is no mixing of CFML code and Java code that happens, so CF server can do its job without worrying about ordering issues or other variable/scope issues. But with, intermixing of CFML & JavaScript code, an end user application will get into crazy difficult to debug and maintain issues.

    Adobe, please give us CF12 next year - you can keep cfclient with yourself.
  28. Doug Cain
    From reading this thread it seems in simplistic terms that <cfclient> is behaving like cofeescript which is quite popular I believe to abstract and produce compiled JS.

    It also trying to allow direct JS API access in a way that sort of mirrors direct JAVA API access.

    Both are interesting ideas but only apply to packaged mobile application deployment, not really enabling simpler "general" mobile interaction with CF.

    Whilst I can see the potential for creating easily packaged mobile apps for a minority of developers i'm not sure it is a main stream feature, unless CF if becoming a "mobile first" type product.

    I just feel there are bigger fish to fry in CF. Maybe actually fixing existing issues (like cfpresentation, so we can produce powerpoint files on a par with cfspreadsheet (but fix its memory issues), PDF forms, perhaps a cfword?) and stop us going to 3rd parties like Aspose to fix functionality that is just broke in the current CF.

    Roll on CF12 it is sounding like a much stronger release than 11 at the moment for my traditional server side needs.
  29. Michael Zock
    So far, I have to agree. With CF's track record regarding auto-generated JS, the main (and probably sole legitimate) use I see for this is quick trow-away apps to test something.
    Kinda like using CFDump to check generated structures before you place real checks around the variable for more in-depth validation.
  30. Sean Corfield
    First, thank you for taking the time to continue explaining how cfclient works (along with the CFB mobile features). As several people have said here: you've completely missed the target on this one.

    That initial JS code you show is not complicated. The CFML code you show is close to identical - but doesn't seem to use transactions (which the JS version does) and doesn't seem to have as much error handling (nor does the error handling that is there do the same thing).

    The CFML code is less structured and less modular too.

    One of CFML's biggest problems in terms of reputation and image is that it has allowed people who don't know what they're doing to build crappy apps that they don't understand. All the previous attempts to encapsulate something that was never that hard to begin with, in order to "protect" devs from themselves, have been pretty much unmitigated disasters - and have perpetuated this image of CFML devs as bumbling amateurs who don't have the skills to learn how to do stuff properly.

    cfclient continues this tradition: it "protects" CFML devs from learning asynchronous programming, from learning JS, from learning how to structure mobile applications properly. The more you explain it, the worse the feature looks.

    Really, you guys should focus on getting CF12 out as quickly as possible and junk all this cfclient stuff.
  31. Tim
    Piggybacking on what Sean said.. (And my own original comment).

    We all appreciative the better tools, and the help at doing "difficult" things. But still let us do it, don't do them for us. The thought that comes to mind "Now anyone can build a mobile app!!", sounds good, but do we really want that? Why not encourage us to learn and be better programmers, rather than lowering the bar?

    You yourself said in your post:
    "This is the question many seem to be asking. Why we could not have just created JS libraries or provide REST Services? or Why we couldn't just create server side custom tags to implement these features?"

    To my mind, and it seems others, you still haven't adequately answered these questions. Also typically if someone pushes a product, and there's a great uprising of "we don't want that", maybe it is time to reconsider. Would you rather push a product that you think is neat, or one that your customers and active users really want?

    I have yet to see anyone on the "<cfclient> is the best ever" side of the argument. So why not at least table it for CF 12, re-poll your customer base to see how badly they want it, and in what form? Then it'll save you the time of developing the rest of something that potentially no one really wants, and give the impression you're really listening to your community. Only cost there is you have to remove the "Does Mobile Apps" bullet from your pamphlet.
  32. Cage
    Though I'd save final judgment until I see <cfclient> in action, I have to agree with Doug, Sean and Tim re: fixing current issues and making existing features rock solid. It seems as there are many "cool" features of CF but they only get you 80% of the way there and then one ends up spending many, many hours trying to complete that last 20%.

    A couple of examples of issues I've encountered in last few weeks which I think many mobile and web developers also encounter:

    1. REST services
    -> The CF version sounds easy but it's been a nightmare to debug. Any issue in the service results in 500 error and I have to write every other line to a log file to figure out which line caused error. Maybe I'm not doing it right but CF should point out an easier way.
    -> Why do I have to serializeJSON/deserializeJSON when dealing with REST services? And then do the opposite if I want to use the same CFC as REST vs normal remote call?
    -> File paths and permission are different in REST vs normal call to CFC. I spent so much time debugging locations and making adjustments whether it was a normal remote call to CFC vs REST call. Virtual application mappings didn't work correctly either so I had to hardcode certain file paths.
    -> What's the story with having to declare most if not all parameters in a REST declaration as strings to be on the safe side? Maybe I'm doing something wrong but every time I declared something as non-string, it wouldn't work just right.

    2. Cloud services
    -> Certain tags don't work with S3 services - e.g., mimetype. Or working with files in RAM. How about improving the support around this?

    3. XML parsing
    -> Make it easier and foolproof! Why do I have to use so many isDefined("") clauses??

    I think most people would prefer to code in JS and have it work as CFML rather than code in CFML and have it run as JS. There are too many "gotchas" in CFML right now to make it a pleasant experience.

    Now, one potential use case scenario (if I'm understanding what <cfclient> might be able to do) and would love, if possible, is the ability to create offline web databases/storage that is accessible via normal CFML database query calls. If it would support offline/online syncing, that would be a super-bonus.
  33. Andrew Scott
    As others have stated, the amount of time and resources gone into doing this feature, then I look at all the bugs that stop me from being proactive or just throw exceptions because of a bug in ColdFusion intermittently, how they are still not fixed and wonder how many more version do we have to wait before the line debugger actually works with singletons stored in the Application scope or slows down when or hangs for no reason.

    If Adobe want to do these things as side projects to fit into other aspects of their business, then modularize ColdFusion and get team resources dedicated to doing that project, but for god sake fix all the older bugs and expections that still plague our language with forcing me to pay over $1k for because your too damn lazy to fix and maintain the actual language itself.

    I am not interested in Mobile development, so why should all the bugs and problems and ORM hooks for more events, 100% cfscript support (promised in CF 10) and yet still not 100%, be something you will actually complete, finish or implement for those of who need it now? Not 5 years and not 10 years, I asked for better hook integration where we could right our own events for ORM or at least give us the events we need and yet I am getting something that I will never use for my $1K upgrade fee....

    Now I know why so many people are still developing in ColdFusion 5..... Adobe you seriously need to get your head out of the clouds and start listening to your existing customers before they move on.
  34. Tim
    Why has Adobe left an engineer alone in all this bashing when this decision on cfclient looks like a mobile ready checkbox decision.

    Where is Adobe's product manager and business team hiding? Was this feature shown to ACP or during private betas to community leaders? What was their feedback?

    I saw Ram asking Sean if he haw done mobile development. How mobile development experience Ram had or Rakshith had before coming up cfclient feature? Which mobile expert or community leader was consulted during coming up of this feature.

    Adobe, lot of explaining for your business team. Don't let a quality engineer be at receiving end.
  35. Ram Kulkarni
    @spills, we don't change the logic in you code at all when we translate it to JS. If you are really curious to know how it all works, then I would suggest to wait till a public build is available.
  36. Ram Kulkarni
    @Sean, I am not sure if you suggested that JS code and CFML code are identical. I thought simplicity of synchronous calls was quite visible in the CFML code.

    I have always found asyc code difficult to maintain. I have worked on a couple of PhoneGap apps and after a few levels of chained callbacks it becomes difficult to remember what the program flow was - especially when you look at the code you have written after a gap.

    I posted those code snippets to show differences between sync and asyc style of coding. You can make it as modular as you want, but it was not my intention to bring out modularity in those code snippets.
  37. Ram Kulkarni
    @Tim, nobody asked me to write this post or explain our stand on mobile features. Since most of the discussion was technical, I jumped in and tried to answer questions.

    When this feature idea was initial proposed, I was one of the team members who supported it and did a prototype too. So if there is any criticism about this feature based on lack of total understanding of it then I do feel responsible and try to address some of the criticism.

    I did not ask if Sean had done mobile development. Regarding my experience in mobile development - I have been doing it on and off for the past two years. I have done native Android development, PhoneGap applications and dabbled in iOS app development too (but not much).
  38. Tim

    "When this feature idea was initial proposed..." Very curious to know who proposed this idea? It looks like it was not you, was it a an ACP or the business team? What are there credentials on understanding mobile application development? The reason I ask this is because, as everyone is saying, you are trying to solve a problem that doesn't exist.

    It looks like your mobile experience level is at a beginner stage, native and ios apps experience does not count as web app experience.

    Can you also clarify feedback from ACP during private betas if they were done?
  39. Rakshith Naresh
    @Andrew: The mobile framework is completely interoperable with JavaScript. But that does not mean you are forced to mix CFML and JavaScript in your code. You have the choice of using JavaScript whenever needed. Whether this has the scope for confusing novice developers, yes there is. That is where certain amount of learning has to be imparted. The documentation for this feature has to do a good job of describing the feature set.

    @Jean: Though the mobile feature set directly runs on the client side, there are a range of server side features within it that makes the interaction of client with server much easier than before. And, no we have not lost the focus of server side functionality just because this feature has been introduced. You will a range of direct enhancements available in Splendor.

    @me: Thanks. We are still in the early stage to talk about the entire feature set. We will come up with a series of blog posts about each feature under the mobile focus when we have a public beta.

    @Miguel/Tim: I agree that we haven't done a great job with some of the UI or form related features in the past. We are taking all steps needed to ensure that we don't repeat the mistakes. Entire feature set does not even venture into UI elements. JavaScript HTML and CSS are to be used to build the UI.
  40. Rakshith Naresh
    @Spills: Please wait for the public beta to happen to get a full understanding of the entire feature set. That is when we will able to explain the features in detail than individual blog posts to address some of the concerns. If you are keen in trying the feature set, then we can invite you on the pre-release. Let us know.

    @Wil S: Your statement that is feature is not for someone who knows JavaScript is not true. The framework offers productivity benefits to a CFML developer as yoy can use certain productivity features of server side on the client side as well. The UI has to be still built using JavaScript and you have the choice of using JavaScript or CFML wherever required. That is the reason interoperability is an important part of the APIs.

    @Doug: The framework that has been outlined is not restricted to mobile app development only. It can be used within a generic web application as well. It is only the Phonegap related integration that isdevice specific.

    @Sean: The intention is not to encourage developers from learning asynchronous programming. In fact, the UI and the related event handling has to be built using async programming. The tags or APIs provide an alternative of using the peoductivity benefits of CF for mobile application development. And saving yourself from a chain of async calls is just a fall out of that. This is not to discourage anyone from learning JavaScript or aync programming in general.
  41. Ram Kulkarni
    @Tim, I have enough experience developing mobile web applications to know its pain points.

    I don't think discussion about who proposed the idea and rections to it is relevant in the context of this blog post.
  42. Andrew Scott
    @Rakshith - Personally I understand what you are trying to achieve, you have gone about it all wrong and it is not something I will ever use.

    As for the learning curve in languages.

    Even though CFML script IS STILL NOT 100%, I would have been more inclined to write your wrapper in EMCA script and throw tags out the window.

    Sorry but define

    <cfclient> - Means I could then use this on anything that is going to be used as a client. People learning this are not going to easily distinguish between these. Won't matter how clear you make the documentation, people read that as ther last resort.

    Now I could understand if you used <cfMobileClient> and allowed people to write EMCA script and NO ColdFusion tags like <cfset etc., people then can learn very quickly that it is identical to CFML Script but it is not CFML.

    This is where everyone is telling you that Adobe have missed the point and the plot here.

    But I have to ask, where is ColdFusion aimed at. Is it the enterprise market or is the average Joe Blow developer. I ask because I don't see anyone paying so much money for a scripting language just to do mobile development and that is the key issue.

    If the language was total open source and didn't cost so much, just maybe, you are on the right track. But to keep adding features that the average person can't afford to go live with so much license costs, you are proving to everyone that Adobe is NOT interested in fixing issues that still plague us since ColdFusion 8.

    Nobody is saying you can't make the attempt, but seriously you need to work on the issues of the language first and foremost otherwise you WILL loose developers very quickly.

    I mean has Hibernate been updated to the latest version, has ExtJS been updated, has the debugger been fixed. Has the scrip now got 100% compatibility, now none of this has been addressed yet.

    If you want to keep your current developers happy, then start being proactive with fixing the product first and foremost before new features get added.

    I no longer program in ColdFusion as a living anymore, but still enjoy writing projects and keeping the community alive as much as I can in what spare time I have. But the reality is that we live in a world where as a developer ColdFusion no longer fits.

    I have been trying to say since ColdFusion 9 beta, that we need 100% ORM event coverage. The amount of times I needed to hook into the likes of postOrmFlush() to be blocked by the lockdown Adobe placed on hibernate it makes no sense for us to continue using something we have no ability to het into and make modifications at this level.

    I mention that because this feature is no different, those who are serious about this kind of development are going to WANT to get into the code an optimize it as much as possible. That to me would mean why would anyone use such a feature to begin with if they need to do this and so far people are saying exactly that.

    Sorry but the tools we need to be productive are not coming, for example it would have been nice in ColdFusion Builder 2 to have added better ORM hibernate integration, like the JBoss tools where people can introspect the data within eclipse. Yet we are still waiting for these type of tools.

    So tell the ColdFusion community how long it is before we start seeing some of these improvements, that are much more needed than some stupid mobile integration that could have been a totally separate project, that we will need to wait 10 more years for all this and they are going to be like @#$% you I can do it now with Grails, Ruby, python etc. So what really makes me want to buy ColdFusion.

    Something called cfmobile / cfclient / or whatever abortion of a name you call it, was more important.
  43. Andrew Scott
    And what about errors like these? Have these been fixed yet?

    ORM is not configured for the current application
    coldfusion.orm.ORMUtils$ORMNotConfiguredException: ORM is not configured for the current application. at coldfusion.orm.ORMUtils.getPersistenceManager( at coldfusion.orm.ORMUtils._entityLoad( at coldfusion.orm.ORMUtils.entityLoad( at coldfusion.runtime.CFPage.EntityLoad( at cfBaseORMService2ecfc1568570515$funcFINDWHERE.runFunction


    Bug 3634391

    These bugs have been happening intermittently for me, for three years and there is no sign of these being fixed or even looked at.

    But cflclient apparently is more important.
  44. Shawn
    @Tim it can't cause the web is so much more now. The product already dives into client side so not sure why this is a suprise. Charting is JS now, and that is a popular feature. The forms do, and while they may not be popular now because they are dated and unflexible, they used to be important before better means revealed themselves. Attatched to a better framework and open to more flexability they can make a comeback. Web Sockets is a critcial feature and it comes with a Flash failover giving CF apps out of the box way more penetration with Web Sockets than the others.

    There is just no way CF can be server side only. Thats the sure way to the product graveyard having the others engaing in client side and CF standing pat. Other languages like .Net do it extensively. They are even more closed with embeded UI controls and a standard IDE.

    To expect them not engage in client-side is a very one dimensional line of thought for the technology industry. Google heard the same criticism when it engaged in mobile devices. People said it was moronic for a search engine to build an OS for mobile. Think they regret it now? Think Yahoo wish they had that one back when they had marketshare? You can't be one dimensional in the technology field, or you'll be in your grave faster than you can dig it.

    If you wanted native apps, there is always Flash Builder, or a kindle book on Java and Objective C. That will give you exactly what you are looking for, and it will consume all your time. There are a lot of big companies backing web standard apps. Its early, but right it looks like native apps will be today's desktop developers a dated field outside of games, and web standards will be your web apps, everything else.
  45. Doug Cain
    @shawn agree that server side is not the only game in town these days but I'm not sure that CF should try and be a one solution fits all product.

    I dabbled with node.js recently and I haven't quite recovered from the experience as it blurs the lines so much between what is client and what is server (perhaps an innovative use of node.js <cfnode.js> perhaps).

    Anyway the main point is CF is a server side technology and its main strength is being one of the best "glues" to fit with all these other technologies.

    The strongest point for me as a CF developer is I can use Java, .net or some other useful tool to solve a problem and still control it with CF.

    The modular nature of CF12 sounds appealing to improve this even more,CF should play nice with as many technologies as possible, wrap the hard stuff BUT allow access to the full feature sets so when you get to the point the CF developer stopped you can still leverage the good bits - SOLR being a great example, cfcharts another (please update the server side rendering though).

    <cfclient> is sounding like it may fit that paradigm but needs to allow full access to it, inevitably the tags will only get you so far and then you need to get more advanced.

    I still consider it a niche feature but I think Adobe needs to sell it in the big picture as to why I want this and how it fits into a mobile future for CF.

    Technical discussion of how a specific feature works is very interesting, but I don't know why Adobe is adding it. Whats the strategic reason? Is there going to be more or is this just to allow Mobile App packaging for this release?
  46. me
    If you want to set up a mobile app business building complex iphone/android applications to rule the world there are some good options out there.

    If you want to set up simple mobile access to your sophisticated web application, cfclient sounds like it might be a useful first step.
  47. Robb
    I've been using Coldfusion since CF5 and my current employer has been using it since 4.5 to give perspective to my following comments. I nor my current employer has upgraded to CF10 because of the restrictive licensing issues and the lack of a sensible modern application deployment process. I have been waiting for years for real debugger and a real IDE, I was excited to see CFbuilder when it first came out but this product has languished as CFB2 was basically a bug fix release with extensions feature. The CFB 2 plugin has not been updated to run on any current version of eclipse since Indigo and won't install on Windows 8 without using compatibility mode. I have a lot love for CF and have produced some cool stuff with it but, my frustration with Adobe is at a breaking point. I want to support you but, you are in utter denial about the current state of the product and more importantly the developer base! The company I work for has been a loyal enterprise customer for years but they will be moving on to open source alternatives and most likely different platforms altogether for a variety of reasons.They have concerns about the ever shrinking pool of experienced and skilled CF developers and the very small ecosystem that Coldfusion server has around it. It is time you make Coldfusion lean and mean and strip away all of the useless crap like cfform, cfgrid, etc... and make server performance the number one priority. You can start by modernizing the language and don't worry about being backwards compatible, worry about being relevant. Why don't we have a CLI, testing framework, scaffolding, a real debugger or a NPM like package manager and why do I have use a proprietary version of Tomcat! Please finish features that are actually useful and even cool like CF ORM, Websockets, REST, S3 access and Gateways as these are far more important to the survival of this product than CFCLIENT will ever be! Adobe had an awesome mobile development platform strategy that worked well with Coldfusion called Flex, remember that?
  48. Cage
    Agree with Robb 100%.
  49. Sean Corfield
    "The intention is not to encourage developers from learning asynchronous programming. In fact, the UI and the related event handling has to be built using async programming. The tags or APIs provide an alternative of using the peoductivity benefits of CF for mobile application development. And saving yourself from a chain of async calls is just a fall out of that. This is not to discourage anyone from learning JavaScript or aync programming in general." -- so there's an inconsistency between JS "written" in cfclient and written manually - and yet devs will still need to learn async JS for general UI work. That is worse than just making them write async JS for the "special" CFML version of the JS. Don't you understand consistency and issues caused by cognitive dissonance?

    The more you explain cfclient, the worse it sounds. You've solved a "problem" that didn't exist by creating a mess of inconsistent rules and inflicting special syntax on devs that is neither JS nor fully CFML.

    I'm shocked that you really don't understand the mess you've made of this - especially when so many people are trying to explain to you what a mess it is. You're not listening to your customers.
  50. Shawn

    Several of my clients are in the same boat with the licensing and they refuse to upgrade, so I'm with you on that. They have said they are working on fixing it. I talked with Rakshith about it in depth at CFSummit, and I'm confident they will resolve it in a way that will make everyone happy.

    As far as stripping out the useless crap, what really makes it useless... the concept of that feature has no value, or just the way it was implemented causes you more headache then its worth. Thats the great thing about tags is you can overhaul a feature and make it work with old code. I'm sour on the features and framework of cfform, but I don't think totally tossing the feature is better than fixing the feature cause it still would save you time if it was done right. Many people here want to see things tossed vs fixed. Some of those things I agree with, some I just think they can be improved and be more flexible.
  51. robb
    @Shawn yeah the licensing is a real issue. I really don't think there is a debate about a lot of features in Coldfuison that are useless and should be removed. My team has been making a concerted effort to get up to speed with REST, backbone, and Angular and completely remove all Coldfusion templates that are outputting HTML and clearly separate client from the server. In doing this we have exposed a a great deal of business logic wrapped up in the views that we didn't originally see as business logic! This is one reason I absolutely hate the idea of cfclient as it blurs this separation, Coldfusion is not Javascript, Objective C, or Java nor do I think it needs to be. The tools for building HTML client sites already exists are mature and have large communities like backbone, Angular, and Knockout, grunt, bower, vagrant, node and lot more are mature and is what is going on around Coldfusion. How will you write a backbone site for Phonegap using cfclient? CFform was interesting in the early 90's not in 2013 soon to be 2014!
  52. Shawn

    So why engage in mobile this way? Well right now there is momentum gaining for web standard native apps. This has already played out historically. In the mid 90's most developers tailored their skills to desktop software. Then there was the silly minority group that wanted to try to do these apps in a browser. Well you can see how that played out. When you manage your accounts online, are you installing software on your desktop to do it or are you visiting their web app? The web standard approach dominated that space and software is now mainly games, security, and productivity software.

    So history is repeating itself on a new device. When they first came out all the cool stuff is native apps. There aren't a lot of types so people can just invest in something for Apple and feel confident on their reach. Well that is changing. Apple isn't the only game in town and apps need to reach all the customers and do so within a budget that doesn't involve development teams for each OS, thus once again the web standard approach is gaining steam. Well thats where we are at now. Nobody knows how it will end up, but you can draw educated conclusions based on history of similar occurances. If history repeats, then Adobe is on the right side of this.
  53. Robb
    @rRobb CFform was interesting in the early 90's not in 2013 soon to be 2014! should have been CFform WOULD HAVE bee interesting in the early 90's not in 2013 soon to be 2014!
  54. Shawn
    Well before the turn of this decade I used Flex, CF, and SQl Server. Each piece played nice yet seperate

    Today if I want to mimic that, I need to learn a form framework, learn an animation framework, remoting learn Web sockets with a failover to avoid bad penetration, if I want data bindings learn one for that, learn countless others for all other things needed to meet requirements, then if you want mobile, you need to learn the native language of each OS. At what point do you say this is getting rediclous. Look at creative cloud. They have an absurd amount of products in that offering, many are worthless to me. Some products have 4 spin offs of itself. At what point do you consolidate for efficiency to spend less time learning and more time developing. I don't want a tool for everything, just a few tools that work really well. If CF is one tool acting as many, then that saves me time as long as its flexability and depth aren't leaving me wanting more.
  55. Andrew Scott
    Well I have been advocating that Adobe should be moving to an Open Source or very easy upgrade path to the CFML language for over 7 years.

    With something like this it was only a matter of time, before the hackers started focusing on the older version of the product.

    Adobe, if you don't believe that this

    is serious. Then continue to ignore us developers and you will find more attacks like this on all the older version of unsupported version of ColdFusion in the wild. And let me tell you that the number of people using older unsupported versions of ColdFusion is higher than you care to admit.

    One day Adobe just may realise that we developers are more switched on than the ColdFusion product team, but 2 more years or even longer before Adobe even thinks about closing this gap with older customers, is going to hurt them because these companies are going to go to newer technology after these attacks.

    Going to be interesting to see how quick Adobe realise there future is now in doubt.
  56. Shawn
    With the new improved licensing coming, I really can't see much of an advantage to not upgrading as it will greatly increase your hardware performance and license value under a better for flexible EULA. I suspect there won't be too many hold outs given how stingy the CF10 EULA is and CF9 nearing its end of core support.

    Only thing that comes to mind is CF12 and language refresh, which will break some backwards compatibility. I could see some companies avoiding early adoption there, but there is a difference between early adoption and an 8 year old version.

    Security wise CF has made it pretty easy to defend against most vulnerabilities when used right and the lesser marketshare contributes to lesser attackers in general. However when CF does have a vulnerability exploited its been pretty big deal of late. Logging to a .cfm file to give hackers control over the server, and accidentally making functions remotely accessible were not small miscues. Hopefully the team can clean up the chances of future attacks. From what I've seen to date CF is far easier and cheaper to protect than the others and the apps I built are definitely in the line of fire.
  57. Spills
    @shawn While the CF team is devoting resources for cfclient and pushing the release date of cf12 to 2016 it will be too late. I know my company will have already moved on with an open source alternative or a new platform. I just can't understand how Adobe seems to be so out of touch with what is going in "real-world". As mentioned in comment previously Adobe will now be competing with Intel and the new IDX phonegap tool that ironically uses Brackets apparently. I have yet to hear what platform technology CFbuilder will use because the track record of product support of the eclipse plugin currently sucks.
  58. Mike Henke
    so essentially you build coldfusion's version of coffeescript? "anything written in cfclient block will be translated to JS."
  59. Shawn
    Improved licensing should be in CF11 not 2016. If its not, then yeah I'm pretty much in the same boat you are. About half the companies I work with would rewrite their apps and it would increase the challenge of getting new ones. I'm optimistic though, heard several good ideas that would fix the issue. Hopefully they make the release. I can't wait on CF12 either. Licensing is handled seperately with a business unit, so cfclient work shouldn't be taking away many resources to getting that done.
  60. Tom Chiverton
    Leaving aside weather CFCLIENT is worthwhile for me (it isn't) and/or if it will be the next CFFORM (maybe), I don't think this should be legal ColdFusion code:

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

    It's not in a CFCLIENT block of cfscript, if I read your post right ?
  61. Denard Springle
    The community has already raised a number of (very) good points about why <cfclient> seems like an odd feature for ACF to pursue, and I thank Adobe for taking the time to respond to each question and criticism leveled at them and trying to help developers understand the feature more thoroughly.

    I think, for me, the real problem I have with this feature is that I have absolutely zero need for it.

    I've already moved beyond CFML for all my mobile app development, except as a server-side back-end.

    We're a couple of years already in to HTML5 on devices, and the vast majority of CFML devs who write mobile apps, out of necessity, learned how to write, debug, package, etc. mobile HTML5/JS with one or more of the myriad of available tools and techniques that have been, and continue to become, available to do this.

    In short, <cfclient> is just too late to the game to be taken seriously by any of us who already moved into mobile app development with HTML5/JS.

    The vast majority of the developers I know have between 5 and 15+ years of development experience in CFML. The vast majority of those developers also know one or more other server side languages. The vast majority of them also know client-side technologies.

    I don't think you're giving CFML developers enough credit. We're not children who need to be spared learning how to be better developers by abstracting away technologies we really ought to understand to be taken seriously.

    JavaScript is a fundamental language and knowledge of its use is no longer optional if you're a web developer in 2013. Javascript frameworks already do a pretty good job of abstracting away the ugliness of pure JS. We really just don't need CFML to do this for us.

    Asynchronous development is *not* that difficult of a concept to understand. Writing asynchronous code is *not* that difficult to do, and neither is debugging it. Those of us who do it for a living know this, and we disagree with wasting your time building this feature set.

    I sincerely appreciate the effort Adobe is trying to make with mobile and I think PhoneGap integration with Builder is a good idea, don't get me wrong, but I have to echo what others have said - this is the <cfform> of today. It will be used by crappy developers to write crappy apps and will be largely ignored by the vast majority of the active CFML community. Maybe I'm wrong, maybe 'enterprise' level developers really, really need this feature to build mobile apps - in which case, have at it... but it seems 90% of the people who talk about CF on a regular all have a (very) negative outlook of this feature, which already dooms it to failure. In many minds, it has already been relegated to the 'unused feature set' bin.
  62. Denard Springle
    One more quick point worth making here...

    Dreamweaver CC removed all server-side languages (except PHP) and has centered itself around HTML5, JavaScript, CSS and includes a, rather robust, PhoneGap integration. Even Edge Code (aka Brackets) is all about front-end development. This leads me to the conclusion that Adobe understands that the majority of developers (regardless of server-side language) write HTML5/JS front-ends, with PhoneGap for mobile, and whatever they want for back-end technology. This also happens to be the trend in both mobile and web applications - HTML5/JS client-side talking to an API server-side. It's all the rage! :)

    Enter <cfclient>, which is the integration of JS (a client-side technology) with CFML (a server-side technology). This tells me that Adobe either a) doesn't communicate internally, b) doesn't really understand the trends, or c) is attempting to play both sides (though in a very limited way with CFML). Websockets made sense - what you guys did there was simple, brilliant and abstracted away some of the complexity of writing one in JS. This... this is something entirely different and I'm confused by the message it sends.

    What gives? Why is the CFML team working in the opposite direction of the trend that the rest of Adobe seems to be following?
  63. Shawn
    I'm not happy with the Dreamweaver removal of CF files and others. When they went there, I thought they were just going to drop the spinets and widgets based on those languages. It was a very stupid move to drop the file extension support. Dynamic apps use these extensions when they are building HTML5 solutions in their apps, so that was a pretty pathetic blunder to not be able to open files in other languages to generate HTML5 code. The bigger slap in the face to the CF product was to retain PHP.

    So Denard, my answer to you is all the Adobe products are very dysfunctional when it comes to a common corporate goal. Each one is looking out for its own interests. DW clearly thinks its spending too much time in server-side support, yet thinks if it loses PHP it kill its marketshare, so it has no problem throwing an internal non-CC product under the bus. Adobe really needs to solidify common goals and get everyone to play together. Adobe's best days were selling a well integrated end to end solution. Marketing wise its easy to see the company cares about 2 things, selling creative cloud subscriptions and selling CMS subscriptions and add-ons to enterprises. Their menu has some 50 links to products between those two things, yet can't spare 1 link for ColdFusion under web development. I really don't know how that conversation goes internally and actually holds traction. "Yeah about that ColdFusion link, we can't give you that because we feel that empty space is going to sell more product." To be honest at this point I wouldn't be surprised if they put a Dreamweaver + PHP link under web development. Under their Dreamweaver CC features page they call it "Modern New Platform" and "more confidence using the newly supported PHP 5.4."

    PHP was my first programming language and I didn't like it. Its messy and incomplete. Its marketshare is completely based on ease of availability. Its not all DW's fault though. CF licensing/versions offered have moved away from availability and more toward enterprise offerings. CF10's EULA really sealed that deal. I think that part was a mistake because CF will never be aggressively sold in their Digital Marketing solutions. They sell prebuilt products and CMS licenses, and the customization is all in Java. They have a better shot of growth in the CC umbrella.
  64. Brian
    @Ram thank you for providing more information and shedding light on the thinking behind the mobile development efforts. We need more of this discussion from Adobe and the CF team.

    Regardless of whether this is functionality one developer will find useful or another won't, my hope is that it works and works well. The biggest thread here and elsewhere is that CF has a history of introducing functionality that isn't ready for prime time and then takes one or more full version updates to fix or improve. I can live with a X.0 version release having some bugs...but they should be fixed immediately in version X.1 not 2 years down the road and require purchase of the next version.

    So as others have posted we need existing functionality to be rock solid before the introduction of major new features.

    I am interested in learning more about CFClient and testing it's usefullness before making absolute statements about whether or not it's worthwhile.
  65. Adam Cameron
    @Brian I think you raise a good point regarding ironing out issues expediently.

    I can't help but think having a decent-lengthed public beta on this would be a good idea, and indeed getting it out there sooner rather than later would be beneficial to the end result. For one thing it would get it in front of expect JS / mobile developers to sanity check. As well as n00b ones at whom it seems targeted.

    The prerelease phase of the ColdFusion dev cycle are always a good length, but the public phase of it is a bit short, IMO.

    It's probably also a good idea to treat it as a component of the CF11 release, rather than part of a monolithic monster, as that would facilitate a more rapid patching cycle, perhaps?

  66. nate
    I have been developing cf since the 1st version what was made way back when. It was attractive because it was easy and easy to make a database enabled application. I think the community has ruined CF. Ya all want to code in java script make everything OO, put everything in a cfc. make a bunch of simple stuff terribly complex. Phone gap mobile apps just add to that. CF should be simple, auto generate everything, and make all the jquery bs and the ajax that goes with it be behind the scenes. CF was once easy and simple and I could hire an 8th graded to code it, and it worked great. Ya ruined that and now cf sucks more than ever. Just saying..
  67. Andrew Scott
    @Nate, 8th Graders today are coding in C++ and C# and Java.

    Just saying.
  68. Tim
    @Nate, not a whole lot of job security in having skills that could be replaced by an 8th grader.

    You don't have to use the complex portions of CF if you don't want to, I'm sure the newer versions will still support the 5 tags you use.
  69. Adam Cameron
    @Nate: your attitude is *appalling* mate. I didn't want to pollute Ram's article with ire directed at you, so I've done it on me own blog, over yonder:

  70. Anonymous
    First of all those who are comparing a ColdFusion v1 with ColdFusion v11 are fools. Why???

    - During CF1 no one knows people will depend on internet for all their business.
    - There was very less or no Security risk.
    - Technology wise we are far away from CF1, whether it's Web Socket, Spread Sheet handling, Caching and so on...
    - Again in recent trend there is Mobile devices which is taking the market. So, whats wrong in adding that in ColdFusion.

    May be my word fool is little rough but if we really want ColdFusion to grow then please put some valid argument.

    I really appreciate the way ColdFusion implementing new technologies and adding security measure.

Leave a Comment

Leave this field empty: