Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cocoa-Like JavaScript Framework Announced

Soulskill posted more than 6 years ago | from the more-coffee-names dept.

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

cancel ×

188 comments

Sorry! There are no comments related to the filter you selected.

Podcast interview with the developers (5, Informative)

bigbigbison (104532) | more than 6 years ago | (#23991611)

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

We always find fault on /. (2, Interesting)

kestasjk (933987) | more than 6 years ago | (#23992331)

But may I say wow, that is a very impressive web-app. It really does feel like an office application and not a web-app.

Re:We always find fault on /. (1)

thetartanavenger (1052920) | more than 6 years ago | (#23992795)

I don't know about you but the speed sure feels like a web app...

That wacky javascript (1)

symbolset (646467) | more than 6 years ago | (#23991617)

Is there anything it can't do? Hey! Somebody gen me up an Ada interpreter in Javascript real quick.

Re:That wacky javascript (2, Insightful)

dave420 (699308) | more than 6 years ago | (#23992363)

Unfortunately there's a lot JavaScript can't do. The main one is "be consistently quick across platforms", something Flash has managed to achieve with its offerings. I'm not saying JavaScript is terrible - it's not - it has many uses, and I use it all the time on my sites. The only problem is it's simply not implemented to do this stuff. The 280slides website, for me at least, was painfully slow. Shoe-horning a UI somewheres it doesn't belong is not necessarily a great thing, and definitely not a great thing when it runs like a 1-legged dog uphill.

Re:That wacky javascript (1)

rboucher (1316519) | more than 6 years ago | (#23992491)

I don't think this is really true. Flash hasn't managed to work on all platforms (like the iPhone), and its certainly not particularly fast on the mac.

Re:That wacky javascript (1)

dave420 (699308) | more than 6 years ago | (#23992917)

Flash is fast on the Mac. As for the iPhone - well, it's a niche phone - of course its flash support is not going to be up to scratch. Especially with Herr Jobs not wanting it :)

Re:That wacky javascript (1)

hvm2hvm (1208954) | more than 6 years ago | (#23992595)

Well yeah, JavaScript was not designed for these things but it is more widespread than java or flash. That's why it's cool that they did this using just javascript. BTW, the program worked pretty good for me except the fact that there is no right click :P. Anyway my point is that for every task you have to do some compromises and choose a balance between the properties that are opposed. In this case you can have a very portable program but it probably won't be quick. If you want to make it quick you have to get to more low level programming which leads to java (faster but less widespread), flash (which also has the downside of sucking) and ultimately to platform specific. Do you have any suggestion that would actually combine the best of those 2 worlds? I cannot see any way of accomplishing that in a simple, elegant matter.

Re:That wacky javascript (2, Interesting)

dave420 (699308) | more than 6 years ago | (#23992933)

Flash isn't as bad as you make it out to be. ActionScript 3 (now fully ECMA-compliant) is phenomenally fast, and highly portable. It works great on Linux, Windows, OS X, and when Flash Lite gets updated to AS3 (it's AS2 at the moment), you'll have your phones covered, too. JavaScript is very useful, but this is not a great use for it. Flash (or, rather, Flex), to me at least, seems like the elegant method. Support, speed, simplicity.

Re:That wacky javascript (1)

Peterix (1060774) | more than 6 years ago | (#23992871)

I concur. Flash is completely unusable on Linux. If this app was made in Flash, I wouldn't be able to run it at all.
It's quite good on a 7 year old PC. I bet I wouldn't see any difference between a desktop app and this thing on recent hardware.

Re:That wacky javascript (1)

dave420 (699308) | more than 6 years ago | (#23992947)

When you say "Flash", what do you mean? AS3 or AS2? Flex or not?

Re:That wacky javascript (1)

Peterix (1060774) | more than 6 years ago | (#23993149)

The normal Flash stuff that can be found on any normal website.
The Linux version of Flash is slow - much slower than the windows version. I can't run more than one flash applet on a webpage without massive lagging and 100% CPU use. Maybe it's good with a different graphics card... and maybe not.

Feh (2, Interesting)

rs79 (71822) | more than 6 years ago | (#23991627)

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 (3, Interesting)

FooAtWFU (699187) | more than 6 years ago | (#23991763)

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

Simon (S2) (600188) | more than 6 years ago | (#23991775)

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.

Re:Feh (1)

TechyImmigrant (175943) | more than 6 years ago | (#23991875)

>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 (3, Funny)

dnwq (910646) | more than 6 years ago | (#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:Feh (2, Interesting)

iluvcapra (782887) | more than 6 years ago | (#23992219)

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.

Re:Feh (1)

The_Wilschon (782534) | more than 6 years ago | (#23992707)

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:Feh (2, Interesting)

jsebrech (525647) | more than 6 years ago | (#23992357)

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, ...).

Re:Feh (1)

rboucher (1316519) | more than 6 years ago | (#23991903)

I agree that Javascript isn't the best solution to write an entire application. That's one of the reasons we build Objective-J. JavaScript 2 is not around, and likely won't be around at all until next year. Even then, it will only be in Firefox. IE isn't going to see JavaScript 2 for a long time. More importantly, though, Cappuccino (the framework) is what's really needed to build great applications. Like you said, it IS a non-HTML GUI toolkit. We're abstracting away all the limitations of the browser.

Re:Feh (3, Insightful)

mattkime (8466) | more than 6 years ago | (#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:Feh (0)

Anonymous Coward | more than 6 years ago | (#23992501)

Do you think that javascript + HTML is a very good combination to write rich GUI applications? Bettern than, say, QT + C++, or GTK + C, or Java + Swing?

Re:Feh (1)

mattkime (8466) | more than 6 years ago | (#23992755)

its great for a large number of applications but it certainly isn't like anything else.

Re:Feh (2, Informative)

dave420 (699308) | more than 6 years ago | (#23992435)

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 (1)

rboucher (1316519) | more than 6 years ago | (#23992485)

Flash and Flex require a (proprietary) plugin, don't work on all platforms (like the iPhone), and are incredibly slow and resource heavy on Macs. Not to mention, being constantly asked to upgrade to the latest version to use some new site is kind of a pain. In my experience, JavaScript is a much faster approach than Flash. Then again, I'll admit to my own bias.

Re:Feh (1)

dave420 (699308) | more than 6 years ago | (#23992989)

Your bias is noted :) The iPhone is a niche market within a niche market. Using that as a yard-stick for adoption is, well, completely retarded. Heck - it doesn't support copy and paste, so I guess those are newfangled techniques never destined to be commonplace. Flash performance on Macs, especially when using AS3 or Flex, is perfectly reasonable. Plus, as it contains all the rendering, you get consistent results across platforms. The only difference between AS3 on Macs and PCs, that I've come across when developing, is Macs can't test a file upload to a server. That's it. When you compare that to the difference between JavaScript implementations across browsers and platforms, you'll see the difference. And, btw, I don't get pestered to update my Flash. Only if a new major version comes out is that a problem. Oh, and one more thing - Flash natively supports a few video and audio codecs. Does JavaScript?

Re:Feh (1)

rboucher (1316519) | more than 6 years ago | (#23993069)

JavaScript doesn't support video at all. That's why 280 Slides uses Flash for videos. Flash definitely has its place in the web world, I just happen to disagree on exactly what that place is :)

Re:Feh (1)

dave420 (699308) | more than 6 years ago | (#23993097)

So where is the benefit of this approach if it still has to use third-party software, which might or might not be the right version, etc., to achieve something that Flash can achieve on its own. I don't know why you're so unhappy with flash - it's one of the fastest methods to implement rich web applications, much faster than JavaScript, and with muuuch more functionality built-in. I'm all ears :)

Re:Feh (3, Insightful)

Archibald Buttle (536586) | more than 6 years ago | (#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.

Re:Feh (1)

shutdown -p now (807394) | more than 6 years ago | (#23993085)

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.

Re:Feh (0)

Anonymous Coward | more than 6 years ago | (#23991843)

Ok, so maybe that really was flamebait, but I tried their impressive app, and it took 30 seconds to load and was then slow as hell. Even moving the little dialog windows around was painfully slow. I can't imagine actually using something like this. And blaming it on interpreted languages it BS. They do not need to be that slow!

Re:Feh (1)

rboucher (1316519) | more than 6 years ago | (#23991879)

Our load times definitely took a hit when we got posted to slashdot (maybe taking about three times as long as usual), but performance of the app shouldn't be slow at all (since the entire app is executing locally). Mind sharing some information about your browser/machine?

Re:Feh (1)

XanC (644172) | more than 6 years ago | (#23991931)

I'm using Firefox 2 on Gentoo, Athlon 64 3000+, 1.5GB RAM. Every click, I'm waiting for seconds, watching it draw and fill every graphical element. It's really unusable.

Re:Feh (5, Informative)

rboucher (1316519) | more than 6 years ago | (#23991969)

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.

Re:Feh (1)

XanC (644172) | more than 6 years ago | (#23992025)

Yeah, if I go back into the same thing, it's pretty good. Looks like it's mostly initial loading. Which, unfortunately, is the worst-case scenario for people wanting to poke around the thing off a Slashdot link.

Re:Feh (2, Informative)

rboucher (1316519) | more than 6 years ago | (#23992061)

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.

Re:Feh (0)

Anonymous Coward | more than 6 years ago | (#23992001)

P4, 2Ghz, 2GB of ram, Linux, and Firefox 3 with a clean profile. Maybe I am not being fair because I expect interaction on par with a "native" application. But playing around with the shapes was really just terribly slow. It wasn't because of the network either.

Caffeine Theme (5, Funny)

FurtiveGlancer (1274746) | more than 6 years ago | (#23991629)

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

Re:Caffeine Theme (1, Informative)

jeiler (1106393) | more than 6 years ago | (#23991649)

And where are my mod points when I need them!

+1 Funny (Unofficial). FurtiveGlancer FTW.

Re:Caffeine Theme (3, Funny)

FurtiveGlancer (1274746) | more than 6 years ago | (#23991943)

In this case, I'll assume you meant "Found The Words." Thanks.

Re:Caffeine Theme (1)

ScrewMaster (602015) | more than 6 years ago | (#23991651)

Is there such a thing as a Foaming Coke Latte? Doesn't sound like it would ever be popular.

Re:Caffeine Theme (2, Informative)

FurtiveGlancer (1274746) | more than 6 years ago | (#23991975)

I believe the Laverne and Shirley [wikipedia.org] 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.

Re:Caffeine Theme (1, Offtopic)

larry bagina (561269) | more than 6 years ago | (#23992965)

After taking a liking to egg creams, I tried mixing coke + a dash of milk a few times. Not horrible, but kind of pointless.

Mocha Theme (4, Funny)

Anonymous Coward | more than 6 years ago | (#23992133)

You are missing the acronym that best describes a combination of Cocoa and Java(Script):

CAFE MOCHA - Cocoa-Alike Framework Extension Mirroring Objective C for HTML Applications

Re:Caffeine Theme (1)

jcr (53032) | more than 6 years ago | (#23992597)

As it happens, we did have Objective-C in the kernel on NeXTSTEP. The old DriverKit was an Objective-C framework.

-jcr

Re:Caffeine Theme (0)

Anonymous Coward | more than 6 years ago | (#23993317)

Maybe a real slashdot hacker might easil

You're right this is so not worth the effort, fuck it

Damn ... (5, Funny)

ScrewMaster (602015) | more than 6 years ago | (#23991635)

Slashdotted already. Don't you people have better things to do?

Re:Damn ... (3, Funny)

FurtiveGlancer (1274746) | more than 6 years ago | (#23991897)

Don't you people have better things to do?

*holds up mirror*

Re:Damn ... (0)

Anonymous Coward | more than 6 years ago | (#23991957)

Oh, so not only do you slashdot the site we want to visit, but then you remind us how ugly we are? No wonder why so many /.ers can't get a second date.

Re:Damn ... (1)

cheesy9999 (750203) | more than 6 years ago | (#23991981)

1MB+ of code and images + Slashdot = not happy. But once the app is loaded, it runs quite fast since it only talks to the server when it absolutely needs to. Load the app directly here: http://280slides.com/Editor [280slides.com]

RTFA (1)

dreamchaser (49529) | more than 6 years ago | (#23991637)

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

SproutCore - it relies on ruby (1)

mattkime (8466) | more than 6 years ago | (#23991735)

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 programming languages, imitating all the others. and, like turkey, its best when its simply itself.

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

rboucher (1316519) | more than 6 years ago | (#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:SproutCore - it relies on ruby (3, Interesting)

aesiamun (862627) | more than 6 years ago | (#23993381)

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:SproutCore - it relies on ruby (0)

Anonymous Coward | more than 6 years ago | (#23992151)

If you want to, you can generate your entire application with javascript as needed. The ruby is for templating so most content can be generated once at compile time.

Re:SproutCore - it relies on ruby (2, Informative)

jsebrech (525647) | more than 6 years ago | (#23992517)

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 (4, Insightful)

moosesocks (264553) | more than 6 years ago | (#23991765)

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.

Re:Taking bets (1)

johny42 (1087173) | more than 6 years ago | (#23993103)

Google has GWT already, and it uses Java rather than some new language/framework.

Frighteningly good demo (2, Insightful)

ehack (115197) | more than 6 years ago | (#23991851)

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.

Excellent! (-1, Troll)

Zygfryd (856098) | more than 6 years ago | (#23991867)

Now we get the terrible syntax and unfamiliar semantics of Obj-C coupled with the implementation incompatibilities of JavaScript!

Re:Excellent! (3, Interesting)

cheesy9999 (750203) | more than 6 years ago | (#23992705)

You managed to fit quite a lot FUD in one sentence.
  • Cappuccino and Objective-J aim to completely abstract away the inconsistencies of the browser DOM (JavaScript the language itself is fairly consistent across browsers)
  • Objective-J brings classical inheritance to JavaScript, which has much more familiar semantics to most people than JavaScript's prototypal inheritance
  • Regardless of Objective-C's syntax, have you seen some of the syntactical hoops JavaScript programmers jump through to get pseudo-classical inheritance? Just check out Crockford's JavaScript pages [crockford.com] and his new book. There's about a half dozen different ways to do it, none of which I find particularly elegant.

I've Got It! (2, Funny)

FurtiveGlancer (1274746) | more than 6 years ago | (#23991893)

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]

Stolen graphics? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23991949)

Is it me, or are they blatantly stealing Apple's graphics (design, icons, etc)?

Re:Stolen graphics? (2, Insightful)

ProfessionalCookie (673314) | more than 6 years ago | (#23992347)

It's you. They're stealing Apple's motif, but I have no quarrel with that!


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:Stolen graphics? (1)

kimble3 (736268) | more than 6 years ago | (#23992893)

Supposedly Apple has converted all of their .Mac applications to use Sproutcore so they are pretty heavily involved in the project.

Re:Stolen graphics? (2, Informative)

rboucher (1316519) | more than 6 years ago | (#23993055)

Just to clarify, Sproutcore is something completely different. Cappuccino and Objective-J have no relationship with Sproutcore or Apple.

Will web apps eventually dominate software? (2, Insightful)

Max Romantschuk (132276) | more than 6 years ago | (#23992033)

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:Will web apps eventually dominate software? (0)

Anonymous Coward | more than 6 years ago | (#23992113)

Not until an internet connection will be as reliable as electricity; give it a few more years..

Re:Will web apps eventually dominate software? (1)

Foofoobar (318279) | more than 6 years ago | (#23992747)

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 via one cetralized core and don't have to reinvent the dataor the backend. All you have to do is recreate the view for the most part.

Re:Will web apps eventually dominate software? (1)

TheCouchPotatoFamine (628797) | more than 6 years ago | (#23992827)

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.

Re:Will web apps eventually dominate software? (1)

Foofoobar (318279) | more than 6 years ago | (#23992889)

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 styles and in fact has bad development styles all over the place. I used to test for them and have gotten into arguments saying that the language really needs to be strongly typed, enforce strongly typed and might even consider releasing a compiler one day. But they say it would make it too complex; they want to cater to newbies and continue catering to newbies which will always hold the language back as far as I'm concerned. But hey, still scales better than Ruby. :)

280 slides (0)

Anonymous Coward | more than 6 years ago | (#23992055)

strange how the only browser it's not compatible with is Opera - the one that is supposed to be the MOST standards compliant

Re:280 slides (2, Informative)

rboucher (1316519) | more than 6 years ago | (#23992191)

We work okay with Opera. Especially the latest 9.5 release. There are a few minor issues though, especially with regard to text scaling.

Re:280 slides (1)

fbjon (692006) | more than 6 years ago | (#23992521)

Works just fine for me..

as fast as ppt (1)

SurNim (1312119) | more than 6 years ago | (#23992131)

As someone who works with M$ office software for mac all the time, this seems to be about the same speed. Dead serious, PowerPoint is the worst software on the Mac OS. (not trying to start a flamewar)

Re:as fast as ppt (1)

rboucher (1316519) | more than 6 years ago | (#23992217)

PowerPoint 2008 on the mac is particularly slow. Actually, I think 280 Slides is significantly faster. It's often faster than Keynote as well, depending on the task.

Re:as fast as ppt (1)

Yvan256 (722131) | more than 6 years ago | (#23992233)

Not trying to start a flamewar either, but why are you even using PowerPoint on a Mac when Keynote is so much better anyway?

Re:as fast as ppt (1)

SurNim (1312119) | more than 6 years ago | (#23992351)

unfortunately i need to for compatibility issues :(

Re:as fast as ppt (1)

dave420 (699308) | more than 6 years ago | (#23992459)

When I tried it, it was slow as all hell. I couldn't even use it. I guess that's one drawback of such applications - the bottleneck is not at your computer, and as such is out of your control. At least with something like Flash/Flex the amount of communication between the server and client can be drastically reduced, and cross-platform compatibility is greatly improved.

Re:as fast as ppt (1)

cheesy9999 (750203) | more than 6 years ago | (#23992527)

Once the app is loaded the communication between the client and server is very minimal (saving/opening documents, searching for images, etc). It's the same sort of model as Flash/Flex. The vast majority of the code is client-side.

Loading has been particularly slow since it appeared on Slashdot. On my computer (2.8GHz) it normally loads in about 3 seconds not cached, and even faster if it is cached. It seems to be loading much faster now than earlier too.

Or are you referring to the actual interface once it is loaded?

Re:as fast as ppt (1)

rboucher (1316519) | more than 6 years ago | (#23992551)

This isn't true. The only difference in total communication size between being based on Flash and being based on Cappuccino/Objective-J is that you're downloading the entire runtime when you visit the site, instead of as a plugin ahead of time. This gives the developer control over what version/what features he or she can use, instead of placing the burden on the user's version of flash.

When the runtime is cached, there is no difference in server communication. Since the app is loaded, and then doesn't communicate at all with the sever except to do things like save and open documents, it does exactly the same amount of communication a Flash application would have to. Plus, eventually the runtime can be cached across all sites that opt-in (like Google is doing with other AJAX libraries), further reducing server traffic.

Wow!! Just damned Wow!! (3, Funny)

Wizard Drongo (712526) | more than 6 years ago | (#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!!!!!

Re:Wow!! Just damned Wow!! (0)

Anonymous Coward | more than 6 years ago | (#23992777)

It is impressive, but I can't stop comparing in my mind it to what many were doing with flash 8 years ago. Flash and silverlight have the whole lock-in proprietary thing going, so I understand hesitation in adoption. It seems to me an open source rich media client (plugin) would be a far better solution than squeezing every last drop out of html/js and still not being able to get what you need from it.

Javascript to design? (1)

WebmasterNeal (1163683) | more than 6 years ago | (#23992463)

"When you build an application in Cappuccino, you don't need to ever deal with HTML or CSS" Wouldn't it be easier to use html and css, and isn't that the purpose of both of those languages? What about users that have javascript disabled?

Re:Javascript to design? (1)

rboucher (1316519) | more than 6 years ago | (#23992593)

HTML and CSS were designed as document layout tools. They're pretty good at that task, but they aren't particularly good at building applications, or application UIs.

As far as users with JavaScript disabled, an app like 280 Slides simply isn't possible without JavaScript. It's an application, not a website. Declarative languages wouldn't be enough. So, since you need JavaScript to work at all, its reasonable to make design decisions that require it to be on.

do something new, please (0, Troll)

speedtux (1307149) | more than 6 years ago | (#23992565)

280slides looks nice, but there are half a dozen other on-line slide presentation programs out there (including Zoho and Google).

Why not actually innovate? Come up with a better way of creating and maintaining slide shows. Do something other people haven't done yet.

Re:do something new, please (0)

Anonymous Coward | more than 6 years ago | (#23992659)

I agree with the parent. There doesn't appear to be anything new here. An important note is that the graphics are all done OUTSIDE of the presentation tool and that is what is making the slides look cool. For example take the tour and try to manipulate the 280 slide picture, you'll notice that he reflection is IN the picture and in Keynote its NOT, it is in fact generated by the Keynote engine.

should be interesting in combo with XULRunner (2, Interesting)

radarsat1 (786772) | more than 6 years ago | (#23992627)

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.

Re:should be interesting in combo with XULRunner (1)

tilde_e (943106) | more than 6 years ago | (#23993239)

Does FF look like a web page to you? It is also written in XUL...

Re:should be interesting in combo with XULRunner (1)

radarsat1 (786772) | more than 6 years ago | (#23993401)

I've been often using XULRunner as a way of hosting some native widgets with an embedded HTML-driven interface. Obviously XUL can do more than that, it's just how I've been using it.

Impressions (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23992631)

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.

Re:Impressions (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23993189)

Objective C (and NextStep/OpenStep/Cocoa) has a 20 year track record of success. I suggest you stick to MFC.

Reinventing XUL... BADLY (2, Insightful)

Foofoobar (318279) | more than 6 years ago | (#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:Reinventing XUL... BADLY (1)

argent (18001) | more than 6 years ago | (#23993345)

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.

Re:Reinventing XUL... BADLY (0)

Anonymous Coward | more than 6 years ago | (#23993421)

It can load --- and work about 99% -- in Konqueror as of 5 minutes ago. It only took a couple of really tiny fixes. It's VERY well done. Usually anything this large is full of browser-specific hacks.

Javascript and HTML/CSS (0)

Bluesman (104513) | more than 6 years ago | (#23992901)

I don't understand what's wrong with Javascript and HTML/CSS that you'd need to build a framework on top of it.

For years when we mostly used native GUI toolkits, the rage was making XML libraries so you could build your application as easily as you could a web page. (see GTK, glade)

And really, writing apps with Javascript is a godsend...using HTML elements with CSS to build an app is so much faster, flexible, and easier than any other method that it's nearly insane not to do it that way, especially when you're targeting the browser.

Not to take away from these guys' work, as their application is nice...but I don't see the framework as being anything special.

Impressive, but broken (2, Interesting)

Haeleth (414428) | more than 6 years ago | (#23993101)

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:Impressive, but broken (2, Informative)

moosesocks (264553) | more than 6 years ago | (#23993169)

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

Re:Impressive, but broken (4, Informative)

rboucher (1316519) | more than 6 years ago | (#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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>