Yeah, well right now it's to early to say anything about the future.

All I am trying to do is give a piece that I feel is missing from the tool
chain and that is something that has AS producing JS.

Maybe people will use it, maybe not. I figure I have nothing to loose and I
can possibly gain from a gamble.

The fact Josh is still highly interested in ActionScript leads me to
believe if we offer up real solutions to former AS devs, they might
actually be overjoyed to see and use it because they know we are not trying
to solve world hunger here, just offer tooling that is mature.

Mike

On Fri, May 29, 2015 at 4:29 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 5/29/15, 12:34 PM, "Michael Schmalle" <teotigraphix...@gmail.com>
> wrote:
>
> >
> >You wanna know the real reason, mainly Josh. If he can create a UI
> >framework like his feathers in AS that transpiles to JS and I can use it
> >for my mobile apps. I could see bridging the gap of his components into
> >FlexJS's MXML/Application and I ... would ... be ... in ... heaven.
>
> I know Josh is quite far on MXMLC and Feathers, but I sure wish I could
> convince him to try to get Falcon/FalconJX working with Feathers and align
> the efforts.  Then when he wraps up some JS framework to map to Feathers
> it will all work in this tool chain.  And now he can do his wrapping by
> writing AS and have it transpile to JS.
>
> >
> >I am NOT knocking all the work Alex etal are doing with FlexJS's
> >uicomponents just that I have always programed UI with code and some MXML.
> >It's the way  I think and Josh's Feathers just clicked for me and I became
> >100% more productive with my mobile apps then in my 2 year stint with Java
> >and opengl frameworks.
>
> I don’t see it as a competition.  I think we want to make sure that the
> tool chain is agnostic about the component sets involved.  I am building
> out a UI component set and SWF tooling that:
>
> 1) I think will give you faster edit/compile/test cycles
> 2) Leverages the runtime’s verifier that should help you when your code
> becomes more dynamic.
> 3) Generates a SWF that is potentially usable in older browsers.
> 3) Should provide re-usable pieces for mocking or emulating these other JS
> UI component sets in SWF form.
>
> If it turns out that folks don’t need these pieces, that will be a bit of
> a bummer, but I’m betting on #2 being important as your apps get bigger
> and bigger and more dynamic.
>
> -Alex
>
>

Reply via email to