The day 1 of CFSummit2013 was great. It started with Ben Forta’s keynote. It was, as expected, excellent. He talked about the history of CF, how it’s goal is still the same (productivity) and which features have worked really well and which ones did not work. It was followed by Rakshith’s demos of some of the new features in the next release of ColdFusion (code named Splendor). He touched upon language enhancements, improvements in PDF generation and Mobile features. My demos of mobile features followed Rakshith’s demos. Unfortunately by the time I walked up to the stage to present demos, we had almost ran out of time. So I had to rush through my demos. I had planned to show a demo of debugging mobile application running on a device using ColdFusion Builder, but could not do so. I was told that there were a few issues with audio and display screen during the keynote.
Adobe had set up a table where CF developers could meet and talk to CF team members. Many attendees came there and showed interest in the mobile work flow that we had presented. I also attended Simon Free’s session on Mobile development features in Splendor. He did an excellent job of explaining what cfclient is and some of its features. In the limited time that we had in keynote, we probably could not explain what cfclient was, but I think after Simon’s session people got pretty good idea of what it is. I am looking forward to the second part of Simon’s talk today.
There were many tweets yesterday about cfclient and how it is trying to replace JavaScript. I want to make it clear that it is not true. I can understand that some of the confusion could be because there is no build of Splendor publicly available to try out these features and you will have to base your opinions on what you see in the conference and what other people are taking about it. Having worked closely on mobile features, both on the server and CF Builder, I will try to address some of the concerns about mobile features in Splendor.
With cfclient, you are trying to replace JavaScript with CFML on the client side
As I already said, this is not true. We can never replace JS with CFML in the browser. All that cfclient would do is try to simplify some of the work flows. There are no features in cfclient that will replace, for example, JQuery for DOM manipulation, Angular JS for MVC, Bootstrap/JQuery Mobile/Sencha Touch for mobile UI framework. I saw some tweet mentioning that we are trying to replace these libraries with CFClient. Again, that is not true. In fact, CFSummit2013 application
that we build with Splendor also used many of these JS libraries.
On the server side, we compile CFML to Java Byte-code. Does that mean we are trying to replace Java? No.
JavaScript is so easy, why do we need CFClient
We never implemented cfclient with the intention of simplifying JS programming. Our goal is to simplify mobile application development using HTML5. And that is not just about knowing JavaScript. There are a few challenges in developing mobile applications using HTML5 –
Many of the device APIs are asynchronous. And asynchronous code could get confusing, both to implement and maintain. Most of the PhoneGap APIs are asynchronous in nature. If you try to use File APIs or Database APIs of PhoneGap, you will realize this. CFClient framework takes care of this complexity.
Have you ever tried to debug mobile applications on device? Currently it is very difficult. You will either have to rely on alert messages, or log messages to JS console . And it is not easy to see console messages when the application is running on a device. cfclient tries to simplify this too. CFClient debugger in ColdFusion Builder can debug cfclient applications running on mobile devices. You can set breakpoints, inspect variables and step through the code.
To display JS console messages, we have integrated Apache Weinre. When youuse Weinre, you need to inject a piece of JS code in each of your HTML files. cfclient helps with this.
Packaging the application is made easy by provide preference options in CF Builder and PhoneGap Build view, which shows you progress of the build and let’s you download the builds.
All above points have nothing to do with whether JavaScript is easy or not. It is the process of creating, testing, debugging and deploying mobile application that is complex and cfclient tries to simplify that. As with any feature in CF, there would be people who do not find this process difficult and they won’t need this feature. But I believe many people will find value in cfclient features.
Past experiences of CF generating JavaScript were not good
We acknowledge that. But that does not mean every attempt is going to have same problems. We have learn from our past experiences. One of the main issue with some of the features in the past, that created JS code, was that JS libraries that we used became outdated quickly and we did not release updates fast enough.
However please understand that cfclient does not create any UI, unlike some of the earlier features. We do use third-party libraries like PhoneGap (Cordova) and Modernizer. But we have implemented cfclient such that you can replace these libraries easily if you want. Specifically regarding PhoneGap, if you are generating a standalone mobile application and packaging it using PhoneGap Build, then PhoneGap build will inject this library in your packaged application.
Unless some of the APIs are totally broken, which will need changes in internal cfclient code, you should be able to update these libraries yourself. And if some of the APIs are broken, then we will release updater sooner, as Rakshith mentioned in the cfhour podcast yesterday.
I do agree that since the JS code is auto generated, it may not look as good as if you had hand coded it. It is also true that since CFClient adds layers of code on top of existing libraries and JS code, it may not be as fast as hand coded JS code. But then this is also true in the case of Java (byte) code generated from CFML on the server side. You will have to decide if benefits of cfclient outweigh these limitations. And most frameworks in any language add additional code layer which might affect the performance. You need to decide if the performance is good enough for you.
As I said, it could be difficult to get a complete picture of what cfclient does without getting a chance to play with it. When we release public beta of Splendor, give cfclient a try and then form you opinion about it.
-Ram Kulkarni
Ram,
Can you reply to some of Adam’s concerns on his blog : http://cfmlblog.adamcameron.me/2013/10/cfclient.html ?
Personally, my biggest concern is when there needs to be changes to the underlying Apache Cordova / PhoneGap infrastructure. As you know when Apple changes their SDK version they expect the world to do it too. When they say “SDK N+1 is out!”, they expect everybody to start using it within WEEKS, not months or years. This often causes new versions of PhoneGap to be released (along with Titanium and all the other frameworks). Apps written in older SDK versions are quickly rejected. This doesn’t bode well for CF with a track record of releasing security patches within a month and feature updates within 6 months (if even). I can’t see how these types of changes would be a higher priority than security updates. Additionally, in the fear of breaking previous code I see the implementation quickly aging and going into the same place that Flash Forms was where Adobe was afraid to update in fear of breaking customer’s code, but the feature becomes less and less useful because it is so far behind.
What would have been nicer would have been to provide something the other guys aren’t — lets say enhancing the included BlazeDS to work with HTML5 and Mobile Apps. Be able to provide real time data, synchronization, etc for CF users. It just seems that so much time and energy is spent focusing on these “for the managers” features and powerful features that could or should be innovated — those with staying power — are being passed up.
We depend on PhoneGap Build to support packaging applications for different SDKs. I can tell you that we have been using PhoneGap since it was version 2.0. We had an app built with 2.0, upgraded with 2.5 and was running till last week on iOS 7, when its certificate expired.
Updating libraries when new version is released is not a problem with cfclient only. Most software today use some kind of libraries. I can only assure you that CF Team intends to roll out updates faster if any APIs is broken.
Regarding what we could have done instead of cfclient – well, we did quite a lot of discussion and brainstorming before deciding to take up this feature. As for synchronization, my personal opinion is that it is very specific to app you are developing. Framework and do only so much in this case. BTW, we have implemented synchronization (mobile client to server) in CFSummit app. Schedule updates and synchronized whenever you restart the application or go to notifications.
I don’t know why you call cfclient as ‘for the managers’ features. Please give it a try and you may find that it is in fact ‘for manager and developers’ feature.
Adobe usually pushes their other products into ColdFusion like Spry, CFPDFFORM for Acrobat, CFPRESENTATION for Connect, and FLEX at the detriment of the CFML language. This is just the same with CFCLIENT and Phonegap. Is there a push for something like CFCLIENT in PHP or Rails communities?
No, but do we have to follow PHP or Rails lead? BTW, there was no push to use PhoneGap. It is just that CF team found it useful for our implementation.
This is nice the CF team found PhoneGap useful but as a ColdFusion developer I would appreciate Adobe to fixing old bugs and helping me with my daily issues like asset pipeline, package manager, better/easier testing integration, etc
It would be interesting to hear Ram’s response to CFSummit 2013 APK Teardown http://fusiongrokker.com/post/cfsummit-2013-apk-teardown
The product is still in Alpha. We are not even feature complete at this point and have not even begun optimization. Some of the extra files that have gone in the APK are from the time when we had done the first prototype of mobile features. Of course we will clean them up before public beta.
I am also aware that LESS should be compiled before packaging. But the LESS files I used were quite small and translation of LESS to CSS was hardly taking a few millis. We were going to explain all this when we were going to make the source code of CFSummit app public.