Hacker News new | ask | show | jobs
by marbletiles 5670 days ago
What WebObjects would have allowed us to do today if it hadn't been left to bitrot was write an app's business logic once, customise the interfaces and have a webapp, Mac app and iPhone app all from the same codebase. They would connect to the same database, and sync seamlessly.

You can feel the lack of it every time an iOS developer complains there isn't an out-of-the-box syncing solution. They're all using CoreData (which is a simplified cut-down version of WebObject's EOF); it should be a simple matter just to sync to a Mac app, let alone to a web site.

Instead, devs have to learn three different stacks and join them all up manually. Frustrating to watch when you know we've had something better since 1995, and it's sitting neglected.

If you see WebObjects as competing with PHP then yes, it absolutely lost. If you see it as creating the cloud 15 years before its time, then it's actually the only contender that comes anywhere close.

2 comments

"What WebObjects would have allowed us to do today if it hadn't been left to bitrot was write an app's business logic once, customise the interfaces and have a webapp, Mac app and iPhone app all from the same codebase. They would connect to the same database, and sync seamlessly."

I think this is pie-in-the-sky just the same way his prediction of being able to write an app in "20% of the time" was.

"Write an apps business logic once." I've been developing software for a while now, 10 years, and I've never seen true company-wide (let alone world-wide) code reuse on a massive scale.

Yes, there is a lot of code reuse. And yes django and zend framework and RoR are all examples of code reuse.

But I've worked with so many entrepreneurs and CEO's who have this same wish: Write it once, Use it everywhere.

It just doesn't work that way in practice.

Ever actually used WebObjects? Especially in the objective-C days this is exactly what it did. (What became) Cocoa has pervasive MVC all the way through. Turning a WO app into a NS app was a matter of working on the V, as it should be.
Just because that's what it CAN do doesn't mean it will ever be used that way in practice.

There are many existing technologies that would let you "write it once and use it over and over in different platforms" which is the generic version of what you described specifically using iPhone, etc, as examples.

But in practice writing code general enough to do that takes much longer and is much more difficult and required more elite developers.

Might work fine for the companies that are Mecca for grade-a development talent. But for the bread and butter companies wherein 90% of software in this world is written? Please.

Lets separate out here Job's utopian spin and focus on what I'm actually talking about, which is not "global level code-reuse" or whatever generic strawman you're aiming for.

But let's say I'm writing a web app, perhaps in RoR. I build an entire model for the backend and set up controllers to drive it. Have my HTML views and I'm good to go. Then I want an iPhone client. I have to reimplement that exact same model in Objective-C, and a good portion of the controllers too.

With WO, all that wasted time vanished. The same models and controllers worked for both, right down to the NSString level and below.

Does that let you write once and expand to everything, everywhere? No. But does it take grade-A talent to work across its supported platforms? No.

I agree with you that this was the WO vision. I think what we have settled on instead is JSON over RESTful interfaces. The downside is that it takes a lot more code to hook the web logic into the interface. The good side is that it works across languages and technology stacks, you just need a JSON library and an HTTP stack.

This is probably a good trade off, because the "one language for everything" has never succeeded in practice.

The exact same model. This is textbook. In practice? There's going to be differences. The exact same database does not mean the exact same model.

Controllers? Night and day. A complete re-write would be necessary. The app will function entirely different.

Generic strawman? Chill, this isn't slashdot. But to say that the only thing stopping this awesome revolution in software development is that Web Objects wasn't successful seems to me to ignore the grim realities of most software development projects: There isn't the ability, talent, budget or planning to produce truly reusable code.

In practice? I've done this. The controllers change only as much as needed to accommodate the new views. If your model has differences you've coupled it too tightly.

"only thing stopping this awesome revolution in software development"

I thought you said this wasn't slashdot? Who is talking about an awesome revolution? I am talking about a smarter way of building software across different platforms, a way that worked then and would work now to solve real problems that we have.

The fact that the solution is in a space that has long been occupied by the type of wishful thinking that has clearly hurt you in the past doesn't mean you get to write the entire concept off.

I'm sitting with my iPhone in one hand, reading your post, and before this I checked my Facebook account using the native iPhone client and now I'm wondering ... what the hell are you talking about?

Do you think the hard part of building something like Facebook is that stupid native client (that can sync just fine)?

Do you think we make our lives easier by only making the "hard part" of a job easier?

Look at the number of little webapps people here make. Do you see absolutely no value in also being able to produce native apps at the same time, with dramatically less additional work, using the tools and languages you already know?

Facebook's native client "syncs just fine" because they did extra work to make it so. Why is it bad wanting to get that functionality for free?

I understand your point mostly, but I think you're wrong nonetheless.

They did get that functionality for free (mostly) with their web client optimized for mobile: which works and behaves just fine. But even so, they rolled their native client anyway, because the web client doesn't feel and behave like a native iPhone app.

A native iPhone app is property optimized for the screen width, it does local caching (which a web app used on a desktop doesn't need to do), it behaves differently in regards to the control used (which respond to different events), and in many cases it is desirable to get rid of the page metaphor, no request/response cycle, etc...

The business logic may be the same, but the UI logic is very different and you don't want something autogenerated because the UI itself is usually a competitive advantage; and assembling it is not the hard part, a lot harder is to come up with a good design or to make your backend stable (I don't know how it happens but when I go to Foursquare 6 times out of 10 their service is down).

For instance ... I'm using Twitter a whole lot more on my iPhone because the native client kicks ass. In contrast I use Facebook more on my desktop because the Twitter's web interface sucks (yeah, I'm weird like that).

What I'm trying to say is ... companies that want cheap transition to new platforms like the mobile, already have the right tools: the web and its related protocols; which are more ubiquitous than ever. If you want more than that (say, to differentiate yourself from the competition, or just to keep up), autogenerating the UI won't help; you'll have to get down and dirty because the beauty of a good design lies in the details.

There's no free launch or silver bullet.

I think you're missing the point. The UI isn't autogenerated -- it's the only bit that isn't. (Aside from DirectToWeb, which is a whole different thing). What WO allows you to do is save on all the backend work and focus entirely on the details of the UI. Which as you say, are the bits that matter.

There may be no silver bullets, but there is having a gun when everyone else is using three different types of hammer.