Netbeans is much slower and has a lot of bugs, but even so I decided to continue using it for my PHP development environments. There are few strong arguments, which beats Eclipse like a hell. Here you’ll find why. I’m trying to answer here, why quite experienced developer (that would be me! :>) decided to use less stable, slower and more buggy IDE than Eclipse.
Keep in mind, that I’ve been using Eclipse only for a few hours, while Netbeans over three hears. This may influence my judgement.
Here are key arguments, most important for me, and ordered by importance to me.
1. The real PHP support in Eclipse in very outdated.
Helios (Eclipse 3.6) is the last official PDT (PHP Development Tools) release and it will be three years old this year. Following years releases (
Indigo in 2012,
Juno in 2012 and early developers versions of
Kepler scheduled for this year) are available, but you have to install PDT manual, as a plugin.
2. Code completion for PHP works strange. It is not opened in every place (Eclipse decides — to often in my opinion — where you can’t write your code) and there are no options for it in configuration (there are — called
These two bugs, though may be small for some, are essential for me and are in the same time key factor in expressing differences between Eclipse and Netbeans. From the first moments of using both IDEs you have a clear feeling that Netbeans was designed for PHP (this edition) — i.e. it was recompiled from source toward PHP development. While Eclipse is a Java IDE, where all PHP-related functionality is only an addition.
I can’t express ideally, what I mean, but I’m sure you know, what I’m talking about.
Configuration & project properties
1. Eclipse has twice or even three times larger options and settings set, but… there is no Import / Export function for configuration. WTF? Do you really think I’m going to click-out everything, spending an hour or two and boiling my brain along with memory, each time I reinstall Eclipse? Netbeans has this since the beginning (of my use of it) and I can install and reinstall it as many times as I like, because restoring entire configuration set (by import) always takes around five to ten seconds.
2. Eclipse has a cool feature of workspaces. But, for every new project, that I create I can only select, whether I want to create it in workspace (from scratch) or in fixed filesystem location (basing on existing sources). No matter, which option I choose, Eclipse-specific files will be kept among project files.
Of course, this has some advantages:
- isn’t something new (Subversion, Git and probably many more uses this technique),
- could be useful (commiting project setting among project files to duplicate both at destination),
- can be easily controlled (files are with dot (
.) in the beginning, so are automatically hidden on Linux and may be easilly hidden on Windows.
But even so, I strongly prefer Netbeans and its option to keep all project settings in a workspace, while project files remains in source folder.
1. In Netbeans you’re debuging entire currently open project (or selected file out of it), while in Eclipse you have a Debug scenarios (as well as Run scenarios), whiche you use to define debug paramters. So it is a common situation (for beginners), that you accicentially debug completely different project than currently opened. Implementation of debug scenarios always forces you to start debug from the same file (specified in scenario params). If you want to debug from different file, you have to modify scenario. In Netbeans you simply pick a file in treeview and select
Debug from its context menu.
2. Debugging is done in the same editor / window / windows set as editing in Netbeans, while in Eclipse both task are run in separate Perspectives. Your IDE looks quite differently whether you code or debug. Some certain versions of Eclipse (see below about “comming back bugs“) have bug and do not automatically switch between these perspectives even though user has ordered so in configuration. This makes debugging even more uncomfortable in Eclipse.
3. In Netbeans any kind of special line (breakpoint, error, bookmark etc.) is marked with icon plus changed line’s background color. This helps much quickly locate such line, especially in a long source code. Eclipse marks such lines only with icon on margin.
4. Big bugs or flaws in key features are repeated or even worse — are comming back — on each following editions. For example,
Helios was reported to work well with step-by-step debugging of PHP files, while
Indigo following it was known to have bugs in this fuctionallity and being not able to stop at breakpoints, when debugging PHP scripts. Many PHP developers were forced by this bug to downgrade to one year older version. Then
Juno, that followed
Indigo was again reported as being free of this bug an beeing able to stop on breakpoints without any problems. Then finally, current developer release (July-comming official) of
Kepler is once again reported as not being able to stop on breakpoints.
5. Another example of “comming back bug” is debug option
Open in external browser, which is respected in some versions and ignored in following one. Though this is so obvious (and simple to fix) bug and though it is known that many developers are still using old versions of Eclipse and though these old versions are still maintained and updated (see below), it has never been fixed in certain versions.
Other, smaller stuff
1. From year to year technology goes forward, we have new monitors and resolutions (currently working on FullHD) and from year to year (version to version) Eclipse toolbar icons gets smaller and smaller. Currently they’re tiny with very lo readability. Not mentioning, that they’re ugly.
2. There is a big mess in versions, packages and releases of Eclipse. Each major version is released only once per year, though overall list of changes between such yearly releases is often smaller than a normal monthly release of other type of softwares. Beside this, older releases are not only kept alive (you can still download seven years old
Europa packages!), but are also still maintained — for example, if a huge bug related to introduction of JRE 7 was found (that prevented from installing any plugin) each releases, up to even those five years old, were updated to it with sub-release (I don’t know how to call it) tag
This allows developers to not to progress to newer version and introduces nothing good except unnecessary mess. Bugs reports, feature requests, forums and blogs are generally divided into those who are using which package. You can for example find some solution or plugin published recently for a five years old package. Very, very strange.