Received: by 10.52.35.169 with SMTP id i9mr5955288vdj.6.1331331667673;
Fri, 09 Mar 2012 14:21:07 -0800 (PST)
X-BeenThere: sproutcore@googlegroups.com
Received: by 10.52.166.66 with SMTP id ze2ls5301595vdb.4.gmail; Fri, 09 Mar
2012 14:21:03 -0800 (PST)
Received: by 10.52.38.231 with SMTP id j7mr677385vdk.5.1331331663708;
Fri, 09 Mar 2012 14:21:03 -0800 (PST)
Date: Fri, 9 Mar 2012 14:21:03 -0800 (PST)
From: Dave <dcpor...@gmail.com>
To: sproutcore@googlegroups.com
Message-ID: <29377371.1277.1331331663173.JavaMail.geo-discussion-forums@vbne13>
In-Reply-To: <26f37e79-98b1-4b21-9a99-ef0ec5d5294f@y17g2000yqg.googlegroups.com>
References: <26f37e79-98b1-4b21-9a99-ef0ec5d5294f@y17g2000yqg.googlegroups.com>
Subject: Re: [ANN] Blossom 1.0.0-beta.1 (SproutCore 3 candidate)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_1275_13070546.1331331663171"
------=_Part_1275_13070546.1331331663171
Content-Type: multipart/alternative;
boundary="----=_Part_1276_29365619.1331331663171"
------=_Part_1276_29365619.1331331663171
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Erich,
Exciting stuff. A couple of questions that I don't think have been asked=
=20
publicly yet.
Can you draw a mental picture for me of where the <canvas> element lives?=
=20
Is there one at the root of my application, and the new Surface and Layer=
=20
classes draw UIs to it (and presumably receive routed events)? Or is each=
=20
button, say, now drawn on its own canvas element? I assume the former. I=
=20
certainly love the idea of canvasy UIs, but I'm not interested in ditching=
=20
the existing DOM-based view layer.
Is your rewritten responder subsystem compatible with SC as it is today?=20
Smaller and faster sounds great but breaking does not.
These sound like great things but not necessarily worth starting over from=
=20
scratch for.
Cheers
Dave
On Friday, March 2, 2012 3:11:56 AM UTC-5, Erich Ocean wrote:
>
> The Blossom 1.0.0-beta.1 was released on March 1, 2012. You can learn=20
> more here:=20
>
> https://github.com/fohr/blossom=20
>
> SproutCore is now in de facto maintenance mode. It's time to re-asses=20
> what we, as a community, want SproutCore to be.=20
>
> As many of you know, Blossom is a serious attempt to advance=20
> SproutCore 1.x forward after the failure of SproutCore 2. I put=20
> forward the rational behind Blossom in early December, 2011 (http://=20
> bit.ly/future-of-sproutcore) and also demo'd early work I had done on=20
> Blossom at the SproutCore User Group in Washington D.C. late January,=20
> 2012.=20
>
> The Blossom 1.0.0-beta.1 (available today) has:=20
>
> - A 100% Node.js native build system, including framework and app=20
> distribution and reuse via npm, the Node Package Manager.=20
>
> - A completely rewritten view layer built around two new classes,=20
> SC.Surface and SC.Layer. Surfaces support GPU-accelerated 3D=20
> transitions, and layers are a wrapper in the style of Core Animation=20
> around HTML 5's Canvas2D. All drawing in Blossom is done via Canvas2D =E2=
=80=93=20
> you never write HTML or CSS.=20
>
> - The latest datastore and statechart code from SproutCore 1.8.=20
>
> - The fast, small and stable runtime from SproutCore 1.4.5. In=20
> addition, the responder subsystem was fully audited and dramatically=20
> reduced in size and complexity.=20
>
> - Pervasive use of assertions (sc_assert), node-based unit tests for=20
> foundation and datastore, and a specialized "fuzz testing" app for the=20
> new view layer that has resulted in extremely robust view handling. SC=20
> 1.x DOM-based bugs are hopefully a thing of the past.=20
>
> - A much more approachable code base, centered around three=20
> frameworks: foundation (node, browser), datastore (node, browser), and=20
> application (browser). Blossom re-envisions SproutCore as a "batteries=20
> included" framework.=20
>
> - No support for mobile browsers. Current usage indicates that=20
> SproutCore is a poor fit for mobile browsers at this time, but...=20
>
> - Blossom supports the ability to compile a SproutCore app to run=20
> _natively_ on mobile devices such as iOS and Android, using a native=20
> (not WebView-based) runtime. The first two native runtimes (iOS and=20
> Mac OS X) are due on April 1, but you can start writing code now,=20
> since the API is identical.=20
>
> Blossom is designed to become the future of SproutCore, but it also=20
> stands on its own. It's amazing how much progress can be made in a=20
> short about of time by people dedicated to advancing the state of the=20
> art. I want to take this opportunity to thank all of the people on the=20
> #blossom IRC channel who chatted with me endlessly about design=20
> decisions throughout Blossom's development. Your feedback has made a=20
> huge difference. And also xTuple, without their support Blossom would=20
> not have been possible.=20
>
> Here's the release notes for the beta:=20
>
> > Blossom's API and feature set are now stable enough to begin developing=
=20
> production applications with, and Blossom includes the latest Statechart=
=20
> and Datastore code from SproutCore 1.8.=20
>
> >This is an early beta for experienced SproutCore developers=20
> targeting the latest releases of the Google Chrome and Apple Safari=20
> desktop web browsers. The public API is 99.9% stable (the only=20
> breaking changes going forward will be to accommodate bug fixes).=20
>
> > Only Blossom's application framework differs from SproutCore in terms o=
f=20
> the public API (the foundation and datastore frameworks remain unchanged)=
,=20
> so the vast majority of your existing knowledge re: how to write SproutCo=
re=20
> apps still applies.=20
>
> > Note: Print-to-PDF support is missing, although Blossom's drawing model=
=20
> does support it correctly, so any SC.View and/or SC.Layer drawing code yo=
u=20
> write today will be supported when Print-to-PDF is enabled in a future=20
> release.=20
>
> Best, Erich Ocean
------=_Part_1276_29365619.1331331663171
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<div>Hi Erich,</div><div><br></div><div>Exciting stuff. A couple of q=
uestions that I don't think have been asked publicly yet.</div><div><br></d=
iv>Can you draw a mental picture for me of where the <canvas> element=
lives? Is there one at the root of my application, and the new Surfa=
ce and Layer classes draw UIs to it (and presumably receive routed events)?=
Or is each button, say, now drawn on its own canvas element? I=
assume the former. I certainly love the idea of canvasy UIs, but I'm=
not interested in ditching the existing DOM-based view layer.<div><br></di=
v><div>Is your rewritten responder subsystem compatible with SC as it is to=
day? Smaller and faster sounds great but breaking does not.<br><div><=
br></div><div>These sound like great things but not necessarily worth start=
ing over from scratch for.</div><div><br></div><div>Cheers</div><div>Dave<b=
r><br>On Friday, March 2, 2012 3:11:56 AM UTC-5, Erich Ocean wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">The Blossom 1.0.0-beta.1 was released =
on March 1, 2012. You can learn
<br>more here:
<br>
<br> <a href=3D"https://github.com/fohr/blossom" target=3D"_bl=
ank">https://github.com/fohr/<wbr>blossom</a>
<br>
<br>SproutCore is now in de facto maintenance mode. It's time to re-asses
<br>what we, as a community, want SproutCore to be.
<br>
<br>As many of you know, Blossom is a serious attempt to advance
<br>SproutCore 1.x forward after the failure of SproutCore 2. I put
<br>forward the rational behind Blossom in early December, 2011 (http://
<br><a href=3D"http://bit.ly/future-of-sproutcore" target=3D"_blank">bit.ly=
/future-of-sproutcore</a>) and also demo'd early work I had done on
<br>Blossom at the SproutCore User Group in Washington D.C. late January,
<br>2012.
<br>
<br>The Blossom 1.0.0-beta.1 (available today) has:
<br>
<br>- A 100% Node.js native build system, including framework and app
<br>distribution and reuse via npm, the Node Package Manager.
<br>
<br>- A completely rewritten view layer built around two new classes,
<br>SC.Surface and SC.Layer. Surfaces support GPU-accelerated 3D
<br>transitions, and layers are a wrapper in the style of Core Animation
<br>around HTML 5's Canvas2D. All drawing in Blossom is done via Canvas2D =
=E2=80=93
<br> you never write HTML or CSS.
<br>
<br>- The latest datastore and statechart code from SproutCore 1.8.
<br>
<br>- The fast, small and stable runtime from SproutCore 1.4.5. In
<br>addition, the responder subsystem was fully audited and dramatically
<br>reduced in size and complexity.
<br>
<br>- Pervasive use of assertions (sc_assert), node-based unit tests for
<br>foundation and datastore, and a specialized "fuzz testing" app for the
<br>new view layer that has resulted in extremely robust view handling. SC
<br>1.x DOM-based bugs are hopefully a thing of the past.
<br>
<br>- A much more approachable code base, centered around three
<br>frameworks: foundation (node, browser), datastore (node, browser), and
<br>application (browser). Blossom re-envisions SproutCore as a "batteries
<br>included" framework.
<br>
<br>- No support for mobile browsers. Current usage indicates that
<br>SproutCore is a poor fit for mobile browsers at this time, but...
<br>
<br>- Blossom supports the ability to compile a SproutCore app to run
<br>_natively_ on mobile devices such as iOS and Android, using a native
<br>(not WebView-based) runtime. The first two native runtimes (iOS and
<br>Mac OS X) are due on April 1, but you can start writing code now,
<br>since the API is identical.
<br>
<br>Blossom is designed to become the future of SproutCore, but it also
<br>stands on its own. It's amazing how much progress can be made in a
<br>short about of time by people dedicated to advancing the state of the
<br>art. I want to take this opportunity to thank all of the people on the
<br>#blossom IRC channel who chatted with me endlessly about design
<br>decisions throughout Blossom's development. Your feedback has made a
<br>huge difference. And also xTuple, without their support Blossom would
<br>not have been possible.
<br>
<br>Here's the release notes for the beta:
<br>
<br>> Blossom's API and feature set are now stable enough to begin devel=
oping production applications with, and Blossom includes the latest Statech=
art and Datastore code from SproutCore 1.8.
<br>
<br> >This is an early beta for experienced SproutCore developers
<br>targeting the latest releases of the Google Chrome and Apple Safari
<br>desktop web browsers. The public API is 99.9% stable (the only
<br>breaking changes going forward will be to accommodate bug fixes).
<br>
<br>> Only Blossom's application framework differs from SproutCore in te=
rms of the public API (the foundation and datastore frameworks remain uncha=
nged), so the vast majority of your existing knowledge re: how to write Spr=
outCore apps still applies.
<br>
<br>> 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 cod=
e you write today will be supported when Print-to-PDF is enabled in a futur=
e release.
<br>
<br>Best, Erich Ocean</blockquote></div></div>
------=_Part_1276_29365619.1331331663171--
------=_Part_1275_13070546.1331331663171--
Message from discussion Blossom 1.0.0-beta.1 (SproutCore 3 candidate)
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |