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 <ngra...@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).
