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

Comments

Podcast interview with the developers

[bigbigbison]

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.

That wacky javascript

[symbolset]

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

Re:That wacky javascript

[dave420]

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

[rboucher]

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

[hvm2hvm]

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

[Peterix]

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

[dave420]

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

[dave420]

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

[dave420]

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

Re:That wacky javascript

[Peterix]

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.

Re:That wacky javascript

[porneL]

It's OK on Intel Macs, but absolutely crappy on PowerPC (my guess is that they've hand-optimized critical stuff in x86 asm only).

Re:That wacky javascript

[bberens]

I've never had problems since flash 9 came out. I do have a discrete graphics card but this machine is like 5-6 years old tech. I think that's a very big YMMV thing.

Feh

[rs79]

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

[FooAtWFU]

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

[Simon (S2)]

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

[TechyImmigrant]

>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

[rboucher]

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

[rboucher]

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

[XanC]

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

[rboucher]

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

[dnwq]

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

[XanC]

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

[rboucher]

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

[iluvcapra]

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

[mattkime]

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

[jsebrech]

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

[dave420]

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

[rboucher]

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

[Archibald Buttle]

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

[The_Wilschon]

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

[mattkime]

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

Re:Feh

[dave420]

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

[rboucher]

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

[shutdown -p now]

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

[dave420]

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

[Richard W.M. Jones]

[Not in reply to your comment, but since you seem to be one of the authors ...]

The $64K question for me is what is / will the license be? Will it be properly open source? All parts or some parts?

Rich.

Re:Feh

[rs79]

" 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

[jlarocco]

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

[TerranFury]

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 browser, I feel like that speaks to a failure of some other part of the software infrastructure.

Re:Feh

[TerranFury]

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:Feh

[Mopatop]

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

Which browser were you using? On my XP3500 with 2gig on FF3 it wasn't slow at all. Faster than a lot of these web-apps.

Re:Feh

[Moridineas]

What about privacy/security concerns?

Re:Feh

[Moridineas]

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!

Re:Feh

[bit01]

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

[jlarocco]

Which browser were you using?

What browser I'm using shouldn't be relevant. That's the whole fucking point of the internet and "web applications". If I have to download a specific browser or use a specific operating system, I might as well just download a native excutable and be done with it. Suffice it to say that I'm using the latest version of a modern browser that isn't Firefox.

Faster than a lot of these web-apps.

That's not saying much.

Re:Feh

[Doogie5526]

Which browser were you using?

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

[axxran]

rboucher, I am a Flex/Flash RIA developer and I think what you guys have done is completely and wickedly awesome. Keep going!

Re:Feh

[jsebrech]

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

[Simon (S2)]

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

Re:Feh

[sentientbrendan]

"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 away performance to get advanced language features, or at least, a reasonable compromise can be reached. C++ has a lot of nifty language features, and it getting a lot more in the next revision (like closures, type inference, and concepts). Java also pays attention to performance, although it isn't quite on par with C++. Many advanced language features have no performance costs, or can be implemented in such a way that those costs are minimal. Some language implementers simply do not care about performance and create a suboptimal implementation.

Re:Feh

[tyrione]

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

OpenOffice does a helluvalot more than this project. However, it's still nice to see such happenings, even if it's Javascript.

Re:Feh

[acb]

for now, let's see when JS2 comes out and will be implemented by all major browsers

And then wait five years until big corporations with centrally-managed desktops finally move on from IE6.

Re:Feh

[yabos]

So it sounds like maybe you're using IE then which is notoriously bad at javascript compared to FF or Safari. Or maybe you're using Opera in which case I don't know anything about it or it's performance in javascript. It shouldn't matter what browser you are using but when some of them suck at standards compliance or some have bad js interpreters then it does matter for now. Also, the site is likely being hosted on a single server because the company is only 3 guys in their 20s who just launched it. You should know by now that when something gets posted on slashdot the site will be slow.

Re:Feh

[TheRaven64]

Which do you expect to be more secure, an app running natively on your local machine, with access to all of your operating system's system calls, or one running in a sandbox designed for untrusted code?

Privacy is only a concern if someone else is hosting the web app - if it's on your own server then it's often more convenient than carrying a laptop around.

Re:Feh

[TheRaven64]

Most of this is due to the fact that current JavaScript implementations optimise for startup times. If your code, running in a naive, directly-interpreted AST implementation, will only spend two seconds of CPU time running then spending 5 CPU seconds of time optimising it is a net loss. There are JavaScript implementations designed for long-running code which do some very nice things (look up 'trace optimisation'), but they aren't used in browsers because, for 99% of JavaScript, they are not useful. The new JS runtime in WebKit uses direct bytecode execution, because compiling to bytecode is fast (so doesn't impact startup times) and executing bytecode is 'fast enough.' If people start doing more things with JavaScript that tax it, then they will change it. From the bytecode, it is relatively easy to optimise and native-compile certain traces in the background, which will give a significant speed boost on longer-running applications.

Re:Feh

[Moridineas]

Which do you expect to be more secure, an app running natively on your local machine, with access to all of your operating system's system calls, or one running in a sandbox designed for untrusted code?

Web apps and the browers IE, Firefox, Safari, etc don't exactly have a great track record of being secure (css, etc!). I can jail, firewall, etc and control everything that runs on my own computer. If I'm using open source, I can compile it myself. Don't generally have that freedom with webapps.

Privacy is only a concern if someone else is hosting the web app - if it's on your own server then it's often more convenient than carrying a laptop around.

Yes, that is EXACTLY the privacy concern.

Re:Feh

[tcr]

My $0.02.. In many cases, I think Javascript has an advantage because you can apply it iteratively.
 
An organisation might already have some JS active on their web presence, perhaps doing something trivial like form validation. It's not such a big deal to add as much or as little Ajax or effect eyecandy as you like, building on what you already have.
 
Doing it in Flex or Silverlight would effectively be a rewrite for a different platform...?

Re:Feh

[MemoryDragon]

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.

There are two problems in javascript on the language level. The lack of namespaces which caused that every library trying to support namespaces implemented its own mechanism. The lack of inheritance. Javascript only goes the half way it exposes the method map which is the prototype map, and no it does not support prototype inheritance on language level, it just exposes the map, thats it nothing more. The result has been that every bigger library added its own inheritance mechanism often causing side effects in other libraries. Exposing the method map is no superior inheritance mechanism it is not inheritance mechanism at all and it is not superior, it falls into an entirely different category of language constructs. A standardized inheritance mechanism is vital to push the language up to the level needed for bigger programs!

Caffeine Theme

[FurtiveGlancer]

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

[jeiler]

And where are my mod points when I need them!

+1 Funny (Unofficial). FurtiveGlancer FTW.

Re:Caffeine Theme

[ScrewMaster]

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

Re:Caffeine Theme

[FurtiveGlancer]

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

Re:Caffeine Theme

[FurtiveGlancer]

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.

Re:Caffeine Theme

[jcr]

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

[larry bagina]

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

Re:Caffeine Theme

[kennygraham]

Multithreaded Apache Requiring Secure Hashes Makes Awful Low Level Operations on Windows Servers?

Re:Caffeine Theme

[kennygraham]

Almost, just no foam. It got discontinued in January of this year.

Re:Caffeine Theme

[jeiler]

"For The Win," but that works, too. :)

Damn ...

[ScrewMaster]

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

Re:Damn ...

[FurtiveGlancer]

Don't you people have better things to do?

*holds up mirror*

Re:Damn ...

[cheesy9999]

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

Re:Damn ...

[kjots]

Cheap +5 Insightful: just say "All Americans suck because {insert generalization here}"

Alright, I'll bite:

"All Americans suck [air] because nature has selected that as the best way to get oxygen into the bloodstream."

Now where's my +5?

Re:Damn ...

[neonmonk]

Could you be any more lame...

Re:Damn ...

[mortonda]

Ow, my eyes... it burns!

Re:Damn ...

[kjots]

Probably. I'll work on it.

Re:Damn ...

[DrEasy]

Great, but now where's the linky to that mirror?

RTFA

[dreamchaser]

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

[mattkime]

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

[rboucher]

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

[jsebrech]

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.

Re:SproutCore - it relies on ruby

[aesiamun]

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

[Mopatop]

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.

Oh please for the love of god don't include any of that Ruby shit's concepts/methodologies into your work - I was really excited about this until I read your post.

Taking bets

[moosesocks]

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

[johny42]

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

Frighteningly good demo

[ehack]

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!

[FurtiveGlancer]

Since it's Cocoa-like, we have to rename it Carob. Quick, somebody get their acronym generator going!

Too slow! Already taken.

Stolen graphics?

[Anonymous Coward]

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

Re:Stolen graphics?

[ProfessionalCookie]

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?

[kimble3]

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

Re:Stolen graphics?

[rboucher]

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?

[Max Romantschuk]

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/ 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?

[Foofoobar]

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?

[TheCouchPotatoFamine]

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?

[Foofoobar]

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

Re:Will web apps eventually dominate software?

[Jesus_666]

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 allow for more robust scripts. But that's all a moot point; the PHP devs are about as enthusiastic about cleaning up their language as Microsoft is about open-sourcing NTFS.

Re:Will web apps eventually dominate software?

[Foofoobar]

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.

Re:Will web apps eventually dominate software?

[dmsuperman]

I could never deal with the slowness that is javascript apps. Not merely loading times, but it's extremely difficult to make the UI even remotely as responsive as it is on a desktop application. No thanks, not until they figure that out. As far as web apps go, this is nice, but it's still a web app, and it's still very slow.

as fast as ppt

[SurNim]

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

[rboucher]

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

[Yvan256]

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

[SurNim]

unfortunately i need to for compatibility issues :(

Re:as fast as ppt

[dave420]

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

[cheesy9999]

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

[rboucher]

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.

Re:as fast as ppt

[yabos]

Good job on the framework(and the app). I can't wait until it's released so I can use it myself.

Mocha Theme

[Anonymous Coward]

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:280 slides

[rboucher]

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

Wow!! Just damned Wow!!

[Wizard Drongo]

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!!!!!

We always find fault on /.

[kestasjk]

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

[thetartanavenger]

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

Re:We always find fault on /.

[Anonymous Coward]

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:We always find fault on /.

[yabos]

Well, it was just posted on slashdot so perhaps it's their server being slow responding to requests that halts the application UI thread and makes it feel slow. A few weeks ago when it was announced, I tried it and it was really fast. Also, you should check it at least on FF 3.x or Safari 4 preview or a Webkit nightly if you have access to that because both have much faster javascript engines compared to FF 2.x, Safari 3.x and IE x.x

Re:280 slides

[fbjon]

Works just fine for me..

Re:Javascript to design?

[rboucher]

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.

should be interesting in combo with XULRunner

[radarsat1]

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

[tilde_e]

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

Re:should be interesting in combo with XULRunner

[radarsat1]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Impressions

[Shados]

You do realise that in this day and age, C/C++ programmers are by far the minority? So the gain is to make the toolkit attractive to other devs, and the mess that is C++ isn't the best bet for that.. That being said, Objective C has been around for ages, so meh. C++0x would be ok, but that doesn't have the same track record as Objective C and isn't ready anyhow.

Re:Impressions

[GrahamCox]

A lot of mediocre programmers seem to complain about Objective-C syntax and Cocoa and whatnot. I can tell you, after 14 years immersed in C++, Cocoa/Objective-C was a breath of fresh air. I picked up the language in about a day and the basics of Cocoa in a few more. Obviously getting really comfortable with it takes a while longer but after doing Cocoa solidly now for 5 years I'd find it very hard to give up. If you've yet to see the advantage then you're probably not doing anything seriously with it. The dynamic dispatch alone simplifies things in a way that C++ can only dream of.

As for MFC, it's a total joke compared to what you can accomplish in Cocoa with a fraction of the code and with a result in another league in terms of stability and quality.

I'm not a rabid fanboi or whatever I'll probably get accused of, but after using a number of languages and frameworks over the years (including developing my own general purpose framework in C++ for Mac) I can tell you that in my experience Cocoa is the best there is right now, and that has been the case for a while.

Re:Impressions

[astrosmash]

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

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.

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.

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.

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.

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

Re:Impressions

[TheRaven64]

To add to what you've said:

If you've read the Gang of Four's Design Patterns book, then Cocoa will be very familiar to you since many of the patterns in that book were lifted directly NeXTSTEP / OPENSTEP. If you haven't, then I suggest you should not be calling yourself a programmer.

The syntax of Objective-C does take a bit of getting used to, but I've recently done some C++ and until then hadn't realised how much of a productivity boost it was. With C++, I frequently get the order of parameters wrong. With Objective-C, I never do because they are encoded in the way you make the call. If I want to insert an object into a dictionary, it's [dict setObject:obj forKey:key]. In languages where the parameters all go after the end of the method name it's often not clear which object should be the first parameter and which should be the second.

The main advantage of Objective-C is the ease of implementing delegates. You can pass an object to another object and have it call methods for certain actions. Remember in Java how you implement the SomethingListener interface and end up with a load of methods implemented as {}? In Objective-C, the object can test whether the delegate implements any given method at runtime. And, since message dispatch isn't tied to class hierarchy, your objects don't have to subclass an existing class. The fact that messages can be encapsulated as objects is also incredibly powerful.

Re:Impressions

[keytoe]

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.

Reinventing XUL... BADLY

[Foofoobar]

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

[argent]

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

[Foofoobar]

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:Reinventing XUL... BADLY

[argent]

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.

Re:Reinventing XUL... BADLY

[rboucher]

Where exactly does it "Breaks in places in Firefox?" Let us know and we'll get right on it.

Re:Reinventing XUL... BADLY

[Foofoobar]

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 model and controller work with XUL apps so you don't recreate them and developers can work within an existing model they already know. And developers can build other frameworks to work other ways as well.

Unless of course you're wrong and it has a Ruby backend... in which case it is a bad XUL ripoff. And you owe me 5 bucks.

Re:Reinventing XUL... BADLY

[Foofoobar]

Yeah and fortunately XUL does not require browser specific hacks.

Re:Reinventing XUL... BADLY

[lanzz]

why, how many different browser platforms support XUL?

Re:Reinventing XUL... BADLY

[oliverk]

Worked like a champ for me. And by champ I mean one of the most seamless web-based apps I've ever seen.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

Prior comment about Google snapping these guys up is spot on. This makes Google Presentations look like it was done by college kids in their dorm room...not the other way around.

Re:Reinventing XUL... BADLY

[argent]

Friend, I think you're confusing me with someone in another thread, because I haven't said anything about whether XUL or Objective J is "better", all I'm claiming is that they are "different". They address different solutions, serve different purposes, are not competing for the same market.

It doesn't matter whether the back end has to be built in ruby or not (and I suspect you're mixing up Objective J and SproutCore, there, but it doesn't matter whether you are or not because I'm not talking about the internal security of the application), if it doesn't run in a sandbox it can't be used as an embedded applet in an arbitrary web page, and if it does it can. Contrariwise, if it runs in a sandbox it can't be used to create a general purpose local application, and if it doesn't it can.

These are two completely separate roles. There is no relationship between them. Attempting to combine the two into a single framework has had such a poor security track record that I'm sure you're not proposing that either of these is suitable for that benighted role.

As for your five bucks, now I'm *sure* you're confusing me with someone else, because I don't bet.

Re:Reinventing XUL... BADLY

[Foofoobar]

Why, how many browser support? So far it just looks like one; all others look like a haphazard guessing game throughout your code. Honestly I'd prefer not to have to guess and rely upon a cross platform solution and not a cross browser solution.

Re:Reinventing XUL... BADLY

[Foofoobar]

Run through it in FF2 and FF3. This is the ongoing problem with browser detects and different browser platforms vs one browser platform across multiple OS's. It's far easier to code a front end for one browser platform for web app that can be cross platform than for multiple web browsers and have to play guessing games with your code and your detecting mechanisms throughout. It also greatly increasing the amount of coding you have to do and time spent debugging.

Also, considering the invent of SSB's, the browser detect is an unnecessary thing and will eventually become a thing of the past. All you have to do is open it within your SSB on your desktop and your app is native. Eventually, I'd guess there will even be a grouped tool for tying the app to the SSB of choice so you can launch from one location.

So again, whats the point when XUL already does this but protects the controller and the model from client side attacks unlike objective-J?

Re:Reinventing XUL... BADLY

[Foofoobar]

Ah... I am thinking sproutcore. Sorry.

Re:Reinventing XUL... BADLY

[yabos]

It's beta ffs, and they haven't even publicly released the framework. Give it some time. I don't see anywhere that they claim it works 100% on every browser yet.

Re:Reinventing XUL... BADLY

[cheesy9999]

The key thing with Cappuccino is that the browser inconsistencies only need to be dealt with once by the framework developers. In theory, application developers should never have to worry about it. Yes, that's a big "in theory", but we've already come a long way in achieving that (you won't find browser hacks in the application code, all browser-specific bugs are bugs in the frameworks by definition)

Regarding XUL: it works on exactly one browser engine, which happens to not be my favorite.

Re:Excellent!

[cheesy9999]

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 and his new book. There's about a half dozen different ways to do it, none of which I find particularly elegant.

Impressive, but broken

[Haeleth]

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

[moosesocks]

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

Re:Impressive, but broken

[rboucher]

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

[they_call_me_quag]

By "broken" do you mean "not yet out of beta"? It's a work in progress so please quit your bitching.

Re:Impressive, but broken

[Cato]

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.

Re:Impressive, but broken

[lanzz]

i've had no problems entering cyrillic text and copy&pasting japanese. everything worked fine, the text was rendered correctly, even in the slide tooltips. i've tested this in safari 3.1.1 and firefox 3, both were ok.

i have no idea how the browser could even intercept the input method switch combo. the OS shouldn't pass such keyboard events to applications at all.

Re:Excellent!

[gazbo]

Yes, but be sure to also check out the bits where he says "but don't do it like this - if you don't try and emulate classical OO it's a lot easier".

2 questions

[v(*_*)vvvv]

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.

2. 280 slides? Why do all these open source projects and Mac inspired projects end up cloning *old* microsoft products? Do you guys really think these app designs deserve that much recognition? You cannot think of any other way to build a slide editor other than to mimic the layout, the functionality, and even the default template. I guess Microsoft really nailed it on the head.

I've seen this time and time again. I say stop cloning, and do something creative with your new toys.

Re:do something new, please

[larry bagina]

Reflections can be done with Canvas. Safari has built-in reflection support via custom css properties.

Re:Wow!! Just damned Wow!!

[larry bagina]

firefox is an open source rich media client.

Re:Javascript and HTML/CSS

[zuperduperman]

I wish what you say was true - but it's not.
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:do something new, please

[Dog-Cow]

The point wasn't to create a Keynote clone. The point was to demonstrate the toolkit.

What are you doing on /. anyway?

Re:do something new, please

[speedtux]

The point wasn't to create a Keynote clone. The point was to demonstrate the toolkit.

There are lots of Javascript-based presentation packages. So what does writing another one demonstrate?

What are you doing on /. anyway?

Waiting for my experiments to finish. What about you?

Re:do something new, please

[SoupIsGoodFood_42]

Because it's just a proof of concept app? It's not the app itself that's the story here, but the technology behind it.

WebObjects...

[amsr]

Isn't this essentially what webobjects was? Cocoa for web based apps, with a browser interface?

Re:WebObjects...

[larry bagina]

WebObjects is server-side.

Re:do something new, please

[lanzz]

The point wasn't to create a Keynote clone. The point was to demonstrate the toolkit.

There are lots of Javascript-based presentation packages. So what does writing another one demonstrate?

they're not demonstrating a toolkit for building presentation packages. they're demonstrating a general-purpose framework for building any GUI web application you might think of.

Re:do something new, please

[speedtux]

they're demonstrating a general-purpose framework for building any GUI web application you might think of.

And why would I pick their framework over any other framework now? What does their "demonstration" actually show?

Non-bloated interpreted languages.

[argent]

Forth and Scheme can be impressively small and tight, and are about as far from C as anything you're likely to run into.

Flashblock

[argent]

If you do it in Flash, then what I'll see when I hit that part of the page is (f), and when I hover over that it'll change to (>), and when I click on that it'll run. If the whole application is in Flash, then I'll often see that three or four times. I'll likely hit the button at the top of the window marked () and look for another alternative.

Why?

1. I can.

2. 90% of the Flash I run into is velveeta. That's "not quite spammy enough to be called spam, but no more desirable".

3. I can't take a .swf and pick it apart and save the actual useful content somewhere for future reference. Yes, I know that's an advantage for you. No, I don't care.

4. Flash performance on my G4 Mac Mini is not acceptable. Without Flashblock I pretty much couldn't use tabbed browsing.

5. Flashblock lets me decide when to download the flash content, screaming video, and other stuff, when I open up three or for tabs for leter perusal.

So, flash is at a disadvantage if you're interested in my eyeballs. Flashblock is available for all Gecko-based browsers. It's installed by default in some of them, and only a click away in the rest, and I'm sure there's equivalents for MSHTML and KDE/Webkit browsers as well.