Skip to content

Instantly share code, notes, and snippets.

@erichocean
Last active October 1, 2015 08:38
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save erichocean/83ac249f80f3fbc12855 to your computer and use it in GitHub Desktop.
Save erichocean/83ac249f80f3fbc12855 to your computer and use it in GitHub Desktop.
[ANN] Blossom 1.0.0-beta.1 (SproutCore 3 candidate)

Blossom 1.0.0-beta.1 was released on March 1, 2012. You can learn more here:

https://github.com/fohr/blossom

SproutCore is now in de facto maintenance mode. It's time to re-asses what we, as a community, want SproutCore to be.

As many of you know, Blossom is a serious attempt to advance SproutCore 1.x forward after the failure of SproutCore 2. I put forward the rational behind Blossom in early December, 2011 (http://bit.ly/future-of-sproutcore) and also demo'd early work I had done on Blossom at the SproutCore User Group in Washington D.C. late January, 2012.

Blossom 1.0.0-beta.1 (available today) has:

  • A 100% Node.js native build system, including framework and app distribution and reuse via npm, the Node Package Manager.

  • A completely rewritten view layer built around two new classes, SC.Surface and SC.Layer. Surfaces support GPU-accelerated 3D transitions, and layers are a wrapper in the style of Core Animation around HTML 5's Canvas2D. All drawing in Blossom is done via Canvas2D – you never write HTML or CSS.

  • The latest datastore and statechart code from SproutCore 1.8.

  • The fast, small and stable runtime from SproutCore 1.4.5. In addition, the responder subsystem was fully audited and dramatically reduced in size and complexity.

  • Pervasive use of assertions (sc_assert), node-based unit tests for foundation and datastore, and a specialized "fuzz testing" app for the new view layer that has resulted in extremely robust view handling. SC 1.x DOM-based bugs are hopefully a thing of the past.

  • A much more approachable code base, centered around three frameworks: foundation (node, browser), datastore (node, browser), and application (browser). Blossom re-envisions SproutCore as a "batteries included" framework.

  • Blossom supports the ability to compile a SproutCore app to run natively on mobile devices such as iOS and Android, using a native (not WebView-based) runtime. The first two native runtimes (iOS and Mac OS X) are due on April 1, but you can start writing code now, since the API is identical. [Update: After profiling, this has been abandoned; embedded WebKit is more than fast enough.]

  • No support for mobile browsers (use the native mobile app runtime instead). [Update: After profiling, this has been abandoned; mobile WebKit is more than fast enough (yay!).]

Blossom is designed to become the future of SproutCore, but it also stands on its own. It's amazing how much progress can be made in a short amout of time by people dedicated to advancing the state of the art. I want to take this opportunity to thank all of the people on the #blossom IRC channel who chatted with me endlessly about design decisions throughout Blossom's development. Your feedback has made a huge difference. And also xTuple, without their support Blossom would not have been possible.

Here's the release notes for the beta:

Blossom's API and feature set are now stable enough to begin developing production applications with, and Blossom includes the latest Statechart and Datastore code from SproutCore 1.8.

This is an early beta for experienced SproutCore developers targeting the latest releases of the Google Chrome and Apple Safari desktop web browsers. The public API is 99.9% stable (the only breaking changes going forward will be to accommodate bug fixes).

Only Blossom's application framework differs from SproutCore in terms of the public API (the foundation and datastore frameworks remain unchanged), so the vast majority of your existing knowledge re: how to write SproutCore apps still applies.

Note: Print-to-PDF support is missing, although Blossom's drawing model does support it correctly, so any SC.View and/or SC.Layer drawing code you write today will be supported when Print-to-PDF is enabled in a future release.

Best, Erich Ocean

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment