flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FlexJS] Guidelines for implementation of layout containers and navigation containers
Date Sun, 01 Oct 2017 02:29:03 GMT
I just want to comment on this:

I expect most users to not care about swf output. However, on the framework level it’s important
for a number of reasons:
1. Runtime type checking. Running the code through the Flash runtime has value even if it’s
never used in production. It offers additional checks which cannot be caught by any of the
compilers. This is a feature built into Flash which is not apparent until it finds bugs.
2. Support for AIR. Being able to target JS and AIR is going to be valuable to some folks.
3. It makes sure we develop with more than one target in mind. To me this is the strongest
reason. Eventually we are probably going to want to target native on iOS, Android, etc. If
the framework is designed to target both JS and Flash, it forces us to abstract things enough
to be applicable to two very different rendering engines. Adding a third and forth target
once it’s designed like that is much easier. There has already been talk about support WebASM
and the like, and the idea of truly native output has come up as well. If you question the
value of that, take a look at React Native. Without being forced to have a second target it’s
way too easy to resort to just thinly wrapping web APIs without giving thought to abstracting
them enough to make the classes applicable to other environments.

I hope this clarifies the mindset a bit…

Thanks,
Harbs

> On Sep 28, 2017, at 10:43 PM, Idylog - Nicolas Granon <ngranon@idylog.com> wrote:
> 
> We are not interested *at all* in SWF compatibility or alignment between a SWF and a
JS version.
> Our goal is to migrate our browser-based applications catalog out of Flash player. We
will keep AIR apps (desktop/mobile) under the Flex/AIR hood. Common libraries (which usually
do not have any UI) will be upgraded to mixed-mode when necessary (and if possible ! If not
possible - or too complicated - we will have two versions, of for SWF, and one for JS).


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message