Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

WebObjects is, in many ways, two products: EOF4 and the web components. I'm going to separate them.

EOF4 was an absolutely insanely well-designed ORM that I absolutely still think has held up very well. EOF4 assumed, hey, you already have a relational schema! and hey, you like your objects to actually act like objects!, and rather than trying to shoehorn one into the other, EOF4 instead provided excellent tools so that you could specify how your database should be represented as objects. Other tools today still provide that (e.g., Hibernate), but EOF4 provided it in an extremely easy-to-use way that at once provided good abstractions, and the easy ability to dive under the covers when necessary.

WebObjects's web components, on the other hand? Probably not. Prior to widespread JavaScript, WebObjects made it extremely easy to write stateful websites without going crazy playing with sessions and the like. Nowadays, the right way to do that is to write a JavaScript application and call a bunch of REST endpoints--something doable in WebObjects, but needlessly complicated. Throw in Objective-C's memory model, and I don't really have any desire to work with WebObjects again.

If this project revives EOF4, and provides a cleanly RESTy way to use WebObjects, I think there could actually be a lot of value for companies that want to reuse their Cocoa models on the server. I don't think we're going to see a general renaissance of WebObjects, though.



Thank you for the insight. I mostly used the frontend components and was already using proper frameworks handling sessions and alike, so this might be why I didn't enjoy it a lot.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: