4 ms·

Though Web Objects didn't take off, I think the idea behind them did. We just call it SaaS. In SaaS products, instead of building the same core ingredient over

Though Web Objects didn't take off, I think the idea behind them did. We just call it SaaS. In SaaS products, instead of building the same core ingredient over and over again for multiple companies, it is built once and then made available via the web to anybody who wants to use it. That's what ViaWeb was, it's what WePay is, it's what Salesforce is -- it's what the web has become. You need software to do something, you Google it, you find a web-app and you start using it. Done. Web Objects, Web Apps, tomato, tomatoe.

danilocampos 16y ago
Always thought he was seeing OOP in general, which, of course, took off in a huge way, even if Web Objects didn't. (NeXTStep was hugely OOP, as were OS X and iOS later, of course.)
- Estragon 16y ago
  OOP was pretty big by the time of the interview, so what he says doesn't make sense, if he's talking about OOP in general.
  - encoderer 16y ago
    Nah, he was definitely talking about OOP I feel. I mean, specifically, he was pimping his product that he was launching, NeXT WebObjects which was just an application server for OO apps. In 1996 most software was being developed in, hmm, C, C++, and Visual Basic 5. Java was just launching. Most web stuff was Perl or old fashioned C. VBScript (Classic ASP) was being developed.
    - stcredzero 16y ago
      One of the things that happened after Steve's infamous Xerox PARC visit, was that he saw Smalltalk, thought it was massively cool and declared that to be the way everyone should program. When he went on to found NeXT, they were pushing Objective-C, which is Smalltalk style message passing layered on top of C. (Trying to get the best of both worlds, though the combination is a bit awkward to me.)
nikster 16y ago
WebObjects was just a really well designed app server. It's obvious things would work that way - even though WO didn't, in the end, "win". Too lazy too look it up but WebObjects might have been designed around the same time as Java. A predecessor to Ruby on Rails at a time when websites were making extensive use of the <blink> tag.
- bonaldi 16y ago
  It also did things that have still really to be replicated for web developers in a joined-up way; things like proper developer tools (including Interface Builder for the web), a seriously nifty ORM, and the ability to write the back-end once and produce both a web app and a desktop app. (I know Interface Builder doesn't appeal to the hardcore set, but at least it is an attempt at a different way of working. Our never-ending focus on creating interfaces programmatically makes me wonder what would have happened to desktop publishing if we'd said "what? We made you a postscript mode for emacs -- what more do you need?" and left it at that.)
  - sudont 16y ago
    There would be front-end developers for print design… HTML really is like postscript mode for emacs, as far as a designer is concerned.
    - bonaldi 16y ago
      Yes, I agree. That's why I think we should do better. Dreamweaver really doesn't come close to what we should be doing in terms of visual and coding tools to let designers and developers work together.
      - sudont 16y ago
        I’m not smart enough to think of a solution. Interface builder in Xcode works because everything’s based on cartesian coordinates, but other than pages starting from top-left, HTML is really based around flowing and cascading. Maybe it’s possible, CSSEdit works great, but requires the HTML to be set up. Espresso’s node layout works well to show hierarchy, but still requires manual HTML editing. One solution would be similar to creating nested NSViews, but turning off {position:absolute} by default. This would force the designer to think in a way that’s similar to how web pages flow in the real world, instead of throwing absolutely positioned elements into a static frame. I’d have to say some sort of blob state file would be the best bet. The designer works in a vector environment that emphasizes mutable viewports, elements and element amounts. Basically dashcode with vector built in.
joshmaker 16y ago
WebObjects now power the iTunes store: http://en.wikipedia.org/wiki/WebObjects http://en.wikipedia.org/wiki/WebObjects

danilocampos 16y ago

Always thought he was seeing OOP in general, which, of course, took off in a huge way, even if Web Objects didn't. (NeXTStep was hugely OOP, as were OS X and iOS later, of course.)

Estragon 16y ago
OOP was pretty big by the time of the interview, so what he says doesn't make sense, if he's talking about OOP in general.
- encoderer 16y ago
  Nah, he was definitely talking about OOP I feel. I mean, specifically, he was pimping his product that he was launching, NeXT WebObjects which was just an application server for OO apps. In 1996 most software was being developed in, hmm, C, C++, and Visual Basic 5. Java was just launching. Most web stuff was Perl or old fashioned C. VBScript (Classic ASP) was being developed.
  - stcredzero 16y ago
    One of the things that happened after Steve's infamous Xerox PARC visit, was that he saw Smalltalk, thought it was massively cool and declared that to be the way everyone should program. When he went on to found NeXT, they were pushing Objective-C, which is Smalltalk style message passing layered on top of C. (Trying to get the best of both worlds, though the combination is a bit awkward to me.)

nikster 16y ago

WebObjects was just a really well designed app server. It's obvious things would work that way - even though WO didn't, in the end, "win". Too lazy too look it up but WebObjects might have been designed around the same time as Java. A predecessor to Ruby on Rails at a time when websites were making extensive use of the <blink> tag.

bonaldi 16y ago
It also did things that have still really to be replicated for web developers in a joined-up way; things like proper developer tools (including Interface Builder for the web), a seriously nifty ORM, and the ability to write the back-end once and produce both a web app and a desktop app. (I know Interface Builder doesn't appeal to the hardcore set, but at least it is an attempt at a different way of working. Our never-ending focus on creating interfaces programmatically makes me wonder what would have happened to desktop publishing if we'd said "what? We made you a postscript mode for emacs -- what more do you need?" and left it at that.)
- sudont 16y ago
  There would be front-end developers for print design… HTML really is like postscript mode for emacs, as far as a designer is concerned.
  - bonaldi 16y ago
    Yes, I agree. That's why I think we should do better. Dreamweaver really doesn't come close to what we should be doing in terms of visual and coding tools to let designers and developers work together.
    - sudont 16y ago
      I’m not smart enough to think of a solution. Interface builder in Xcode works because everything’s based on cartesian coordinates, but other than pages starting from top-left, HTML is really based around flowing and cascading. Maybe it’s possible, CSSEdit works great, but requires the HTML to be set up. Espresso’s node layout works well to show hierarchy, but still requires manual HTML editing. One solution would be similar to creating nested NSViews, but turning off {position:absolute} by default. This would force the designer to think in a way that’s similar to how web pages flow in the real world, instead of throwing absolutely positioned elements into a static frame. I’d have to say some sort of blob state file would be the best bet. The designer works in a vector environment that emphasizes mutable viewports, elements and element amounts. Basically dashcode with vector built in.

joshmaker 16y ago

WebObjects now power the iTunes store: http://en.wikipedia.org/wiki/WebObjects http://en.wikipedia.org/wiki/WebObjects