Cocoa-Like JavaScript Framework Announced 188
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."
Taking bets (Score:5, Insightful)
Who wants to bet how long it will be before Google buys up the guys who made that presentation app?
It could certainly be a bit faster, but it's still damn impressive.
Frighteningly good demo (Score:3, Insightful)
This is a seriously good piece of software.
If they can do the same for Word and Excel then MS is going to be out of business.
Will web apps eventually dominate software? (Score:3, Insightful)
Traditional web apps are slow, because of all the chatting with a server. But well made AJAX, and frameworks like this one and OpenLazlo, http://www.openlaszlo.org/ [openlaszlo.org] are changing that.
Makes me wonder... Maybe soon(ish) a lot of apps which are now strictly in the desktop domain will really be viable through a browserlike environment?
I've been quite skeptical myself, but every time I see something like this it makes me wonder if I'm just not seeing the true possibilities...
Re:Feh (Score:4, Insightful)
>>I agree with you: Javascript is not technically the best solution to write such an application
And how exactly does JavaScript fall short?
A lot of programmers look down on it because of its poor start but in its current state its a perfectly capable programming language, even without superfluous v2 features. The biggest problem with web apps is supporting IE 6.
Re:Stolen graphics? (Score:3, Insightful)
After I closed keynote, not thinking, I hit command-n to get one more look and 280 Slides opened it's new presentation theme picker- and for a sec I thought it was keynote.
In the end I say yay for competition!
Re:That wacky javascript (Score:3, Insightful)
Re:Feh (Score:4, Insightful)
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).
Why?
Because JavaScript doesn't (yet) support classes?
If that is the answer, then with all due respect I thoroughly disagree. JavaScript is an OO language, it just uses differential (or prototype-based) inheritance, rather than class-based inheritance. It's quite possible to write fully featured GUI apps using a language that adopts a differential inheritance model. I did that for many years on the Newton, using NewtonScript.
The Newton OS APIs (object prototypes) that went with NewtonScript worked just fine, and provided a GUI that was in a number of ways more advanced than Cocoa. Gave very decent performance on an extremely limited platform.
Personally I have yet to be convinced of the wisdom of including classes in JavaScript2 - it feels unnecessary to me.
Impressions (Score:1, Insightful)
As a C/C++/Java developer who is learning Cocoa and Objective C now out of necessity, I remain unimpressed. I'm a fairly quick hacker who taught myself everything from Pascal to Assembly to C and C++. I still think it was foolish for Apple to implement a key technology in a language that is largely unknown by most C/C++ developers. And I've yet to see the advantage...in fact, I'd say that there are enough disadvantages in retraining developers that more than offset any advantages the language could possibly have. Having working in C and C++ for 20 years, I find Objective C code very difficult to read and impossible to understand with just a glance like C/C++. The method call mechanism is far too compact to easily separate the parameters and labels in method calls seem to be a great way to further confuse things.
I'm not one to evangelize Microsoft products, but MFC was far easier for me to pick up and start working with than Objective C + Cocoa. I'll give Apple credit for being gutsy and going outside the sure-bet languages, but it honestly seems like a huge mistake for adoption. I think someone in Apple is very proud of their choices, and don't realize how much it has hurt the platform in terms of adoption.
So I'm simply amazed that anyone would bother creating a javascript alternative that reflects all the difficulties associated with moving to the Apple development world.
Reinventing XUL... BADLY (Score:3, Insightful)
Re:Impressions (Score:1, Insightful)
Re:We always find fault on /. (Score:1, Insightful)
Your right.. we do.. slow as hell to the point of not being functional pretty much sums up my experience with the demo.
You have CSS, HTML, JS/DOM...how much more abstraction do you really need to build an interface for a largly client-server application? When used by someone with half a clue these systems properly combined in a three-tier model are more powerful than any abstraction library currently avaliable.
If the client-server pardigram does not apply to your application (IE its largly client based like a word processor or graphics manipulation tool) and you prefer the standard GUI event models write a java applet -- thats what its there for.
Re:Feh (Score:5, Insightful)
" If you're not trying to write a high-performance scalable computing cluster app, or an operating system, or a fancy computer game, then bloat really isn't an issue."
Spend 20(+) years fixing other peoples code then get back to me on that one.
Re:Javascript and HTML/CSS (Score:2, Insightful)
CSS, even if you have compliance to recent specs (which we don't) fundamentally lacks the kind of layout options that you need to create truly slick interfaces.
Browser DOM support differs substantially across the major browsers - so much that you would be insane to build a complex app without some kind of framework or library to abstract away the differences.
Now - I do agree that using HTML and CSS can be a good foundation for delivering apps - but eschewing the use of frameworks to help do it is insanity.
Re:Feh (Score:4, Insightful)
Did you even try the demo? On my dual-core Opteron with 4 gigs of RAM it was *painfully* slow. I can run Windows in Qemu, then run Office inside of that, and it would seem really fast compared to their demo. A little bloat here and there isn't an issue. When an app is so bloated and slow that it's unusable for anything practical, it's a real problem.
If I wanted to feel like I was building a presentation on an ancient 286, I would just dig one out of my closet
Also, until you're volunteering to buy the RAM for me, you can kindly shut the fuck up about how cheap it is. Thanks.
Re:Feh (Score:3, Insightful)
That's probably true, but sometimes optimizing for programmers' convenience is more important than reducing every ounce of bloat to the bare minimum.
For prototypes yes. For most other things no. Depends on what you mean by a bare minimum though.
RAM is cheap enough and reusable; programmers' time isn't either.
Neither is the user's time. And there are usually a lot more users than programmers.
If you're not trying to write a high-performance scalable computing cluster app, or an operating system, or a fancy computer game, then bloat really isn't an issue.
or a database or a real time system or a desktop app or ...
RAM use has a very high inverse correlation with speed/responsiveness. A working set using even one byte more than the first level cache is enough to slow a program down by 5 or more times. And that's not even counting the other levels of cache.
For me "280 Slides" is way too slow to be useful on this core 2 duo laptop with GB's of memory.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
Re:Feh (Score:4, Insightful)
What browser I'm using shouldn't be relevant.
Well, it does. The "300% increase in javascript speed" browsers like to advertise with new versions actually means something. It's akin to a site using SVG or CSS3--except it does work with every browser, it's just slow.
Re:Feh (Score:3, Insightful)
Re:Impressions (Score:3, Insightful)
I completely disagree with you on how readable ObjC is. I find that embedding the parameters directly within the method names to be extremely concise when trying to figure out what the call will do. Putting the parameter DIRECTLY next to the relevant descriptive text in the method name makes sense.
[containerTarget putElement: anElement intoStorageNamed: storageName];
is much clearer to me in an overview than something like:
containerTarget->putElementIntoStorageNamed( anElement, storageName );
In my mind, the call convention of ObjC forces you to write good method names and disambiguates the order of the parameters explicitly. It just reads like a sentence, which is wonderful.