Design Element
Comment on "Separation of Model and View Web Frameworks"
by David Phillip Oster — Aug 02
The obvious answer is: just write the apps in Cocoa. Instead of a web app, write a web-enabled OS X application. When your program needs to talk to a server, use NSURLConnection to do your asynchronous GETs, POSTs, PUTs, and DELETEs. No need to compromise on the app side, and you get the full power of the user's machine for the user interface, with local processing and storage for offline use.

Server side, same deal: use you can write the whole server, or you can install the fastCGI module in Personal Web Sharing (Apache) and just accept requests. Once again, you have the full power of Cocoa available to you: Core Data, for example as a back-end data store.

Of course, there are downsides: the client only runs on OS X, and the server only runs on OS X. The big plus is you get up and running fast. Once it works, you have the leisure to decide if you want to rewrite it in something that opens it up to the rest of the world.

You'll still need to "write your application twice": a quality web app needs a server that can stand up to malicious clients, so every input has to be validated on the client, then validated again on the server, but at least since they are both Cocoa, you can use the same source code in both places.

I've actually implemented a small web app this way. The client was iPhone, so Cocoa was the obvious choice. The test server was the Mac on my desk. The deployment server was not a Mac, but once I had a working system, I translated the server code from Objective-C to C, and just compiled and ran that code on the deployment server.
Back to "Separation of Model and View Web Frameworks"
Design Element

Copyright © Scott Stevenson 2004-2015