I'm go-presenting the Flash Israel 2011 opening keynote with Lee Brimelow tomorrow. Or rather, I'm trying to. Weather last night close to shut down DTW, so I never made my connection in JFK. I am now in Amsterdam, and have an 8 hour wait until the flight to TLV. I'll arrive in the wee hours Tuesday morning, not long before we have to present. Still, I'm really glad to be visiting Israel again, even briefly.
Somewhat related, back in April 2010 I stated that the new DOT 3 Hour Tarmac Delay Rule was a bad idea. I predicted that it would make airlines overly risk averse, pushing them to return to the gate too early, because canceling flights would be cheaper than risking huge fines. And the pilot on my DTW to JFK flight last night confirmed my fears when he announced that he'd like to wait in the queue longer, that he thought we probably could get out, but that the airline is insisting we deplane because we had just broken the 2 hour mark. Nice, thank you government, you have once again proven how utterly useless you are, and how the Law of Unintended Consequences is alive and well.
Ok, now what to do for 8 hours in Amsterdam?
The next generation of World Wide Web Consortium (W3C) standards promises to usher in new levels of interactivity and interoperability on the Web, but the transformation won't happen overnight. The media is buzzing about the promise of what HTML5 has to offer for the future of online interactive experiences, but buzz often generates along with it a lot of hype. At the same time, people are nervous about the current state of the standard, which browsers require what codecs, and how to future-proof their online media investments.
Our buddies at Brightcove attempt to set the record straight with a new whitepaper: HTML5 Video Facts & Fiction. Does HTML5 kill Flash and plug-ins? Is HTML5 video ready for prime time? They cover everything you need to know about the current and future state of one of the most important emerging standards for cross-platform online video delivery, HTML5.
The report is free, but registration is required.
In the interests of full disclosure, I'll state upfront that I am not a fan of <cfscript>. At least, not in its current form, and not how it has evolved since first introduced back in 1998.
Which is probably a good place to start this discussion, back in 1998. Cold Fusion 3.x (yes, with a space) was an important release. The truth is, with the exception of the introduction of Cold Fusion Studio, Cold Fusion 3 itself was rather anti-climactic, it did not add that much over Cold Fusion 2 (which had been a massive overhaul of the original Cold Fusion). What made Cold Fusion 3 so important was the fact that it was released in mid-1997 and early 1998 (versions 3 and 3.1 respectively), right when the .com juggernaut was in high gear, and right when building sites quickly (so as to go public a week later) was the mission of the day. Cold Fusion rode the .com wave magnificently, and (for better or worse) a huge number of the .com successes (and failures) were powered by Cold Fusion.
Which brings us to the Cold Fusion 4 planning sessions in the first half of 1998. We identified two areas of focus for Cold Fusion 4. First, apps were starting to become more complex and more critical, the term "enterprise" was being used in the same sentence as "web" for the first time, and words like "scalability" and "redundancy" and "clustering" and "failover" suddenly peppered every conversation. For Cold Fusion this translated into an acquisition in the clustering space, which then facilitated the release of ColdFusion Enterprise, and that in turn made it possible to raise the price of a Cold Fusion offering (as the lower price was becoming an obstacle to being taken seriously in larger organizations and deployments). Second, with Perl quickly falling out of favor for web development, and with ASP 2 just released and PHP starting to pick up steam among developers used to more traditional languages, we decided to introduce a scripting syntax to Cold Fusion for the sole purpose of trying to entice those developers.
So, how did Cold Fusion 4 do? The Enterprise focus was a huge success (even though we ignored the analysts who told us that the best thing we could do for the product was to tack a couple of zeros at the end of the price). The scripting idea, however, failed. Why? Well, for starters, <cfscript> never actually did enough. Sure, it made if statements and variable assignments feel more like they would in traditional languages, but as soon as you needed to do any real work you'd have to drop to tags anyway. Fail. In addition, the language was actually not like the languages whose developers we were targeting, and felt clumsy and awkward to them (which, in truth, it was). Fail. And finally, to be a viable option against perceived free alternatives you need to add value, not get in the way, and so as a result of the prior two issues, price became the deciding factor, and developers were just not going to pay for something that got in the way instead of helping. Fail.
Now, just to be clear, Cold Fusion 4 was one of the most successful Cold Fusion releases ever in number of copies sold. Cold Fusion 4 itself was in no way a failure. But the scripting feature? Yep, that failed. Miserably.
Over the years we kept tweaking <cfscript>, but never really committed to it. We talked about how to make <cfscript> a first class citizen in ColdFusion, we talked about introducing a .cfs file where everything would be in script, we talked about ways to expose all CFML tags in <cfscript>, we revisited the scripting concept with each and every release, but never really committed to it. It's not that there was no interest in the feature. There was, lots. But when you have to weigh features for releases you have to play the prioritization game. Add resources to Feature A and you have to remove from Feature B, or ship the product later, and so on. And every time we ended up having to decide between adding new features or providing users with an alternative way to do what they already could do. And each and every time new features won the debate, and understandably so.
Recently, with the releases of ColdFusion 8 and ColdFusion 9, we finally did commit engineering resources to improving <cfscript>. ColdFusion developers can now write CFCs in <cfscript>, they can access just about any CFML tag using scripting syntax, they can create arrays and structures using shorthand notation, they can use operators that actually look like script operators, and more. For some ColdFusion developers, this is a long overdue enhancement. For some. For others (arguably most) it's irrelevant.
And for me? Well, for me it's too little too late. Remember, the original intent of <cfscript> was to broaden the ColdFusion developer universe by making the product compelling and appealing to traditional computer language users. That never happened. And enhancing <cfscript> now, all these years later, is not going to make it happen either.
So does <cfscript> have any value now? Absolutely, but not as originally intended. Nowadays I see two primary use cases for <cfscript>.
First, it can indeed make life easier for ColdFusion developers. At its simplest, long lists of <cfset> statements are a pain, and the equivalent <cfscript> block is just cleaner and more elegant. Complex nested business logic can also be easier to manage and comprehend in <cfscript>. Moving back and forth between the various languages used in development is easier when using <cfscript>. Ever tried porting a Java or JavaScript or PHP function to CFML? Do it once, and you'll find yourself thankful that <cfscript> exists. <cfscript> can, and does, make life easier and more productive for ColdFusion developers. And I am fully supportive of anything that makes ColdFusion even more productive than it already is. Productivity is, after all, ColdFusion's very raison d'être.
But in addition, there is one area where I think <cfscript> can indeed deliver on its original objective, to some degree, and that is for users of other Adobe products and technologies, and most importantly, Flash. There are hundreds of thousands of over 2 million Flash developers and designers out there (far more than there are ColdFusion users actually), and many have top-notch client-side skills but have done nothing server-side ever. And now they need to do just that. I have lost count of the number of times a Flash user has asked how to generate an email message or make a simple database query, stuff that ColdFusion does so easily and beautifully that we take it for granted. I want ColdFusion to be the obvious choice for every one of those Flash developers and designers. This is a huge growth opportunity, and one that ColdFusion is uniquely positioned to address. And when you add AIR and Flash on devices to the equation, the opportunity becomes even greater and even more apparent.
So, be it to simplify the development lives of ColdFusion developers, or to empower Flash and Flex users, ColdFusion scripting is compelling and much needed. But, in its current form, <cfscript> fails on both counts. Why? Simply because <cfscript> today is an oddly bastardized nonsensical language that seems to be mutating rather than evolving. It is not JavaScript, although there are similarities. It's not Java, although <cfscript> CFCs look quite Java-like. Actually, to be brutally honest, it's not anything that any existing developers would recognize or find intuitive. And so while I am supportive of ColdFusion scripting, I believe that just as the original Cold Fusion 4 implementation failed to deliver, so is its current form hindering its own chances of success.
Scripting in ColdFusion? As I said, I'd wholeheartedly support the effort, but I'd want it based on an established language, similar to what we should have done way back when. Some have suggested that <cfscript> be implemented in JavaScript, and I'd be fine with that. JavaScript is used by just about every ColdFusion developer, and being able to use the same language for the client and the server would be useful and compelling. Others have suggested that <cfscript> be implemented in ActionScript. Personally, I'd welcome this option, and judging by the response when we sneaked this functionality at MAX I'd venture to suggest that the idea would be very popular.
I started off by saying that I am not a fan of <cfscript> in its current form. But I am most definitely a fan of solving the problem that <cfscript> could, and should, solve. As such, I'd like to see <cfscript> in its current form deprecated. And then let's figure out exactly what <cfscript> should look like in the future. That would be a very useful discussion to have (although I've definitely aligned with the server-side ActionScript camp on this one).
The Korean edition of my Sams Teach Yourself Regular Expressions was published a while ago, but my copies just arrived today, and thus this post. I've been writing since the mid 90s, and have dozens of translations neatly organized on my shelves. But, it's still quite a thrill every time I get my hands on a new translation. And this Korean translation is no exception. The book is beautiful and of particularly high quality, the printing is crisp and clear, the paper is a high-end off-white that is highly readable, the text shading I use to highlight matches in the Regular Expression examples was implemented really well, there is a nice pull out reference card in the back ... as I said, just beautiful. Any Korean readers out there? I'd love to hear what you think of this one.
Yep, you read the title correctly. I just hosted a Connect session at 39,000 from somewhere over Wyoming using Delta in-flight Wi-Fi. Chat, screen share, video share, even multiple presenter video feeds, and it worked really well. (I did not use voice out of consideration to my fellow passengers). Pretty impressive! Tweet 1, 2, 3.
