When I found Sprouts last year, it seemed the coolest thing
imaginable, and the answer to a huge set of issues. I'm not a highly
skilled programmer, though; I have too many hats; and my sprouts
efforts have been too long on the back burner.
As fall settles in and I look forward, I'm now wondering if Sprouts
even is a future. The toolset is great of course, it's the output that
concerns me: SWF.
It seems accepted at this point that iPhones, iPads, and IPods will
simply never play a SWF. No matter what. Moreover, pick up an Android
Galaxy and the average user will see whitespace where a SWF should be,
even after downloading plugins.
Thanks for posting here. I agree with your concerns about the future of SWF development, but Sprouts is much more than just that.
For one quick example, one can use Sprouts to emit native iPhone apps using AIR.
Another point to make, is that Sprouts is actually a generic platform for wrapping line-command tools and creating (and distributing) supporting tools like libraries and generators. It just so happens that no one (that I know of) has actually built any infrastructure for tech other than Flash, but I've sat down to start on some, like Google Closure and Haxe, for example.
These should be relatively simple to build out, and the flashsdk source could be a nice place to start if anyone's interested.
On Thu, Sep 29, 2011 at 7:59 AM, Ed Jones <ed.jo...@gmail.com> wrote: > When I found Sprouts last year, it seemed the coolest thing > imaginable, and the answer to a huge set of issues. I'm not a highly > skilled programmer, though; I have too many hats; and my sprouts > efforts have been too long on the back burner.
> As fall settles in and I look forward, I'm now wondering if Sprouts > even is a future. The toolset is great of course, it's the output that > concerns me: SWF.
> It seems accepted at this point that iPhones, iPads, and IPods will > simply never play a SWF. No matter what. Moreover, pick up an Android > Galaxy and the average user will see whitespace where a SWF should be, > even after downloading plugins.
> More recently, Adobe has released (previews) Edge and Wallaby (http://
> Am I missing something? You all know much more than I. Where's the > right path?
> -- > You received this message because you are subscribed to the Google Groups > "ProjectSprouts" group. > To post to this group, send email to projectsprouts@googlegroups.com > To unsubscribe from this group, send email to > projectsprouts-unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/projectsprouts?hl=en
I was actually thinking about starting something for Haxe! How's the status
of this project? I've been lurking around Haxe for years, and I see it's
finally starting to get traction (and it's a great language and with a
*lot* of potential) but it does miss a lot of "rubyiness" and I think
Sprout can definitely be the answer to that :)
I was also thinking about starting a sprouts-jekyll-blog project, not only
to generate, but to manage a jekyll blog. However, I've found this:
Which solves most of what I wanted :). However, Sprouts could still be used
to wrap octopress, and generate more specific jekyll "mashups".
Something that octopress still doesn't automate well is provisioning of the
blog to a server. Of course, there's some documentation on how to deploy
it, but I want to automate that to the maximum extent possible: with a
command and some args set it up in the sever (provisioning), and then use
git (or other known means) to update it.
I've also been thinking of somehow integrating sprouts projects with Chef
and Vagrant. I'm not a Chef nor a Vagrant guru, but the two already play
well together. I was wondering if we could have sprouts generate vagrant
projects (including installing and setting up a vagrant VM automatically if
needed) and then hooking up Chef to provision the server. Again, sprouts
would be the glue / automator.
I've been looking into alternatives (like Thor), but I always come back to
sprouts, reason being it seems to offer a better infra-structure and I'd
rather invest in a like-minded community than just hack together a couple
of generators/tools that do not foster existing code (and duplicate a lot
of it).
On Thu, Sep 29, 2011 at 6:13 PM, Luke Bayes <lba...@google.com> wrote:
> Hey Ed,
> Thanks for posting here. I agree with your concerns about the future of
> SWF development, but Sprouts is much more than just that.
> For one quick example, one can use Sprouts to emit native iPhone apps
> using AIR.
> Another point to make, is that Sprouts is actually a generic platform for
> wrapping line-command tools and creating (and distributing) supporting
> tools like libraries and generators. It just so happens that no one (that I
> know of) has actually built any infrastructure for tech other than Flash,
> but I've sat down to start on some, like Google Closure and Haxe, for
> example.
> These should be relatively simple to build out, and the flashsdk source
> could be a nice place to start if anyone's interested.
> Thanks!
> Luke
> On Thu, Sep 29, 2011 at 7:59 AM, Ed Jones <ed.jo...@gmail.com> wrote:
>> When I found Sprouts last year, it seemed the coolest thing
>> imaginable, and the answer to a huge set of issues. I'm not a highly
>> skilled programmer, though; I have too many hats; and my sprouts
>> efforts have been too long on the back burner.
>> As fall settles in and I look forward, I'm now wondering if Sprouts
>> even is a future. The toolset is great of course, it's the output that
>> concerns me: SWF.
>> It seems accepted at this point that iPhones, iPads, and IPods will
>> simply never play a SWF. No matter what. Moreover, pick up an Android
>> Galaxy and the average user will see whitespace where a SWF should be,
>> even after downloading plugins.
>> More recently, Adobe has released (previews) Edge and Wallaby (http://
>> Am I missing something? You all know much more than I. Where's the
>> right path?
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ProjectSprouts" group.
>> To post to this group, send email to projectsprouts@googlegroups.com
>> To unsubscribe from this group, send email to
>> projectsprouts-unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/projectsprouts?hl=en
> --
> You received this message because you are subscribed to the Google Groups
> "ProjectSprouts" group.
> To post to this group, send email to projectsprouts@googlegroups.com
> To unsubscribe from this group, send email to
> projectsprouts-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/projectsprouts?hl=en
I've been taking a look at the sprouts-flashsdk gem, quite enlightnening
experience :)
I've started a small project with Haxe, and although haxelib works nicely
to some level, it doesn't have the same level of robustness as gems +
Bundler to boostrap new environments quickly. My idea now is to create a
sprouts-haxe gem that sets up the local environment with haxe if needed (by
downloading and installing it), as well as a couple of haxelibs
automatically.
For haxelibs, could I use the Specification class? It think that's their
purpose right, to wrap package of files. I might create a subtype of that
to handle haxelibs, something like:
haxelib 'nameofhaxelib'
For example, in this case, this haxe project is basically a Chrome plugin.
I might rename that to sporouts-haxe-chrome later on.
So, this would call haxelib and install the lib automatically. Delivering
the haxe project to another dev would mean he/she would only have to bundle
and then use the respective rake tasks, considering of course Ruby and
bundler is installed :)
In the build tasks. Am I following the right line of thought?
Any insights appreciated,
Thanks!
- Marcelo.
On Sat, Apr 28, 2012 at 12:31 AM, Marcelo de Moraes Serpa <
> I was actually thinking about starting something for Haxe! How's the
> status of this project? I've been lurking around Haxe for years, and I see
> it's finally starting to get traction (and it's a great language and with a
> *lot* of potential) but it does miss a lot of "rubyiness" and I think
> Sprout can definitely be the answer to that :)
> I was also thinking about starting a sprouts-jekyll-blog project, not only
> to generate, but to manage a jekyll blog. However, I've found this:
> Which solves most of what I wanted :). However, Sprouts could still be
> used to wrap octopress, and generate more specific jekyll "mashups".
> Something that octopress still doesn't automate well is provisioning of
> the blog to a server. Of course, there's some documentation on how to
> deploy it, but I want to automate that to the maximum extent possible: with
> a command and some args set it up in the sever (provisioning), and then use
> git (or other known means) to update it.
> I've also been thinking of somehow integrating sprouts projects with Chef
> and Vagrant. I'm not a Chef nor a Vagrant guru, but the two already play
> well together. I was wondering if we could have sprouts generate vagrant
> projects (including installing and setting up a vagrant VM automatically if
> needed) and then hooking up Chef to provision the server. Again, sprouts
> would be the glue / automator.
> I've been looking into alternatives (like Thor), but I always come back to
> sprouts, reason being it seems to offer a better infra-structure and I'd
> rather invest in a like-minded community than just hack together a couple
> of generators/tools that do not foster existing code (and duplicate a lot
> of it).
> Let me know your thoughts,
> - Marcelo.
> On Thu, Sep 29, 2011 at 6:13 PM, Luke Bayes <lba...@google.com> wrote:
>> Hey Ed,
>> Thanks for posting here. I agree with your concerns about the future of
>> SWF development, but Sprouts is much more than just that.
>> For one quick example, one can use Sprouts to emit native iPhone apps
>> using AIR.
>> Another point to make, is that Sprouts is actually a generic platform for
>> wrapping line-command tools and creating (and distributing) supporting
>> tools like libraries and generators. It just so happens that no one (that I
>> know of) has actually built any infrastructure for tech other than Flash,
>> but I've sat down to start on some, like Google Closure and Haxe, for
>> example.
>> These should be relatively simple to build out, and the flashsdk source
>> could be a nice place to start if anyone's interested.
>> Thanks!
>> Luke
>> On Thu, Sep 29, 2011 at 7:59 AM, Ed Jones <ed.jo...@gmail.com> wrote:
>>> When I found Sprouts last year, it seemed the coolest thing
>>> imaginable, and the answer to a huge set of issues. I'm not a highly
>>> skilled programmer, though; I have too many hats; and my sprouts
>>> efforts have been too long on the back burner.
>>> As fall settles in and I look forward, I'm now wondering if Sprouts
>>> even is a future. The toolset is great of course, it's the output that
>>> concerns me: SWF.
>>> It seems accepted at this point that iPhones, iPads, and IPods will
>>> simply never play a SWF. No matter what. Moreover, pick up an Android
>>> Galaxy and the average user will see whitespace where a SWF should be,
>>> even after downloading plugins.
>>> More recently, Adobe has released (previews) Edge and Wallaby (http://
>>> Am I missing something? You all know much more than I. Where's the
>>> right path?
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ProjectSprouts" group.
>>> To post to this group, send email to projectsprouts@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> projectsprouts-unsubscribe@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/projectsprouts?hl=en
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ProjectSprouts" group.
>> To post to this group, send email to projectsprouts@googlegroups.com
>> To unsubscribe from this group, send email to
>> projectsprouts-unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/projectsprouts?hl=en
Oh and of course, abstracting the somewhat ugly build.hxml (and getting rid
of it) in favor of Ruby would be a nice idea for Haxe. I've seen people
using Ant, but a rakish build for haxe would kick ass!
On Mon, May 7, 2012 at 9:32 PM, Marcelo de Moraes Serpa <celose...@gmail.com
> I've been taking a look at the sprouts-flashsdk gem, quite enlightnening
> experience :)
> I've started a small project with Haxe, and although haxelib works nicely
> to some level, it doesn't have the same level of robustness as gems +
> Bundler to boostrap new environments quickly. My idea now is to create a
> sprouts-haxe gem that sets up the local environment with haxe if needed (by
> downloading and installing it), as well as a couple of haxelibs
> automatically.
> For haxelibs, could I use the Specification class? It think that's their
> purpose right, to wrap package of files. I might create a subtype of that
> to handle haxelibs, something like:
> haxelib 'nameofhaxelib'
> For example, in this case, this haxe project is basically a Chrome plugin.
> I might rename that to sporouts-haxe-chrome later on.
> So, this would call haxelib and install the lib automatically. Delivering
> the haxe project to another dev would mean he/she would only have to bundle
> and then use the respective rake tasks, considering of course Ruby and
> bundler is installed :)
> In the build tasks. Am I following the right line of thought?
> Any insights appreciated,
> Thanks!
> - Marcelo.
> On Sat, Apr 28, 2012 at 12:31 AM, Marcelo de Moraes Serpa <
> celose...@gmail.com> wrote:
>> Hey Luke,
>> I was actually thinking about starting something for Haxe! How's the
>> status of this project? I've been lurking around Haxe for years, and I see
>> it's finally starting to get traction (and it's a great language and with a
>> *lot* of potential) but it does miss a lot of "rubyiness" and I think
>> Sprout can definitely be the answer to that :)
>> I was also thinking about starting a sprouts-jekyll-blog project, not
>> only to generate, but to manage a jekyll blog. However, I've found this:
>> Which solves most of what I wanted :). However, Sprouts could still be
>> used to wrap octopress, and generate more specific jekyll "mashups".
>> Something that octopress still doesn't automate well is provisioning of
>> the blog to a server. Of course, there's some documentation on how to
>> deploy it, but I want to automate that to the maximum extent possible: with
>> a command and some args set it up in the sever (provisioning), and then use
>> git (or other known means) to update it.
>> I've also been thinking of somehow integrating sprouts projects with Chef
>> and Vagrant. I'm not a Chef nor a Vagrant guru, but the two already play
>> well together. I was wondering if we could have sprouts generate vagrant
>> projects (including installing and setting up a vagrant VM automatically if
>> needed) and then hooking up Chef to provision the server. Again, sprouts
>> would be the glue / automator.
>> I've been looking into alternatives (like Thor), but I always come back
>> to sprouts, reason being it seems to offer a better infra-structure and I'd
>> rather invest in a like-minded community than just hack together a couple
>> of generators/tools that do not foster existing code (and duplicate a lot
>> of it).
>> Let me know your thoughts,
>> - Marcelo.
>> On Thu, Sep 29, 2011 at 6:13 PM, Luke Bayes <lba...@google.com> wrote:
>>> Hey Ed,
>>> Thanks for posting here. I agree with your concerns about the future of
>>> SWF development, but Sprouts is much more than just that.
>>> For one quick example, one can use Sprouts to emit native iPhone apps
>>> using AIR.
>>> Another point to make, is that Sprouts is actually a generic platform
>>> for wrapping line-command tools and creating (and distributing) supporting
>>> tools like libraries and generators. It just so happens that no one (that I
>>> know of) has actually built any infrastructure for tech other than Flash,
>>> but I've sat down to start on some, like Google Closure and Haxe, for
>>> example.
>>> These should be relatively simple to build out, and the flashsdk source
>>> could be a nice place to start if anyone's interested.
>>> Thanks!
>>> Luke
>>> On Thu, Sep 29, 2011 at 7:59 AM, Ed Jones <ed.jo...@gmail.com> wrote:
>>>> When I found Sprouts last year, it seemed the coolest thing
>>>> imaginable, and the answer to a huge set of issues. I'm not a highly
>>>> skilled programmer, though; I have too many hats; and my sprouts
>>>> efforts have been too long on the back burner.
>>>> As fall settles in and I look forward, I'm now wondering if Sprouts
>>>> even is a future. The toolset is great of course, it's the output that
>>>> concerns me: SWF.
>>>> It seems accepted at this point that iPhones, iPads, and IPods will
>>>> simply never play a SWF. No matter what. Moreover, pick up an Android
>>>> Galaxy and the average user will see whitespace where a SWF should be,
>>>> even after downloading plugins.
>>>> More recently, Adobe has released (previews) Edge and Wallaby (http://
>>>> Am I missing something? You all know much more than I. Where's the
>>>> right path?
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ProjectSprouts" group.
>>>> To post to this group, send email to projectsprouts@googlegroups.com
>>>> To unsubscribe from this group, send email to
>>>> projectsprouts-unsubscribe@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/projectsprouts?hl=en
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ProjectSprouts" group.
>>> To post to this group, send email to projectsprouts@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> projectsprouts-unsubscribe@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/projectsprouts?hl=en
