LearnWhy Objective-J, Cappuccino and SproutCore are completely changing the web app industry


Ryan Carson
writes on June 25, 2008

I’ve been reading a lot about Ojective-J, Cappuccino and SproutCore and I believe these new frameworks are going to have a huge impact on the web app industry and user experience on the web.

So what are they?

Objective-J is a clone of Objective-C, the language behind OSX desktop apps. It was created by the guys at 280North who recently launched 280Slides (a browser-based version of Apple’s Keynote). If you’re interested, I managed to find a link to the Objective-J source which hasn’t been open sourced yet. More files here and here.

Cappuccino is a port of Cocoa (the set of Mac OS X Objective-C application frameworks) to the web. It was created by the 280North team.

SproutCore is JavaScript framework created by Charles Jolley which is being used in the new Mobile Me platform that Apple has just introduced.

So what’s the big deal?

Right now, people are generally building web apps with CSS, HTML, a sprinkling of AJAX and their framework of choice (Rails, Django, Symfony, etc). The basic client-server model still dominates.

Objective-J and SproutCore change all that. They allow you to create true desktop-like apps right inside the browser. They don’t rely on a continous web connection and they are as quick as desktop apps. In fact, if you run them inside a site specific browser like Fluid, you probably would think they were real native desktop apps.

Everyone already generally agrees that we’ll see a melding of the desktop and the browser, but Objective-J and SproutCore are the first solid step in this direction. They’ve abstracted away all the basics so developers don’t have to re-invent the wheel for every web app they build.

Quoting from Mac Fanatic:

“Developers have even more reason to be excited. The whole Javascript/HTML/CSS design process to manipulate the DOM is abstracted to a higher layer with the introduction of Objective-J. The Objective-J language allows developers to write code in a style more like writing for traditional desktop applications. The developer doesn’t directly interact with the DOM or style the page with CSS. Instead, Objective-J itself manages all the views and drawing the objects to screen. More so, the Cappuccino framework provides functionality that is traditionally lacking from other Javascript frameworks, such as: copy/paste, undo/redo, document management and archiving, vector graphics and animations.”

So the big shift is this: instead of relying on the client-server model, you can build asyncronous, offline, robust web apps right inside the browser. In fact, they don’t even need to connect to the web at all.

And even more interesting is this: if you use Cappuccino, those apps will automatically look and behave like OSX native desktop apps – with zero learning curve on the developer’s side. He or she can simply focus on building an kick ass app instead of trying to re-invent basic UI functionality every single time.

You might be saying “Duh. You can already do this with AIR or Silverlight. What’s the big deal?” The answer is that Objective-C, Cappucino and SproutCore are all open source. I think this is very important as it ensures the ideas aren’t directed by one specific company or organization (and their financial goals).

Backed by the big boys

Everyone has heard about Mobile Me, Apple’s latest incarnation of the .Mac platform. They are essentially porting Mail, Address Book, iPhoto and iCal to the web … but what isn’t as well known is that Apple have chosen to use SproutCore for Mobile Me.

This is really exciting for a couple reasons:

1. A massive consumer based company (Apple) is building applications for the browser that look, feel and function exactly like desktop apps. This will change the average web user’s expectations of what ‘web apps’ should be able to do, thus eventually completely removing the need to differentiate between desktop and web apps. The user simply won’t care.

2. We will start to see standardization in UI conventions because more and more apps are built on frameworks that mimic OSX. (This could be the topic of another large blog post as it relates to Apple’s long term strategy to crush Flash, AIR and Silverlight and standardize everyone in the whole world on Cocoa.)

So that’s it. I’d love to hear your thoughts on where this is going. Whatever happens, we’ve got exciting times ahead.

Additional Reading

47 Responses to “Why Objective-J, Cappuccino and SproutCore are completely changing the web app industry”

  1. Quite funny to stumble upon this post in 2013. I wasn’t familiar with Objective-J and Cappucino yet, and because of the title I really thought I was missing out on something. It shows that it’s hard to predict how things develop but I guess we can conclude that it didn’t go the way you envisioned 🙂

  2. Why Objective-J, Cappuccino and SproutCore are completely changing the web app industry,

  3. You’ve gotta love it. I just took my first shot at Sproutcore to town and while it is probably the most basic and stupid sproutcore app ever, everybody loves it.
    Finally, the web grows up. Before, everybody was designer and developer in one, but that made a lot of bad designers and lousy developers. Now, we get developers and designers seperated. And that’ll greatly improve professionalism in the industry, I suppose

  4. Очень понравился ваш сайт, спасибо. Удачи.

  5. Дааа)) Вы бы знали что про Вас пишут в других блогах)))

  6. Спасибо, пост действительно толково написан и по делу, есть что почерпнуть.

  7. Good blog and really interesting, will check for another one soon.


  8. On the ‘Usability’ side. Staying in the same hole for ever for the sake of novice users is not the way to go at all. People of all ages are becoming much more at ease with technology. Alan Cooper in ‘About Face’ reminds us that novice users become moderate users pretty quickly.

    Now if we could only have a standard for vectors (svg) on the web, yeah, I’m talking to you Webkit!

  9. These types of apps. will be just as accessible as any other dynamic page. Remember when people were saying google won’t be able to spider dynamic pages?
    From my few minutes of playing with it, SproutCore seems to spit out standard html/css/js.

  10. Matthew on July 1, 2008 at 11:36 am said:

    One occasionally-overlooked problem with these client-side-centric web application frameworks is, because the UI code is all run client-side, the application is not spiderable.

    If you’re looking just to replace a user’s private desktop application, this isn’t necessarily an issue, but if your business model is still based in part around making content available on the web, or attracting traffic from search engines, this is a significant downside.

    Not that this is a problem for all of these frameworks – those which compile to Javascript and can run code on both the server and client side (like GWT) should give more flexibility.

  11. @Breton – you’re right, I did misquote the paper, sorry about that. The “intuitive = familiar” bit was the main point I remembered from it and I re-linked it without rereading it. Thanks for pointing it out.

    But I think I still have a case in saying that we shouldn’t change things too quickly. I do agree with you – the status quo is not ideal, and it is boring to keep using it. However, I would look at this work as a transition – improvement as a process, not an event – so that instead of simply releasing “Version 2.0” we’re evolving the interfaces we currently use. For now, we’re just changing the layer below the interface. Ideally, this should be as transparent as possible, in order to cause the least disruption to the users who need to keep doing all their stuff – they can’t afford to have downtime. The more downtime they have – think re-training, re-education and system upgrades, the more money they lose in unproductive time.

    I do think this use of web technology is exciting (if only for us developers) because we can get people to start trusting the Internet for more than just serving static documents. Once people start using it for richer and richer applications, they’ll start appreciating the advantages, and then (fingers crossed) even funding its improvement, especially in regards to speed… and where the real money has to be spent – on infrastructure (think about widespread fibre optic!). Then we can have all the real advantages, like true data portability – forget carrying around fragile CDs or portable hard drives. Installation becomes a thing of the past, you’ll never lose your data, media sharing becomes much easier… you name it.

    So I think that while this isn’t the final word by any means, it is a step in the right direction. What do you think?

  12. What about old-fashioned java applets maybe it is time we rediscovered them and forget the pain of the past. Java is becoming open-source modern java is very very fast and I did hear sun really is improving the applet plugin as part of some javafx thing.

  13. @elliot yes I’ve read that before. Have you read any of raskin’s other writings? Did you even read the article that you linked to? Did you know that he was not actually making a case FOR familiarity, or intuition, but rather, raskin is against using intuition as a measure of interface quality.

    I’m not saying that familiarity is necessarily a bad thing. It’s just not very exciting, and it’s absolutely not the revolution Ryan is touting it as. It’s just a convenient way for apple to duplicate their existing interface work directly on the web, including the good and the bad along with it. But why this would be a compelling use case for the rest of the web industry is an argument that has simply not been made.

  14. This is really interesting, I will be looking into all of this at some point when I get some time. From what I gathered not all components have been open sourced yet?

    Is there a package you can grab with all you need to get started?

    Are there tutorials out there?

  15. @Breton: Because intuitive = familiar. Try teaching a 60 year old to use a new interface.

  16. @Ryan

    In looking back, I think I worded that wrong and I agree that you were in no way suggesting that everything should look the same. Please accept my apologies about that.

    I do feel that the explosion that was Web 2.0 had to be attributed in some part to the community doing a hard shift away from the Microsoft and Java solutions of the world because they desired to have more flexibility and freedom in the front-end development.

    The issue with solutions like .NET is that they seek to constrain the interface while making the back-end wide open. This is backwards to the creative needs of the community in my opinion and my only concern with the “abstracting away” of the nuts and bolts is that it will begin to remove flexibility.

    Abstraction of the front-end world is more tricky because there are such nuances that have to be considered. Granted, there are some people that like paint-by-number, but there are many others that like the blank canvas approach.

  17. Yes, finally a javascript framework that lets us do exactly the same things we’ve been doing for the last 25 years! This will change EVERYTHING!

    It’ll help people that already code cocoa apps to ease into web development, the same way ASP.NET has let windows programmers do web development, and GWT for Java developers. I predict the same levels of crimes against usability, accessibility, performance, and web architecture as we’ve seen in the past.

    The only real advantage these sorts of frameworks offer over their desktop counterparts is zero installation, and, occasionally, sidestepping the usability nightmare that is filesystems. These advantages were already there for plain vanilla web apps, and didn’t need a fancy framework to provide them. All the other various advantages of the “webpage” paradigm are thrown out with the bathwater, without stopping to think, “Just what is so great about desktop applications anyway?”

    Seriously, why are desktop-like applications so desirable? Is it the animations? The responsiveness? Undo/Redo is nice, copy/paste is another usability problem, but neither of those features are especially difficult to achieve with just plain vanilla javascript. I don’t think it’s really any of those things. it’s more likely about the comfort that the familiar provides. It’s the window, and the close button, and the toolbar, and everything else that reminds you of being in a familiar environment. That’s okay, but let’s not fool ourselves into thinking this is a revolution. It’s comfort food, nothing new.

  18. I’ve always been a fan of Moo Tools for building more “desktop like” applications on the web, but it’s absolutely clear that this is not the way web apps will be built in the future: html + css, with a sprinkling of js to spruce things up. SproutCore is a fantastic step forward, but in my mind, Objective-J is the more important development.

    I am quite surprised Apple chose not to use Objective-J or Cappuccino to build Mobile Me, and perhaps if they were released to the public earlier in Mobile Me’s development cycle, I reckon they would have been the chosen tools.

    The benefits of using these frameworks should not be compared, however, to the benefits of Adobe AIR – these are different concepts. AIR is all about building installable cross-platform desktop apps, Objective-J and SproutCore are frameworks entirely in the browser and not, as such, “platforms”. These frameworks are pushing the boundaries of the web *so* far that I can’t see AIR ever becoming a success.

    The power to developers that is being provided by these open source frameworks is a wake up call to Adobe and Microsoft with their proprietary technologies (Flash and Silverlight). Many smaller apps are now able to be replaced by web versions, and Apple has seen this relatively early on. Looking at Microsoft, they’re internet presence is more focused on search and “crushing Google”, not improving their ailing software strategies.

  19. @Jason McCay

    You asked “Why is there such a strong desire to have one design, one way, one approach for applications.”

    I’m not promoting one way for all those things. What I’m excited about is abstracting development away from some of the nuts and bolts that have already been built (and built well).

    We need to focus more on building innovative apps, instead of re-inventing the low level components and design elements.

  20. @Ted: I agree… Alex gave a talk at Google I/O last month, Can We Get There From Here, and he talks about a continuum of Web-ish to Desktop-ish on Slide 24. Basically his order goes something like HTML Prototype Dojo GWT Silverlight Flex. Dojo takes an interesting approach that the “compile step” is optional… it improves performance, but it’s JavaScript to JavaScript.

    @Ryan: I agree, it is cool that people are constantly pushing the limits of the web. We have a constant debate about doing stuff that’s webby, meaning that just cloning the desktop UI and showing it in the browser often misses out on the best pieces of the web. Also, things like back button support, accessibility, vector graphics, animations, etc., are all things that are solved by toolkits like Dojo that really let you choose how desktop-ish you want your web app to be. The new objective-c and cocoa toolkits are interesting in unifying the programming approach for Apple desktop devs. It’s also interesting to see if going the other direction, with really good JavaScript bindings for Cocoa in Leopard, making it quite a bit easier to use web technologies to create nice desktop apps on OS X.

  21. @LachlanHardy

    I believe GWT has a good support for accessibility and internationalization.


    I don’t mind developing it using Java (as opposed to Objective-J?). You get a lot of things from that: solid debugger, solid IDE, solid framework. Sure, you can’t do heavy meta-programming that you could in JS, but there’s not much of meta-programming needed anyway when you’re building a simple UI.

    @Dylan + Ryan

    I don’t mean to be rude, I think Dojo is a great framework. But I felt that there are differences between the Dojo-like frameworks versus GWT, Objective-J.

    The latter group provides a way to do JS via some other languages. They’re more of a platform than a JS library/framework. So I think Ryan is kind of right for mentioning Objective-J/Cappuccino as something new.


    I develop UI using GWT + Ext-GWT everyday and I do share your sentiment once in a while: “is it necessary to make this look exactly like a desktop app but supports history and probably supports offline as well?”

    It’s been a painful experience for me to support both web and desktop mindset/features. Fortunately GWT, Ext-GWT and GALGears help to ease my pain.

    But something I observed outside technical issues/debates. Recently I asked people who are not technical-savvy: which one you’d prefer, a desktop-like application on your browser (think of Ext-GWT/Ext-JS) or a web 2.0-like look-n-feel (think of GMail, Google Readers). They all said they prefer the web 2.0 look-n-feel because desktop-app look-n-feel reminds them of the complicated desktop software they have to deal with every single day.

    On the other hand, most developers I talked to (developers, not web developers), prefer the desktop-like UI because they believe that “the browser can do better than what it is right now and we haven’t fully take advantage of it.”

    Two sides of world…

  22. Wasn’t focusing on app building instead of worrying about “basic UI functionality” and making the web act just like the desktop something that Microsoft attempted to do with the Visual Studio IDE and subsequent .NET platform?

    “Hey look all you desktop developers, you too can program for the web…just drag and drop your interface elements, select some drop-downs and Ka-Chow!, a fancy web site that looks and feels just like a desktop app!”

    The separation between design and implementation is, in my opinion, a good thing. Why is there such a strong desire to have one design, one way, one approach for applications. Does this not stifle innovation? Aren’t web apps more than just their component parts?

  23. Some would argue that accessibility is actually the biggest drawback of these frameworks (I’ve examined both SproutCore and GWT amongst others of similar ilk). The 2.0 crowd has never been interested in that, though, so I’m still trying to work out if I’ve been obsolesced or if this is just the same old RIA without a plugin. They’re still too young for me to make the call, but accessibility concerns me. As do the constraints of working within each framework’s understanding of how to do things on the web.

  24. Interesting Post, I’ve been very impressed with the functionality of 280slides for the last couple of weeks, very interested to see what apple do with their new workings.

  25. Nice post, it’s something were looking into more and more at work, I’m agreed with Elliot that a lot that’s holding it back is the complaining and short-sightedness, we wouldn’t even be at this point without the people mentioned thinking out of the box so why not take things further and fully embrace these technologies and give them a whirl.

    I am just a front end designer though, so I’m quite happy to make these app’s look pretty and do fancy things whilst my developers work on the backend stuff 😉

    I’m really really excited about this stuff, and it seems that Apple (again) are pushing these technologies that have existed for a while in front of a larger population.

  26. @Elliot, it’s true that computers are becoming faster, however that also means desktop apps are becoming equally faster. Javascript applications are not likely to ever become as fast their desktop brethren, but they are sure to become FastEnough.

    The biggest limitation is not speed, however. The interaction between the local machine and the in-browser application is lacking, though; Dragging and dropping files and interaction with local applications like Growl and Addressbook are lacking in RIAs. Hopefully stuff like Yahoo Browser+ and single-app “browsers” like Fluid will be changing that.

  27. @Josh

    Anyone who complains about slow web apps isn’t thinking ahead. Squirrelfish has boosted Safari well into the clear in terms of Javascript speed, and Mozilla will be doing their best to keep up. Combine this with Moore’s Law and increasing processing power, and it’s quite clear that things will improve.

    The only thing that will stop the situation improving is people complaining. It’s just another example of the “640kb of memory ought to be enough for anybody” shortsightedness.

    Either that, or I totally just got trolled.

  28. Every time I hear SproutCore I imagine it’s either some new vegan hardcore squarefoot political movement, or a new song by Operation Ivy.

    Sproutcore(HedgeCore rewrite) ! by OpIvy

    “What happened to your garden, something’s not the same
    Something in your squarefoot has made a violent change
    We come, we see, we dive and destroy
    Anhilating sprouts, is what we enjoy!”

    Yeah, I should sleep.

  29. @Dylan

    Thanks for stopping by – been ages since we chatted.

    You’re right, I should’ve mentioned Dogo, GWT and others, but I feel that there’s a major ground shift to building entire applications right in the browser. This is now hitting the ‘main stream’ I believe.

  30. While these toolkits are interesting, people have been building some pretty amazing, desktop-ish apps with Dojo, GWT, Tibco General Interface, Zimbra, Ext, and other toolkits for quite some time (and this is not to discount jQuery, Prototype, MooTools, YUI, UIZE, and on and on). Support from “huge” companies has been there for a while… Dojo for example (disclaimer, I’m the co-creator of Dojo) has the backing of big companies like IBM, BEA, and AOL and has received corporate contributions from the likes of Sun and Google.

    Ajax in the enterprise has been like this for quite some time (what I describe as Ajax Dark Matter, http://www.sitepen.com/blog/2007/04/19/ajax-dark-matter/ ), and we’re seeing more and more of this on the consumer side which is really neat.

    We’re also seeing the proliferation of JavaScript on the server-side, with work such as Jaxer, Axiom Stack, and Persevere. Exciting times indeed…

  31. @Anthony – Thanks for the heads up on the Mobile Me link. Fixed now.

    @Ted – Interesting point re: Google Web Toolkit. I’d actually forgotten about this (haven’t heard much about it since it launched). I’ll give it another look.

  32. It’s long dead as a technology from IBM, but I wonder how IBM’s Sash technology (see http://findarticles.com/p/articles/mi_m0FOX/is_20_4/ai_60301535 or search on “sash weblications”) could/would intersect with these toolkits.

  33. Personally, I think the bigger thing going for these toolkits vs AIR/Silverlight is that they’re on top of what’s already there, rather than requiring a plugin. For me, that’s a way more important reason than OS/not.

    @Ted, GWT is fine, except you have to program in Java.

  34. @Josh

    They’re slow because the JS files are still generated by human’s hand.

    If you want something faster but still JS, you should give “Google Web Toolkit” a try. It is faster, smaller and better than these libraries in terms of the JS output.

    Sometime I do find it odd when people heard about Objective-J and SC and to think that these are “new invention” while GWT has been there since 2006 and obviously have 2 years start.

    I’m using GWT professionally and I can confirm that it is by far the best one out there. Check out Ext-GWT too: a faster version of Ext-JS.

  35. They are *not* as fast as desktops. They are dog slow and cause frustration in users despite all the spinning gee whiz visual eye candy. We are in the upswing on the hype with these things and hopefully they will follow their RIA big brothers into the graveyard.

    I’m waiting for the next thing like everyone else. This ajax garbage isn’t it.

  36. Anthony Bruno on June 25, 2008 at 2:31 am said:

    Wonderful Post!

    Would love to give some insight, but Im just here to let you know your Mobile Me link is invalid.


Leave a Reply

You must be logged in to post a comment.

man working on his laptop

Are you ready to start learning?

Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Start a Free Trial
woman working on her laptop