Well not necessarily,
Either via DOM emulation or swapping the PlayerGlobal with a DOM API, you
could technically build full AS components that get converted into JS.
Given the second choice, then you'd still need to be aware of the HTML
quirks as if you would handcraft JS components.
The first solution would obfuscate the platform specific API to something
similar to today's Flash display list. (less Flash specific, more generic)
Speaking for the current Flex, we love the fact that anything is virtually
possible, and the framework is very extendable to whatever the client
demands.
Would hate to lose that flexibility on the UI side of things, but great
things come at a price :)
We mainly focus on HTML/JS now, but falcon can go much broader, true write
once, run everywhere is utopia... But we could try to draw that line as low
as we can?
A VanillaSDK-API would have to be extensive to suit most (enterprise) needs,
as you mentioned some kind of Ext-JS plug will get you quite far in the UI
requirements section,
then again a more generic Apache Flex sdk to target UI could be better
ported in the future, if you plan to not just target JS, but anything else,
as native Android for example.
Tough choices! And to be honest I know too little of the whole current
web-ecology to keep blabbering on about this :)
In the end, we need enough traction to this new Flex framework from the
outside world, we need to fill a gap and be successful at how it plays its
role compared to the other HTML (or other platform target) solutions.
-----Original Message-----
From: Roland Zwaga
Sent: Saturday, January 26, 2013 2:51 PM
To: dev@flex.apache.org
Subject: Re: [ASJS] AS to HTML5 in action: announcing the ASJS Publisher and
the VanillaSDK JS framework.
On 26 January 2013 01:40, Hans Van den Keybus
<h...@dotdotcommadot.com>wrote:
But if I understand it correctly, wouldn't it mean in Erik's model that
when I create my own custom datagrid component for instance, I would also
have to write a JS version for this? (For me personally this is what I
would want to avoid -- writing JS myself :) )
I hate to be a party-pooper here :) But I think if you're going to be
building HTML/JS applications there is no way
around having to learn at least a measure of JS and do some JS coding
manually.
When creating an HTML component I think JS is actually exactly the language
you need to add the UI logic, since the UI logic
is very platform specific (in this case the browser) it is probably easier
to have those pieces of code done in JS than it is
to cross-compile them.
From where I sit I think having all of your business logic (which in most
applications will be the brunt of your code) will make
much more sense being cross-compiled.
That's why I was suggesting the integration options with existing HTML
components, there's a wealth of them out there ready to be taken
advantage of. If you want to build components from the ground up, IMHO,
going native is the best choice.
But feel free to disagree and prove me wrong of course :)
cheers,
Roland
