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
And where are my mod points when I need them!
+1 Funny (Unofficial). FurtiveGlancer FTW.
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
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.
I believe the Laverne and Shirley combination of Pepsi and milk would be as close as I've seen.
You'll never know until you try one. Good luck ordering one at Starbucks, Caribou, etc.
Invenio via vel creo
True. But, we're optimizing for real world use, not Slashdot :).
One thing we're looking into doing is starting to load things in the background once the app is already in use. We can put some of these loads on timers, so as to not affect normal use, but make the initial loads of the UI elements snappier.
We work okay with Opera. Especially the latest 9.5 release. There are a few minor issues though, especially with regard to text scaling.
Surely using Flex would make more sense than JavaScript. It has all the benefits you mentioned, plus it performs a hell of a lot faster, and is far more cross-platform, as JavaScript implementations are still far from standardised across all platforms and browsers.
i was disappointed to find out that SproutCore projects are created with RUBY and that you touch javascript very little, if at all.
You don't need ruby when deploying, and the code you write is javascript. Sproutcore uses ruby to make life more convenient while developing, but it is a pure-javascript framework.
Just to clarify, Sproutcore is something completely different. Cappuccino and Objective-J have no relationship with Sproutcore or Apple.
It's a proof of concept. Give them some slack!
-- If you try to fail and succeed, which have you done? - Uli's moose
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.
I assume you're one of the authors? Just thought I'd add a comment that the performance must be fairly variable between OS/browsers at the current stage. I have absolutely no complaints under Safari and Webkit nightlies (which stands to reason I suppose)--seems fast.
Win2k3 IE7 took substantially longer to load initially, but then seemed fairly fast (not quite as fast as safari it seems)
Win2k3 FF2 was in between IE7 and Safari.
Really awesome app--I'm inspired to finally pick up some more Cocoa!
It's not new (it predates Java), and it wasn't implemented by Apple. It is technology that Apple inherited when they bought NeXT Computer, and it is arguably one of the most important factors in the resurgence of the Mac platform.
You're just not familiar with Smalltalk syntax yet. I went through the same process; it's a seemingly big deal that melts away pretty quickly. You'll come to appreciate the syntax once you start passing around method selectors like textView:willDisplayToolTip:forCharacterAtIndex:. Of course, you don't pass around method selectors in C++ and Java, but it's absolutely key to way things are done in Cocoa. The big stumbling block, especially for C++ developers, is to understand Cocoa design and how to take advantage of Cocoa's and Objective-C's unique features. You have to unlearn C++, and if you happen to like (or think you like) C++ then that can be a frustrating but ultimately rewarding and enlightening process. And then you'll understand why someone would create "Objective-J" for Javascript.
It was Mac developers who ultimately decided to adopt Cocoa. Back in 2000 one of the open questions with OS X was whether developers would adopt Cocoa and Objective-C. Apple offered their C-based Mac APIs for existing Mac developers, they offered Cocoa bindings for Java developers, and they offered plain old Cocoa. Despite its learning curve, Cocoa eventually won over the existing Mac developers. Most importantly, Mac users have come to demand Cocoa applications and are generally hostile towards most Carbon apps (as well as Qt and Java Swing apps, of course).
I can't help but think of .NET in same context, a development platform I generally like. Will Windows users ever demand .NET applications in the way Mac users demand Cocoa applications? (Windows users will never demand WinForms apps, but if Windows developers embrace WPF, another unique approach to GUI development with a significant learning curve, then I think the answer will be yes).
ENDUT! HOCH HECH!