I saw reference to an article by Robert X. Cringely entitled “An AIR of Invisibility: Adobe has Microsoft in its sights” on Brian Rinaldi’s blog, and I’m very glad I did. Robert Cringely is consistently one of the most insightful tech writers and thinkers working today, which is quite contrary to this kind of totally nonsensical, worthless garbage that seems to be the bulk of tech “journalism” online these days, so I’m always interested in what he has to say. In this particular article he discusses the concept of “invisible software,” Adobe’s products that fall strongly into this category (namely the Adobe Reader and the Flash Player), and what this may mean for the future of Rich Internet Applications as well as their extension onto the desktop.

I strongly recommend reading Cringely’s article, but to summarize, “invisible” software is software that is so ubiquitous that you don’t even think about it anymore. It’s just there, and you know it’s going to be there on virtually any given platform. Cringely could only think of two pieces of software that have become invisible in this way, and perhaps not coincidentally they’re both Adobe technologies. For me, even though I realized when I first heard about the acquisition of Macromedia by Adobe that it was all about Flash, I think Cringely’s discussion really opened my eyes to what this all really means and what a colossally shrewd move the acquisition was for Adobe. Maybe they just got lucky and weren’t thinking about where we’d be today when they acquired Macromedia, but I doubt it. I believe they saw where things could go, knew how to get there, and it’s all just now starting to be realized and revealed to us.

What we’re experiencing right now is one of those points in time in which numerous seemingly disparate elements are actually very much related, and this notion became concrete for me this past week via two conversations. On the face of it these conversations seemed to be addressing completely different issues, but in reality they were coming at the same point from from different angles. Combine this with what’s occurring in the RIA and web development space at this moment and things get very, very interesting. Whenever this sort of situation occurs I think it can best be described as zeitgeist. A profound shift is happening, and we as developers may just be too close to the nuts and bolts of it all to see what’s happening. This all brought to mind my favorite passage from Hunter S. Thompson’s Fear and Loathing in Las Vegas:

“We had all the momentum; we were riding the crest of a high and beautiful wave. So now, less than five years later, you can go up on a steep hill in Las Vegas and look West, and with the right kind of eyes you can almost see the high-water mark–the place where the wave finally broke and rolled back.”

We’ve been hearing about RIAs for years now, but with the addition of the Adobe Integrated Runtime (AIR) and Microsoft Silverlight into the landscape, the web development world is finally about to change. Adobe’s acquisition of Macromedia was a substantial underwater seismic event, and we’re just now starting to see the waves forming. As in the Hunter S. Thompson passage above, before too long we’ll have the perspective of both time and experience to be able to look back and see where the wave broke. What has until now been known as “web development” is no longer solely about the web, and the browser and operating system are both about to become largely irrelevant. As it just so happens, irrelevance is a bit of a theme in this discussion.

Converging Conversations

One of the main things that has me starting to ask rather fundamental questions about what I’m doing these days is the fact that I’ve started doing quite a lot of Flex development. At first it may seem that Flex development is all about the UI, which in some senses it is, but this different perspective has profoundly changed the way I think about the backend of my applications as well. The mind shift I’m having through my Flex development combined with several conversations I’ve had in the past couple of weeks has me asking some rather existential questions. What kind of developer am I? A ColdFusion developer? An RIA developer? Is this really so narrowly definable anymore? Does it even matter?

The first recent conversation that plays into these questions occurred on a mailing list. (I’ll leave out the details to protect the innocent.) The gist of the conversation concerned Adobe User Group sites not use Adobe technologies, which spilled over into the oft-had discussion concerning Adobe’s position on ColdFusion. Adobe Labs doesn’t use ColdFusion, for example, and some people get rather perturbed when they see an Adobe web site using PHP as opposed to ColdFusion. Adobe.com does, however, use ColdFusion, which resulted from Adobe’s acquisition of Macromedia and the decision by Adobe to use Macromedia’s web site, not the pre-existing Adobe web site, as the company’s web site moving forward.

The reasons behind technology choice are many and varied. As a ColdFusion developer and proponent, I would of course love to see Adobe use ColdFusion as the technology behind all their web properties. But how realistic is this expectation? In the abstract there seems to be no reason why Adobe wouldn’t use their own technology for everything they do. In the real world of business, on the other hand, there are pesky little items such as deadlines and budgets, and in that context the “build vs. buy” decision becomes a very real one of dollars and cents, not to mention time to market. Does Adobe build something like Labs from scratch using ColdFusion, or if something already exists that does exactly what’s needed but it’s written in PHP, do they use that instead? For everyone except ColdFusion evangelists this choice is a no-brainer.

The second related conversation was one I overheard concerning Flex. In this conversation the topic of Flex development came up, and one person in the conversation said, “I don’t see the point of Flex. Until they get it running outside the browser I don’t think they have a compelling story there. It would be great if you could mix something like ColdFusion directly in your Flex code. Maybe they’ll get there eventually.”

Rather than jump into the conversation, which I suppose I could have done, I decided to ponder this for a bit. Is the person who made these statements simply misinformed, or is Flex still largely misunderstood by the masses? AIR is pretty new, so it’s not surprising that someone who isn’t neck-deep in the Adobe product line may not have heard of it, know what it does, and know where it fits in the development landscape. For that matter, even those of us who know about AIR are still figuring out where it fits and where best to use it.

I was a bit curious, however, as to why someone would think that there’s no compelling Flex story simply because it runs in the browser. Maybe I’m missing something, but to me, being able to take a complex application and give users a far simpler, richer interface than could be created with HTML is pretty compelling. Add to that the amazing speed with which you can develop a Flex front end, and I think there’s something exciting for both developers and users. Throw AIR into the mix–and yes, I realize I’ve been rather duplicitous on the value of AIR to this point–and I think this is a key component to the profound change in the air (pun intended) that’s occurring right now. As with all technologies they should be used where appropriate, but when I need a desktop-like experience in my “web” applications, I can write something more functional for the user in less time by using Flex, and soon I’ll be able to take that exact same application and deploy it on the desktop. That’s not just compelling, that’s rather mind-blowing.

The comment concerning the ability to mix ColdFusion code in with the MXML code was also interesting to me, and I think this was probably the real spark that started me down this thought process that I’m trying–perhaps in vain–to outline here. Flex is all about the presentation layer. It doesn’t care what technology is feeding it data, and it doesn’t talk to databases. That’s not its job. Giving people the ability to mix CFML in with the already-powerful MXML and ActionScript 3.0 would be an unwarranted and unwanted mixing of concerns with negative benefit. In reality, the fact that Flex doesn’t let us throw CFML into our front-ends is a technological enforcement of the way in which we should be building our pure CFML applications. CFML code in the UI should be related solely to the UI. In a CFML application we achieve this through good architecture, whereas Flex has this separation of concerns built into its DNA.

Flex’s job, and one it does extremely well, is to pull data in from anywhere and give the user the ability to work with that data in a highly interactive way. As a technologist I think Flex’s UI capabilities are just plain cool, but interactive charts and graphs, drag-drop, and slick state transitions aren’t just “cool,” they allow the user to interact with and visualize data in ways that would otherwise be extremely difficult or impossible. If there is one thing I took away from the recent Flex Maniacs conference, it’s something that Macromedia pushed hard and something that Adobe clearly gets and is pushing even harder: Experience Matters.

So back to the crux of this discussion. If Flex and other players in the RIA space don’t care where they get their data from, and they can talk to more or less any technology, what does that mean for ColdFusion? Does this better level the playing field for ColdFusion, or does it make ColdFusion invisible? Does invisibility for ColdFusion translate into irrelevance? Hold these thoughts for a moment, because in order to truly pull this all together we need to take a brief detour and discuss converging technologies. This is key to understanding the new Internet application development ecosystem.

Converging Technologies

In addition to these converging conversations, which include “Why isn’t Adobe using ColdFusion for everything?” on the one hand, “Why is Flex compelling?” on the other hand, and Cringely’s article right in the middle, we have to consider the convergence of technologies in order to get a complete picture of the change that’s occurring in the development landscape. We have technologies such as Flex, AIR, and Silverlight on the front end, and technologies like ColdFusion, PHP, Java, Ruby, etc. in the middle-tier and backend space. What’s interesting and challenging, however, is the endless combination of options developers now have at their fingertips, as well as the increasing number of “places” (which I’ll use as a generic term referring to where applications run) in which our applications will be used.

First let’s consider the front end technologies, because where the application runs dictates a lot of decisions that we as developers will be making as we navigate our way through the new development world. In general terms, applications can run in the browser of desktop or mobile devices, natively (meaning as an installed application or via a runtime such as AIR) on desktop or mobile devices, and can either require a mandatory Internet connection or be usable offline through the local caching of data. On a device like a BlackBerry, even a seemingly simple web page can function as an application by deploying it as an icon to the BlackBerry desktop. To the user, clicking on the GMail client versus clicking on an icon that launches a web page from their BlackBerry desktop is the same thing. They don’t care what they’re launching as long as it gets them the data they want.

There are clearly shades of gray here as well. Even the word “browser” means myriad things because the size and capability of the browser dictate what can and can’t be done with the application. In the case of Flash and Silverlight, the browser is merely a container for a virtual machine inside which the application code runs. With AIR we have that exact same application spilling over into the desktop via an OS-specific runtime, and gaining tremendous capabilities (as well as security concerns) in the process. Even the notion of being connected isn’t an absolute. Connected full-time or only occasionally? Does the device automatically cache data so it can be displayed when there is no connection? When we say “connected” what do we mean? Traditional high-speed Internet, mobile broadband, or a mix of the two with devices that freely switch back and forth? Does it matter? Should it matter?

We all know the hugely compelling story of Flash’s market penetration. Flash is on nearly 99% of all browsers, and new versions of Flash hit a 50% install base within six months of being released. Flash Player 9, which is what’s required to run Flex applications, is already on 83% of browsers. As developers we can write applications that run in the Flash player and know to a virtual certainty that they will run. More importantly, they will run in the exact same way regardless of the browser and operating system. The available AJAX frameworks are getting better at helping developers not have to worry about browser compatibility issues, but compatibility issues still exist, and having done both Flex and AJAX recently I can say that for me the development experience in Flex is far better than AJAX. That being said, the right technology for the job needs to be at the forefront of our minds. Flex isn’t appropriate in all situations, and neither is AJAX. Both should be tools in our development toolbox.

If the right technology for the job is indeed Flex there’s little to argue against it. There’s no huge price tag for server software like there used to be, the development environment is fantastic, many parts of Flex are open source, and you can rest assured that what you write in Flex will “just work” because of the invisibility of the Flash player. Not that Flex doesn’t have its issues, but even as young as Flex is (Flex 1 and 1.5 were little more than proof-of-concept technologies in my opinion), it’s a very strong platform that developers can use to give users better experiences both in the browser and now, with AIR, on the desktop as well.

Where appropriate, developers need to consider that users may want to use our applications in multiple ways on multiple platforms. For example, I’m currently working on an application that will have a full Flex client that will run in the browser, but based on some of the features the users want I can see making this an AIR application at some point in the future. In addition, users want to be able to access the application from a BlackBerry. Does that mean I have to figure out how to fit a 1280 x 1024 Flex application onto the BlackBerry? Even if the BlackBerry did have Flash (which it doesn’t), trying to cram the complete application onto a BlackBerry screen doesn’t make sense, and honestly that’s not even what the users want or need. A very simple subsection of the application is what they want to use on the BlackBerry, so we’re focusing on deploying just what they need as a BlackBerry application. To me as a developer this is simply a web page that pulls data from the same backend as the Flex application, but to the BlackBerry user it’s just another BlackBerry application they use to access vital data from the application.

As I’ve heard Hal Helms and others say over and over again, “To the user, the UI is the application.” When I first heard this statement I think I interpreted it a bit differently than I do now. It could be taken to mean that the user doesn’t care about all the technical wizardry that makes the application work, so whether the application is Flex with a Java backend or a simple series of HTML pages, they just want it to work and be easy to use. This is a perfectly valid interpretation. Viewed in the context of the current discussion, however, the statement could apply equally to developers if we remove “to the user” from it and simply state, “The UI is the application,” or perhaps more appropriately, “The UIs are the application.”

Clearly this isn’t exactly true since we developers still have to build all the backend nuts and bolts to make these various UIs work, but if we start thinking in these different terms it shines a completely new light on how we develop our applications. For example, I just bought a brand-new, fully loaded Toyota Prius, and there is a serious amount of technology going on in this car. The touchscreen navigation system alone is amazing, and when I think about that in combination with all the technology that actually runs the car (it drives too!), it’s rather astounding. What’s most impressive to me as a technologist, however, is what a phenomenal job they did in making sure that I don’t know or care (that much anyway–my geek curiosity still applies to a certain extent) how all this technology works behind the scenes. I just know I can push a button, say “Italian restaurants,” and the car will show me where they are. If only all the applications we build worked so well.

I preached in my recent presentation at CFUnited that the business logic of an application needs to be front-end agnostic, meaning any type of front end should be able to talk to the business logic layer of an application. This is accomplished by creating a service layer in your application that serves as a public API to the business layer of the application, and this service layer can be leveraged by multiple types of front-end clients. Not only is this a great way to separate business logic from the presentation layer, it also makes your business logic completely reusable as the front end of your application evolves or exists in multiple forms, as with the Flex client and BlackBerry example mentioned above.

When I gave this presentation the point I was trying to make was that the front end of the application is irrelevant, and that the backend should be detached enough from the front end that it doesn’t care what type of front end is talking to it. This perspective probably isn’t surprising given that A) I’m far more of a backend developer, and B) the title of the presentation was “OO Architecture Back to Front.” Since I gave that presentation I’m regretting the title a bit because I’m starting to think this puts the emphasis where it doesn’t belong, even for “backend” developers like myself.

Now that I’m thinking about things in a different way, it could equally be said that the backend of the application is irrelevant. From the perspective of the user, the backend is substantially more irrelevant than the front end. To repeat the wisdom introduced above, to the user, the UI is the application, so we developers need to spend a lot of time on the UI to make it as nice and functional as we can. If the UI is bad, the application is bad, because the user doesn’t care how beautiful (or not so beautiful) the code is on the backend.

To the user, the backend is invisible. They don’t see it and don’t want to see it, because the only time the backend rears its ugly head to the user it means something has gone wrong. They don’t care what the backend does, the language in which it was written, or any of the technical details whatsoever. They just want it to work. As developers, once we start thinking of the business logic of our applications as a black box that’s exposed via services of various kinds, we stop caring about the backend as well. Once it’s written and working it becomes rather invisible even to us. This isn’t to say it doesn’t take a lot of work to build the business layer of an application, but I hope you’re beginning to see my point.

The BlackBerry example above is one very simple yet very real-world instance of converging technologies, but even such a trivial example brings to light how we as developers need to broaden our scope and “think different” (to borrow a phrase from Apple) about what it means to be a developer. Specifically, we need to think about many different types of devices and clients communicating with the same backend, which also means we need to start thinking about our backend as a commodity that’s invisible to the user and, once it’s written, largely invisible to us as well.

Is ColdFusion “Invisible?”

What does this mean for ColdFusion? Is ColdFusion invisible? The short answer is yes, but unfortunately not in the good way. (The longer answer is maybe; read on for more details.) Adobe Reader and the Flash player are invisible in the sense that they’re on everyone’s computer so we can rely on them and take advantage of their huge install base. This is positive invisibility. ColdFusion, unfortunately, falls into a different category of invisibility. ColdFusion is invisible because, other than to the developer writing CFML, ColdFusion doesn’t matter. For the most part the exact same functionality could be written in any technology and no one but the developer knows or cares. The speed and lack of hair-tearing with which you can build something in ColdFusion may make it a great choice, but again, no one but a developer cares.

Going back to my CFUnited presentation, I showed a concrete example of three completely different UIs all talking to the same ColdFusion backend. First I showed an HTML interface ca. 1996, then I showed an AJAX interface using the AJAX capabilities of ColdFusion 8, and then I showed a Flex interface. You can imagine extending this to a BlackBerry browser or another mobile client quite easily. The intent of this demo was to emphasize the importance of creating a service layer on top of the business logic of an application, because A) it abstracts and encapsulates the business logic, and B) it creates a situation in which swapping out the front end of an application is quite simple. In this sort of architecture you can completely change the front end of an application without the backend knowing or caring that any changes occurred.

Now think about this from the other direction. Suppose I had written three versions of my business logic code, one in PHP, one in Ruby, and one in Java. Would this have changed the substance of the demo? Not in the least. I could have had the 1996-era HTML interface talk to PHP, the AJAX interface talk to Ruby, and the Flex interface talk to Java, and no one would have been the wiser. To the user, and even to the developer of the UI, this doesn’t matter. The user really doesn’t care, and the UI developer just needs to know what services to talk to and how to talk to them in order to retrieve data and display it to the user.

At this point it may seem that I’m painting a rather grim picture for ColdFusion because in the scenario outlined above, ColdFusion is largely marginalized. Is the picture really this grim for ColdFusion? Yes and no. On the one hand, the technological irrelevance on the backend is good for ColdFusion because it levels the playing field. To put it another way, since the choice of backend technology doesn’t for the most part limit what you can do with it, there are fewer reasons not to use ColdFusion than may have previously existed.

ColdFusion also has an extremely strong selling point in this new world order of application development because it can talk to more or less any other technology. ColdFusion 8 vastly improves performance and eliminates many of the shortcomings on which its detractors have been harping on for years, such as image manipulation capabilities, more and better deployment options, server monitoring and profiling, and integration with .NET. ColdFusion has been described in many of the recent ColdFusion 8 presentations as “glue,” and when the features are considered as a whole it’s some pretty powerful glue.

On the other hand, there are many other brands of glue out there, and while they may not be as nice as ColdFusion in some respects, based on the skillset of the developers on a project, the budget, and so on and so forth, it may make logical sense to use something other than ColdFusion. As I mentioned above, the love of a particular technology doesn’t drive the decision-making process from a business perspective, so from a business perspective it has to make sense to use ColdFusion in order for that to be the choice. This could be because your company is full of ColdFusion developers, it could be because you use contractors and that’s their technology of choice, or it could be because your company has already standardized on ColdFusion. However, the fact that you can accomplish what you need to accomplish using more or less any technology is bad for ColdFusion. ColdFusion has to sell itself on the how of developers accomplishing their tasks, and to the people with the checkbooks in an organization that’s sometimes a hard sell.

Making the Invisible Visible

Given this new development world, one in which in my estimation the backend technology is less important than perhaps it used to be, how does ColdFusion become visible? Visibility for ColdFusion these days means making it the best technology with which to interact with the converging clients and devices outlined above. ColdFusion 7 took a baby step forward on that front with the introduction of SMS and Instant Messenger (IM) event gateways as well as improvements in the handling of web services. The issue with ColdFusion 7 was that these features were more or less all the further it went on this issue. I highly doubt it’s as dead simple to create an SMS or IM gateway in any other technology, but the introduction of these features didn’t seem to change the game much. ColdFusion was perhaps a bit ahead of its time with these features, so maybe we’ll see more done in this area in the future.

With the very small amount of hindsight we now have looking back at ColdFusion 7, the single most important feature for ColdFusion’s future viability was the Flex Connectivity capabilities in the 7.0.2 release. This one bit of functionality instantly made ColdFusion the easiest technology to use with Flex. Even with this there are of course solutions that allow Flex to communicate with practically any technology, but ColdFusion is still striving to be the best backend technology for Flex development with the inclusion of the free version of LiveCycle Data Services in ColdFusion 8. This combined with ColdFusion’s legendary ease of use and speed of development and you may be asking yourself, “Why isn’t everyone using ColdFusion?”

Unfortunately I don’t have the answer to that question. If I knew how to get the world to adopt ColdFusion I would have done it by now. As ColdFusion developers we love ColdFusion and know the advantages it offers, so maybe we all need to stop railing against things that we can’t change, dump the inferiority complex, continue to use and evangelize ColdFusion, and simply enjoy our technology.

Trying to convince someone whose starting point in the discussion is “ColdFusion sucks!” is, sadly, a waste of breath. The recent comments on digg.com following the “Ghost in the Machine” article mentioned at the beginning of this tome showed a level of ignorance of and FUD about ColdFusion that none of us can even begin to fight against. The best we can do is have reasonable conversations when possible and put our money where our mouth is by building great applications with ColdFusion.

To that last point, building great applications with ColdFusion, I think the word “with” needs to be explained. I could have written “… building great applications in ColdFusion,” and the fact that I didn’t was deliberate. The majority of applications we’ll build in the future–and that future is now–probably won’t be solely in ColdFusion because a CFML/HTML front end is but one of many options available to us. Flex applications, AIR applications, AJAX applications, and mobile applications can all be built with ColdFusion, and probably be built better and more easily with ColdFusion than with other backend technologies.

This to me is going to be ColdFusion’s greatest strength moving forward. The new front-end capabilities of ColdFusion 8 are fantastic, and while this makes ColdFusion a great choice for HTML/AJAX application development, in the end this is a rather limited selling point. It’s the glue capabilities of ColdFusion and how well it interacts with Flex that are going to make ColdFusion viable, perhaps even more than viable, as the aforementioned waves begin to crest.

Your Point Being …

So the upshot of all of this is, well, I’m not sure. Parts of this were admittedly rather rambling, but regardless of their lack of organization and brevity, these are some thoughts that have been going through my head recently so I thought I’d try to put them together in a semi-coherent fashion, share them, and hopefully get your thoughts on them. As I mentioned at the beginning of all of this, I do believe that we’re in the midst of a sea change as developers, and if we don’t pay attention we might just miss it.

I realize that I may have painted a less than rosy picture for ColdFusion. That wasn’t my intent, and actually I believe ColdFusion has a very bright future in this new space. At the same time we all have to be aware that leveling the playing field is both good and bad for ColdFusion, but the good outweighs the bad. ColdFusion isn’t going anywhere and will continue to be and perhaps increasingly be a logical choice for the backend on Flex applications.

I think my main point is this: the times they are a-changin’. Going forward I’m not sure where my development path will lead me, what technologies I’ll be using, and how they’ll all fit together. The one thing I do know for certain is that for the last 10 plus years I’ve thought of myself as a ColdFusion developer, with brief detours into ASP, Java, .NET, and PHP along the way. I always came back to ColdFusion, however, and I’m always happiest as a developer when I’m using ColdFusion. In that sense I suppose not much is changing. I’ll continue to love ColdFusion, and I’ll continue to explore other technologies as job requirements or my personal interest dictate. What is changing dramatically, however, is the nature of technologies I use, and the very nature of the development field.

Regardless of how we feel about ColdFusion, we all need to recognize and embrace the change we’re in the midst of right now. Most of us won’t build pure web applications anymore. Most of us will be building many fewer single-purpose applications than we have in the past. Like it or not, we’re going to be spending more time on the front end of applications than we have in the past, and some of this front end technology may be completely foreign to us. We web developers will also find ourselves thinking more like desktop developers with technologies like Flex, which eliminate the traditional request/response model that has become second nature to us, and AIR, which takes our current skills and literally puts us squarely on the desktop.

Frankly I’m excited by these prospects. Taking this different approach has caused me to revisit the fundamentals of my development process and has irrevocably changed how I will think about development moving forward. It also opens up worlds of possibilities that even a year ago were still only on the horizon, only some hazy future possibility yet to be realized.

Now that the future is here we as ColdFusion developers must embrace it and make it part of what we do. ColdFusion is great; always has been, always will be. It’s also something that will only be part of what we do moving forward. The great news is that we bet on a pretty solid horse, and it’s not one that’s getting sent to the glue factory any time soon. Our skills as ColdFusion developers, augmented by various front end technologies, make us important assets to the new development world. We simply need to change our thinking a bit, sharpen our tools and pick up some new ones, and build great applications of all kinds for our users.

Comments