Apple's SproutCore, OSS Javascript-Based Web Apps

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.

Comments

Re:There are many areas where Apple matters

[SanityInAnarchy]

I think the iPhone would disagree there. Pretty much as long as Apple refuses to put Flash on the iPhone, anything iPhone-friendly will have to be some flavor of HTML. The fact that it would also work well on Linux is a bonus.

lockin

[Speare]

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

[FF0000 Phoenix]

No, it's intentional. Think of it as a Rorschach test for your opinion on Apple. Putting in “from” means pro-Apple. Putting in “from not” is the opposite. As it is, I think we all know which category you fall in. No wonder you posted anonymously.

An odd fit?

[iamghetto]

The photo gallery demo on SproutCore.com fails to work on Opera - the right photo pane not even rendering. Although Opera isn't widely used, with its exceptional standards-compliance it's a great barometer for how compatible something may ultimately be.

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 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:An odd fit?

[93 Escort Wagon]

Although Opera isn't widely used, with its exceptional standards-compliance it's a great barometer for how compatible something may ultimately be. Fans of Opera always say this; but it's been my experience, when developing web apps, that Opera tends to lag behind Firefox and even Safari when it comes to CSS support - specifically when it comes to using Javascript to modify various CSS parameters on the fly.

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:There are 6 million iPhones out there

[catmistake]

just Fyi, I, and roughly a million others (probably more) have been loading binary apps on iPhone for a year or so. Some of these apps, such as the package manager, rely on HTML... and every so often they update and it gets even slicker. I really can't understand what you mean by 'inconvenient,' when it seems the whole point of webapps is precisely for convenience.

Re:proprietary

[josath]

I definitely agree...but some things just can't be done in javascript. If you need more performance, video/audio, real tcp/ip socket connections (not that crazy 'comet' hack, or wasteful polling), zlib compression, even if you want to rotate an image to an arbitrary degree on the client with antialiasing, then you need flash. Java applets take too long to load, even though the runtime performance is usually better than flash. Flash has the advantage over Silverlight of install base. SVG has limited browser support & limited features compared to Flash.

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

[DECS]

According to real statistics, well over 80% of iPhone users "use more than ten functions," and even more use Safari for browsing. That's why the phone has a majority share (~75%) of mobile website traffic in stats despite "only" taking 27% of the new phones sold in the US and only having been on the market for a year.

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?

[HisMother]

None of the other commenters here seem to have checked out their site at all. Sproutcore is apparently a JavaScript-generating, Ruby-based templating framework. To me it looks kind of like a Rails clone with jQuery built in.

Personally I'm not seeing the need...

Re:proprietary

[John Dowdell]

"If things can be accomplished with COMPLETELY open and free (as in freedom) frameworks and languages, why choose Flash?" The key word in that sentence may be the first.... ;-) (The original story seemed strange to me... many screenfuls of text, with the elevator pitch seeming to be "One particular JavaScript Framework will Rule The World -- *if* it's from Apple!" The weblogs didn't show much skepticism today, so I'm glad to see some realistic questioning here at Slashdot.) jd/adobe

How does it compare to GWT?

[VGPowerlord]

After reading a bit about this, it sounds like something similar to Google's GWT (with Gears), except that SproutCore uses Ruby instead of Java.

How do the two compare?

Re:How does it compare to GWT?

[Anonymous Coward]

except that SproutCore uses Ruby instead of Java.

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:How does it compare to GWT?

[Anonymous Coward]

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

Re:proprietary

[riceboy50]

flash probably wouldn't be viable on it The conclusion I come to is that Flash is too bloated. I have run into many situations where it killed even my desktop systems.

Re:tagging retards...

[IntlHarvester]

Actually if you look at the (very minimal) docs on sproutcore.com, it runs out of a Rails app server.

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?

[IntlHarvester]

Actually it seems to generate all the HTML (not sure if that's what the grandparent meant by 'code'), including re-implementing standard browser widgets.

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?

[Anonymous Coward]

"I'm pretty surprised no one has mentioned ExtJS, another VERY full-featured JS interface library. SproutCore is super young in comparison, it looks like, but it will be interesting to see how it advances"

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

[PenguSven]

Also-to add to the above. I pay for .Mac (soon to be MobileMe) it gives me auto synced mail, bookmarks, contacts, storage, gallery etc etc for the aforementioned price. being a contractor, every hour I'm not working is an hour I'm not making money. now at $75/hr exactly how many hours do you think I need to spend finding/configuring these other services that "do exactly the same" over a year, before I'm worse off, from a purely financial point of view.. i'll give you a hint: it's not many.

Re:There are many areas where Apple matters

[Snocone]

If it helps to get the retards to pay $100 per year for a set of services they can get elsewhere for free,

How long does it take you to find those services? To integrate them all to the convenience level provided by .me? To manage them?

I currently bill out at $100/hr, which makes .me a cost of exactly 1 hour of my time. Strikes me as a good deal less than I'd sink into replicating it with "free" services.

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.