Skip navigation

I’ve been intentionally learning how to develop using Sproutcore for about a month now, so I’ve been more aware of the buzz about it, and I have to say that most things I read are missing the point about the value promise of Sproutcore.

The impetus behind my learning is that it is an application development framework for the HTML5/JavaScript platform, versus the Flash Platform that I’m used to developing for. The key here is that it is an application development framework. It is not another DOM access library, widget set, or MVC, and it shouldn’t even be compared to them. It’s not a “Flash-killer“. It’s not even a “Flex-killer” per se, although in my mind it is an alternative in part.

Flash is just a display technology. Flex boils down to just a widget set and bindings library. Intrinsically, Flex lacks a good application development pattern. That’s partially why Seppuku is a viable alternative to maintaining the average Flex app built by someone else. There’s no built-in MVC, or unit testing strategy or IoC methodology.

I realize that Adobe’s building in support for FlexUnit4 in Flash Builder 4 / Flex 4 SDK which is wonderful. Michael Labriola et al are doing a fantastic work there that is critical for the Flex project. These necessessities have been the mother of invention with MVC frameworks like Cairgorm, Mate, FlightFramework, and HydraMVC for MVC. Lack of IoC has also inspired Mate, and Flight, as well as the excellent Swiz framework, and the DI part of HydraFramework. And, don’t even get me started on server interaction complexities.

I say all that to illustrate that the Flex development stack really fundamentally consists of Flash -> Flex (widget set, bindings, themes) -> MVC -> IoC -> Unit Testing -> Development environment (IDE, code tools, code gen) -> Support (documentation, community). I feel like that stack is essential to consistently producing good applications built using the Flex SDK, and I think other companies realize this too.

If you look at what Microsoft is doing with Silverlight, they are positioning themselves to own that stack, and not only that, but they have the advantage of not being the first in that they can fix all the things that Adobe has done wrong. It all looks really promising except for a few things, which I’ll discuss in a moment.

Let me begin by saying that contrary to popular belief, I don’t necessarily enjoy being married to Adobe and the Flash Platform. I really do embrace the ideology of an open, standards-driven web. The market has helped drive Flex because you really could deliver a richer “desktop-like experience” on the web, spawning the RIA buzzword. HTML5 and browser implementations are undeniably slower to progress than a company-owned platform like Adobe has. It was the evolution of Flash as a vector graphics rendering plugin for graphically fun and interesting content that facilitated it’s insane propagation, not it’s ability to draw text inputs and combo boxes.

Ok, back to Silverlight. First bad thing: you are locked into Microsoft. That’s a bad thing, just like being locked into Adobe is a bad thing. However, I would argue that specifically for web development, being locked into Microsoft is better than being locked into Adobe. They own the whole stack, and if you drink the MS Kool-Aid you never have to really leave Visual Studio. Also, Silverlight plays much nicer than Flash with the HTML DOM, which means you as the developer have a greater level of flexibility in how you implement Silverlight as part of your solution.

Second bad thing: you have to work in Windows. It’s not just that I really dislike working in Windows; it’s more that I dislike that I’m forced to. At least Adobe provides Windows, Mac, and (kinda) Linux support for their IDE and Player. I sincerely believe that a web development platform should be OS agnostic.

Ok, wasn’t I writing about Sproutcore? Oh yeah. I’m already way past the tl;dr threshold for most people, but there’s a lot to blab about discuss. All that background was to make the point that an application development platform is more than the display layer and widgets, and even goes beyond the language you’re using. I beleive the fundamentals of an application development platform are:

  1. A prescriptive methodology: You or other developers need to be able to look at your source and not have to figure out how you’ve interpreted solutions to basic problems.
  2. Consistent development workflow: You or other developers should be able to intrinsically understand how your application can be scaled or altered as it evolves.
  3. MVC methodology: You or other developers should be able to intrinsically understand how your application separates concerns.
  4. Data access consistency: You or other developers should strive to unify data access methodology so that applications are easier to debug regardless of server technology.
  5. Unit tests: The application platform should provide a way of structuring unit tests for all aspects of the platform, including establishing Fixtures for data access logic.
  6. Build tools: Scaffolding, configuration, etc. tools should minimize “monkey work” and give the developer the ability to go from thought to implementation as quickly as possible.
  7. Good documentation: it goes without saying that docs should ideally help the new learner ramp up, and serve as a reference to experienced devs.
  8. Helpful community: I could write an entire post about this one based on my experiences in the Ruby community, but it is critical to have mentors and people who are willing to accept that fact that you are an annoying little n00b and require hand holding like a little child as you ask questions and sound like an idiot for a few days. Also, when you are off the teet and developing like a madman, you need intelligent people to bounce ideas off of. If you go from n00b to the smartest one in the community in a week, you’ve got problems with the community.

Granted, I’ve only been evaluating Sproutcore as I’ve been finding time around regular work, holidays, and spending time with my family, but I’m definitely over the 0 – 1 level of proficiency and actually starting to build things and ask real questions, and I can say that so far, when I need to do something, it feels like Sproutcore has provided for it in a very logical way. All my personal requirements for a good framework are accounted for. I’m not going to port HydraFramework to Sproutcore, because it’s unnecessary in Sproutcore; it already has a wonderful MVC and bindings methodology. I’m not scrounging for a unit testing methodology; it also has been provided for. Skinning / theming couldn’t be easier. Build tools are great. I can develop on my 486 running Ubuntu if I wanted to. There’s always someone idling in #sproutcore who is helpful. The docs are great. It may not have achieved feature parity with the Flex development stack yet but it shows tremendous promise.

So again, the question isn’t Sproutcore vs. jQuery. In fact, you can (and probably will) use jQuery if you develop Sproutcore apps. The question really isn’t even Sproutcore vs. Flash vs. Silverlight, but it’s so easy to frame it up like that. The point of Sproutcore is that it provides the beginnings of an end-to-end application development strategy in HTML5 that competes with Adobe’s Flash Platform (Flash + Flex + Cairngorm + FlexUnit) and Silverlight’s presentation layer and tools.

There are a few additional things I want to point out. I’m not saying it’s the only way by any means. You can write an open standards desktop experience using any recipe you’d like. Maybe my point is that I feel that choosing an application development platform is more than the sum of its parts.

I have also been evaluating Cappuccino by 280 North. For all intents and purposes, it competes directly with Sproutcore, and I’m not blatantly ignoring it. However, my #1 hangup with it is the Objective-J abstraction. I understand using Objective-C for Cocoa development. I understand JavaScript for web development. But to me, I see not much more than a syntactical advantage for Cocoa developers as the point of Objective-J. For me, it makes more sense to stick with JavaScript as JavaScript. I’m going to try to keep my eye on it, especially the Atlas project.

I’d definitely be interested in hearing your experiences with Sproutcore or your own recipe for RIA *choke* or Desktop Experience type applications. I’ll also try to post more details as I continue evaluating.

Advertisements

12 Comments

  1. Great overview, thanks a bunch.

    Having never used sproutcore, how would you say sproutcore compares with something like GWT?

    As I understand it sproutcore is more a set of tools to help you write your own application api and widgits?

  2. hackeron: I would say that it really isn’t comparing apples to apples, at least in terms of development environment. GWT compiles Java to deployable JavaScript, and is more of a comprehensive IDE environment in eclipse. Sproutcore, Cappuccino, etc, are uncompiled JavaScript frameworks / abstractions, and while they may provide tools to help you get your work done (Abbot, Atlas, etc), they aren’t required, and you can edit code in any editor and see immediate results.

  3. Regarding your comment of “Second bad thing: you have to work in Windows”

    – For Silverlight development you can use either Visual Studio OR Eclipse with the Silverlight tools installed. So you can develop your front-end on both Mac or Windows

    – Regarding your backend you could either use Visual Studio on Windows or Mono/MonoDevelop on the Mac/Linux.. although obviously the former will be more fully featured.

    Although another way that I have personally used is to use VMWare Fusion on the Mac in Unity mode and have Visual Studio sitting on the dock. Other than the Windows UI you wouldn’t realize that it isn’t a native application.

  4. Joe, developing Silverlight in anything but Visual Studio is severely limiting. Additionally, virtualizing Windows just to run Visual Studio (which I do for .NET development) is still far from ideal.

  5. Could you tell us more about your experiences with the Ruby community which you alluded to?
    And do you have any experience with the Python community? Any better? I’m not trying to start a flame war or troll, I am just a noob asking for the opinion of another person with some experience.

  6. I’ve read a lot of crap about Sproutcore today but this article is considered, thoughtful and enlightening. You’ve convinced me that it’s worth installing Ruby to give it a try.

  7. I’m in your same boat. I’ve been a Flash/Flex developer almost my entire profreshional career, but I’m intrigued by Sproutcore as it is a little more “the complete package” for me at this point (and so far for the basics its been a cinch to use).

    Unfortunately its really hard to jump right into Sproutcore and I have a feeling its going to be slow moving. There just really isn’t the documentation and support available yet.

  8. My comment comes 6 months after the article, but now find myself where you were in January. Very good article. I’d like to add that what brought me here is slightly different: mobile app development.

    By the end of the year there will be more iPhones, iPads, and Android phones (ie. app-based) than PCs. When that sinks in (to information consumers in general), we will clearly be in search of a way to build solutions once and deploy them to both as mobile and web apps. SproutCore looks as potentially the best way to do this.

  9. Thank you for this insightful article. We too are evaluating Sproutcore for our web application. Good luck!

  10. I agree, and my company builds an HTML5-based application development platform (http://www.springbase.com).

    We love that using open technologies means you can leverage all the cutting-edge work being done around the world on HTML5, JavaScript, CSS, etc., rather than waiting for a vendor to ship something (if ever).

  11. I agree, Sproutcore and other frameworks are beginning to provide end-to-end pipelines. But the keyword there is *beginning*. If Adobe halted all tools development, it would still take years to achieve the maturity set Flash/Flex delivers today. I do feel that Flex has shifted focus more towards desktop/mobile application development. AIR 3 and the ability to package up the runtime with your app or write native extensions makes it (to me) viable for all types of apps without ever touching Objective-C or HTML5.

    Sencha has two offerings with Extjs and Touch. Even with one of the premier HTML5 frameworks, at the end of the day you have to tailor two different experiences. It’s not write once, deploy everywhere. I still favor Flex in the browser and a redirect page to the iTunes native equivalent (cross-compiled from Flex to iOS).


2 Trackbacks/Pingbacks

  1. […] Thoughts On Sproutcore and App Dev In General « lukesh +interactive […]

  2. […] Thoughts On Sproutcore and App Dev In General « lukesh +interactive blog comments powered by Disqus /* […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: