Ben Forta

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.
I mentioned Dreamweaver, the award-winning and highly rated Web design and development tool, a Macromedia creation, and now part of Adobe’s Creative Suite. Way back in Allaire days I flew to San Francisco to meet with Macromedia to discuss them adding CFML support to Dreamweaver, and offered guidance around their initial ColdFusion support. Since then, Dreamweaver has continued to add ColdFusion integration, more enhancements in some releases and less in others, but always supported. At one point there was an aggressive push by the Dreamweaver team to make that product the best tool for ColdFusion developers, and support was added for CFCs, RDS, debugging, and more. And many ColdFusion developers, including myself, did indeed jump on the Dreamweaver bandwagon (and, to be very fair, many developed a sort of love-hate relationship with the product, what it did it did well, but there was too much it did not do, and much of what it did well we did not care about). Like HomeSite, Dreamweaver is not an IDE, but for many developers it worked and worked exceptionally well. Dreamweaver is a big, powerful, and extensive product, the undisputed leader in its space. But for many ColdFusion developers it didn’t work as well, especially the hardcore coders who never wanted a design view and never wanted color palettes and never wanted most of what Dreamweaver focuses on (those same developers who may feel more comfortable in an Eclipse or Visual Studio type world). In short, many coders find that Dreamweaver is better suited for web design and development than actual coding. And they are right; this is not in any way a criticism of Dreamweaver, the product just has a different purpose and target user base. In fact, the most recent Dreamweaver updates have focused primarily on CSS and XML/XSL and JavaScript, and rightfully so, that’s what most Dreamweaver users need. So, while Dreamweaver is definitely not for all ColdFusion developers, many of them, especially those without a strong coding background, find Dreamweaver to be an ideal ColdFusion development tool.
The third ColdFusion development option is Eclipse. Eclipse is an open source software development platform comprised of an IDE and a plug-in system to extend it. It is written primarily in Java, and is used to develop applications in Java and numerous other languages (as well as development that isn’t even language based at all). Eclipse itself does not support CFML, but the community leveraged the plug-in system to create CFEclipse. This project was initiated back in 2004 by Rob Rohan, and since then many others have gotten involved to varying degrees, with Mark Drew most recently taking the lead. Adobe, and the ColdFusion team specifically, actively supported the CFEclipse effort, and contributed code to the project. CFEclipse is designed for developers not served by Dreamweaver, and does not support any of the design centric features that Dreamweaver boasts. CFEclipse is definitely a tool for coders, and many ColdFusion developers do indeed rely heavily on this tool. The real beauty of CFEclipse is the openness of the Eclipse platform and the extensive array of plug-ins available. Need support for HTML, JavaScript, Regular expressions, SQL, version control systems, XML, DBMS front-ends, and more? No problem, download the right plug-in and you’re all set. That’s pretty compelling, a real IDE that gives developers complete control is highly appealing, and lots of ColdFusion developers have indeed gone this route. But, it’s not all rosy, and Eclipse based development has lots of detractors who find it slow and sluggish, inconsistent, not quite polished, buggy, and worse. And there is validity to those concerns, and regardless of how you feel about Microsoft, taking Visual Studio for a ride makes you quickly realize that Eclipse is a perpetual work in progress. Still, as many ColdFusion developers have discovered, Eclipse + CFEclipse + whatever other plug-ins you need = a powerful ColdFusion development platform, and the closest we’ve ever gotten to a real ColdFusion IDE.
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.
Many of the ColdFusion team wanted to resurrect HomeSite (yes, I know it was not truly dead so resurrect may be a strong word, but let’s be honest, it was not quite alive either). This option has merit. HomeSite is small, tight, fast, and we’d fully control the environment allowing us to create a truly ColdFusion specific experience. But in the end this option was deemed unworkable, particularly after this much time. In addition to all of the ColdFusion support that we’d have to have written, we’d still be faced with having to support all other related web technologies (HTML, CSS, XML/XSL, JavaScript, and much more), being Windows only, and having to maintain a team of developers who could not share any work or resources with any other development teams in the company because they would be the only ones writing in Delphi. As much as we all loved HomeSite, its continued development was impossible to justify.
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.