Apple's SproutCore, OSS Javascript-Based Web Apps 203
99BottlesOfBeerInMyF writes "AppleInsider is running an article about Apple's new SproutCore Web application development framework, utilizing Javascript and some nifty HTML 5 to offer a 'Cocoa-inspired' way to create powerful Web applications. Apple built on the OSS SproutIt framework developed for an online e-mail manager called 'Mailroom.' Apple used this framework to build their new Web application suite (replacing .Mac) called MobileMe. Since SproutCore applications rely on JavaScript, it seems Apple had good reason to focus on Squirrelfish for faster JavaScript interpretation in Webkit. Apple hosted a session last Friday at WWDC introducing SproutCore to developers, but obviously NDAs prevent developers from revealing the details of that presentation. Apple has a chance here to keep the Web becoming even more proprietary as Silverlight and Flash battle it out to lock the Web application market into one proprietary format or another. Either way, this is a potential alternative, which should make the OSS crowd happy." TechDIrt's writeup on the browser evolving towards acting as an OS expands on the theme AppleInsider raises.
Re:There are many areas where Apple matters (Score:5, Interesting)
lockin (Score:5, Interesting)
I started writing on DOS. (I won't count the Apple ][.) Wrote for PDP-11s. Wrote for Windows. Wrote for SGI GL (before OpenGL). Each new platform was yet another paradigm, yet another set of non-portable libraries or techniques.
I like POSIX, and I like portable languages and toolkits that I can take from platform to platform. I like writing little graphical apps or command-line tools in Perl, Python, GTK, SDL, OpenGL that I can run on Linux, Windows, Mac OS X, or even my Nokia N810. All the knowledge is transferrable, all the benefits of the little tools are transferrable with a little work to smooth out details like widget placement or font decisions.
I never bothered to get deep into Objective C, because while it's theoretically transferrable, it is really just used to write for the Apple Carbon/Cocoa/Core/Whatever/Don'tNitPickItsJustAnExample* stack. Same went for DirectX on Windows when I still wrote software for Windows. I would like to make apps that do whizzy things with Core Animation or whatever, but I just can't make myself get excited at the prospect of learning yet another vendor-lockin technology. The hardware-accelerated compositing is cool, the effortless scripting of visual objects is interesting, but not interesting enough to actually learn something that won't be portable.
If I really want a visual effect like Core This or Direct That, I will write a portable library to do it in OpenGL on Python or something. Or if the need isn't extreme, I'll just wait for someone else to write the general library if it ever happens.
Re:Shouldn't that be... (Score:3, Interesting)
An odd fit? (Score:3, Interesting)
It's an interesting idea, and maybe I'm missing the "awesomeness" of it, but I don't find a compelling reason to switch to this over a standard development stack. It just seems as though it's a highly widgetized javascript framework, running on ruby.
I develop in Rails and C#, and I'd just as soon use jQuery [jquery.com] and it's host of extensions to build my own application like widgets that I could use across any backend.
I've looked through the documentation and I'm hoping I'm just missing something about SproutCore's awesomeness.
Re:There are 6 million iPhones out there (Score:5, Interesting)
Re:proprietary (Score:3, Interesting)
Unfortunately there's really no other choice if you want to build certain types of (buzzword alert!) "Rich Media Applications".
More on-topic: This ScriptCore looks like Yet Another Javascript Framework (YAJF?). Some choices seem particularly odd, such as choosing to reimplement buttons through javascript code instead of using native browser widgets. And they say it's iPhone-compatible, but oddly one of their demo pages caused my Java VM plugin to start up! I'm not sure what it's being used for though.
Re:There are 6 million iPhones out there (Score:5, Interesting)
Web development is for the web, not targeted at the iPhone. Whether or not key customers can view your content is a big deal. iPhone users will have more impact than their numbers suggest, just as Mac users do.
The fact that this also benefits Linux users is just a nice finish.
It's a Javascript-centric Rails clone? (Score:1, Interesting)
Personally I'm not seeing the need...
Re:proprietary (Score:2, Interesting)
How does it compare to GWT? (Score:3, Interesting)
How do the two compare?
Re:How does it compare to GWT? (Score:1, Interesting)
How do the two compare?
Based on this, my guess is that SproutCore won't make you wish you had lost your sight as a child as you write thousands of lines of boilerplate to coerce Apache to serve up your Ajax hello world. It'll be more like:
require 'sprout'
sprout = Sprout.new
sprout.content = "Hello World"
sprout.render
Re:proprietary (Score:2, Interesting)
Re:An odd fit? (Score:4, Interesting)
When I have filed bug reports against Opera the developers have been very responsive - but still, the fact is that I've had to file bug reports because of shortcomings in Opera.
Re:tagging retards... (Score:3, Interesting)
But otherwise it looks like a front-end toolkit, so its not clear to me how much it actually depends on RoR.
Re:But what will the code look like? (Score:3, Interesting)
Just taking a glace at it, I agree that it would be difficult to integrate sproutcore with an exisitng web app, its really an entirely different approach.
Re:But what will the code look like? (Score:1, Interesting)
Looking at WebKit vs Mozilla, NeXTStEp vs Be, and, to a lesser extent, iPod vs the rest, for comparison, my money would be on SproutCore, no matter how far, if anything (I haven't looked at either framework), behind it is now. The two things Apple has been good at for the past few years are focus and looking through what things are at what they could become if that focus were directed at it.
Re:There are many areas where Apple matters (Score:3, Interesting)
Re:There are many areas where Apple matters (Score:3, Interesting)
How long does it take you to find those services? To integrate them all to the convenience level provided by
I currently bill out at $100/hr, which makes
If you're not worth that much, or if you choose to not optimize your time as sensible people do -- that being the only absolutely limited resource there is! -- I respectfully submit that it is you, and not worthwhile people, who is the retard.
Re:How does it compare to GWT? (Score:1, Interesting)
Well, I haven't written anything in SproutCore yet, only read some of the docs, but I have written some stuff using GWT. Here's a 30 second comparison based on first impressions.
You write your apps in JavaScript with SproutCore. With GWT you write them in Java and GWT compiles it down to optimized JavaScript. You can mix and match Java/JavaScript quite easily. As it happens, I think JavaScript is a nicer language than Java but nonetheless, writing web apps in Java has turned out to be surprisingly pleasant. Mostly because Eclipse is pretty damn good, and because it's much more natural to write clean, object oriented code in Java than in Javascript. You certainly can write such code in JavaScript but the environment really doesn't encourage it. Also, lots of Java libraries can be reused if they aren't heavily dependent on the JRE (eg, generic calculation libraries).
SproutCore seems very MVC centric. GWT in contrast really isn't. You can certainly build an MVC app in GWT but there isn't much support for it out-of-the-box. SproutCore is also very into the properties and bindings aspect of the framework. They seem to consider this pretty central. Of course you can write code with properties and callbacks in Java too. I'm not aware of any direct equivalent to bindings.
SproutCore seems to be Ruby centric but I can't tell for sure if it really is. GWT is backend independent - if you use Java you get nice features like simple RPC and the ability to step from client into server using the debugger, but I'm not using a Java backend for my project and it works OK anyway.
SproutCore seems to have very light documentation. This is my main concern about it. Having read what material I could find on the site I don't really feel like I understand the framework or what it offers me well. Also, their doc viewer app triggers visual glitches in Firefox 2/Linux which is a practical concern. In comparison the GWT docs are excellent [slashdot.org]. The SproutCore API reference is very sparse and, to be frank, buggy (check out the progressbar docs).
SproutCore manufactures its own widgets to make them look Apple-like. GWT uses native widgets. Native widgets take on the native theme and are accessible. If you're writing software with accessibility requirements (eg, for govt) then this fact alone kills SproutCore dead AFAICT. If you want extra widgets for GWT you can use GWT Ext [gwt-ext.com] which is a much more complete widget library than what SproutCore provides.
GWT has an excellent optimizing compiler, which lets you write at a high level of abstraction whilst still giving small downloads and decent speed. SproutCore doesn't.
Anyway, to conclude, I wouldn't use SproutCore today. It seems very immature documentation wise, it might have a hard Ruby dependency, I'm not sure why I'd want to use it and GWT has many (many) features that I now wouldn't want to be without. GWT has really changed the way I think about writing web apps. It'd take one pretty amazing JavaScript framework to make me leave it and SproutCore just isn't it.