I still remember the first time I discovered an IDE. This was over 20 years ago, and I was working on a personal project (a DOS based game), and picked up Turbo Pascal on the advice of a friend. Yes, I know I am dating myself now, but Borland’s Turbo Pascal was revolutionary. Aside from featuring a fun language and featuring lightning fast compilation (this was in 640K and 286 processor days), the real game changer was the development experience. File and project manipulation, a real editor, integrated help, F9 to compile and any errors or warnings instantly identified in code, a profiler, even an integrated step-by-step debugger … all things we take for granted nowadays, but back then this was revolutionary. The beauty, the simplicity, the sheer elegance, Borland got it right. And when they then added Turbo C and Turbo Assembler and more to the mix, they had found a winning formula and they dominated the landscape (right before making a whole series of superbly dumb business decisions that effectively killed the company and thereby handed the lead on development tools to competitor Microsoft, but that’s a whole different topic).
So why this trip down memory lane? Lately I’ve been thinking a lot about IDEs and the ideal development experience. And I’ve been thinking about the fact that there is no ideal development experience, at least not one that is ideal for all developers. We coders take our IDEs very seriously, and rightfully so. When you spend so much of your time writing code you should indeed be using tools that help you be more productive (as opposed to tools that trip you up). And once we find something that we like, we resist any changes. IDEs rank right up there with politics and religion as topics that only the brave would dare debate.
Which brings me to ColdFusion IDEs. Or rather, the lack thereof. Or … Well, let’s briefly look at the popular options to date:
Back in Cold Fusion 3 days (yes, back then it was Cold Fusion, two words) we realized that CFML developers needed a development tool. We bought HomeSite from Nick Bradbury, and created a version of it called Cold Fusion Studio (eventually renamed to HomeSite+). This tool enjoyed a very loyal following, and the fact that it was Windows only was not much of a concern as so was Cold Fusion itself (and back then we did not see the sea of shiny silver Macs that we see at ColdFusion events these days). HomeSite (including Cold Fusion Studio and HomeSite+) was not an IDE, it was an editor, and an exceptionally good editor at that. It was lightweight, responsive, extensible, and mostly intuitive. But it was also written in Delphi, a language that is tough to keep supporting. And most importantly, it was never really a profitable product. Considering what it cost to maintain, and the number of copies sold, HomeSite was always more important because ColdFusion needed it than it was as a product unto itself. But that was a long time ago, and we’ve done nothing (ok, almost nothing) with HomeSite since Macromedia acquired Allaire close to a decade ago. ColdFusion has evolved significantly in that time, but HomeSite has never kept up with it (it does not even know what a CFC is!). Between the fact that HomeSite was written in a language basically not used anywhere else in the company, and the fact that it was never a profitable product, and the fact that Macromedia had demonstrated phenomenal success with Dreamweaver, HomeSite just suffered from neglect. Still, HomeSite has fans to this day, and many ColdFusion developers love it and still swear by it.
So, three options for ColdFusion development, HomeSite, Dreamweaver, and Eclipse. And all three are in use. We’ve been researching and polling this for years while trying to figure out what we need to do to best serve the ColdFusion community, and no clear winner has emerged. All three have loyal bases who love (or at least like) what they use, and who don’t like the alternatives. The exact ratios vary based on the venue, ask the crowd at cfObjective and Eclipse is the clear leader, ask at MAX or many usergroups at Dreamweaver comes out ahead, and visit many of our customers and you’ll find lots of HomeSite in use, and even these generalizations have exceptions. The reality is that there is no one size that fits all, and despite the very strong opinions and emotions on the subject, there is no clear leader when it comes to ColdFusion development tools.
This has proven to be a very difficult situation for the ColdFusion team. We know that ColdFusion developers need an IDE now more than ever. As ColdFusion has become more capable, as ColdFusion applications have grown in complexity and scope, as the skills of ColdFusion developers have increased, and as the Enterprise and mission-critical use of ColdFusion has mushroomed, so has the need for a real IDE. And so we argued and discussed and researched and debated long and hard to come up with a plan, looking at all the options, and weighing their pros and cons.
It became clear that Dreamweaver is not the ColdFusion IDE, and that trying to make it so would not be in the best interests of Dreamweaver or ColdFusion users. Dreamweaver should, and will, continue to support ColdFusion, and those who are happy doing their ColdFusion development in Dreamweaver must be served and supported. But Dreamweaver needs to focus on where web development is focused, as it is indeed doing now. Forcing full blown ColdFusion IDE functionality into Dreamweaver will not be advantageous to either ColdFusion users or Dreamweaver users.
Which left Eclipse. As already mentioned, there are some very compelling arguments for the Eclipse platform. And on top of those, Adobe as a company has committed to Eclipse as made evident by Flash Builder, LiveCycle Workbench, and now Flash Catalyst. Building a ColdFusion IDE that could leverage other work within the company, and more importantly, could align with those projects (especially considering how many developers are writing ColdFusion powered Flex apps) makes lots of sense. But, as already noted, Eclipse can be awkward and inconsistent, and addressing this is anything but trivial.
When weighing all of the options, and removing emotion from the discussion, it becomes abundantly clear that Eclipse is indeed the right platform on which to build a ColdFusion IDE, which is why we’re doing exactly that for ColdFusion Builder. Doing so allows us to support CFML and ColdFusion development, it allows us to support all supporting Web technologies, it allows support for everything from FTP to version control to SQL and more, it perfectly aligns with other Adobe offerings, and it provides a platform that we can truly commit to and build on as we plan the future. Between Flash Catalyst, Flash Builder, ColdFusion Builder, and LiveCycle Workbench, we’ve got an end-to-end development workflow on the same platform, and building on Eclipse is the only way to accomplish this. We’ve had to figure out what plug-ins to use, what to license, and what to write ourselves, so as to deliver the best experience for ColdFusion developers. And I’m not sure that we’ll get it right for version 1 (ok, I am sure we’ll not get it right, there, I said it). ColdFusion Builder is definitely a 1.0 product, and users should understand that. But they should also understand that we are building the tool to allow for rapid improvements, constant updates, and flexible extensibility. Version 1 will be good, and subsequent versions will be better, it’s all upside from here.
Having said that, we fully understand that not all ColdFusion developers will want to use an Eclipse based ColdFusion Builder. And that’s fine. There is no one size fits all when it comes to developer tooling, and that would be the case whatever option we chose. And recognizing this, we do plan on updating Dreamweaver for ColdFusion 9. CFEclipse is not going away, and there are other 3rd party tools that offer varying degrees of CFML support. There are now more options for ColdFusion developers, and that’s a good thing. And most importantly, ColdFusion developers are getting a long overdue addition to their toolbox, the ColdFusion IDE we so deserve, and one that is well positioned to grow and evolve along with the product it supports.