Slashdot Mirror
Cocoa-Like JavaScript Framework Announced
TwilightSentry writes "Ars Technica reports that a group of developers has created an Objective-C-like extension to JavaScript along with a class library mirroring Cocoa. They've used these to release an impressive demo app called 280 Slides. The article notes, 'Whereas SproutCore seeks to "embrace the platform" by giving a Cocoa-like development model for developers already using HTML, CSS, and JavaScript to make a web app, Cappuccino and Objective-J take an entirely different approach. "Since Cappuccino runs entirely on the client, at run time, we're never actually generating HTML or CSS," says Boucher. "When you build an application in Cappuccino, you don't need to ever deal with HTML or CSS. All of your interface is designed in Objective-J and Cappuccino. Cappuccino focuses on application architecture more than anything else, like building applications that know how to save and open documents, or copy and paste. We also built a powerful graphics engine into Cappuccino, so you can make rich applications like 280 Slides."' The developers plan to release the framework and preprocessor as open source. No mention is made of a specific license."
A couple of weeks ago one of the developers of 280 slides was interviewed by Leo Laporte and Amber MacArthur on their net@night podcast.
http://www.popularculturegaming.com -- my blog about the culture of videogame players
I agree with you: Javascript is not technically the best solution to write such an application (for now, let's see when JS2 comes out and will be implemented by all major browsers).
It would be much better written with a non-HTML GUI toolkit, but porting all kind of applications to the Web has some advantages that locally executed apps don't have. Thus we have to see if the benefits outweight the downcomes, and for some the "bloat" is acceptable if the application is online, does not need to be installed and so on.
One of the other, not so obvious benefits (imho) of having all kinds of apps online in javascript is that those applications usually are cross-platform, pushing the OS every day a bit more in the background, and forcing windows on less and less people (if you remember the Netscape days, that was exactly the reason Microsoft tried (and succeeded) to crush them - or at least that was what the press was saying at the time). I think most people that run windows still have to run it because of some arcane app that only runs on that platform, and locking that user right in. If this becomes a trend, more and more applications will become cross-platform and less and less users will be forced to use one specific platform. And if that day comes, maybe javascript v3 will become better suited for rich GUI Apps.
I just don't trust anything that bleeds for five days and doesn't die.
Well, the nice thing about Objective-J is that it's a strict superset of JavaScript. At any time you can simply write pure JavaScript and it will run just fine. You don't even technically need to use Objective-J to use Cappuccino (our framework), but it makes it MUCH easier. As far as using Ruby or anything else, everything we do in the application is pure client side. The only interaction with the server is via XMLHTTPRequests. We'll be able to distribute Cappuccino/Objective-J as a simple download.
There may be some initial delays when you open up new UI elements (since we delay loading to improve initial performance). Our images are taking longer than usual to load. If you use the app for more than a few minutes (i.e. after you've initially loaded most of the UI), does the issue persist? It shouldn't. The best explanation I could offer is that Firefox 2 on Linux does have some performance issues of its own. FF3 would probably help a lot. That being said, I use it on my macbook pro with FF2 all the time without issue.
Unfortunately browsers don't provide much (or really any) information about many non-english input methods. On the plus side, copy/paste does work with any unicode character (if it's any consolation). This is definitely a problem, and a shortfall of one of our earlier design decisions. We're working on revamping our text system to resolve this, and other issues.