SproutCore 1.10.0 Release Candidate 1

written by SproutCore

The SproutCore team is pleased to announce the pre-release of SproutCore 1.10.0. Version 1.10 is, without a doubt, the fastest and most feature-rich version of SproutCore to-date and includes several new features, internal improvements and bug fixes and is a recommended upgrade for all SproutCore developers.

To install SproutCore for the first time, please visit http://sproutcore.com/install/ for instructions. If you are upgrading from a previous version of SproutCore, simply run the following:

gem update sproutcore --prerelease

Highlights of Version 1.10.0

In this release we dug deep into the core of SproutCore to improve the entire development and runtime experience from start-to-finish. This includes clean-ups of the developer API to improve consistency and memorability, brand new features for automatic layout, transition animations, live updates and more and working through extensive internal refactors of key components to boost speed and reduce memory consumption.

Continue reading

Develop SproutCore on Cloud 9

written by Dave Porter

Contributor & community member Umberto Nicoletti has discovered a great way to develop SproutCore applications – and SproutCore itself – using Cloud 9’s great browser-based IDE for free, any time, and anywhere, including his living room! He’s got a step-by-step guide to firing sc-server off in a Cloud 9 workspace up on his blog; check it out here.

Dispatches From the Edge: Automatic Transitions and SC.View Optimizations

written by Tyler Keating

Version 1.10 is shaping up to be a fundamental advancement of SproutCore as the best framework for creating powerful user experiences on the web.  We’ve already been doing the best of breed practices for creating dynamic web applications for some time.  For example, running in the client, maintaining the application “truth” in code, minimizing touching the DOM and many other practices that keep SproutCore apps as fast as possible.  These features allow you to create extremely complex interfaces that update instantly as the user interacts with them.  However, while instant updates were a major advancement, they can give the interface a jarring feel and therefore the next level of application design is to go beyond instant updates and add “life” or “play” to your user interface with subtle transitions.

As such, SproutCore 1.10 will include a new automatic transition architecture that is so easy to use, developers can actually play around with complex transitions while first implementing a view rather than needing to commit more time to it later.  To do so, you simply specify a transition plugin to use during one of the four state changes: appending, becoming visible, becoming hidden and removing.  To make it even easier, SproutCore includes a few built-in transition plugins: SC.View.FADE, SC.View.MOVE, SC.View.BOUNCE, SC.View.SPRING and SC.View.SCALE and it’s very easy to write your own transition plugins to do any type of advanced animation based on the SC.Transition protocol.

Continue reading

classNameBindings: Dynamic CSS classes made easy

written by Dave Porter

As a mature framework, SproutCore is full of little features to make common tasks drop-dead simple – including some hidden gems. I recently added some documentation to the framework (and to the indispensable docs.sproutcore.com) for one of them, and wanted to highlight it here on the blog too.

Dynamically adding and removing CSS classes on a view is a common need — for example, to swap background images when a property changes. But there’s no obvious way to do this; I burned my share of time trying to crack it manually, and I’ve watched other devs do the same. The usual solution ends up being a custom renderer, but that’s messy and verbose, operates at the wrong level of abstraction, and opens the door to all kinds of bugs if you’re not intimately familiar with the render API.

Enter classNameBindings. It’s is a quirky but powerful little property that makes dynamic class names a breeze. (No relation to the convenience key format fooBinding, by the way.) Here’s what classNameBindings looks like:

Continue reading

SproutCore 1.9.2 Released

written by Tyler Keating

We are pleased to announce the immediate release of SproutCore 1.9.2.  This release contains important fixes to the 1.9 code-base and is fully backwards compatible.  We recommend that all users of SproutCore upgrade to this latest version in order to have the best development experience.  To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

Build Tools

  • We’ve softened the build tools dependency requirements from being ultra-pessimistic (i.e. within the minor version) to being just pessimistic (i.e. within the major version).  This helps to prevent Bundler conflicts.
  • Fixes the snake case generator for ‘sproutcore gen‘, so that names like ‘SCProject’ get properly transformed to ‘sc_project‘ and not ‘s_c_project‘.
  • Fixes the ‘$repeat: repeat‘ property used with the @slice SCSS directive when generating the @2x version.  It was incorrectly appending @2x to the end of the whole path (ex. /resources/images/image-sliced-from.png@2x) instead of inserting it before the extension (ex. /resources/images/image-sliced-from@2x.png).
  • Fixes incorrectly named “responder” generator to “state” generator for generating SC.State subclasses.  You can now generate an SC.State file using ‘sproutcore gen state‘ or ‘sc-gen state‘.
  • Added support for un-prefixed background-size CSS attribute when spriting.  This allows spriting to work properly in retina Firefox.
  • Fixes inconsistencies and improper syntax in several templates created with ‘sproutcore gen‘.  Generated files are now cleaner and provide more descriptive help comments.
  • Fixes missing stylesheet warnings on a clean app generated with ‘sproutcore gen app‘ or ‘sproutcore gen statechart_app‘ by adding a default stylesheet to the app. Also adds a default stylesheet to a design, when using ‘sproutcore gen design‘ (i.e. creating an SC.Page resource).


  • Fixes regression in IE7 and IE8 which caused XHR requests to fail to notify.
  • Fixes improper binary search used by SC.ManyArray.prototype.addInverseRecord that resulted in an infinite loop when using addInverseRecord with an orderBy function.
  • Fixes bug that allowed the context menu to appear regardless of overriding contextMenu in a view or setting SC.CONTEXT_MENU_ENABLED (globally) or isContextMenuEnabled (on a view) to false.  This makes the context menu event handling behave the same as the key, mouse, etc. event handling.
  • Fixes actions: insertNewLine, deleteForward, deleteBackward, moveLeft, moveRight, selectAll, moveUp and moveDown to be always handled by the SC.TextFieldView element when it has focus.
  • Fixes the hint value for SC.LabelView so that it will appear when the label has no value and isEditable is true.
  • No longer modifies the underlying items given to an SC.SegmentedView directly so that we don’t dirty the original objects.
  • Fixes debug files being included in builds. These files (one of which is a 2.5MB test image) would get included into every build, because they were at the wrong path.  These files should not ever be loaded in an app, but if you created an app manifest based on the contents of the built static directory, you could invariably cause the client to download over 2.5MB of files that are never used.
  • Fixes determination of touch support in Chrome on Win 8.
  • Adds missing un-prefixed border-radius rules to the default theme for browsers that have dropped the prefix.

As always, every bug fix includes an accompanying unit test to ensure that the bug does not re-appear in the future.

Dispatches From the Edge: Super Fast Collections

written by Tyler Keating

One of the most advanced changes coming in 1.10 is the formalization of a major enhancement to SproutCore’s collection views.  Some of you may have heard of, used or tried to use the SC.CollectionFastPath mixin which gives SproutCore’s collection views, namely SC.ListView and SC.GridView, a massive performance boost.  The performance boost comes from pooling the item view objects, pooling item view layers (i.e. elements) and re-positioning layers using layout styles without modifying the DOM tree.  By re-using objects and elements, we can increase the speed that our collections can update, making gigantic lists perform like butter, even on mobile.

However, using SC.CollectionFastPath was unwieldy and difficult to get working correctly.  Turning it on was not enough, you also had to provide a couple properties on your item view class that were totally undocumented.   Due to the fact that SC.CollectionView is already optimized to create item view objects and layers only for the visible portion of the collection, it could be hard to even be sure that the fast path code was active or not.  This is all changing in 1.10.

We believe that every SproutCore view should be as fast as possible out-of-the-box on every platform and so we’re making these improvements a part of SC.CollectionView directly.  This means that by default, SC.ListView and SC.GridView will be fully optimized without any further configuration.  That said, when creating custom item views, you should properly support render and update.  Since view performance is so important, you should already know how to do this and if you need a good example, check out the custom item views in the new demo in the SproutCore Showcase.  This demo was created to debug this new technology as well as to demonstrate working with gigantic lists.

For now, the feature is still being tested and fine-tuned and any additional real-world feedback is appreciated.  So please check it out on the SproutCore master branch and bring any issues forward so that they can be addressed before release.



For discussion, please use sproutcore@googlegroups.com or #sproutcore on IRC.

Note:  Whereas, before you needed to set properties to turn this on, you have to set properties to turn it off right now.  If for whatever reason, you don’t want to pool elements, you can set isLayerReusable to false on your custom item view and if you don’t want to pool views, you can set isReusable to false as well.

Dispatches From the Edge: Invoking “Next”

written by Tyler Keating

As the 1.10 release nears completion, I thought I’d better start writing about some of the many improvements now, lest the final release blog post would take me two days to write.  A lot of the changes, including today’s topic, were the result of working on big feature additions and discovering that more support was needed closer to the core.  Which brings me to the topic of this post:  SC.RunLoop.prototype.invokeNext. Continue reading

SproutCore 1.9.1 Released

written by SproutCore

We are pleased to announce the immediate release of SproutCore 1.9.1.  This release contains important fixes to the 1.9 code-base and is fully backwards compatible.  We recommend that all users of SproutCore upgrade to this latest version in order to get the best development experience.  To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

  • Fixes a bug that left childView elements in the DOM when they were rendered as part of their parent’s layer and the child was later removed.
  • Fixes improper implementation of SC.SelectionSet:constrain() that prevented the last object in the set from being constrained.
  • Fixes minor memory leak due to implicit globals in SC.MenuPane.
  • Fixes memory leak with child views of SC.View. The ‘owner’ property prevented views from being able to be garbage collected when they were destroyed.
  • Fixes SC.stringFromLayout() to include all the layout properties.
  • Fixes the excess calling of parentViewDidResize() on child views when the view’s position changes, but it’s size doesn’t.
  • Fixes an issue that occurs with SC.ImageView’s viewDidResize implementation, where it fails to resize appropriately.
  • Fixes a bug in SC.Locale that caused localizations to be overwritten by the last language localized.
  • Fixes SC.Request’s application of the Content-Type header. It was incorrectly adding the header for requests that don’t have a body which would cause some servers to reject GET or DELETE requests.
  • Fixes a bug where SC.Record relationships modified within a nested store, would fail to propagate the changes to the parent store if isMaster was NO in the toOne or toMany attribute.

As always, every bug fix includes an accompanying unit test to ensure that the bug does not re-appear in the future.  For further details, please view the complete Change Log.

Recap of Tyler Keating’s SproutCore Meetup Talk – Intro To SproutCore, Past, Present and Future.

written by Tim Welsch

Link to view recorded version of the meetup on Vimeo

Speaker: Tyler Keating – was working as a contractor at Strobe, which got bought by Facebook. He inherited the framework and is currently the Administer of SproutCore. Tyler holds the keys to all the SproutCore assets. Today, Tyler has taken on a leadership role with SproutCore as its Project Lead.

Background on libraries and frameworks: Currently, there are lots of JavaScript libraries and frameworks out there right now. A library can be considered a bunch of code that can be dropped in at any point in the development process and can work with what you have already. It can work with your processes and format structure. A good example of a library would be JQuery. Frameworks, on the other hand, expect a developer to follow its guidelines, process and file structure (structure of its code). Under this definition, SproutCore is definitely defined as a framework.

With a framework like SproutCore, a developer would want to be starting from scratch building a brand new application. SproutCore comes with directories and file structures and expects those who use it for development to put things in certain places, use its bindings, use its build tools, etc.

SproutCore on the “Spectrum” of JavaScript libraries and frameworks, on the far left, you would have a library like JQuery and on the far right, a framework like SproutCore. Very few JavaScript frameworks can be found on the far right, most them fall somewhere in the middle between being a library and a framework. Usually, these middle of the road type frameworks want to provide the M or C of MVC. Many of these frameworks found in the middle and most libraries out there do not have the tight integrations found in frameworks like SproutCore. They also just provide a bit and not a “full picture” so to speak. What you see are that libraries start to group together to more tightly integrate and slowly become more of a full picture.  This happens all the time, but with SproutCore that was the end goal from the start, so the integration is more advanced.

On another spectrum, a spectrum of web applications, on the far left you would have an application like Wikipedia which is basically a page of documents and links while on the far right you would have an application like iCloud, that has animations, very ambitious user experience, loads of data, multiple browsers, etc.  When developers want to design an application, provide localization in multiple languages, SproutCore has this directly built in as well as things like infinite scrolling lists. One could try coupling a bunch of libraries together, but this would become a very laborious effort from the standpoint that you would have to write a bunch of code to do it.

SproutCore: When thinking of using SproutCore to build an app you would want to be starting from scratch. The goal of the app that you are building with Sproutcore should be native-like performance and native-like feel. You want to be able to take advantage of the multiple pieces and build tools that SproutCore offers developers. With SproutCore you can:

  • Combine all your JavaScript
  • Compress your files in a single file
  • Use auto-eaditing for images
  • Properly cache so the app can be installed one time and live for a really long time
  • Take advantage of localization that has been built directly in the framework

SproutCore provides:

  • build tools
  • auto spriting
  • file structure
  • localization strategy
  • highly integrated collection views
  • MVC components
  • statecharts
  • client-side data store that can be queried

SproutCore gives you a lot more pieces than other frameworks or libraries while at the same time tons more  in terms of performance.

Where SproutCore is going? Today the framework is a very full suite with lots of features, components and tools to use. There is no plan to “dumb down” the framework and try to compete with some of the newer frameworks on the market. SproutCore has been around longer with many engineering hours already spent building it out to be better and beyond what is coming out today. The Core Team of SproutCore wants to leverage what they have and continue to build on it. The Core Team wants developers to use SproutCore for building apps that are large scale, long lived and will continue to grow.  Another advantage that SproutCore has is that it has been thoroughly tested and carries lots of support across browsers.

Apple and others involvement:  Apple created SproutCore 1.0 and has been the largest contributor thus far. You can tell Apple spends many many hours on the code making it cross browser compatible, localizable.  I think iCloud is available in over 100 different languages. Apple helps make the framework very professional and has been a really great resource from a testing standpoint. Facebook, as far as anyone can tell, does not have any interest in SproutCore. Eloqua is also one of the major contributors to SproutCore, in particular the excellent client side data store components.

What has happened to SproutCore since the end of Strobe? SproutCore was completely worked on by Apple and its creator, Charles Jolley. Charles was very adamant that it be open source and have a community of support behind it. When SproutCore was under Apple, very few people who were contributing back to the framework. Charles then left Apple and created Strobe which spent a lot of energy building and marketing SproutCore. Strobe was unable to keep going and was eventually purchased by Facebook. As far as anyone can tell, Facebook is just interested in the people behind the framework, not SproutCore itself. So SproutCore was left untended for a couple months. I, who had been working as a contractor at Strobe, then spent the time to keep SproutCore going by collecting the assets, passwords, etc.  Appnovation also stepped in to provide community support. Today, engineering work continues and the framework continues to be built out. Currently in 1.8, with 1.9 out very soon and 2.0 already having some work done on it. With Strobe gone, the marketing and promotion side of things sputtered at which point companies like Appnovation have stepped up and filled that gap.

SproutCore 1.9:  1.9 is essentially just about done. In the past, SproutCore has had versioning problems, so it was hard to know when to upgrade an application built with it. SproutCore 1.9 is backwards compatible with new features releases with a number of bug fixes. It is not meant to introduce any new problems in existing apps. SproutCore 1.9 has a number of styling fixes to the ACE theme so that is works in a lot more scenarios properly, it also provides the introduction of SC.Color which is object for the manipulation of colors and adds XHR2 events.

SproutCore 2.0: The next major release will be SproutCore 2.0 which means its not going to be completely backwards compatible. Strobe’s 2.0 that was in the works is not related to SproutCore. The project got spun off and became EmberJS.  SproutCore 2.0 is going to move to node based build tools because right now the build tools are written in Ruby. This makes it harder for the Core Team to work on the build tools because they have to know Ruby. Additionally, anyone using SproutCore has to have Ruby installed to use the framework when building an application. Thus the move to Node is happening for several reasons most notably because the Node installers are better maintained and Node makes it easier for people to contribute back to the code since they are based in JavaScript as well. The release of SproutCore 2.0 is going to bring about the clean up of the numerous of sub-frameworks (libraries), because several were not maintained well. SproutCore 2.0 is also going to place a major focus on expanding the desktop framework because right now there are number of tablet and phone specific views to be added and we want to add more layout helpers. We are expecting to re-label the desktop framework a UI framework and raise it to higher level standard.  The Core team wants to make it easier and faster and with 2.0, people will be made more aware of all the features and tools that are out there on the 2.0 release through an emphasis on better documentation, guides and tutorials that will be made available online.

To summarize: SproutCore will continue to grow and get easier to use. We also expect it to have a lot less of a learning curve for developers wanting to create really fast and robust applications.

Link to view recorded version of the meetup on Vimeo