Announcing Cappuccino

It is our great pleasure to finally release Objective-J and Cappuccino to the open source community today. We’ve been working hard on this, and we’re incredibly excited to get it into people’s hands and start seeing what they can do with it.

Objective-J and Cappuccino offer a different take on web development.

Imagine that if every time developers wanted to add a new feature to Python, or even just fix a simple long standing bug, they first had to get permission from Intel and AMD. They’d start by drafting up a proposal of the desired changes, then approach the large chip makers, try to build a consensus, and finally wait patiently while these chip makers actually did the implementing of the proposed features. Sounds a bit silly doesn’t it? Well, this is exactly the way web development works today. It’s as if at some point we all decided that the future of the core technologies of the web would be in the hands of a very select minority, while the rest of us would have to look on from the sidelines and hope for the best.

Pretty much everyone agrees that JavaScript, and application development on the web in general, are in serious need of an update. But then why has JavaScript stagnated for so long? The reason is pretty simple: the motivations of the people designing it are fundamentally split from those of the people that actually use it.  You don’t have to search very far to notice this, just look at the now defunct ECMA Script 4 proposal.  Most JavaScript programmers today could list a number of features and bug fixes they’d like in JavaScript, such as classical inheritance, better media support, and access to the webcam.  However, instead of tackling these very tangible concerns, ECMA Script 4 instead chose to focus on obscure problems like let-versus-var scoping rules. The result was an overly bloated and complex proposal that was destined to be scrapped, and more importantly, would have not pushed the next generation of web applications even had it succeeded. Ironically enough, in the last couple of years the most important developments have been proprietary additions like Microsoft’s XMLHTTPRequest and Apple’s canvas tag. Even vendors, though, aren’t in a position to move the web forward at a great pace. Browser vendors decisions are rooted in internal politics, and complicated by the fact that the major players don’t play well together.

And that’s why Objective-J is different. Objective-J is not simply a new JavaScript library, but an attempt to restore control of the language and basic building blocks of web development to the developers.  We believe in the importance of getting the entire community involved, so that we can experiment and move forward at our own pace. So while it’s true that Objective-J is great because it adds features like Ruby’s methodMissing and classical inheritance, the real beauty of Objective-J is that it already works in every major browser and it is completely extendable at our discretion. New language features can be added as necessary, and since every individual developer ships the entire runtime without a plugin, no one company can control the destiny of any other, unlike Silverlight or Flash. Perhaps most importantly, you’re not bound to our development schedule.

It’s the Frameworks, stupid.

In reality, Objective-J was built to support the real star of the show: Cappuccino. Cappuccino is essentially a port of the GNUStep frameworks (or Cocoa as more people are familiar with them), and it aims to fundamentally change the way applications are written on the web. Unlike many other libraries out there today, Cappuccino is designed with the express purpose of building desktop caliber applications that run in the browser. That’s why we chose to base this framework on proven technologies that have had thousands of successful applications written on them already, and have been proven to be one of the best development environments there is.

To be clear, Cappuccino is about building applications, not web pages. When you think about applications, think 280 Slides, or GMail, or Meebo.  jQuery, Prototype, and others do a great job of making static web pages a little more interactive, but they weren’t designed for building full fledged applications.  Similarly, Cappuccino is not for building web pages; it’s optimized for a completely different set of tasks.

280 Slides is the first app built on Cappuccino, and it’s a great showcase of what’s possible.  Cappuccino builds in many of the features you see, like the Document architecture, object copy/paste, global undo and redo, drag and drop, and great graphics support.

We’re open sourcing this technology because we sincerely want to be part of a world where there are more high quality web applications like 280 Slides. We’ll be putting a lot of resources into Cappuccino in the future, and we plan to build a strong open source community around the development platform. We can’t wait to see where you take this with us.

– Francisco

  • Hi,

    Congrats for this brilliant release. I really liked your mission statement and wish you good luck for future improvements. I am very excited about Cappuccino and know, if picked up; it will change the way web applications are programmed.
  • Nice work indeed!

    One question, how is the source code protected? I mean, all the source code is downloaded to the clients machine ... For example, I could write a spider and download all the files that comprise your Slides application! Not that I will do that :-) But this is a problem I think ...
  • openspecies
    nice javascript "ontop" runtime,

    one comment about your dictionary implementation:

    http://openspecies.blogspot.com/2008/08/collectionable-object-in-javascript.html

    use Json to serialize and unserialize your plist
  • This is really cool, I can see this getting pretty huge. Especially now Chrome and Firefox 3.1 are promising massive Javascript performance gains.. your timing couldn't be better!
  • sxs
    Hi there,

    nice things!

    I'm just playing arround. And now I wanna make some "server calls". I tried this:

    var aRequest = [CPURLRequest requestWithURL:"http://foo.bar.com/?ajax=givemesomejson"];
    var connection = [CPURLConnection connectionWithRequest: aRequest delegate: self];
    [connection start];

    I implemented the delegates and the didFailWithError one is triggered.

    Now I see that i have to pass a CPURL object to [CPURLRequest requestWithURL:].

    But I can't find any documentation about to make a propper CPURL-object, nor I find something in the source (as far as iI understand it ;-)
  • boucher
    you don't need a CPURL, the request is just fine. You also don't need the [connection start]. This is a bug int he documentation -- the connection is automatically started.

    Of course, XMLHTTPRequests must follow the same origin policy -- are you making a request to your same domain? Have you examined what the error passed to didFailWithError: is? May help debug the problem. Try hitting us up in our irc channel irc.freenode.net#cappuccino
  • chris
    having some tutorial or just some simple examples for server interaction would be great...

    e.g. reading and editing a SQL table
    -> generate the XML file on the server and write a PHP handler for the updates, what about the list in cappuccino

    probably it's just me but I think that giving such an example would be helpful for quite a few people...
  • >>I love the idea of it. Have you look into using Google’s V8 for maybe those that still want to compile it before running it in the browser. I am not sure what it would take to do it but since you mention it will work in Chrome, then it would be neat to see it compile ahead of time. Just a thought.

    That doesn't make any sense. Chrome needs JavaScript source to run just as any other browser does. It can't run compiled JavaScript.

    Now, if Obj-J could be translated to ActionScript, then you'd have some sort of bytecode running in Flash.
  • Donnie
    Just wondering what your take is on building a proprietary application. The code is sitting there fresh for anyone to view. While you are still covered by copyright of course, I am wondering how Ojective-J and Cappuccino communities would address this? Or would you even?
  • boucher
    Donnie,

    This is something that everyone developing JavaScript for the web faces. There's really no panacea, but most people have resorted to minification and obfuscation to offer a little defense. While I'm not sure its strictly necessary, I would love to see some of these existing tools adapted to work with Objective-J.
  • thibaut
    It's wonderfull to see this, we waited for it a long time, finally, it's here, but what about sproutcore ?
  • Is there any way I can help you for this project? This is ABSOLUTELY AMAZING I'm I'll be using it in my next project. Don't hesitate to e-mail me if you need a hand!
  • boucher
    Adrian, come join us on our mailing list and in the IRC channel. We're happy to have people helping out each other, and working on improvements to the cappuccino code base. I'll be writing up lists of projects people can work on in the code too, so you may want to check out the source on github and get familiar!
  • John
    Good Job, I love your examples, now Im going to check which one is easier to develop with, SC or Cappucino.
  • Guys, I am truly blown away by 280 Slides and I think Objective-J is quite an achievement. I must disagree, though, that the ES4 proposal focused on the wrong things.

    First of all, it did include classical inheritance (but media support and webcam access are "browser glue" issues outside the scope of the language spec). And most developers I talked to decried the introduction of classes, fearing that JavaScript was mutating into Java. Some voices — most notably Doug Crockford of Yahoo! and Dustin Diaz of Google — wanted an ES3.1 with incremental improvements (such as the "let" keyword you dislike) and bug fixes.

    I will agree that ES4 was guilty of biting off more than it could chew, but I think it was going in the right direction to begin with. I'll further agree that we could use richer APIs from the browser environment, but that's to be addressed by HTML5 and the WebIDL initiative. HTML5 itself is a petri dish for the "add, then standardize" model of XMLHttpRequest and the CANVAS tag.

    This only proves, though, that developers have varied gripes about their tools and will come up with varied solutions. Glad to see Cappuccino is officially out; I'll be sure to take a closer look this weekend.
  • Kevin
    Since I don't yet know Obj-C and am just now learning the syntax, I have a newbie Obj-J question. Is there a forum, or some appropriate place for me to go with my newbie questions?

    thanks in advance, 280 Slides is brilliant and it's exciting to learn the framework you used to develop it.
  • boucher
    Kevin, you should feel free to check out our IRC channel, or post your question to our mailing list. Both can be found on this page: http://cappuccino.org/discuss/list.php
  • Aron
    Brilliant!
  • Greg Patrick
    One of my thesis students pointed me to this site, and I have to say that I'm impressed with what I see. This is just what I need for some applications that I've been planning.

    Great job!!!
  • I love the idea of it. Have you look into using Google's V8 for maybe those that still want to compile it before running it in the browser. I am not sure what it would take to do it but since you mention it will work in Chrome, then it would be neat to see it compile ahead of time. Just a thought.
  • oomu
    @michael

    the LGPL gives you the same concrete right than MIT to use the final product (cappucino) with your proprietary products.

    You just can't appropriate yourself cappucino, modifying it and release it again AS a proprietary product. (you can't do "cappucino++ the proprietary version so much better")

    but you can use it besides your commercial proprietary web applications with no problems. As you can use a LGPL cocoa frameworks inside a proprietary software without breaking the LGPL (or your own eula, because the LGPL authorize you to do that).

    and lgpl is lawyer knowledge

    webkit is lgpl, did it stopped nokia ? no. everything is fine, no need to worry. the licence is used and known as much than MIT or BSD.
  • Ask Solem
    Nice work!

    Why are you translating to _objj_msgSend() instead of directly to javascript? Wouldn't the js engines have a hard time optimizing the code for what it is? I understand why you would use msgSend in C, but js already has this.
  • boucher
    objj_msgSend gives us all of the benefits of a dynamic runtime. For example, it allows us to implement Ruby's method_missing feature. it also allows for cool Objective-C features like method swizzling (swapping the implementation of a method in a class dynamically at run time)
  • Very cool. Please could you consider releasing it under a different and less restrictive license (like MIT) as this can be a deal breaker for a lot of people (look at the palava surrounding ext's licenses).
  • Nice! Thank you for contributing to the improvement of the web.
  • Me
    OMG! This is SO cool!!!!
  • Johan Kool
    This looks very promising and extremely powerful. It is very nice to be able to use my knowledge of Cocoa now too for web applications. I am certain this will come in handy at some point for me. I look forward to further tutorials and sample code, though it looks quite straightforward so far.
  • Michael
    As I am just about to start building a web app and need to decide the approach to take, can anyone give me (or point me to) comparison information between Objective-J/Cappuccino and Sproutcore? One major difference is the license (LGPL vs. MIT), and the LGPL may actually be a deal-breaker for my super-paranoid company's lawyers, but what about from a functional perspective?
  • Jon-Erik
    I'm very excited about this, and have already begun playing around. I've been using both Cocoa and GNUStep for quite a while now, and I've been dreaming of being able to do this.

    Now, here's the thing... does this implement NIB files, and if so, can we build them in XCode? If not, is there going to be some kind of tool like Interface Builder to "draw" the applications so that we can focus on the logic?

    Even better--are there any plans to implement something like CoreData so that we can REALLY just focus on the logic?

    That's a fine how-do-you-do, I know, after delivering this wonderful product. I'm just thinking how easy it is to start writing useful programs using XCode... and how amazing it could be if the web could do that.
  • Awesome! I've been hanging out for this since WWDC.
  • @Luis:

    That's the basic idea (technically Cocoa, GNUstep, Cocotron and Cappuccino are implementations of OpenSTEP). Granted some things translate to the web better than others, so you have to keep that in mind.
  • Devon
    I heard on Macbreak Weekly you have some internal UI design tools. Is there any info on the release of those?
  • Luis Masanti
    As far as I understand, Objective-J and Capuccino will allow me to "program a web app as if I'm doing a GNUstep [a.k.a. Mac/iPhone] application"?
  • @Kevin Driedger: At some point we'll be posting a series of blog entries describing our rational behind the things we've done

    As far as the language goes, right now we're mostly sticking with the features Objective-C has. Objective-J is already fairly close to Objective-C 1.0, and has some of the features of 2.0 (like, uh, garbage collection, which we get for free from JavaScript, of course)

    We'd love to hear what other people would like to see, and of course we'd love to get improvements from you guys too.
  • @Rahul Dave:

    We have the option of doing the preprocessing ahead of time one the server, which is typically done for frameworks and deployed applications.

    We aren't compiling all the way down to some form of bytecode, but rather preprocessing at a higher level to turn Objective-J constructs into standard JavaScript constructs. For example, the message send operator [object message] gets turned into a JavaScript function call to objj_msgSend()
  • fintler
    This is really sweet guys. WYSIWYG editors for the web are gonna start looking like Interface Builder now. :)
  • The amount of love I feel for you right now cannot be expressed in words.

    Thank you for all your hard work. I'm excited to dive head-first into this stuff.
  • Adam Lett
    Awesome. And what great luck for you guys that Google just announced Chrome, which really seems like the browser Cappuccino was meant to run on. I wish you great luck

    - Adam
  • Thanks for all the hard work in getting this release together. I'd like to hear more of the story on how you decided on the syntax of Objective-J and what you're next thoughts are for extending the language. I hope you're plans are to keep it small and simple!
  • Is there any notion of speeding up by moving the objective-J interpretation cycle to the server and mixing downloading of media with bytecode interpretation on the client as is done by YARV on the server and HotRuby in the browser..
    http://hotruby.yukoba.jp/
blog comments powered by Disqus

Download

Cappuccino and Objective-J are licensed under the LGPL. For more information, see our licensing page.

Copyright © 2009 - 280 North, Inc. Cappuccino and Objective-J are registered Trademarks of 280 North. Logo by Sofa. Hosting by Slicehost.