Daniel Eran Dilger
Random header image... Refresh for more!

Cocoa for Windows + Flash Killer = SproutCore

Daniel Eran Dilger
Regular readers will recall that when Safari for Windows shipped, I suggested Apple was likely looking to move its Mac OS X Cocoa development model into the Windows arena in order to broaden Cocoa’s visibility and adoption.

Over the last year, I’ve also outlined Apple’s efforts to starve Adobe’s Flash and AIR (and by extension, Microsoft’s me-too Flash plugin called Silverlight), at a time when pundits have insisted that Flash was a vital missing element on the iPhone and that Apple could/should/would be scrambling to port Flash to it. It might be a surprise to find that Apple’s air supply attack on Flash and its interest in dusting Windows with Cocoa are actually related.

Cuckoo for Cocoa: Is Safari on Windows the next iTunes?
Safari’s Controversial Potential as a New Yellow Box for Windows

Gone in a Flash: More on Apple’s iPhone Web Plans
Flash Wars: Adobe in the History and Future of Flash

A Few More Surprises.
It might also come as a surprise that Apple will soon release a suite of apps that will join QuickTime, iTunes, and Safari on the Windows platform. Like Apple’s existing Windows apps, the new ones will all put the Mac OS X user interface in front of millions of new users. Additionally, they will also advance Cocoa-style development in front of a much larger audience, because Apple is also giving away the frameworks it used to create those new apps.

Another surprise is that all those apps will also run cross platform on Linux. How will Apple do this? Not by shipping a large, cross platform Yellow Box runtime for various other operating systems as it attempted to do back in 1997.

Instead, Apple is refining Cocoa for deployment within the web browser to enable developers to build those so called “Rich Internet Applications” that Adobe wants users to build in Flash/Flex/AIR, Microsoft in Silverlight, Sun in Java, and so on.

Cocoa and the Death of Yellow Box and Rhapsody

Despite the marketing efforts of Adobe, Microsoft, Sun, and other RIA toolkit vendors to generate a level of RIA hype that echos the client Java excitement of the mid 90s or the thin client enthusiasm of the late 90s, RIAs haven’t really taken on the world by storm. Instead, Flash, Silverlight and other proprietary tools and their required runtime plugins are all still aiming at some future date when they can claim the status of being the platform monopoly in RIA development.

However, many of the most popular rich web apps today are from Google, including Maps, Reader, Docs, and Sheets. Google’s rich web apps take on Microsoft Office desktop apps without even needing Flash, Silverlight, or Java. Instead, Google simply uses open web standards: HTML, JavaScript, and CSS. If Google’s leading rich web apps avoid using those proprietary plugins, why should anyone else resort to using Flash or something similar?

Google’s frequent partner Apple has been thinking along the same lines, scrubbing its website of all unnecessary Flash elements and building everything in those same open web standards: HTML, JavaScript, and CSS.

The Challenge of Funding Open Tools Development.
One might think that all web developers would flock to free and open solutions rather than selling themselves into slavery to a propriety web-like platform such as Flash or Silverlight. After all, once they’re dependent upon those runtimes, the power will lie with Adobe and/or Microsoft and competitive pressures to improve those tools will dry up, just as Windows and Internet Explorer flatlined after reaching their monopoly critical mass.

Of course, one might also think that PC makers would embrace free and open Linux, but that largely hasn’t happened either, for many of the same reasons. The problem in both cases is that open web standards don’t directly make anyone rich. Nobody owns them, so as with Linux, nobody can make much of a business model out of investing development efforts into improving them… unless they do so indirectly or for indirectly strategic purposes, as RedHat and IBM do in profiting from sales Linux related services.

Indirect strategies explain why both Google and Apple share the same strong affinity for an open web, in contrast to more short sighted developers would would blindly shackle themselves to Flash or Silverlight simply because those tools might help them accomplish their immediate objectives without too much effort.

Mobile EEE PC, UMPC, and Internet Tablets vs the iPhone: Linux' Mobile Problem

Mobile EEE PC, UMPC, and Internet Tablets vs the iPhone: Linux’ Mobile Problem

Why Google and Apple Want an Open Web.
Google is investing in standards-based tools for web development because it wants an open Internet; Google needs an open web because it can’t compete and sell ads if Adobe or Microsoft infect the open web with proprietary Flash or Silverlight plugins and subsequently convert web content into opaque binaries instead of open HTML.

Apple doesn’t sell ads, it sells hardware. But if the web requires Flash or Silverlight to run, Adobe or Microsoft can either intentionally kill alternative platforms like the Mac (or Linux), or simply make them work so poorly due to their own incompetence that those platforms risk becoming non-viable. Adobe has already proven its incompetence in delivering Flash for the Mac (and really any platform outside of Windows), and I shouldn’t need to recap Microsoft’s historical readiness to destroy anything that isn’t Windows.

And so Google and Apple are bound together by different interests that happen to converge: Google wants the web open so it can sell ads, while Apple needs it open so it can sell hardware that browses the web well. Currently, the two companies are both working to achieve these goals in independent, often complementary ways.

Google’s API Inexperience.
Google introduced its Google Gears as a mechanism for beefing up rich web apps with offline storage. However, Google’s API development experience is really limited to exposing access to its web services such as Maps, Gmail, and others. Google Gears, Android, and the company’s other efforts to deliver significant new platform APIs are still unproven.

An an example, Google’s progress in delivering the Android SDK, while introduced back in November 2007, has been eclipsed by Apple’s iPhone SDK both in release cycles and in sophistication and polish since its debut in February 2008.

Another problem for Google is that it doesn’t have a large and committed user base. Google has contributed a lot code to the community, but that doesn’t mean that the community will necessarily use it.

The Apple of Your API.
In contrast, Apple has very strong and mature development tools and platform frameworks that have been proven in the marketplace for many years and are widely adopted in the markets Apple competes in.

Apple originated the first mainstream graphical platform with the Mac. That model subsequently served as the basis for Microsoft’s Windows, which grew into popularity as Apple lost itself in the conundrum of Copland in the early 90s.

Apple employees who left in the late 80s to form NeXT created the first mainstream object oriented platform frameworks, again establishing the standard that the rest of the industry would aspire to clone or use as a reference to develop upon. Apple and IBM’s Taligent, Sun’s Java, and Microsoft’s unfinished Cairo all intended to ship something that NeXT already had in production use among high profile clients.

The Secrets of Pink, Taligent and Copland

The Secrets of Pink, Taligent and Copland
SCO, Linux, and Microsoft in the History of OS: 1990s
1990-1995: Microsoft’s Yellow Road to Cairo
Why OS X is on the iPhone, but not the PC

Apple’s API Philosophy.
After the remains of the old Apple acquired NeXT in 1996 and began work on Mac OS X, the company worked to continually develop and refine its desktop APIs using a unique philosophy that focuses upon:

  • enabling features
  • abstaining from developing unnecessary APIs
  • iterating over code to refine it
  • and delivering quality over quantity.

Apple’s emphasis on code quality and elegance in the API has allowed Apple to move faster than Microsoft over the last decade while also preventing Apple from having to painfully revisit major legacy problems resulting from sloppy coding and poor planning. That in turn has rebuilt Apple’s reputation in API development following its mid 90s Copland disaster.

Despite having a significant following of developers behind its desktop platform, Apple hasn’t begun resting on past performance. With the iPhone, Apple didn’t just directly port its desktop Cocoa API, but took the opportunity to refine and rethink how things should work given an entirely new set of circumstances and the opportunity to start fresh. As cited by the SproutCore blog from the Apple document “iPhone Getting Started Docs,”

“One of the biggest differences is the extensive use of properties throughout the UIKit class declarations. Properties were introduced to Mac OS X in version 10.5 and thus came along after the creation of many classes in the AppKit framework. Rather than simply mimic the same getter and setter methods in AppKit, UIKit employs properties as a way to simplify the class interfaces. For information about properties, see Properties in The Objective-C 2.0 Programming Language.”

SproutCore Blog
iPhone Getting Started Docs

Apple’s Cocoa Flavored Open Web.
The company is now pushing Cocoa-inspired development outside of Mac OS X and the iPhone to a broader scope: the web. Apple has already demonstrated its ability to deliver rich web applications with the kind of direct interaction and offline state features normally associated with desktop apps in .Mac Web Gallery, which debuted last fall. After experimenting with a variety of JavaScript framework helper tools to do this, Apple put its resources behind SproutCore.

That has not only allowed Apple to advance its own rich web apps using open web standards, but also to share SproutCore, its Cocoa-inspired, cross platform JavaScript frameworks, under an open source MIT license. That sharing will help provide an open alternative to Flash in the RIA space. SproutCore doesn’t compete against the use of Flash to make animated ads or navigation applets, but rather in deploying full, highly interactive applications, the target of Adobe’s Flash-based AIR platform plans.

One of the biggest announcements of WWDC was Mobile Me, a rebranding of .Mac that aligns it with the iPhone and cross platform users. Apple added a new web calendar and contacts, and a revised Mail and iDisk online file manager modeled after the Finder. The Gallery component of Mobile Me is an update of the existing .Mac version of Web Gallery, which was built using an earlier version of SproutCore.

Apple’s Mobile Me Takes On Exchange, Mobile Mesh

Charles Jolley’s SproutCore.
The SproutCore JavaScript framework was developed outside of Apple by Charles Jolley, originally to create an online email manager called Mailroom. Apple hired Jolley as part of its .Mac team and collaborated to rapidly improve upon his framework.

SproutCore not only makes it easy to build real applications for the web using menus, toolbars, drag and drop support, and foreign language localization, but it also provides a full Model View Controller application stack like Rails (and Cocoa), with bindings, key value observing, and view controls. It also exposes the latent features of JavaScript, including late binding, closures, and lambda functions. Developers will also appreciate tools for code documentation generation, fixtures, and unit testing.

A key component of its clean MVC philosophy that roots SproutCore into Cocoa goodness is bindings, which allows developers to write JavaScript that automatically runs any time a property value changes. With bindings, very complex applications with highly consistent behavior can be created with very little “glue” code.

Cocoa Bindings Programming Topics: What Are Cocoa Bindings?

Oh No, Web Apps?
That makes SproutCore a light Cocoa alternative for deploying web apps that look and feel like Mac OS X desktop apps. At WWDC, Dr. Michael B Johnson of Pixar gave a lunchtime presentation where he pointed out that if you don’t need 64-bit addressing, multithreading, or other desktop-only features, it makes a lot of sense to deploy apps using the web.

But aren’t web apps awful? They historically have been, particularly in the days when every server response required a page load. The development of Ajax technologies, which allow the current page to draw new data from the server asynchronously in the background, has helped. Modern Ajax websites such as Flickr offer drag and drop features, and Google’s use of Ajax in its web apps has made them more desktop-like, but web apps are often well behind those designed for the desktop in terms of a usable interface.

SproutCore helps push things forward; it keeps rich interaction local within the user’s browser and supports offline functionality, making web apps behave more like desktop apps and less like the constantly reloading HTML pages that users dislike. They also look like desktop apps, and in particular can look like Mac OS X desktop apps.

The SproutCore framework also solves a lot of problems for web developers. It takes care of browser incompatibility issues to run cross-platform in Safari, Firefox, or Internet Explorer 6/7. It also makes it easy to leverage the fancy CSS features of modern browsers.

A Front End to WebObjects, WebDAV.
SproutCore also delivers the premise of thin client computing, where applications all run remotely from a back end server and therefore don’t need to be installed or managed on every client.

The disadvantage of thin client apps is that they have typically offered minimal functionality due to the weaknesses in thin platforms such as the web. SproutCore solves this by relying on modern web browser features, which are now sophisticated enough to enable thick client web apps.

SproutCore web apps also combine the power and flexibility of web services with the advantages of client-server computing, prompting Apple to refer to the new model as “web client – server.” In Mobile Me, its new web apps tie into web services vended by WebObjects and WebDAV servers, but anyone can build SproutCore web apps that tie into PHP or any other existing servers that offer up data in XML or JSON objects.

Cocoa and the Death of Yellow Box and Rhapsody

Thinking Outside the Yellow Box.
If you were waiting for the resurrection of Yellow Box or Cocoa for Windows, stop waiting and start coding. SproutCore brings the values of Leopard’s Cocoa to the web, domesticating JavaScript into a functional application platform with lots of free built-in support for desktop features.

Being based on open web standards and being open source itself means SproutCore will enable developers to develop cross platform applications without being tied to either a plugin architecture or its vendor.

Sitting on top of web standards will also make it easy for Apple and the community to push SproutCore ahead without worrying about incompatible changes to the underlying layers of Windows, a significant problem for the old Yellow Box or some new Cocoa analog. SproutCore also lives in a well known security context, preventing worries about unknown holes being opened up by a new runtime layer.

Make Apple SaaS.
All of this advances some interesting new potentials. Apple already has a silent lead in the consumer “Software as a Service” market with .Mac; While Google, Yahoo, and MSN have built models around pushing ads to fund their online mail, photos, and other applications, Apple has been quite unique in being actually able to sell its .Mac service to subscribers. Everybody wants to do what Apple is actually doing.

Mobile Me will retarget .Mac to also serve iPhone users, greatly widening its potential audience and putting Apple’s Mac OS X apps in front of a lot of Windows users. In the future, Apple will undoubtedly add new apps to its Mobile Me suite. Will it get into the online Office race with SproutCore versions of its iWork apps, available to both Mac and Windows users? How about an expanded Back to My Mac, with direct home file sharing and VNC Screen Sharing services available over the web?

And what about third parties? Surely there are enterprising developers who’d like to get in on the Mobile Me platform. Apple should consider hosting third party web apps, either bundled as part of the service (and making Mobile Me more valuable) or as additional apps users can subscribe to for a small additional cost. Imagine a Mobile Me version of QuickBooks that offered similar direct web access and mobile push sync with the iPhone.

Apple - MobileMe - Features

Apple – MobileMe – Features

The WebApps Store.
Web developers have often found it rather impossible to sell their services, but Apple can solve this problem just as it is solving the same problem in mobile software. By offering the equivalent of an iPhone Apps Store within Mobile Me, Apple could create a viable subscription market for web apps and web services that worked like an extension of iTunes. In fact, Apple could add a WebKit view in iTunes and use it to display Mobile Me apps to a wide audience, tied right into iTunes for billing.

Of course, Apple doesn’t need the iTunes infrastructure to sell web apps, as it also has Safari for Windows and its apps also run in Firefox or Internet Explorer. If you thought the Apps Store was interesting, a market inside of Mobile Me should really get interesting.

With everyone clamoring over Facebook for offering Flash-like applets as a free service in the high turnover, profitless profile market, perhaps Apple’s ability to serve real applications and web services as a paid service to its highly loyal users who are driving record profits will get some attention, too.

WWDC 2008: New in Mac OS X Snow Leopard
Myths of Snow Leopard 1: PowerPC Support — RoughlyDrafted Magazine
Myths of Snow Leopard 2: 32-bit Support
Myths of Snow Leopard 3: Mac Sidelined for iPhone
Myths of Snow Leopard 4: Exchange is the Only New Feature!
Myths of Snow Leopard 5: No Carbon!

Cocoa for Windows + Flash Killer = SproutCore
Apple’s other open secret: the LLVM Complier

Ten Big New Features in Mac OS X Snow Leopard

I really like to hear from readers. Comment in the
Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , , , ,

  • droughtquake

    Too bad lazy website developers will continue to overuse Flash. And only test their sites on Explorer.

  • Pingback: Under The Bridge » Blog Archive » WWDC Reflections()

  • Pingback: Cocoa for Windows + Flash Killer = SproutCore()

  • Michael

    nice article daniel. now if this sproutcore could actually get some attention from the rest of the media, we’re on our way to great web apps with no future for microsoft in the picture :) but even if apple uses it, it’s not likely that most tech reporters will pick up the fact that it will end up using something like sproutcore.. since apple usually is pretty secretive about how its stuff works under the hood :( anyway, you can always hope :D

  • blacktalonz

    I didn’t see you really dive into the back end opportunities for Apple. The thicker the client the more opportunities for Apple to build in advanced functions in OS X Server to make it really stand out.

    A really awesome set of server tools geared toward bringing painless and intuitive Advanced SproutCore support would be extremely nice.

  • blacktalonz

    Thicker does not really describe what I mean, not thicker in the sense of client side operations, but thicker on features of the web apps.

  • dicklacara

    OK, I may be a bit dense here, but I don’t see the tie-in to Cocoa.

    I finally gave up, today, and decided to learn Cocoa/Objective-C programming. Will this help me with the web programming this article discusses?

    I have programmed web sites using pure JavaScript, Perl, ColdFusion and some PHP.

  • dicklacara

    Actually, what I really want to do is program for the iPhone platform. There was a limited (because of NDA) discusson on another web forum of a new method of developing iPhone Web apps that approach the speed/capability/appearance of native iPhone apps.

    Is SproutCore the vehicle for delivering this new class of iPhone web apps?

  • lmasanti

    “A really awesome set of server tools geared toward bringing painless and intuitive Advanced SproutCore support would be extremely nice.”

    Apple already has WebObjects (full Java, so should be able to run in almost any server) and has put a lot of attention on Ruby on Rails.

    These can be the “backend engines” of choice.

    But I think that the most important part would be a tool (iWeb?) to easy develop the apps.

    Robert X. Cringely (“MeMobile, You Kaput: Apple’s plan to take over the world”) has a similar prediction and the suggestion to Apple to buy SalesForce.

  • Pingback: MobileMe? - MacNN Forums()

  • Pingback: Platform Problems « what?()

  • Pingback: 5 Days Ahead » Cocoa for Windows + Flash Killer = SproutCore()

  • L

    I tried that iPhoto like demo on SproutCore. It’s slow! These apps might do better with out all the browser. Create a webkit runtime to run the RIAs without the browser UI.

    Alternatively, take Yellow Box all they way down to the kernel/metal so it doesn’t depend on Windows, Linux or the OS, except for drivers. I call it pseudo-virtualization. The trick is to not saturate the CPU like Flash. There’s already a project that provides the Linux desktop experience installed as a screen saver.

  • Pingback: Air Supply » Blog Archive » Cocoa for Windows + Flash Killer = SproutCore()

  • Pingback: Following Apple on the road to rich web apps | Apple,iPhone,Mac,iPod()

  • lmasanti

    A remainding question:

    News on Safari 4 speaks of a way to “Save this page as a standalone web app”.

    Is this the answer to AIR, Gears et al.?

    In other words: Will I be able to make a desktop app out of a [series of] web pages, including SproutCore, SQLite access and more?

    (Of course, this maybe is the big reason behind the optimization of JavaScript in WebKit.)

  • http://www.roughlydrafted.com danieleran

    email from a reader:

    “There are few blogs I read “cover to cover”, however your post about SproutCore reminds me yet again why RDM is on that exclusive list in my RSS reader. Your analysis is in another league from the regurgitated press releases of the mainstream computer media (or the vapid ramblings of the many “Captain Obvious” bloggers around the net). It wasn’t until I read your post about SproutCore that the fog lifted and I finally “got it”.

    For a while I’ve been scratching my head as to why Apple would port Safari to Windows and by implication, take on Firefox. It just didn’t make any sense to me at all. They seemed way out of their element on that one. Furthermore, it didn’t make sense why they were making such a big deal about Javascript performance in the newest versions of Safari. It STILL didn’t click when I read an article the other day about how the webkit developers have a roadmap for making Javascript even faster. I could tell I didn’t have the full picture, but I just couldn’t get my head around it. All of this makes sense now. It’s always bothered me that Apple has had a bit of a blind spot when it came to the web. Many of their web-based efforts seemed to be a bit half-hearted and not up to the quality of their desktop commitments.

    Now however, it all makes perfect sense. Cross-platform Safari is Apple’s insurance policy to keep all the other web browsers honest and force them to compete. This ensures all browsers have sufficiently suitable javascript engines to run Apple and 3rd party web-based apps. By themselves, web-based apps don’t help Apple. However, the existence of web-based apps that automatically work with the iPhone drives more customers to the product (and opens the door for other Apple hardware products in the future). This is also why Apple was so reluctant with the iPhone API: Because they know it’s probably already the “Carbon” of the iPhone platform.


  • Pingback: seriouslymac » Blog Archive » Following Apple on the road to rich web apps()

  • dicklacara

    To take that question a little further, will the saved page (with proper authorization) have access to the underlying file system and CLI (as possible in some Wigets).

    If the answer is yes, then the desk app nee web app can be a powerful surrogate for almost anything that the underlying OS can do– restart, shutdown, format drive…

  • Pingback: Following Apple on the road to rich web apps()

  • lmasanti


    Joining our comments with Mike’s (cited by Dan) I can see that in the future we will able to start Safari on Windows, go to a site and save it as a stand alone app on Window’s desktop.

    That’s the Trojan Horse that Apple is building!
    Program to the PC/Solaris/BSD/Linux programming only to Mac OS X!

  • labrats5

    I finally get it; the reason why Apple is pushing so hard to have the Web be open source, and why they are now so keen on making rich internet apps (RIAs). It’s not even just to protect their own platform from being killed by dropped proprietary support: it’s an indirect attack against Microsoft Windows.

    There are two faces to any OS: the OS as a program and the OS as a platform. Now, Apple seems to have quite the advantage when it comes to the program side, which cares about security, usability, speed, features and the like. But all of OS X’s advantages as a program are completely overshadowed by Windows’ advantage as a platform. There is simply a far bigger and more entrenched ecosystem built around Windows.

    Although Apple does care about it’s developers, it knows that it will never be able to directly take on Microsoft’s ecosystem. Apple’s recent moves, such as not including Carbon 64-bit support, show very clearly that they care far more about OS as a program than as a platform. That move screwed over Adobe big time, but allows Apple to build a smaller, tighter OS.

    So is this an admission of defeat from Apple? Are they relegating their OS to niche status that will run great but barely run anything? Of course not. Apple realizes that the de facto platform of the future won’t be Windows or OS X, but the internet. Up until now, writing an internet application meant sacrificing features and usability for the ubiquity of running on any machine anywhere with user specific data and settings backed up and always accessible. If MobileMe is any indication, now you can have your cake and eat it too. And if Safari really does let you save web pages as apps, then you can even use web apps when not connected to the net (although the manipulated data obviously won’t be backed up online).

    Apple desperately want RIAs to take over, and wants them to use open standard so that they can run on any browser. Microsoft failed to take control of the net through the proprietary nature of IE6 because Mozilla captured enough market share to force web sites to be platform agnostic. If Microsoft or Adobe is able to push their RIA platforms to monopoly status, they could kill off Mozilla and Safari at a whim.

    But what if the opposite happens? What if RIAs are built off open standards and have all the functionality of client apps? Well, then the OS as a platform ceases to matter. Microsoft Windows becomes a program first, plaftorm second, and now all those huge flaws are brought into greater relief. OS X ‘s vast superiority as a program becomes all the more important and apparent, and there aren’t very many good arguments left against switching to it.

    Yes, I know it sounds farfetched, but for many non-power users this is already becoming a reality. My Mom and Dad spend all of their computer hours either in the browser or in Microsoft Word. What happens when a great Web alternative to Word shows up? They don’t need or understand half the features in Microsoft Word, but being able to edit and print documents from any computer without having to email them, while backing up all their documents is a feature that they can understand. What hold does Windows have over them anymore? Nothing! Millions of people are in the same boat, with only one or two key apps keeping them tied to Windows. What happens when those apps go online? OS X and Windows shed their platform, and stand as programs to be compared feature by feature. And who do you think will win that battle?

  • lmasanti

    “What if RIAs are built off open standards and have all the functionality of client apps? ”

    I think that this is the direction taken by Apple and Google. And that appears to be a “winning team”!

    Will Apple need to develop MobileOffice? (RIA counterpart of iWork?) Maybe not. Just get into Google Apps.
    Also, there would be a lot of new possibilities on social networking to be added to MobileMe.

  • Pingback: otherslikeyou.com » RIAs()

  • Pingback: Jon’s Blog » Following Apple on the road to rich web apps()

  • Pingback: Following Apple on the road to rich web apps - Apple.CooOne.Com()

  • Pingback: links for 2008-06-16()

  • Pingback: Mac Fanatic » SproutCore - Feature Rich Javascript Framework()

  • Pingback: Cocoa for Windows | Technology Blog()

  • Pingback: Cocoa for Windows + Flash Killer = SproutCore: Apple JS Framework » D' Technology Weblog: Technology, Blogging, Tips, Tricks, Computer, Hardware, Software, Tutorials, Internet, Web, Gadgets, Fashion, LifeStyle, Entertainment, News and more by Deepak()

  • Pingback: The Strange Tale of MobileMe and Apple’s Post-PC | TightWind - Kyle Baxter()

  • Berend Schotanus

    Well done, good article!

  • Pingback: Rod Drury > Sproutcore()

  • Pingback: Could the 2.0 software have flash support!? - The iPhone Blog Forums()

  • Pingback: Cocoa for Windows + Flash Killer = SproutCore (Danieleran/Roughly Drafted) | NewsMeToday()

  • Pingback: محمد احمد ملياني ::: » مفاجئات تتفجر من خلال WWDC()

  • http://unscriptable.com unscriptable

    Wow Dan! Great article!

    A couple of months back I asked you to shed some light on how Apple and Google were going to fight against Silverlight (for exactly the reasons you state). This article not only reinforced my beliefs and hope for Google’s plans, but opened my eyes to how Apple is joining the effort!

    I knew Apple wouldn’t stand by idly, but I had no clue about SproutCore! Big eye opener!

    (Btw, I am a Javascript/HTML/CSS programming guru. I spend my entire day with dojo, prototype, and other javascript platforms (having written two proprietary platforms for Fortune 500 companies, as well.)

    Safari 3 and FF3 — with their support for offline use and OS-level integration — are poised to blow Web 2.0 (Web 3.0?) wide open and into our daily life.

    Exciting times. :-)

  • Pingback: » CrisDias weblog()

  • Pingback: Apple's open secret: SproutCore is Cocoa for the Web - MacTalk Forums()

  • Pingback: SproutCore: Apple’s Flanking Move? » Alex Jones()

  • Pingback: What’s All the HubBub? Roughly Drafted Article on SproutCore… Some Key Points to Consider | Visualrinse | Design and Development by Chad Udell()

  • Pingback: Dragonchasers » SproutCore a Flash killer?()

  • Pingback: Tomblogg » Blog Archive » links for 2008-06-16()

  • MikieV

    Kind of amusing to remember Microsoft’s intent to “cut off Netscape’s air supply” to prevent -just- this sort of cross-platform, browser-based assault on Windows…

    Microsoft may have won the “browser wars”, but it only delayed the inevitable.

  • http://tech.shirl.com Bill Shirley


    seems to be down all morning (Jun 16),
    that’s not promising,

  • Ajay

    Great analysis, thanks for sharing it! Apple’s efforts with Safari make perfect sense now.

    Keeping webkit open also ensures that opensource crowd will port it to every conceivable platform there is in due course.

    As application built with SproutCore and similar frameworks emerge, it’ll take away the pain of being stuck to a particular OS.

    It increasingly looks like standards compliant browsers and frameworks are becoming a platform by themselves. Apple’s entry into the scene legitimizes the platform.

  • http://johnsessays.blogspot.com John Muir

    These big view articles are always the best, and I take my proverbial hat off to the comments here as well. How come most of the rest of the Mac web yawned at Mobile Me? Oh, of course, because they didn’t get their xMac and tablet…

    Looking forward to RDM’s future transition to a rich environment!

  • http://coderad.net StrictNon-Conformist

    Let me throw in a devil’s advocate thought into the fray: if the frameworks works in JavaScript and is purely open-source available to all takers, what makes it valuable for keeping/drawing people to the Mac OS when all applications that can run on the platform are OS-agnostic, with the only differentiating thing being that if you run an application on a native OS API as opposed to JavaScript, it can do more and be faster?

    At this point, the only real differentiating factor is the potential for a reduced user tweaking quotient (UTQ) requirement for the underlying hardware and OS, as that’s the biggest difference at that point. If you love to tweak stuff and work with the nitty gritty details, Linux (depending on distribution) may force that, and Windows has its own level, and OS X has a certain amount. What this may mostly provide is more of a portable way to integrate iPhones/iPod Touch and their full-sized Macs.

  • Pingback: Javascript News » Blog Archive » SproutCore: Being talked of as a Flash killer? Really?()

  • Pingback: Sproutcore « Laurent’s Weblog()