EOF, sure, but WebObjects in general? You don't actually want that. You just think you do.
Look: WebObjects was amazing at the time. But have you used it recently (meaning in the last several years) to write something? Because it's almost literally impossible to write something that looks modern and acts modern.
WebObject was designed to hide web development as much as possible from the developer. I.e., to make writing desktop applications and web applications as similar as possible. You'd make a view in HTML, a controller in Objective-C (or later Java), draw connections between them just as if you were making something in Interface Builder, etc. Basically, HTML just became another OpenStep view you could target.
The downside of hiding the web part of web development as much as possible is you get a technology that is very far removed from modern practice. To achieve the view/controller design pattern above, WebObjects effectively effectively uses a continuation-like pattern to hide the whole HTTP request/response loop. That's why WebObjects URLs are disgusting beasts: they tell WebObjects what state corresponds to what you're doing. ASP.NET WebForms does this same thing, by the way, although it slaps its data (called ViewState) into invisible form elements on the client-side, whereas WebObjects stores its state server-side. Former inflates the page by 30k in even simple situations, latter makes the server need tons of RAM, but they both get you to the same place, and about equally well.
The problem is that's not how you write web apps these days. If you're doing a simple-as-tea CRUD app, then sure, whatever, but you could also just publish your FileMaker or Access database to the web and be done with it in that case. And for everything else, WebObjects, unlike even ASP.NET WebForms, makes it virtually impossible to have clean, trivially usable REST endpoints, which means you can kick your responsive client-heavy web app ideas to the curb. Yes, you can work around it, and ProjectWonder provides some tolerable solutions, but you're really fighting the framework the whole way. Why bother?
I'm also highly dubious that having Objective-C on the server is really a good thing. All those pointer errors you make in your iOS app that generally just result in a crash suddenly result in your server being rooted. Memory fragmentation becomes an insanely huge deal, since Objective-C's GC is primitive, and so on and so forth.
EOF was great, and would probably still be great. WebObjects was a great idea at the time, but that time has gone.
> You don't actually want that. You just think you do.
No, I pretty sure I want an updated version of it. We don't have any clue where it would have evolved, but I wouldn't be surprised if Apple would have kept at it, there would have been a "Final Cut Pro X" moment.
> All those pointer errors you make in your iOS app that generally just result in a crash suddenly result in your server being rooted.
I really don't seem to run into those as much as others, maybe I'm lucky. Between Ruby or Objective-C, I'll take my chances with Objective-C.
Look: WebObjects was amazing at the time. But have you used it recently (meaning in the last several years) to write something? Because it's almost literally impossible to write something that looks modern and acts modern.
WebObject was designed to hide web development as much as possible from the developer. I.e., to make writing desktop applications and web applications as similar as possible. You'd make a view in HTML, a controller in Objective-C (or later Java), draw connections between them just as if you were making something in Interface Builder, etc. Basically, HTML just became another OpenStep view you could target.
The downside of hiding the web part of web development as much as possible is you get a technology that is very far removed from modern practice. To achieve the view/controller design pattern above, WebObjects effectively effectively uses a continuation-like pattern to hide the whole HTTP request/response loop. That's why WebObjects URLs are disgusting beasts: they tell WebObjects what state corresponds to what you're doing. ASP.NET WebForms does this same thing, by the way, although it slaps its data (called ViewState) into invisible form elements on the client-side, whereas WebObjects stores its state server-side. Former inflates the page by 30k in even simple situations, latter makes the server need tons of RAM, but they both get you to the same place, and about equally well.
The problem is that's not how you write web apps these days. If you're doing a simple-as-tea CRUD app, then sure, whatever, but you could also just publish your FileMaker or Access database to the web and be done with it in that case. And for everything else, WebObjects, unlike even ASP.NET WebForms, makes it virtually impossible to have clean, trivially usable REST endpoints, which means you can kick your responsive client-heavy web app ideas to the curb. Yes, you can work around it, and ProjectWonder provides some tolerable solutions, but you're really fighting the framework the whole way. Why bother?
I'm also highly dubious that having Objective-C on the server is really a good thing. All those pointer errors you make in your iOS app that generally just result in a crash suddenly result in your server being rooted. Memory fragmentation becomes an insanely huge deal, since Objective-C's GC is primitive, and so on and so forth.
EOF was great, and would probably still be great. WebObjects was a great idea at the time, but that time has gone.