Sprouts and Apples

9 views
Skip to first unread message

Ed Jones

unread,
Sep 29, 2011, 2:59:06 PM9/29/11
to ProjectSprouts
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://
www.webmonkey.com/2011/08/review-adobes-edge-offers-web-animation-sans-flash/
| http://www.webmonkey.com/2011/03/adobe-unveils-wallaby-flash-to-html5-converter/
)as indications that they're losing the war.

Am I missing something? You all know much more than I. Where's the
right path?

Luke Bayes

unread,
Sep 29, 2011, 11:13:34 PM9/29/11
to project...@googlegroups.com
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




--
You received this message because you are subscribed to the Google Groups "ProjectSprouts" group.
To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to projectsprout...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/projectsprouts?hl=en

For other info you can visit our project at: http://projectsprouts.org, or on Github at: http://github.com/lukebayes/project-sprouts

Marcelo de Moraes Serpa

unread,
Apr 28, 2012, 5:31:55 AM4/28/12
to project...@googlegroups.com
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.

Marcelo de Moraes Serpa

unread,
May 8, 2012, 2:32:49 AM5/8/12
to project...@googlegroups.com
Thanks Luke.

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.

Marcelo de Moraes Serpa

unread,
May 8, 2012, 2:34:49 AM5/8/12
to project...@googlegroups.com
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!
Reply all
Reply to author
Forward
0 new messages