Hacker News Reader

Comment by heyts | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

> 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.

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

Reply on news.ycombinator.com