Entity view (Content)

Intro To SproutCore Webinar Q&A

By twelsch
Mar. 19, 2013
sproutcore, html5We recently had a webinar providing an introduction to the HTML5 SproutCore framework. We had A LOT of questions during the presentation so we decided put them, along with their answers, in a blog post and share it with everyone. Thanks to Dave Porter, SproutCore Lead Developer & Core Team member, for delivering the presentation and taking the time to provide answers to all the questions that were asked.


  • In front end web development, what exactly is the use of an MVC framework?

This is a great question, which really highlights the new world that SproutCore lives in. Most web application stacks treat the browser as the slow, far-away View layer, and handle the Models and the Controllers on the server side. This makes for a slower, less-responsive, offline-incapable “application” which runs as a series of documents strung together with hrefs. Definitely sub-optimal.

SproutCore’s approach is fundamentally different: it moves the whole of the MVC pattern into the browser, with only data loaded dynamically (into the M part). It acts, and develops, like a native app, and it makes for a much better user – not to mention developer – experience.

  • Is SproutCore seamless with jQuery, HTML5, CSS3?

SproutCore is built on jQuery, HTML5 and CSS3. But those technologies, and the associated years of accumulated web development wisdom, represent a heavy compromise between the Internet’s original (and still very relevant) structure as a network of linked documents, and its recently-burgeoning purpose as an application platform. SproutCore optimizes aggressively for the application case, and leaves behind a lot of document-y cruft in the meantime. It takes HTML5, CSS3 and JS and builds a robust, desktop-quality application development experience on top of them.

As a trivial example, SproutCore follows the same layout convention as every application development framework ever and defaults to absolute positioning of widgets. A less trivial example is SproutCore’s total abjuration of truth-in-the-DOM: since the DOM is the slowest, most memory-intensive part of the whole browser, SproutCore does all its work in the browser’s invisible brainspace (JavaScript) and then paints to the DOM at the last possible instant. All of this makes for very fast web applications — built with both the best of the web, and the best modern application development methodologies.

This question represents a number in the same vein, so I’ll address each of the “web trifecta” directly:

JavaScript – SproutCore is JavaScript, and you’ll be spending your time writing syntactically valid JavaScript. It’s built on top of it, though, and uses the best parts of JS to deliver a better, more robust, more application-y experience for the developer. For example, it introduces a proper class-based inheritance system. (If you’ve spent any time in plain-vanilla JavaScript, you know that JS’s object orientation is a little bit … odd.) So although knowing JavaScript is helpful when learning SproutCore, and is the only real prerequisite for diving in, understanding OO is a great advantage. If you’ve jumped around between Java and C++ or Objective-C (by which SC was originally inspired), with maybe a little of the .NET languages (my own path), then you’ll feel right at home in SproutCore, moreso than you will in other web application frameworks.

CSS – There’s only one difference between standard web-dev stylesheets and SproutCore’s: in SproutCore, element positioning is done in code, not in CSS. This is necessary for some of SproutCore’s more aggressive optimizations. Outside of positioning, SproutCore uses CSS the same way you’re used to. It comes with a very nice default theme called Ace, which gives you all the good-looking widgets that you need; if you want to give your app a distinct look, then extending or replacing Ace is easy and satisfying.

HTML – This is the area where SproutCore differs the most from traditional web development, and for very good reason. HTML, vis-a-vis the DOM, is the slowest, most memory-intensive part of the browser. Done properly (and SproutCore goes to great lengths to do it properly), it’s much more efficient to build your application in the browser’s invisible JavaScript brainspace and paint it into the DOM at the last moment. This is a very different approach than traditional web development, but if you’re willing to think a bit differently, then you’ll find that it’s an approach that’s highly optimized for what you’re trying to do: build world-class, native-caliber applications that happens to live in the browser.

  • What are some signs that a project is an app rather than an appified document?

There are two simple considerations that you can use to decide where your project lands.

The first is whether the information you’re serving up is more document-like, or more data-like. On the document side, think of news articles, blog posts, or recipes. If they’re not changing regularly, then things like bus schedules and price lists can be thought of as documents as well. On the data side are things like dynamic inventory lists, reservation listings, transactional information, stock market prices, and things like that which are likely to change a lot.

The second consideration is whether your users will be passively consuming the information, or whether they’ll be actively manipulating it – whether by searching in a lot of different ways (read-only manipulation) or by actually getting their hands dirty creating and editing new data or documents.

No matter what kind of information you’re serving up, if your users are passively consuming it, then you don’t need an app. And even if your users will be generating a few transactions, for example placing an occasional order on an e-commerce site, then you probably don’t need an app. But if each user is involved with dynamically searching, editing or creating, then you need an app! Even with blog posts: if they’re reading it, it’s just a web page, but if they’re writing it – think, Google Docs – then it can get quite app-y.

  • Is it free or paid? What is the SproutCore licensing situation?

It’s free free free! SproutCore is open-source tip to toe and MIT-licensed for maximum freedom for you and your company. We at Appnovation hope that you’ll consider us for your development and ongoing support needs, and we at SproutCore hope that you’ll consider contributing back to our community, but if you choose SproutCore, you’ll be using it under a free, perpetual license.

  • We have some pretty heavily visited online properties, can sproutcore handle that kind of traffic? Are there any high-traffic sites that use SproutCore?

SproutCore actually builds out the absolute best-case scenario for high traffic sites. Your application’s static files are packaged for maximal cacheability, and more of your application is static than with any other framework or stack. Meanwhile, the dynamic side is kept to the absolute minimum: data only, and preferably with RESTful JSON (although it’s trivial to build in support for any weird legacy APIs). So the majority of your app loads off of Apache, for example, while the Ruby or Python side is doing what it does best and serving bare bones data. Each part is as lightweight as possible.

I recently completed work on a web ebook reader for Kobo Books, Inc., which is the third- or fourth-largest ebook vendor. You can check it out at read.kobo.com. SproutCore’s primary corporate backer is a little company called Apple Inc., and their property icloud.com serves as a web extension for iPhone, and actually as a web version of their iOS operating system. If you’ve got an iPhone and an iCloud or iTunes account then you should check it out to see what SproutCore can really do.

  • Does SproutCore support any templating systems?

SproutCore sports a very powerful, highly optimized custom view API which gives you direct control over the DOM creation process – if you want it. (If you’re familiar with Backbone’s approach, ours is similar.) You can use this control to leverage the templating engine of your choice, and we encourage you to!

  • How does SproutCore integrate with, or compare to, HTML5 "native apps" for mobile devices built with PhoneGap/Cordova?

SproutCore is a powerful addition to the PhoneGap stack! With a SproutCore app wrapped in PhoneGap, you can turn your app from “native-caliber” to native-deployable via the iOS, Android and BlackBerry app stores. It’s 2013 and everybody everywhere has gotten behind the promise of the open web; PhoneGap/Cordova helps take your app the last step of the way to native.

  • Does the framework support a data persistence layer?

SproutCore’s data layer (the M in MVC, if you will) is very robust. Along with actual models, there’s a queryable data store in memory, and a data source for interfacing with any kind of API you might have to work with. The data layer is one of the banner application development features that SproutCore ports over from the desktop world.

“Data persistence” can refer to two different types of local storage: session, and long-term. If you’re rapidly reloading full pages from the server every time local state changes enough, then storing session information locally is very useful. But SproutCore applications are different: they run as true persistent applications, so you don’t need to do anything special to store data for the duration of the session – its whole data layer is just there, the whole time!

In terms of long-duration state storage, SproutCore has a really nice wrapper around localStorage (including a fallback for older browsers); for bigger data, we plan on adding support for IndexedDB & WebSQL soon (as soon as the standardization and market penetration get to the right spot).

  • Is it similar to Sencha ExtJS?

I haven’t used Sencha, but yes, the promise of a fully client-side MVC app is the same. SproutCore’s optimizations are more aggressive from a DOM-avoidance perspective, and of course SproutCore is MIT-style Free and Open Source!

  • Can you talk about the development environment? Is it possible to jump from a LAMP stack into SC?

Yup — SproutCore is generally deployed on a LAMP stack. The Apache layer serves up the static files (packaged for maximal cacheability, easing the burden on your static servers), while the P layer of your choice serves up bare bones data for client-side consumption. You’re going to be building your application differently than a standard out-of-box Django, PHP or Drupal site, but the same skills apply.

  • Does it come with pre-built widgets like datagrid, charts?

SproutCore’s view layer is chock full with desktop-caliber widgets. Its CollectionView class, and children like ListView, GridView and TableView, are optimized for enormous data-sets with thousands of rows. (SproutCore’s promise of a 100,000-item list view at the same speed, with the same memory footprint as a 10-item list, is one of its banner features, and I’ll be giving another presentation soon on taking full advantage of it.) There aren’t any plug-and-play chart views in the core framework, but I believe the extended community has some views that may serve your needs, and if they don’t, we hope you’ll commit some back!

  • What browsers do you support?

Everything all the way back to IE7. SproutCore abstracts as much as it can, and we’ve built a lot of backward-compatibility behind those abstractions.

  • Is there a preferred IDE for SproutCore?

SproutCore is JavaScript (and CSS), so you can use anything that can handle that. We all use Sublime Text 2 these days.

  • What about mobile and responsive design patterns, does have support for that?

SproutCore’s layout engine is automatically responsive, in that it encourages you to lay out your application relative to the browser window (or screen, on mobile) rather than building it to a specific width. For more advanced responsiveness, we’ve got a new feature called Design Modes slated for 1.10 which will allow for responding easily and dynamically to different screen widths. The Kobo Instant Reader (read.kobo.com) makes heavy use of an early version of it; I encourage you to take a look.

  • How does it compare to YUI - What about dynamic module loading?

Dynamic module loading is super simple in SproutCore (via SC.Module), and some of the highest-performance apps I’ve seen use it to load less-used parts of the app lazily. SC even preloads them as strings, using a technique that Gmail pioneered a few years ago, when idle.

  • When will a comprehensive book on SproutCore be coming out?

Very soon! The lead developer of SproutCore himself Tyler Keating is writing one now, due for release this summer. He's the best framework-innards guy that I know, and I'll definitely be picking up a copy when it's available.

  • Is there any latency/locking issues with multiple users who are editing same data on the server?

This is of course one of the big challenges of modern applications: how do you maintain consistency between many copies of the same data? There are many long books (and many robust debates on the IRC channel) about this. You’ll have to figure out how best to solve this question for your particular needs, the same as if you were building a Django or PHP app, or a native app backed by the full power of Amazon’s Web Services. Whatever design you come up with, though, SproutCore has the tools (a full-featured data store, data source interface layer, and built-in statechart) to help you build a fast, responsive web application.

  • What do you see coming up in future for SproutCore?

We’re in the middle of a maintenance pass for version 1.10, and a few features will sneak in as well (a new, even faster CollectionView, and the above-mentioned Design Modes). Meanwhile one of our core team members works on the banner feature for version 2.0: node.js build tools! SproutCore has a Ruby legacy, and the build tools (which do some minimal compilation, along with providing SASS and Compass support) are still in Ruby. We’re excited to move the whole stack to JavaScript, a language that all of our contributors are guaranteed to speak.

That’s speaking in terms of features. In terms of market penetration, I see SproutCore’s future as, among other things, the natural successor to Adobe Flex in the corporate-intranet, data-heavy space. In a few years, I expect a lot of folks to be spending their work-days manipulating data in SproutCore instead of Flex or (shudder) Access. On their PCs, Macs, phones or iPads by the way.

  • How do I get involved?

If you’re interested in taking a closer look, head to sproutcore.com to download it and have a look at the guides. We have an active mailing list via Google Groups, and we’re on IRC at #sproutcore on freenode.

Post Tags: