Steve Jobs Introduces WebObjects [video] (1996) | Hacker News Reader

Steve Jobs Introduces WebObjects [video] (1996)

channel9.msdn.com

186 pointslpsz98 comments

At the 23:50 mark the slides follow the familiar model seen in Apple media events today.

The approach: in 3-4 concluding slides, concisely reiterate key selling points, compatibility, price, and the availability timeline. I've always found this approach to be particularly effective -- I'm highly likely to unambiguously remember these most important bits given that they are presented last.

I wouldn't say that's exclusive to Apple or something they came up with - sounds like sales 101 to me.

What is fascinating to me was seeing how passionate he was on a product like it was his life goal while talking, and a few years later totally focused on another completely different thing.

It is impressive to me since I am having hard time to let go my little hobby projects and start another one, while he is doing it on much higher level with the same passion. Respect on that.

He actually wasn't that passionate about enterprise stuff, but could clearly make it look like he was in important events like this. I think at this time, he was getting tired of NeXT and was looking to sell the company so he could focus on Pixar, or something like that. He was really tired of the computer business. I remember seeing an interview with him from around the same time period where the interviewer asked him to talk about NeXT's enterprise stuff and the response was something like "You don't really want to hear about that right? It's not really that interesting."

That was the 1995 Cringley interview. About 54 minutes in. "You don't really want to hear about NeXT, do you?" was the exact statement. And he claims that innovation in the computer industry is in software within seconds.

I think Jobs' response was more about disarming the perceived courtesy. While polite to ask Jobs about what he was doing with NeXT in 1995, the highlight of his career (and general interest) would be with Apple and to a lesser degree, Pixar.

Kind of like talking to a rock legend about their latest album, when most people care about their breakout period.

> What is fascinating to me was seeing how passionate he was on a product like it was his life goal while talking, and a few years later totally focused on another completely different thing. > It is impressive to me since I am having hard time to let go my little hobby projects and start another one, while he is doing it on much higher level with the same passion. Respect on that.

He's the world's greatest used car salesman.

What a trip to see Steve Jobs not only try to sell something pre-iPod-success, but something as technical and relatively pedestrian as a web framework...And he does it well, without the use of a primetime-polished slideshow or catchphrases.

The one visual that sticks out to me in this video: the silhouettes of people arriving mid-speech and leaving early.

"relatively pedestrian as a web framework"

In early '96 having a RAD MVC web framework backed by an ORM was really pretty groundbreaking (even moving codebases relatively seamlessly between an OpenStep desktop app and WO was possible), though yeah, this was Jobs going after the Enterprise audience rather than consumer electronics, very different vibe.

At the end you can see a glimpse of the UI for Concurrence, the presentation software Steve Jobs used up until Apple created Keynote.

http://www.kevra.org/TheBestOfNext/ThirdPartyProducts/ThirdP...

Found this story about the first time Steve Jobs moved from using physical slides to Concurrence running on a NeXT http://www.nextcomputers.org/NeXTfiles/Articles/NeXTWORLD/92...

Sounds like the Enterprise Objects Framework was an ORM?

Yep! https://en.wikipedia.org/wiki/Enterprise_Objects_Framework

Apparently it provided the basis for Core Data, too.

It was actually one of the first and heavily inspired the beginnings of Hibernate.

And yes it is the basis of Core Data.

The QA is really interesting. Most of the questions I felt he handled well and showed that he has knowledge of the domain. Two questions in particular stood out:

Q: How can I, as a developer, get my hands on the expensive software suite?

A: Come talk to us. We can accommodate developers who are willing.

This may have been some early input for him to think about sdks and the philosophy of providing developers with tools early on.

Q: What is your view of transactions on the web?

A: We don't think it's a technology problem. It's more of a social/business problem

He was clearly wrong on this one, with the advent of cutting edge technology companies like PayPal and Stripe that followed.

I don't see how he was wrong.

Transactions on the web exist, there are improvements to the UI but it is a social problem (I am afraid of my credit card being stolen) and business problem (Don't worry, trust us we won't let anything bad happen to your credit card).

He made it sound as though it is technologically trivial, as long as society and businesses would get behind the movement. I don't think that is the case from a security standpoint and also designing an api that would allow for widespread adoption.

> He made it sound as though it is technologically trivial

This is a guy who built three operating systems and countless revolutionary apps under his watch. Many of which given the constraints back in the day would've been incredibly complex.

By comparison web transactions IS trivial.

Hmm I was more impressed by PayPal's business tenacity than with their technical ingenuity. Along with the entrenched credit card companies they had to deal with fraud and organized crime.

He was clearly wrong on this one

No, he was right. In 1996 people were just scared of using their cards online. No one big was doing it yet, consumers didn't trust anything about the end-to-end process. There are more risks now than there were then, if anything (given how many trojans and hackers there are targeting cards now), but people are used to it now.

Paypal didn't bring any particularly new technology, they just bought confidence and bigness.

So, about the 10x programmer myth, productivity etc...

Steve mentions that it took about 3 weeks with 3 programmers to build this app. The tools & technologies have evolved and today we can build this kind of thing with a tiny fraction of this effort...

To me that's the kind of thing that really matters after all: evolving technology & tools, not the "10x programmer myth", or those "how to be more productive" tutorials. The tech evolution has a much bigger impact on productivity than those individual productivity recipees.

Those programmers were arguably 10x or 100x programmers, not run-of-the-mill. They made a choice to work on new technology, solving a hard problem. And then put in the effort, probably with little handholding, and managing the uncertainty.

These are traits not found in the average or even median programmer.

I can see close to 10x productivity gains depending on my work environment. If I have three meetings spaced throughout the day, a ton of quick interruptions, and I am trying to learn something new, forget it. If I get to focus on that one thing, then I can be pretty productive.

I also think that the 10x thing is more to do over the longer term (rather than "look at what I bashed out in 2 hours"). I probably don't code as quickly as I used to, but I am a lot more thorough, and having made plenty of crappy mistakes designing my code in the past, I am in a far better position to know what will make my code robust, and maintainable time a month or two down the line.

And, 100x cheaper, if taking consideration of free cloud offerings.

These profound factors keep me working everyday, although I haven't made my millions yet. There was an article about Nokia or Ericsson around early 2000, saying that people tend to overestimate the impact of technology in short term but underestimate in long run. It's the case.

He's obviously in pain here, selling business software on NT of all platforms.

The timing of this video is funny because soon after he went back to Apple to recapture the glory which is consumer electronics.

You are talking about the days when Apple was about to close its doors after the Copland failed experiment and NT was picking up steam against UNIX based workstations.

In 1996 it appeared NT was going to conquer the IT workstation desktops.

NeXT was also going multi-platform with OpenStep.

It must have been painful for him to give up on NeXT's beautiful hardware. To see his beautiful software running on lesser computers probably did hurt.

My final project assignment at the university was to port a particle simulation engine from NeXT/Objective-C to Windows/C++.

The professor had his Cube disconnected on his office, piled with other stuff. No one believed NeXT would survive.

> No one believed NeXT would survive.

And, surprisingly, now every Mac is, essentially, a NeXT.

I would really like to know how cutting-edge this was at the time. It seems incredible to me how little has changed in how we make dynamic web applications.

At the end of the day every dynamic web application does the same thing: concatenate and send back strings.

Sure, let's go down that road. At the end of the day every software that runs does the same thing: flip bits back and forth.

From 1996 to 2005 dynamic web applications concatenated and sent back strings. After that we started sending back strings and concatenating. Sadly half the web hasn't caught on to the "new" way.

not every application/use case needs or benefits from dependency on XHR and JavaScript

> Sadly half the web hasn't caught on to the "new" way.

  s/Sadly/Gladly/

There's something gloriously simple and effective about the page-is-a-page metaphor. Solid, unambiguous URLs that do what they say on the tin. It's not the "old" way, it's the native way.

There is nothing glorious about clicking a button then watching the screen flash and slowly reload eventually revealing a tiny change. Simple I'll give you. Effective, yes, if the user can suspend reality and pretend the state change happened instantly.

How about a URL that unambiguously specifies the state of all parts of the page? Paste that in a browser and it pulls up the page with all its dynamic parts set as before.

That's an absurd example. Why did you assume that I am arguing the extreme case? All I'm saying is that the page-is-a-page metaphor is legitimate, efficient and comprehensible. It should not be dismissed simply because some over-engineered client side framework looks cool.

Obviously "tiny" changes can be performed with client side code without breaking the page-is-a-page metaphor. Look at Facebook -- a good example of an extremely mature application where the page-is-a-page metaphor remains fully intact.

And of course not all websites fit the metaphor, in which case you obviously should not use it.

Indeed it is absurd that we have known how to refresh part of a page for a decade now and yet half the internet still refreshes the whole page. I'd say this has to do with developers still relying upon server side frameworks they learned years ago.

This has nothing to do with looking cool. Your server generated dynamic full page can look great. Didn't you see Steve Jobs's Dodge site? This has to do with user experience, in particular performance. The problem with Steve's site is that a slight change in search criteria resulted in a two second full page refresh. It made me want to shop for a Ford.

Sure their are cases where full page refresh is fine. Shopping isn't one of them. Reading a news story that spans 10 pages isn't one of them. Most of what I use the internet for isn't one of them.

And then there are web applications. Without partial page refresh these feel like shopping for a Dodge in 1996.

There is nothing glorious about clicking a button only to have nothing at all happen because a fragile dependency system is broken, making the entire site less usable.

I use Ghostery to block a lot of tracking JS. This includes things like FB stuff. The number of sites that break because a call to "FB.init" throws an exception is astonishing.

It's ridiculous how quickly people (by which I mean developers) have forgotten the concepts of graceful degradation and progressive enhancement.

There are very few use cases where a web application simply cannot function without javascript.

I used to sell WebObjects projects during the dotcom boom and the ORM was a big selling point. There weren't a lot of frameworks or web dev options back then.

Looking at options today, I feel like a kid in a candy store.

WebObjects is still available and in use by a small but active circle today.

http://wocommunity.org

It moved from Objective-C to Java under Apple. Apple discontinued shipping it with OS X Server Snow Leopard, but the frameworks are still available/free. The community picked up where Apple left off with the open source Project WOnder.

It is a full stack development framework. Enterprise Objects Framework(EOF) is the ORM or Model layer like Cayenne or Hibernate. WebObject components are the front end View layer like you might get from Tapestry.

I have yet to find a web framework that rivals its Controller layer, DirectToWeb (D2W). D2W sits between the Model and the View. It can generate Views automatically using information from the model and with customizable direction from a rule system. It also provides controller actions with customizable callbacks.

Out of the box, WebObjects can reverse engineer your database, constructing a full model of it, and D2W can then construct a full blown Create/Read/Update/Delete interface to it with no coding required. If you don't have a database, you build a model and WebObjects can generate the SQL necessary to create the database for you as well.

It's still pretty amazing, despite being treated like an ugly step child by Apple. It still powers the billion dollar iTunes store as well AFAIK.

I was a WebObjects Developer for 2 years from 2007-2009, the company I worked for still uses it for their massive health-care-related web apps. It's a really cool framwork to use, as it incorporates so many aspects that are usually provided by different libraries.

The developer community is small, but very active. Every year they hold a "World of Web Objects (WOWO)" conference right around WWDC in San Fran.

Project Wonder has done amazing work to bring Ajax and many other "Web 2.0" features to WO.

It does still power the iTunes store, and the Apple Store. A friend of mine that worked at our sister company landed a job with Apple working on the iTunes store, and AFAIK, he's still there doing that today.

I used to work at Apple many years ago in a past life but IIRC:

Project Wonder was definitely at the core of iTunes Store. They had your typical monolithic web application and used most of the WebObjects technologies.

The Apple Store was different. They had dozens/hundreds of micro services which used WebObjects only in the front i.e. to handle request/response and routing. They may have even switched it out by now.

Interesting. I remember reading the Project Wonder mailing lists and the creators and maintainers of it were certain that Wonder wasn't being used by Apple for anything "public facing", but they strongly suggested it was used a lot internally.

I've always wanted to work for Apple... care to share any thoughts?

Same advice given to me a few years back. If you're good and want to work at Apple doing web development, apply. They're hiring.

Oracle Application Express can do something like reverse engineer a database and produce a full CRUD interface.

And it's perfectly, utterly awful.

Web Objects was the first web framework I worked in, back in 2001, and I didn't really understand it at the time, but it already had built and running in production many of the features that I subsequently came into contact with via supposed innovations in other stacks. The J2EE 1.3 spec for example added "entity beans" and unleashed hideous vendor implementations like WebSphere on developers. The impact of all the anti-patterns that spec inspired are still visible in the development world today - I'd say it is indirectly responsible for the rise of Spring and Rails.

WO also had the added benefit of being a full-stack solution. The way the J2EE spec was built up of sub-specs really contributed to the fragmented Java framework universe. Developers then had to get used to spending think-time reasoning about the way the pieces and "tiers" fit together and less time building coherent apps.

A couple of tangentially related discussions:

https://news.ycombinator.com/item?id=8715128

https://news.ycombinator.com/item?id=1968611

For anyone confused: What Steve pronounces as Olé/Olay is OLE.

There was some weird 90s conversion of abbreviations to acronyms. One suck.com writer was called 'Duke of URL' pronounced like 'Duke of Earl'

The Yahoo campus cafe URLs is pronounced "Earl's"

Acronyms, traditionally, are by definition pronounceable as words. Things like "U.S.A." where you only pronounce the letters are called initialisms.

> Acronyms, traditionally, are by definition pronounceable as words.

Yes, I'm aware of that, hence stating 'There was some weird 90s conversion of abbreviations to acronyms' in the comment you're replying to.

I say Earl when I speak of U.R.L.s. And I'm not ashamed of it.

How would you pronounce it?

Oh El Eee, like the names of its constituent letters.

But then I've never heard it pronounced, only ever read it. So maybe "Olay" was the normal pronunciation.

> So maybe "Olay" was the normal pronunciation.

It was.

I assume you also say SQL as 'ess que ell' as opposed to 'sequel.' Probably a generational thing.

I say "olay" but "ess que ell". For me OLE is closer to an actual word (Olé), but SQL is nothing like "sequel".

SQL was originally SEQUEL, thus the pronunciation :)

It took me a while to learn "sequel" was the pronunciation, yes.

But this is because I learned SQL from reading about it, not going to conferences.

That's the point where I cease to follow any discernible convention. I don't think I'm the only one.

  SQL:        "ess kyoo el"
  T-SQL:      "tee-sequel"
  PL/SQL:     "pee el ess kyoo el"
  SQLite:     "sequelite"
  SQL Server: "sequel server"
  MySQL:      "my ess kyoo el"
  PostgreSQL  "Postgres"

PostgreSQL may be the worst/best compromise. The Press FAQ provides an audio file the pronounces it post-grez-que-elle, keeping enough of both pronunciations to be a linguistic spork. Considering it's roots with Ingres, it makes sense, but it also feels like a layered pun.

http://www.postgresql.org/files/postgresql.mp3

"SQL" is pretty complicated:

http://patorjk.com/blog/2012/01/26/pronouncing-sql-s-q-l-or-...

Once interviewed a guy who kept talking about knowing "Squeel". Had no idea what he was talking about until he mentioned "Squeel Server". Cue banjo music...

I've never heard GUI pronounced until moving to the Bay Area. Before I called it G-U-I (still do).

I've never known anyone to spell it out like that. It has always been "gooey".

I loved the CRUD acronym when I first heard it. Sounds like an insult, and it kind of is one!

Whizzy wig was the first time I realised what I'd read in my head wasn't how others pronounced an acronym.

Mine was the first time i tried to buy a SCSI drive in the US. The sales person didn't even understand what i meant, when i said "es see es i". Then he pronounced "sceuzy" and i was amazed :))

I once requested the "Wi-fi" key in a hotel, at St. Malo, France. The receptionist gave me a weird look and, after I explained myself, said «Oh, le "wee-fee"».

You arrr ell

Never mind how it's pronounced. No developers in their right mind would automate Excel from their web server the way they did in that demo!

Many developers "in their right mind" did exactly that. For a pretty long time, this was the way people manipulated spreadsheets in an automated fashion unless you wanted to buy expensive products from third-party vendors.

So many people do that Microsoft keeps a knowledge base article about it:

http://support.microsoft.com/kb/257757

"We don't recommend or support it but because you want to do it anyway, here's what to consider to make it work less badly"

http://tapestryjava.blogspot.com/2003/09/excellent-discourse...

https://mail-archives.apache.org/mod_mbox/tapestry-users/200...

http://vschart.com/compare/apache-tapestry/vs/webobjects

http://tapestry.apache.org/

YouTube - https://www.youtube.com/watch?v=TaX25rxOY8Q

It's remarkable to see a presentation presenting programmatic construction of HTML as a novel concept.

This was 1996. WebObjects was far ahead of anything I used at the time. I started using WO and EOF in 1999 and it had stuff like scaffolding (D2W) at that time. When did RoR introduce this?

That is the thing with RoR.

There were frameworks before it that offered similar functionality, but since the web was growing up only a few developers got to see them.

Man can Steve sell and make things look good. I used Webobjects for some projects back in the day.

I read somewhere that WebObjects were in part the inspiration for JEE.

Somehow the OpenStep efforts got sidestep by making Oak into Java and everything else got ramped down.

I wonder how it would have been if Sun had kept with OpenStep instead.

The spirit of this lives here: http://seaside.st/about

And it is an awesome framework.

ReactJs is going the same kind of components based thing these days. Nothing so new, except for where the component is running...

Also of note is that Seaside uses the concept of continuations to manage multi-page flow which is a very fitting abstraction for this problem, and that most languages can't afford to do. That means they can code complex behavior as if the line between client and server did not exist.

Kind of, but in the 3.x series, please note that continuations are now completely optional.

As continuations are quite memory heavy, the new way allows for lighter sessions.

One interesting thing for me was, to see how slow the server interaction really was.

"We love the Internet Explorer browser very much" - Steve (6:58 minutes)

- said no apple employee ever.

I am not entirely sure about this.

While I don't have personal experience, from what I've read, IE on Mac was a fair bit different from IE on Windows. IE 5 for Mac, released in 2000, used something called the Tasman engine: http://en.wikipedia.org/wiki/Tasman_%28layout_engine%29

> At the time of its release, Tasman was seen as the layout engine with the best support for web standards such as HTML and CSS.

Also from http://en.wikipedia.org/wiki/Internet_Explorer_for_Mac#Inter...:

> The Macintosh Edition introduced a new rendering engine called Tasman that was designed to be more compliant with emerging W3C standards such as HTML 4.0, CSS Level 1, DOM Level 1, and ECMAScript.

I vaguely recall reading somewhere that back while IE for Windows was giving web developers prematurely grey hair, IE for Mac was a much nicer browser and much more comfortable to support as a development target. I think it ended up getting less time/thought/effort from Microsoft eventually. Also, Safari was released in 2003 (beta in January, default browser in OS X 10.3 Panther, in October).

IE for Mac was actually fairly nice, especially in the early days of OSX. I kinda miss that candy blue icon in my dock.

IE on Mac was really good, back in the day. More standards compliant than the Windows version and a different codebase.

http://en.wikipedia.org/wiki/Internet_Explorer_for_Mac

This may have been back when apple needed ie mac as web sites weren't working well on mac.

For a while sadly it really was the best web browser for mac.

For a while, it was the best web browser, period, on any platform (including Solaris and HP-UX). Netscape kinda blew.

He was at NeXT, not Apple in 1996.

By that time, NeXT's core product line had morphed from being a series of Unix workstations to being an implementation of the NeXT APIs that ran on top of several platforms, including Windows.

So much so that IE for Mac shipped as the default web browser for Mac OS from 1998 onward until Safari was announced in 2003.

Considering Cyberdog was the only thing Apple had at the time, that's not surprising. https://en.wikipedia.org/wiki/Cyberdog

Interesting that he dismissed interpreted languages for non-trivial code, as if it were obvious that the performance wouldn't be good enough. But wasn't Perl already being used for CGI scripts in 1996?

I'm sure you could make it work, but back then fewer engineer-hours had gone into making interpreted languages fast, and hardware was slower. It was also common to run a website on one machine.

Tangentially related: https://twitter.com/GregB/status/27244912213

"> @spolsky: Digg: 200MM page views, 500 servers. Stack Overflow: 60MM page views, 5 servers. What am I missing? << That's the PHP factor"

Yes and it was a pain.

I learned never ever again to use interpreted languages for anything else other than shell scripting.

"Giving your credit card to someone over the phone is far less secure than giving it to someone over the web." [27:53]

Great job by Steve Jobs!

Reply on news.ycombinator.com