On 11/26/12 1:15 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>> Instead, I want to leverage what is there, and specifically disallow support
>> for Flash APIs that will be hard to implement, at least in the early going.
>> In fact, the right test when building an app in this new framework would be
>> to not import any Flash classes. I would prefer to wrap important Flash
>> concepts in a way that makes them easier to implement on the HTML/JS side.
>> For example, why cross-compile all of the AS Flex button code? There's a
>> pretty good button baked into the HTML/JS stack.
>
> I think I abused the term API a bit. With JS player I meant the entire
> JS 'engine' (actively avoiding the term framework ;-)) that takes the
> compiled JS app and makes it "happen" in the browser.
Well, I may not understand what you mean by "engine", but in my prototype, I
don't think there really is one. The way I see it, apps are an assembly of
components with some glue code. I don't want to try to write another layer
that is like a VM/engine.
>
> The 'native' HTML/JS controls, as you call them, don't provide a
> consistent look and feel across browsers and platforms and certainly
> don't allow for skinning (yes, CSS allows for some, but not nearly
> what we're used to). This has always been one of the strong points of
> Flex and I think we should seriously consider making it one of the
> strong points of FlexJS.
Sure, folks are welcome to embark on an advanced skinnable set of
components, but IMO, the basic set should be pretty bare bones. Hopefully
there is some existing pattern for providing custom buttons in HTML/JS we
can just wrap. But I hope we don't have to try to transcode an AS button
implementation. That just sounds like a lot of work.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
