Fog Creek Software
Discussion Board


I'm interested in your thoughts on the comparisons between XAML (as being developed in Longhorn) and NIB (as the Cocoa Frameworks in OS X).

They seem to me to be attempting to solve the same problem; that of separating interface from implementation.

I'm interested if you feel the XAML implementation is XML-mania gone mad (a la native XML Databases)?

Jon Deeming
Tuesday, February 24, 2004

I don't think XAML is XML gone mad. I think it's a great replacement for the .rc file format -- a million times more powerful than .rc files -- and once you've decided it's going to be a text file format, XML makes sense as a meta-format.

I don't know the first thing about NIB. I have never heard of it until now. So I can't compare and contrast -- maybe someone else here can?

Joel Spolsky
Fog Creek Software
Tuesday, February 24, 2004

As I understand it, NIBs are basically all of the user-interface widgets serialized to disk.  You lay them out with something like Interface Builder, and save it to a .nib file.  In your program, you instantiate the widgets.  The .nib file gets linked into your program (or something like that).  At runtime, it just deserializes them into memory.

I've never actually done this myself, so I may be wrong, but that's how I think it works.

Tuesday, February 24, 2004

That fits with what I've seen.
It's an inheritance from the NeXT OS.
.nib means something like Next Interface Builder
and AFAIK it's the interface serialized with hooks to the code.
I don't know how they worked that was state of the art back in early 90ties when I was still a rookie at Uni.

Wednesday, February 25, 2004

That NIB thing sounds a lot like form files with Delphi and C++Builder. These contain all controls and components on the form with properties and event hooks, and are linked as binary resources with your executable.

Frederik Slijkerman
Wednesday, February 25, 2004

I'm not sure if it's been changed since 10.0, but the NIB files were non-XML data structures - I think they were for Carbon apps and weren't for Cocoa apps.  The goal was to eventually have the NIB be an XML structure - so one could change the interface programmatically by modifying the XML.

I've not seen the code, but I imagine it's a bit more straightforward than XAML - which is a bit cumbersome but still a fine solution to the problem at hand.

The idea behind the NIB is to separate the interface from the code.  Essentially it reinforces the MVC notion that pervades Objective-C and Cocoa by making the UI a receiver and generator of messages.  This way one could have a single app which is accessible from a GUI or from a command line or elsewhere and the program itself has no need of extra code to handle each additional input/display possibility.

Programming a NIB is incredibly simple (drag and drop to show how messages are passed).  When it becomes XML (if it hasn't already), it will simply be even more basic and editable. 

As a side note, Apple uses XML throughout OS X for a variety of pursposes - perhaps most visibly in their preference (PLIST) files.

Wednesday, February 25, 2004

Nib does indeed stand for 'next interface builder'.

Nib files use the NSCoding protocol to encode their objects into a file. This means that if you write a Cocoa object that conforms to that protocol, you can lay it out in IB like native controls. Interface Builder simply rocks - it's easily the fastest way to write native GUI applications on any platform. In 10.3, they added a new bindings system that rocks.
I'd go far enough to say that with Cocoa, Joel's 10 year requirement to get good software is obsolete.

Steven Canfield
Thursday, February 26, 2004

*  Recent Topics

*  Fog Creek Home