I was reading this blog entry over at java.net this past weekend, and I tried to register for an account and sign in for the past two days just so that I could reply to this blog entry of Kirill's. Alas, java.net and I have issues, so I'll write my reply here.
There are a few issues with comparing NetBeans Matisse and Apple's Interface Builder (IB). The first off, is that each exists in their own ecosystems. Apple developers usually use Xcode and IB exclusively in designing their (Cocoa) applications. There are a few large counter examples, but for the most part, most developers use Apple's tools. Because of this, everything tends to conform to the Apple Human Interface Design specs. It's much easier to program a Mac Apple's way than to try to do it yourself. The expectation of Mac developers and users alike is that things will be done Apple's way, using Apple's APIs.
In Java, things are different. In Java-land, developers have different expectations because Java GUI programs live mainly on Windows and Linux boxes (okay, mainly Windows). However, since cross-platform ability is one of the main selling points of Java, we can treat Java programs as needing to work on Windows/Mac/Linux/Solaris (I threw in Solaris for fun). Additionally, most Java developers (at least the vocal ones), are very used to Apache-style open source access to common libraries. This means that Java developers expect open formats. They expect to be able to muck around with an XML file. They expect to not have binary/proprietary file formats describing things.
.Net/C#/Microsoft world is much closer to the Mac landscape from a developer's point of view. Microsoft has some of the best tooling in the industry. If you live and work in Visual Studio, you can expect that your programs will look and work like "Windows programs". Visual studio developers could care less about open formats... so long as it can be edited in Visual Studio, that's sufficient for most .Net/C# devs.
So the two main questions raised by Kirill are described by this comment by him:
-
elharo - i've raised two questions, and you didn't answer them. The first is - what tool besides Interface Builder can be used to operate on NIB files. If there is none, then the "locking" part of NetBeans argument is irrelevant. The second question concerned designed / intended use of each one of the tools (Interface Builder / NetBeans). As long as you stay in NetBeans (even if it means locking), what does it matter that it's split between two places? How would that get out of sync?
Of course, both questions are about Interface Builder against NetBeans, and not about NetBeans against other Java IDEs. My belief is that if you (as the developer) decide to use some IDE to visually operate on your UIs, you shouldn't complain about locking (JSR 198 is simply bound to fial {sic} miserably in such a dynamic and highly evolving field as Java IDEs). If you want interoperability and portability, don't use tools for your UIs.
To which, I answer Apple developers don't care about "locking". They are using a Mac for crying out loud. Macs are proprietary systems built upon an open source foundation. You are very much locked into the Apple design aesthetic if you are using a Mac. You can't compare the two development tools from this perspective. IB is the tool to design interfaces on a Mac. You don't have other options, and you wouldn't want them anyway because it didn't come from Apple.
Now, if you are in Java-land, you come in with a different set of expectations, largely due to the ecosystem that Java has fostered. Things are expected to be open. Things are expected to be XML configurable. Things are expected to work with multiple tools (because everything can read XML right?). It is expected demanded that a developer be able to view and change configurations of things by hand, if needed.
However, you can certainly compare the two approaches (IB and Matisse) from a structural standpoint. You might as well throw in Visual Studio into the mix as well (although, I'm less familiar with the newest version). I like the IB and Visual Studio technique of placing things in one location (regardless of the implementation of that store). I don't know why NetBeans has things repeated at the .form and source code levels. This just seems silly to me. As far as the argument that having a binary format lets the Matisse developers could change things quickly, why not just include a version tag in an XML config file? Then they could load a different handler for whatever version the file requested.
In my opinion, the main reason why Java is so ridiculed on the client side is that Java development tries to ignore the underlying operating system. It tries to hack on a look-and-feel to mimic the underlying operating system. There are definite up sides to this... however, there are very real downsides as well. If you try to be all things to all people, you can easily end up being nothing to no one. If, however, there was a way for Java GUIs to embrace the existing methods of the underlying operating systems to draw and design GUIs, then you may have something. However, if the java-cocoa bridge is any indication, then the validity of this approach has passed us by.