SproutCore is essentially (I’m sure I’ll get some of the details wrong so don’t flog me, okay?) a porting of the Cocoa frameworks for use in web apps using JavaScript.  SproutCore is what Apple’s new MobileMe is/will be since the author of SproutCore is now an Apple employee.

If you take a look at this blog post from April, the developer does a great job of explaining the current state of web apps and how Ajax minimizes the inherit lag time of the web.  His take is that Client-Server applications will become the new way of doing things (at least for the next 15 years or so).  Build two applications – one for the client and one for the server – sharing data as needed.  It’s a ‘thick client’.

He also says that writing an application is JavaScript is like writing a desktop app in C.  This is where the port of a framework like Cocoa to JavaScript makes a lot of sense because the framework has had decades of work to make it fast and efficient, however, doing a straight port isn’t practical simply because of the decades of ‘cruft’ in the frameworks.  In other words, if Cocoa were written from scratch today, it would be leaner and meaner and wouldn’t have to support all that legacy stuff.  But wait, isn’t that what Apple’s doing with the iPhone?

Why JavaScript?  For the simple reason that it’s in every web browser on the planet!  In another blog post he suggests using a conversion tool to deploy your SproutCore application as a, wait for it, a static HTML web page.  Yikes that seems pretty darn simple.

Daniel Eran Dilger at Roughly Drafted Magazine speculates that this is Apple’s first foray into web apps and a way to kill Flash, Air and Sliverlight.  True or not it’ll be interesting to see if Apple ‘got it’ early this time.

I still have my doubts about web apps being more like desktop apps.  It still seems that you’re limited to the browser and implementing multi-step undo will be difficult.  Things like being in the middle of a form and accidently quitting the browser and losing your edits (because the app can’t stop and ask if you want to save your changes before closing) are significant features that will have to be overcome.

But, perhaps the solution isn’t a true web browser experience.  Perhaps it’s using a web browser control in a thin desktop client application.  If the controls act and work the same as a desktop application would the user ever know the difference?  Interesting times I think.