At the time of NeXT’s heyday in the early ‘90s, most GUI programming was textual. You’d call add(button) and button.text = “Hello World” to build up your GUI, and have to wire up the events from your button to take specific actions. Quite a lot of GUI programming is still like this, even now.
What NeXT brought was a GUI editor that allowed you to drag a button from a palette and onto a window (or view). You could then change the text on the button by double clicking on it and renaming the default text. You also got to determine where and how large the button was in relation to the rest of the window.
Most GUI builders could do this, so what was special about Interface Builder?
Two things stood out. First, you could specify how the button reacted to window resizing. There was a “springs and struts” layout mechanism that allowed you to say which parts were fixed offsets and which were variable. You could also say if the button would resize, and if so, in the X or Y or both directions.
The second thing was the ability to connect the button to an action. By Ctrl clicking and dragging, you could wire up the default action to a “selector” — in effect, a virtual method call, on the owner of the button. This owner would be populated at startup, typically the application (controller). So you could have your code with the responder and another team build the UI, and they would join together at runtime.
You could also use properties generated by code as well - you could connect the button’s field to an object’s property (aka an outlet) so that changing the code changed the UI.
The fact that you could drag and drop connections from UI to code, and from code to UI, as well as building a responsive UI, was really what stood out.
This still lives on in Xcode today; IB and PB begat Xcode and IB which begat Xcode. The “nib” format - Next Interface Builder - was a binary format file containing the descriptive state of the Ui and the wiring requirements, which was renamed “xib” when XML became all the rage is the same thing. The fact that IB has been subsumed into Xcode still hides the fact that is what’s happening under the covers.
I think it’s important to realise that this was in an age when Windows 3.1 was all the rage, and we had only just got out of 256 colour VGA while Next station had 16 million.
Nowadays with everyone doing MVC programming with the web, it doesn’t seem so important. But then there was a time when no one wrote unit tests because it was seen as pointless; but it is from these seeds that ideas become mainstream.
Great description. Two things I'd add to that: NeXT's Smalltalk heritage, with what I think of as real object orientation, was great for UI programming. Objects on screen were actually objects that you could message. And Display Postscript made it much easier to get visually solid results.
I can't remember where I read this, but the basic notion was that the Mac was easy to use but hard to program, limiting its adoption. Jobs learned a lesson in that he wanted his NeXT machine to be easy to use and easy to program.
As you say, it might all seem a bit tatty now. The web has raised the game of interface creation quite a bit. But this was in the late 1980s, where a lot of what they did was revolutionary.
And the dithering was wicked fast. I remember playing back multiple videos on NextSTEP fully dithered and quite good looking where the same machine (dual boot setup Intel P90) had huge issues even playing back one video.
I’m sure that your aware that Ms access, Delphi, Visual Basic, progress as well as a host of other tools existed at the time, and you’re fine to point out that Next was superior but given that really none of these systems survived, something else must be going on.
Sure, but Delphi was released in 1995 as the first version, whereas this was something I was programming in 1992 (and I came late to the party with Nextstep 3).
Try using plain ES7+ (with async/await) JavaScript with Mithril (for defining components and their behaviors) and Tachyons (for Atomic CSS for styling). I like that combination best after having used Smalltalk and a variety of GUI builders (including Delphi and ones for Smalltalk and NewtonScript) and Angular and React. (TypeScript is OK too for bigger projects where documenting interfaces wins out over speed of development in plain JavaScript...)
And having dealt with GUI builders with special formats and coding implication related to objects sending special events, I'd much rather just write plain code in one language in a text editor than wrestle with a limited WYSIWYG tool.
Mithril's brilliance is assuming the UI is dirty if you have touched it in some way (mouse click, keystroke, etc.) and always rerendering after the event is handled (except if you want to optimize that). That leads to UI code which is much easier to reason about than arbitrary networks of dependencies like older UI toolkits emphasized. That style of UI development feels a lot more like, say, programming a continually-rerendering video game in for OpenGL than programming a dependency-based UI for VisualWorks/NeXTSTEP/Delphi/VB/etc..
More on all that by me: https://github.com/pdfernhout/choose-mithril
"tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphasize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations."
And I say that even having been an official NeXTSTEP developer once upon a time -- after I gave Steve Jobs my business card when I met him after he gave a talk at Princeton and he got me into the developer program (after my paperwork to join that developer program had previously apparently been ignored with its aspiration to build a system where any piece of data could be linked to any other piece of data). Even reading through all the glorious NeXT developer info, I never felt I could afford the NeXT hardware though as much as I wanted it (the short warranty gave me pause too) -- so my career as an independent software developer went in different directions. After reading the article and comments here, I can wish I had just thought to go work for NeXT instead of wanting to be a customer...
What NeXT brought was a GUI editor that allowed you to drag a button from a palette and onto a window (or view). You could then change the text on the button by double clicking on it and renaming the default text. You also got to determine where and how large the button was in relation to the rest of the window.
Most GUI builders could do this, so what was special about Interface Builder?
Two things stood out. First, you could specify how the button reacted to window resizing. There was a “springs and struts” layout mechanism that allowed you to say which parts were fixed offsets and which were variable. You could also say if the button would resize, and if so, in the X or Y or both directions.
The second thing was the ability to connect the button to an action. By Ctrl clicking and dragging, you could wire up the default action to a “selector” — in effect, a virtual method call, on the owner of the button. This owner would be populated at startup, typically the application (controller). So you could have your code with the responder and another team build the UI, and they would join together at runtime.
You could also use properties generated by code as well - you could connect the button’s field to an object’s property (aka an outlet) so that changing the code changed the UI.
The fact that you could drag and drop connections from UI to code, and from code to UI, as well as building a responsive UI, was really what stood out.
This still lives on in Xcode today; IB and PB begat Xcode and IB which begat Xcode. The “nib” format - Next Interface Builder - was a binary format file containing the descriptive state of the Ui and the wiring requirements, which was renamed “xib” when XML became all the rage is the same thing. The fact that IB has been subsumed into Xcode still hides the fact that is what’s happening under the covers.
I think it’s important to realise that this was in an age when Windows 3.1 was all the rage, and we had only just got out of 256 colour VGA while Next station had 16 million.
Nowadays with everyone doing MVC programming with the web, it doesn’t seem so important. But then there was a time when no one wrote unit tests because it was seen as pointless; but it is from these seeds that ideas become mainstream.