Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming

Cocoa-Like JavaScript Framework Announced 188

Posted by Soulskill from the more-coffee-names dept.
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."
This discussion has been archived. No new comments can be posted.

Cocoa-Like JavaScript Framework Announced More

Cocoa-Like JavaScript Framework Announced

Comments Filter:

  • Podcast interview with the developers (Score:5, Informative)

    by bigbigbison ( 104532 ) on Sunday June 29, 2008 @12:14PM (#23991611) Homepage
    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 [twit.tv].

  • Feh (Score:2, Interesting)

    by rs79 ( 71822 )

    I've played with and written interpreted langaugesand for decades I've hels the fervent belief that the further away from C you go the worse the bloat.

    And "hello world" is how many bytes in this pig?

    • Re:Feh (Score:4, Interesting)

      by FooAtWFU ( 699187 ) on Sunday June 29, 2008 @12:36PM (#23991763) Homepage

      That's probably true, but sometimes optimizing for programmers' convenience is more important than reducing every ounce of bloat to the bare minimum. RAM is cheap enough and reusable; programmers' time isn't either.

      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.

      • Re:Feh (Score:5, Insightful)

        by rs79 ( 71822 ) <hostmaster@open-rsc.org> on Sunday June 29, 2008 @05:38PM (#23993997) Homepage

        " 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:Feh (Score:4, Insightful)

        by jlarocco ( 851450 ) on Sunday June 29, 2008 @06:25PM (#23994287) Homepage

        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.

        • Did you even try the demo? On my dual-core Opteron with 4 gigs of RAM it was *painfully* slow

          I wonder how much of that is client-side and how much server-side? As for the client-side issues: What browser were you using?

          I tried the demo on a pretty standard desktop machine -- my guess is that it was about as beefy as yours (probably less, in fact) -- in a university computing lab (I can post back later with exact specs if you'd like) running some 2.x version of firefox, and I thought it ran reasonably fast.

          That said, I do tend to agree with you. When we resort to running applications in a web brow

      • Re: (Score:3, Insightful)

        by bit01 ( 644603 )

        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 fan

      • "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."

        That leaves what exactly? Dinky web apps that are not used by many people, so performance doesn't matter? Internal apps?

        People care about performance not because *all* or even *most* applications need high performance but because the most *interesting* ones do. Also, complexity analysis is core to computer science.

        Now, you don't need to throw a

    • Re:Feh (Score:4, Informative)

      by Simon (S2) ( 600188 ) on Sunday June 29, 2008 @12:39PM (#23991775) Homepage

      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.

      • >but porting all kind of applications to the Web has some advantages that locally executed apps don't have.

        That is not what I was thinking while flying 35000 feet above the Atlantic ocean last night.

        I was however able to write some code and compile it with my locally executed copies of vim, gcc and cygwin.

        • Re:Feh (Score:4, Funny)

          by dnwq ( 910646 ) on Sunday June 29, 2008 @01:09PM (#23991977)
          Because everyone spends all their time flying 35000 feet above the Atlantic ;)

          Quick, beam me up. I want to live in your floating habitats too.

        • Re: (Score:3, Interesting)

          by iluvcapra ( 782887 )

          This framework is all in javascript and locally executed, however; with HTML5 local storage you should be able to run it as well as any server app once it's loaded.

          If you haven't tried the demo you should, it's really quite superb, just the initial load is rough now that it's been slashdotted.

          • So, in other words, I can download this app and run it locally? For free (and Free)? Wow! That really sounds just ... like ... openoffice?

            • Re: (Score:3, Funny)

              by TerranFury ( 726743 )

              So, in other words, I can download this app and run it locally? For free (and Free)? Wow! That really sounds just ... like ... openoffice?

              The funny thing is, OpenOffice takes about the same amount of time to load.

              (At first, the above sentence was intended as a joke; then I realized, sadly, that it was actually true -- at least before the site got Slashdotted.)

        • Re: (Score:3, Interesting)

          by jsebrech ( 525647 )

          If you have the google gears plugin installed, google docs works offline. Offline support is not an inherent advantage of native apps. The only truly insurmountable advantage native apps have over web apps is performance, but with today's vastly overpowered multi-core machines, performance has faded into the background, and it's going to become less relevant as the browser upgrades get rolled out (javascript 2, faster layout engines, hardware-accelerated graphics api's, ...).

          • What about privacy/security concerns?

            • What about them? Local is local. Google gears has a security model whereby only the app that put the data locally can access that data again. There's no practical difference with local native apps security- or privacy-wise.

      • Re:Feh (Score:4, Insightful)

        by mattkime ( 8466 ) on Sunday June 29, 2008 @01:46PM (#23992325)

        >>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: (Score:3, Informative)

        by dave420 ( 699308 )
        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.

      • Re:Feh (Score:4, Insightful)

        by Archibald Buttle ( 536586 ) <steve_sims7@yaho[ ]o.uk ['o.c' in gap]> on Sunday June 29, 2008 @02:07PM (#23992513)

        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.

        • 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 rich GUI apps are IMHO quicker to write, more responsive, have more features, are better maintainable with a GUI toolkit like for example SWING, GTK, QT, Winforms or wx instead of HTML + Javascript. I have nothing against Javascript, but I really would not like to work with a Javascript CAD application. Or Maya. Or a programming IDE. For now. Maybe in a few years things will be different, but as things are today Javascript apps just feel very sluggish and "incomplete" to their non-javascript antagon

      • What, exactly, will JS2 (I assume you mean EcmaScript 4 by that) bring to the table that's lacking now to handle this type of applications? It is perfectly possible to write neat object-oriented code in JS, and common techniques and conventions of doing so have been agreed on for ages.

  • Caffeine Theme (Score:5, Funny)

    by FurtiveGlancer ( 1274746 ) <.moc.loa. .ta. .yuGhceTcoHdA.> on Sunday June 29, 2008 @12:15PM (#23991629) Journal
    To extend the meme, now I'll start development of C-Objective Kernel Editor (COKE). that will be followed by Linux Apache Tkl/Tcl Extensions (LATTE) which, of course, demands Folding On AMD Machines (FOAM). Sorry, but I'm too tired to come up with an acronym for marshmallows. ~

  • Damn ... (Score:5, Funny)

    by ScrewMaster ( 602015 ) on Sunday June 29, 2008 @12:16PM (#23991635)
    Slashdotted already. Don't you people have better things to do?

  • Anyone even remotely interested should read the article. There is some interesting discussion below it in the comments section between commenters and the developers.

  • i took a look at SproutCore since i'm familiar with some Cocoa ideas, like data-interface binding, which would be great in javascript. i was disappointed to find out that SproutCore projects are created with RUBY and that you touch javascript very little, if at all.

    just how important is ruby to sproutcore? go to their download link and they tell you to "sudo gem install sproutcore"

    very disappointing for a javascript programmer. i suspect this will be the same.

    javascript is the turkey lunch meat of programmi

    • Re:SproutCore - it relies on ruby (Score:5, Informative)

      by rboucher ( 1316519 ) on Sunday June 29, 2008 @01:03PM (#23991935)
      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.

      • Re: (Score:3, Interesting)

        by aesiamun ( 862627 )

        Where can I download it?

        I keep hearing how phenomenal this is, but I can't find it and objective-j.org says 'coming soon'.

        Come, don't push a website if it doesn't exist.

    • Re: (Score:3, Informative)

      by jsebrech ( 525647 )

      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.

  • Taking bets (Score:5, Insightful)

    by moosesocks ( 264553 ) on Sunday June 29, 2008 @12:37PM (#23991765) Homepage

    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)

    by ehack ( 115197 ) on Sunday June 29, 2008 @12:48PM (#23991851) Journal

    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.

  • I've Got It! (Score:3, Funny)

    by FurtiveGlancer ( 1274746 ) <.moc.loa. .ta. .yuGhceTcoHdA.> on Sunday June 29, 2008 @12:55PM (#23991893) Journal
    Since it's Cocoa-like, we have to rename it Carob [living-foods.com]. Quick, somebody get their acronym generator going!

    Too slow! Already taken. [continuent.org]

  • 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...

    • OpenLaszlo is what inspired me to start integrating XUL into the PHPulse framework. People shouldn't have to learn whole new ways of doing things when these methods already fit old paradigms like MVC. You just have to integrate them in such a way as to take into cosideration multiple document types upon delivery and request.

      That way regardlesss of whether a user on your system logs in to your web page or in to your application via an SSB from their desktop, you still control all their priveleges the same
      • php ahhhhh! /jk, but OpenLaszlo has inspired me to do many things, including, well, use openlaszlo everywhere, the Original RIA King. I think OL is much more advanced the XUL, if only because it has everything in one place and doesn't have completely separate parts for the interface, logic, etc. Some may disagree, but i think that gives OL less of a learning curve and supports code sharing between people.
        • I agree. OL really is a good tool. It integrated XUL well and inspired me to try to do the same. You really should be able to reuse as much as possible and think of the javascript and XUL as merely a separate view that is separated out by the doctype. It is a very well implemented integration of XUL.

          And I take no offense to the PHP jk. The PHP community brings it on itself. Too many bad developers out there in PHP who have no formal training. Plus the language does nothing to enforce good development styl
          • As for PHP: I like that it allows me to quickly throw something together. The language lends itself very well to quick and (more or less) dirty scripts that would be more complicated to to implement in a stricter language. I often use it as a shell scripting language when I need to get something done right now with no regards to the solution being pretty. Regarding types in PHP... I'd prefer PHP to support explicit types but use type inference by default. That way it would retain its ease of use but also a

            • the PHP devs are about as enthusiastic about cleaning up their language as Microsoft is about open-sourcing NTFS.

              Sad but true. I've actually been considering converting to Java. The only reason I keep developing the framework in PHP is because I can help people develop in MVC better and now with XUL, I can give them an all-in-one framework for development and integration.

  • Wow!! Just damned Wow!! (Score:4, Funny)

    by Wizard Drongo ( 712526 ) <wizard_drongo@@@yahoo...co...uk> on Sunday June 29, 2008 @01:43PM (#23992295)

    Just WOW!!

    As someone who is just learning Cocoa, and finding it though since it's my first real programming language, I am amazed at what 3 guys in a college dorm have cooked up.
    Apple need to drop that spruotCore thing like a rock and make happy with these guys. I read that they worked for Apple before spinning this out...
    Perhaps if they get offered much better paid positions with Apple they might come back. This is some seriously cool shit they're doing. That web-app required no knowledge at all of HTML & CSS!!
    You could even probably write code for OS X and "port" it to the web in minutes!! If Apple get in on this, they could seriously bring about a shift from Flash and horrible media plugins like that silverlight crap, to something everyone can use, even iPhones and Blackberry's.
    Words fail to describe how awesome that demo app is.
    I was dreading getting to the point of having to learn me some java so I can do web-apps eventually. They've actually managed to make me interested!! Programming is hard and I'm finding it tough, but now I really want to master Cocoa and start on Objective-J and Cappuccino.
    WAY TO GO!!!!!

  • should be interesting in combo with XULRunner (Score:3, Interesting)

    by radarsat1 ( 786772 ) on Sunday June 29, 2008 @02:24PM (#23992627) Homepage

    I've been playing with XULRunner quite a bit lately and though I haven't yet applied it to a "real" application, I have to say it's pretty nice and convenient to be able to design a cross-platform GUI for a local application using HTML and CSS. The trouble of course is that your application looks like a web page. (This is getting less important now that it supports native widgets of course.)

    If this is open-sourced in a license-compatible manner with XULRunner, it might make for some very interesting, user-friendly (i.e., pretty), and completely cross-platform local applications.

  • Reinventing XUL... BADLY (Score:3, Insightful)

    by Foofoobar ( 318279 ) on Sunday June 29, 2008 @02:28PM (#23992651)
    Works in Safari. Breaks in places in Firefox. Can't even load in Konquerer. Again, I'll use XUL which seems to be being used by Amazon, IBM and alot of others large name companies and is alot further along than reinvent the wheel with a bloated lubrary.

    • Re: (Score:2)

      by argent ( 18001 )

      XUL extensions can modify parts of the user interface outside the displayed window or website, access local files, even run local unsandboxed code.

      This is implemented entirely in Javascript, so runs inside the sandbox.

      • Right but that means that you have to load far more than you would have to in XUL and it doesn't look like the platform it's on (like SWING apps). Like I said... bloated, OS specific. And with XUL... it doesn't require an understanding of Ruby; you can develop in in Java, C, C++, PHP, Perl, .NET, and Ruby or all in Javascript too if you want.

        • Re: (Score:2)

          by argent ( 18001 )

          My point is that it's solving a different problem than XUL, so it's not "reinventing XUL". For the things Objective-J is designed to do, you couldn't use XUL, and for the things XUL is designed to do, you couldn't use Objective-J. There's no point of contact, other than the fact that they're both using ECMAscript. You might as well compare Konfabulator and Flash, and complain that Flash isn't standalone and doesn't let you save local state, or that you can't embed Konfabulator widgets in a web page.

          • True in a slight sense but one overlaps and duplicates. Objective-J trys to be the model-view-AND-controller which is a horrible idea as anyone would tell you; unless everything is HOUSED on the client and no one but that ONE CLIENT is accessing the app, a javascript MVC app cannot be properly secured.

            However... in XUL, you just build the VIEW in XUL and then have the OPTION to build the model and controller however you wish. For instance, in PHPulse, it has integrated XUL support so your existing PHP mod

    • Re:Reinventing XUL... BADLY (Score:4, Interesting)

      by rboucher ( 1316519 ) on Sunday June 29, 2008 @05:55PM (#23994089)
      Where exactly does it "Breaks in places in Firefox?" Let us know and we'll get right on it.

  • Impressive, but broken (Score:3, Interesting)

    by Haeleth ( 414428 ) on Sunday June 29, 2008 @03:26PM (#23993101) Journal

    I had a quick go with 280Slides. The interface was impressively slick.

    Then I tried to enter some non-English text, and it totally freaked out on me. When I pressed the keyboard combination to switch input methods, 280slides inserted three capital 'A's with acute accents. When I tried to type a simple Japanese phrase, 280slides inserted a single lower-case 'a' with a little circle over it.

    This is the 21st century. We live in an increasingly globalised world. Applications that can't handle Unicode and multiple input methods have no place in this day and age. Back to the drawing board, guys, and don't come back till your nice slick interface has some basic i18n features, please.

    • Re: (Score:3, Informative)

      by moosesocks ( 264553 )

      It's a proof of concept. Give them some slack!

    • Re:Impressive, but broken (Score:4, Informative)

      by rboucher ( 1316519 ) on Sunday June 29, 2008 @03:45PM (#23993229)
      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.

      • Re:Impressive, but broken (Score:5, Interesting)

        by Cato ( 8296 ) on Monday June 30, 2008 @12:44AM (#23996951)

        Why would the browser need to tell you about a non-English input method? In my experience of I18N of web apps, this is completely unnecessary, since the input method is invisible to the application (rather like switching keyboard layouts) - all that's needed is for the web app to support Unicode etc. Since JavaScript uses Unicode natively, I can't quite see how 280 North has managed to break Unicode support like this.

  • 1. How can you not be generating CSS or HTML if the interface requires it?

    we're never actually generating HTML or CSS

    I am assuming that they mean they only generate Javascript, that then generates the HTML and CSS as necessary, but that is not to say you're not dealing with HTML or CSS entirely. It would be great if they abstract those elements away completely, but as is so often the case, when something isn't right and you have to fix it, one must resort to jumping over those barriers and hacking their way to where they can accomplish what is need.

Slashdot Top Deals

Whoever dies with the most toys wins.

Close