Does Mozilla Need an IDE?
When discussing the user experience of AllPeers, I sometimes joke to our team that there are two kinds of people: those who use Emacs and those we really care about. To some extent I’m making a valid point (i.e. that we shouldn’t add billions of obscure preferences to service the granola-eating Linux crowd), but I suppose I’m also masking a deep-seated insecurity. I’ve been using some sort of visual development environment since Turbo Pascal, and as a result I’m never 100% confident of my “real hacker” status, even when I’m tracking down race conditions in multithreaded C++ code. After all, there are people who regularly use Alt-Tab-Esc-Shift-α to copy their screen buffer to a temporary file on their FTP server and toast themselves a strawberry pop tart, simultaneously.
Perhaps that’s why people smarter and more knowledgeable than me feel that we don’t want “to go down the IDE route”. After all, you should be able to service all your coding needs with a Unix shell, a Perl script or three, a dash of M4, a paperclip, two quarts of butane and a slightly moist stick of chewing gum. At the same time, there seems to be a strong consensus among the Mozpad crowd that we do want an IDE, a windmill I was futilely tilting at way back in April 2005
All disingenuous mock self-deprecation aside, I do feel that a Mozilla-based IDE would be a major asset. Visual Studio is a truly great programming environment, but it isn’t exactly tailored for Mozilla development, so everything from managing projects and makefiles to viewing string variables is a total pain in the butt. Plus it only runs on Windows, and if I have to look at one more gdb backtrace there’s going to be blood on the keyboard. Firefox made it easy to surf the web on Windows, Mac and Linux without noticing the difference, and we need the same thing in the software development world.
The other big consideration is debugging JavaScript and XUL. If I got all of my preferences right this would be slightly less painful since I could probably reload my chrome files without restarting Firefox. But for debugging JavaScript components, Venkman is still going to be the only option, and whenever I’m using it it’s either crashing or so slow that I want to kill myself or (in my more lucid moments) kill the person who wrote it. A custom-tailored Mozilla IDE could have kick-ass cache management (refreshing files as soon as they are modified) and cross-language debugging.
We’re Mozilla experts by now at AllPeers, and we still struggle with the inadequacies of our development environments on a daily basis. Is it any wonder that the prospect of developing on Mozilla is daunting to the uninitiated? Of course, there are many other things we can do to help, like creating a complete and usable SDK (something I’ve committed to contribute to as part of my Mozpad activity) so that would-be Mozilla application developers don’t have to start by building Mozilla (the software development equivalent of learning aerial skiing by performing a quintuple-twisting triple flip). And it goes without saying that creating a great Mozilla IDE will require a monumental effort. But personally I’m convinced that it’s a worthwhile goal that, if successful, would have a huge impact on the quantity and quality of software developed for the platform.
17 Comments »
Trackback URL RSS feed for comments on this post.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
ActiveState’s Komodo is a Mozilla-based IDE with support for Firefox-style extensions (using both JavaScript and Python, I believe).
Although the free (as in beer) Komodo Edit lacks most of the neat features compared to Komodo IDE (which costs $295 for a “perpetual” single-user license).
It’s mostly geared towards dynamically typed languages, I don’t know if there are extensions for things like C/C++ and associated debugger support (though that would certainly be possible to cobble together if such are lacking).
Perhaps extending Eclipse with tools for the Mozilla technologies could be another way. Given more work on JavaXPCOM, it would be possible to hook directly into XPCOM components for some nice features, all without having to write the whole IDE from the ground up.
Comment by Fredrik — 7/10/2007 @ 1:21 am
Not a Mozilla developer, but as a general rule, I think IDE support in open source projects is good, as long as it’s doesn’t impose a burden on those who don’t want to use one. Emacs and VI users should be able to code without worrying that they’ve broken the IDE. That’s something that happens from time to time with Java projects where the IDE is using a different list of libraries from the command-line tools, and so code compiles fine in one but not the other.
Comment by Simon Geard — 7/10/2007 @ 1:21 am
I really think that people should take a look at Komodo Edit. It’s a wonderful piece of software from some long-time Mozilla project contributors.
Comment by Mukunda Modell — 7/10/2007 @ 1:37 am
You’re spot on here. There are a lot of talented engineers who would love to further Firefox, Gecko, and other Mozilla technologies, who look at the barriers to entry and decide it’s not worth it. You don’t have to work hard if you work smart, and an IDE could help a lot of smart people to do important work.
Comment by Bo — 7/10/2007 @ 2:53 am
I have to also point out that Komodo and Komodo Edit are fully functional IDE’s built completely on Mozilla technologies and have support for XPCOM and XUL file types, good code editor support, extension support and years of maturity. If there is a large need for a Mozilla based IDE, I have to wonder why it is not the defacto standard for Mozilla development.
Perhaps we should be asking why Komodo is not the defacto standard. Any new Mozilla IDE would have to overcome the same developer buy-in challenges as Komodo, after the years of development time needed to reach its feature level.
Comment by Mark FInkle — 7/10/2007 @ 3:56 am
Neither Komodo Edit nor Komodo IDE are free software. It’s a pity, but Komodo is not a solution for the free software community.
Of course, there is also Eclipse: Europa (Eclipse Platform Runtime Binaries) + ATF + XULBooster + DLTK + CDT. But there is a true obesity issue in this solution; i agree with Benjamin Smedbergs when he says: “We need to stay focused on the strengths of the Mozilla platform and the web paradigm and not be distracted by “RIA madness”, complex toolchains, or the need to imitate existing proprietary solutions.”
Anyway, i agree with allpeers too in that we need an IDE focused on Mozilla Platform and web paradigm… In fact we should invent the killer IDE, running inside the browser… The Free Software community should launch such a project with Mozilla, AllPeers, FSF…
Comment by genium — 7/10/2007 @ 12:00 pm
Eclipse seems like an ideal platform for building an IDE from. It already supports C++, is designed to be extended to support other languages, and is free and open source.
Comment by liminal — 7/10/2007 @ 4:48 pm
Yes it does.
Comment by pd — 7/10/2007 @ 5:41 pm
Eclipse has > 300 committers, the support of all industrial biggys, 18 million LOC…. and you want to rule out your own IDE-framework? NIH is the biggest problem of the different FOSS-communities. You want to rule out your own frameworks for the sake of ruling out your own frameworks. Off course you have no chance to compete neither against Eclipse neither against Microsoft… and you know that. And do you think that the +30 committers that you need for realizing such a project will work for free? Do you know that VS.NET has about 800 developers and Eclipse more then 300? Please get a clue!
Comment by Tomasini — 7/11/2007 @ 11:35 am
Hey Matt,
first off, I share your fate of having started out using IDEs (Borland C++, in my case, both on DOS and Win 3.1). I’ve since gone down the Emacs path for most of my early Linux work, and got reasonably proficient at it. However, I was an instant-switchover to Eclipse once I saw it, and even though I switched to NetBeans now (mostly for the better C++ and UML tools), I didn’t regret it one minute.
The most important reason was its CODE MODEL. A code model, as you probably know, lets you do all sorts of nice things in a semi-intelligent manner, like renaming a method (not the same as replacing a string), refactoring, and so on. You probably could build a code-model-based editor but I haven’t seen one, yet.
Obviously, for the same reason, you’ve got a tough job before you in doing an IDE for web-development — there is not just one but many different models to support.
That said, I would strongly recommend against building a new IDE from scratch. Of course, it may sound like “doing what you preach” in using Firefox when you’re out there advocating Firefox as the platform. However, it really isn’t. Its just an enormous waste of time because tool building is always distracting. Also, the requirements of an IDE are likely to be quite different from the requirements of a typical Firefox app, so you’re not even getting much out of extending the platform for the IDE case.
Additionally, multi-platform is the key, in my case. I don’t want an IDE that I can use only for Firefox development. I do more than just Firefox development and I want one IDE for all of it.
My personal recommendation would be to have a look at NetBeans — they’re open, cross-platform, much less convoluted, and their team is based in Prague
Comment by Ingo — 7/11/2007 @ 1:32 pm
Development environment has been an issue for the life of my project.
I have an embedded app that wants to be a XULRunner app but the time doesn’t seem quite right to switch.
Initial content development was difficult—no Venkman, or other extensions in the embedded app—and was mostly done in a browser that was missing the extra functionality of the full app. There was also a lot of debug-by-alert when internal features were needed.
XULRunner looked like a good way to get access to extensions but I instead choose a hybrid path of sorts: I wrapped the embedded app’s c++ code in a component, added/changed some “glue” and wedged the app into Firefox via a command line handler (a small javascript file inserted in the right place allows me to hijack the browser for development)
We can now develop custom-application content using every Firefox extension in existence. After debug-by-alert development, I find it hard to be too critical of Venkman…
So we have a kludge solution that works fine for us. Reaching this point was a lot more complicated that the last few paragraphs imply. The makefiles alone…
There are numerous Development Environment issues that hopefully can be resolved independent of their eventual inclusion in an overall integrated solution.
Comment by jerryc — 7/12/2007 @ 8:45 pm
“granola-eating” ? Please explain.
I don’t hire those who can’t work
with a toolset from top to bottom.
It’s a tough policy, but I can’t
afford to hand-hold supposedly
proficient “programmers” who need
security blankets — clients rarely
have licenses for fancy IDEs.
Comment by AC — 7/12/2007 @ 11:31 pm
On a less-grouchy note, I understand the claim
that development on *nix should not be made
artificially difficult as some rite of passage;
and that an IDE can be a gentle introduction;
still, I have rarely seen a programmer on ANY
platform who began with an IDE/Turbo clone and
gradually became familiar with non-IDE tools:
I suspect this has a great deal to do with the
toolset available (or permitted) in academic
coursework.
Furthermore, IDE users do seem less willing to
experiment with changing the underlying build
system of a codebase (auto* to CMake, etc.).
If one were simply maintaining an older set
of code (90s C++), I can see how an IDE might
help — I’m not convinced that they are suitable
for new application development; after all, how
many have full support for C99 features recently
introduced in the GCC 4.2/trunk series ?
Comment by AC — 7/12/2007 @ 11:42 pm
AC,
I’m sympathetic with your viewpoint from an educational standpoint. I actually didn’t start developing in TurboPascal, I started by hand-assembling for the Apple II/Motorola 6502. I wouldn’t want to see “real programmers” start with a visual environment that hides a lot of the complexity of what’s happening under the hood. Ideally professional software developers should understand everything that’s going on, way below the level of the OS shell (processor-level optimizations, etc.).
That said, there is a huge community of programmers who are not professionals, and part of our job is to make as much programming goodness available to them as possible. Also, I find that a good IDE makes me far more productive, even though I could do without if I absolutely had to. You’ll pry my visual debugging environment from my cold dead hands, buddy!
Comment by Matt — 7/16/2007 @ 11:27 am
You might take a look at the Eclipse AJAX Toolkit Framework. It has support for XULRunner and Javascript debugging. It might be a good place to start?
Comment by Ian Skerrett — 7/17/2007 @ 8:17 pm
Eclipse. Heck, it’s SWT browser widget is even able to hook up to XulRunner and run gecko…
I recently started working on Eclipse plugin development, and it’s quite a complex beast… so I think you might run into a shortage of developers who are proficient in both the Eclipse platform AND the mozilla platform to be able to build a really integrated environment.
Comment by Kim Sullivan — 7/18/2007 @ 11:28 am
thank you nice sharing
Comment by cep program — 5/14/2008 @ 9:12 pm