3 ms·

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 w

by bonaldi 16y 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.

encoderer 16y 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." 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.
- bonaldi 16y ago
  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.
  - encoderer 16y ago
    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.
    - bonaldi 16y ago
      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.
      - encoderer 16y ago
        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.
        16y ago
bad_user 16y ago
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)?
- bonaldi 16y ago
  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?
  - bad_user 16y ago
    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.

by bonaldi 16y ago

encoderer 16y 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." 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.

bonaldi 16y ago
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.
- encoderer 16y ago
  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.
  - bonaldi 16y ago
    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.
    - encoderer 16y ago
      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.
      - 16y ago

bad_user 16y ago

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)?

bonaldi 16y ago
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?
- bad_user 16y ago
  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.