The problem with SproutCore
Monday, 14 July 2008I’ve been meaning to sit down and this article on SproutCore ever since it shot to fame as the underlying client-side framework used to build Apple’s recently released MobileMe web application. You see, SproutCore seems to have had a falling out with web standards and web development best practices, something that wasn’t getting picked up in all the mainstream coverage it was receiving.
For the uninitiated, SproutCore is a JavaScript framework developed by SproutIt. It was initially developed to enable them to build their Mailroom application, which according to their website is a hosted help desk service for consumer-oriented businesses
. So far, so good. The description given on the SproutCore website makes it sound like the framework is similar to other JavaScript libraries like YUI and JQuery, only a little more focussed on the application as a whole:
SproutCore is a framework for building applications in JavaScript with remarkably little amounts of code. It can help you build full “thick” client applications in the web browser that can create and modify data, often completely independent of your web server, communicating with your server via Ajax only when they need to save or load data.
What the above paragraph only hints at, though, is that SproutCore doesn’t just ignore progressive enhancement — it hacks it into tiny little pieces, urinates all over them and then mails them back to you one by one:
After lots of testing, we have found that the most efficient way to server a SproutCore application is as a … static web page! Once a SproutCore application is loaded into your web browser, it communicates with your backend server using Ajax.
Can you guess what an application looks like with JavaScript disabled? If you said “a blank page”, you can give yourself half a gold star. The unfortunate truth is that what you get is even worse than a blank page - you get a page devoid of any content but with UI controls that do absolutely bugger all. Don’t just take my word for it; check out the check out the SproutCore Photos example and then turn JavaScript off and hit refresh.
I thought we’d moved past this whole progressive enhancement issue back when Jeremy Keith was banging on about it to anyone who stood still for long enough. Alas, it seems there are still some poor unfortunately souls who have yet to benefit from Jeremy’s wisdom.
The total disregard for progressive enhancement is not the only thing wrong with SproutCore. Almost every UI widget and container in the framework is represented by nested <div> elements, differentiated only by their combination of class names. Where semantic elements are used they are used incorrectly (i.e. using <label> for headings). There is no sign of tab-enabling them or WAI-ARIA support, and all of this means that SproutCore applications are likely to be totally inaccessible out of the box.
OK, so SproutCore is bad, but what does all this have to do with Flash? That’s a fair question, given that the main focus of this blog has been Flash / Flex / AIR for the past 3 years. The answer is that the About SproutCore page takes a fundamentally misinformed swipe at Flash, and I’m calling them on it:
Why should I use SproutCore instead of a plugin like Flash or Silverlight?
Nobody likes using software running in a sandbox and no one likes to download plugins before they can use your software. If you want to create an application on the web that is fast, fluid, and native, and usable by everyone, use the only technologies that come built right into every browser: HTML and JavaScript. SproutCore makes it easy to do just that.
It seems that the SproutCore developers may have forgotten that JavaScript also runs in a sandbox, and it’s a great deal more restrictive than the Flash Player. Just try making a cross domain request using JavaScript, or setting up a permanent connection to a socket server, or (as is available in Flash Player 10) run-time access to local files.
They also seem to have missed the fact that the percentage of users unable to see Flash content is significantly lower than those fumbling around the Internet without JavaScript disabled. According to Adobe’s statistics content published for Flash Player 9 is viewable by an average of 97.4% of web users across all markets. That compares very favourably with the 95% of users who have JavaScript enabled according to w3schools.
Oh, and there’s nothing special about SproutCore’s fast, fluid and native
controls - they are no more or less fast, fluid or native than Flash or Flex components. You can make either one look like native operating system controls but that doesn’t mean you should, and speed of execution and layout is down the to the implementation. On the speed front, it’s interesting to note that Mozilla are busy integrating Tamarin (the ActionScript virtual machine built into the Flash Player) into Firefox in order to support ECMAScript Edition 4 and speed up JavaScript execution.
The worst thing about all this for me is that this is the framework that Apple have chosen as the foundation of their MobileMe web application. There are lots and lots of bad frameworks on the Internet, but to see one used in such a prominent application by a company normally very meticulous about application design and user experience is disappointing.
I hope that the SproutCore developers read this article and take on board at least some of the points above. There’s nothing in the framework that cannot be fixed, though fixing the whole progressive enhancement issue is going to require a shifting of the framework’s focus away from 100% client-side application logic.
Hey, I don't think a blanket statement as saying "SproutCore is
Johannes Fahrenkrug | Monday, 14 July 2008 | 3:06 pmHey,
I don’t think a blanket statement as saying “SproutCore is bad” is very professional, just as saying “Flash is slow” would be. At WWDC the creators made clear that SproutCore is not intended to be used for web pages, but for desktop-like applications that simply use the browser as their runtime platform. So having JavaScript turned on is a requirement to use SproutCore applications. But is that so bad? Having Flash installed in a requirement to use Flash applications. So is the one requirement worse than the other? The great (I did not say perfect) part about SproutCore is that it gives you as the developer a way to quickly use the development features that you love from the server side of web development - like MVC, observers and an easy-to-use, built-in testing suite - for the client side of your application.
I think SproutCore has a lot of potential. Easily enabling developers to write testable JavaScript applications is a Good Thing ™. So while SproutCore might not be perfect yet, it definitely deserves a chance.
Johannes: I deliberately tried to stay away from hyperbole in
Steve | Monday, 14 July 2008 | 3:35 pmJohannes: I deliberately tried to stay away from hyperbole in this post, and I feel that the reasons given in the article justify my classification of SproutCore as a bad framework. Some of the things it tries to accomplish (including those you have highlighted) are good things, but in my opinion the negatives outweigh the positives.
Supporting progressive enhancement, web standards and accessibility in a JavaScript framework is difficult but certainly not impossible. The YUI Library isn’t perfect in this regard, but most of the widgets can build their JavaScript representation based on content defined in the HTML document, and they all support keyboard navigation and make sensible use of semantic HTML.
[...] the web browser, what should happen when you turn
SproutCore » Should Progressive Enhancements Be Required for a Web Application? | Monday, 14 July 2008 | 3:45 pm[...] the web browser, what should happen when you turn the programming language off? This is the issue raised by Steve Webster [...]
Thanks for the article. The problem with a Reality Distortion Field
John Dowdell | Monday, 14 July 2008 | 4:21 pmThanks for the article.
The problem with a Reality Distortion Field is that it bites the speaker, too.
jd/adobe
Thanks for your comments, and not to put down your
Charles Jolley | Monday, 14 July 2008 | 6:52 pmThanks for your comments, and not to put down your interpretation of progressive enhancement, but I would point out that you can’t use the techniques YUI uses if you want to build a complex desktop-class app. They are too inefficient on the page for one thing and preclude a fast deployment model (i.e. using all static pages) for another.
If you are building a web site and want to enhance it with some JavaScript, by all means use a widget library like YUI. SproutCore is for building a different kind of app.
To support non-JS browsers (and I think you should do something for them), then use a and tag in the SproutCore app to redirect them to a simple page-driven experience. This is also a good way to address non-iPhone mobile markets.
Progressive enhancement doesn't have much meaning on a web application
Andrew | Tuesday, 15 July 2008 | 2:57 pmProgressive enhancement doesn’t have much meaning on a web application as complex as MobileMe. It would be wasted dev effort to try to make it sort-of-work without Javascript.
For a publishing site with a few extra features (digg, etc)…sure, progressively enhance away. For a hardcore web app (Outlook Web Access, MobileMe, Gmail)…don’t cripple yourself by trying to cater to the outliers, especially if they represent 5% of your potential audience.
The interesting thing about SproutCore is that it looks and feels a lot like Cocoa / ObjectiveC, and abstracts away a lot of tedious stuff. It isn’t right for everything, but for the right problem set it’s a viable choice. It’s also a little slow with release-version javascript interpreters…but FF and Safari are soon-to-release huge improvements there (Tamarin, Squirrelfish), and the number of users using IE on MobileMe is insignificant and probably worth some active discouragement.
Also: 95% vs 97.4% isn’t that big of a difference. The 5% who disable Javascript or have ancient browsers are just going to have to live without complex web apps. HTML5 (FF and Safari very soon, probably not IE8) will also enable local data storage.
I agree that the assertion that “no one likes to download …” is silly. Flash is established, although the versioning can be tricky sometimes. And as you note, slightly fewer people enable Javascript than have Flash. Those are valid reasons for avoiding Silverlight, of course, outside a controlled user population. But not Flash.
The point about sandboxing is also questionable. Perhaps they meant that Flash feels like it’s running in a sandbox, which it does. It doesn’t interact with the DOM, and I think it’s safe to say that doing the whole site or app in Flash has a well-known set of problems.
We know why Apple doesn’t like Flash though — Adobe has been a terrible partner in the Flash world. The OSX plugin is pretty awful. There’s a reason that so few Flash developers work on Macs, and it isn’t because they don’t want to.
I sympathize with Apple’s interest in “seeing other people”, so to speak. The RIA space is very important and contentious…and Apple doesn’t have proprietary tech there, so for them to sign up for more mistreatment from Adobe or Microsoft would be just plain dumb. As a standards geek, I’ll be happy if the answer turns out to be open standards and superior tech in the interpreter.
@Andrew who commented, I'm sorry you're an idiot. I've successfully
Ben | Tuesday, 15 July 2008 | 7:22 pm@Andrew who commented, I’m sorry you’re an idiot. I’ve successfully implemented a very similar version of what apple has done with me.com using progressive enhancement and best practices to great success. To say its OK to turn away users is just plain old stupid.
@Ben who replied, I'm sorry you missed the point.
Andrew | Tuesday, 15 July 2008 | 9:17 pm@Ben who replied, I’m sorry you missed the point. Apple doesn’t have to worry about users that might enjoy progressive enhancement. Firefox and Safari users upgrade their browsers, and Apple doesn’t care about IE users.
SproutCore is great for Apple. Maybe not for you.
If you’re implemented an equivalent service to MobileMe (or OWA, or Gmail) without Javascript or Flash, you’re a rockstar. The world would love to see it. It’s not the problem Apple wants to solve, but mazel tov.
They key is: what captures the imagination of the main
Naseer | Thursday, 17 July 2008 | 6:20 amThey key is: what captures the imagination of the main audience right now… And right now, that’s the developers. Apple’s big push is to move further in that since there are new energies being created and spent in the Cocoa programming environment… for the iPhone, feeding back to the desktop, and now moving to the web. SproutCore plugs into that with MVC, bindings, etc. Making it easy for new developers to jump in is a wise move, because today’s adopters are tomorrow’s providers.
[I know this is a business and people dynamics comment in a tech heavy discussion, but I hope you see the point. And full disclosure: I own the stock!!!]
[...] Webster recently wrote an article about how horribly standards-stupid
SproutCore - Standards Stupid? - McArthur GFX - Standards Compliant CSS Design | Wednesday, 23 July 2008 | 10:56 pm[...] Webster recently wrote an article about how horribly standards-stupid SproutCore (the Javascript framework Apple used to make MobileMe) is. He kind of has the right [...]
I somehow lost interest when reading: "Flash Player 9 is
kenfegore | Thursday, 24 July 2008 | 8:41 pmI somehow lost interest when reading: “Flash Player 9 is viewable by an average of 97.4% of web users across all markets. That compares very favourably with the 95% of users who have JavaScript enabled”
compares favourably?
That is Flash Player 9, not Flash Player 10, which is used as a comparison for its advanced features.
What about Flash being proprietory without any guarantee to supply the same features across all platforms?
What about mobile Flash restrictions and full Flash memory and (for mobiles) battery requirements?
And where is the ‘progressive enhancement’ in Flash applications? It is called the ‘build two sites’ technique, which would equally work for SC.
kenfegore: I'm sorry you lost interest, but the statistics I
Steve | Friday, 25 July 2008 | 8:59 amkenfegore: I’m sorry you lost interest, but the statistics I have available show that Flash Player 9 has a greater reach than JavaScript. The comparison with Flash Player 10 (which hasn’t even been released yet, except in Beta form) was around one specific feature - local file access - and wasn’t a central pillar of this article.
The “Flash is proprietary” argument is actually pretty meaningless these days. Yes, it is developed by a single company rather than a standards body like the W3C, but that could be said to work in Flash’s favour. The pace of change within the W3C is glacial, as is evident by the slow, ponderous pace of the XHTML2 and HTML5 standards. Adobe as a company will only make money if developers build on their platform, and they will only do that if there is sufficient ubiquity in the platform. Unlike the W3C or browser manufacturers, Adobe has a vested interest in maintaining Flash compatibility cross platform. If you want to see evidence of this, you just need to look at the Linux Flash Player, which once lagged behind the Windows and Mac versions by as much as 2 years but is now released at the same time with the same features.
As for cross-platform compatibility, it’s interesting to note that SproutCore’s own compatibility page admits that it will only run on a handful of web browsers and excludes the likes of Opera (very important if you want to try and build mobile applications) and IE6 (the browser with the biggest market share on the Internet today). By contrast, Flash is supported by all browsers that support ActiveX and/or the Netscape Plugin interface, across a range of platforms.
Finally, progressive enhancement is just as possible with Flash as it is with standards-based technologies, and the notion of building two sites has been outdated for a good few years now. See Christian Heilmann’s progressively enhanced Flash charts for a perfect example of Flash progressive enhancement done right.
It should be noted that this article wasn’t pushing Flash application development over SproutCore. It was pushing the concept and virtues of progressive enhancement, which is something that SproutCore fundamentally does not support.
You're a flash guy. I think your response is predictable. I
shaggy | Friday, 08 August 2008 | 8:07 pmYou’re a flash guy. I think your response is predictable. I guess the way i’d state it is sproutcore is just a bad as flash but doesn’t use a plugin. (;
How does the fact that MobileMe costs $99 per year
Steve M | Monday, 18 August 2008 | 12:53 pmHow does the fact that MobileMe costs $99 per year play into this discussion? Doesn’t that in many ways narrow down the audience of possible users? I would guess that a $99/yr service is targeted at a smaller audience than say free gmail, or some other site. How many people willing to spend that much per year for this service are really running a browser that isn’t capable of running these apps?
[...] - bookmarked by 5 members originally found by TakaSohma1
Bookmarks about Plugins | Tuesday, 26 August 2008 | 5:23 pm[...] - bookmarked by 5 members originally found by TakaSohma1 on 2008-08-13 The problem with SproutCore http://dynamicflash.com/2008/07/the-problem-with-sproutcore/ - bookmarked by 6 members originally [...]
Complaining about the lack of graceful degradation is a bit
steviant | Monday, 13 October 2008 | 11:16 pmComplaining about the lack of graceful degradation is a bit rich coming from a Flash developer don’t you think? when Flash’s idea of “progressive enhancement” is a message telling you the equivalent of piss-off if you don’t use one of Adobe’s “blessed” architectures.
The only way to get a worse degradation experience is to use Microsoft’s Silverlight - which supports even less platforms than Flash.
At least it’s possible to get the source to a number of independent working JavaScript implementations without having to hitch your success to the whim of a commercial entity who could decide it to be financially or strategically expedient to cut your air supply at any moment.