Thanks for sharing. Can you elaborate a bit why GUI development for NeXT was (and probably is) superior comparing to Windows GUI development (even if we include Borland's effort).
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.
[1] https://paulhammant.com/2013/03/28/interface-builders-altern...
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.
Unfortunately I can’t go back and edit the original post to fix. Thanks for correcting me!
https://en.wikipedia.org/wiki/History_of_Delphi_(software)
Visual Basic came out in 1991, by which time Nextstep was already at version 2.1
So yes, these things existed, but after Next had demonstrated them.
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...