On 1/18/16, 12:03 AM, "OK" <okrue...@edscha.com> wrote:
>>Any library without dependencies on Flash has a chance of working when >>cross-compiled. > >Does it make a difference if the swc is compiled by using the standard >Compiler or by the FlexJS Compiler? I guess it depends on what your goals are. FlexJS should be a viable lighter weight framework for building Flash/AIR-based applications. But most folks are looking to use it to write MXML and AS and cross-compile it to output HTML/JS/CSS-based apps. If all you want is just a SWF, then it doesn't matter which compiler compiles the SWC. ActionScript ByteCode (ABC) is just abc code no matter what compiler is used. But if you want to see the SWCs functionality work without Flash, you actually need to cross-compile the source code for the SWC with the FlexJS/FalconJX compiler. > > >>Why do you want to load FlexJS modules into a Flex app? > >I could extend existing Flex Apps by using FlexJS for selected >functionalities. >On the one hand working with the standard SDK gives me a safe feeling with >the certainty that I'm >able to do my work and on the other hand I could try FlexJS and integreate >it without any risk. I'll ponder whether it will be practical to create a component set that lets you see some small portion of your UI written in FlexJS work in your regular Flex app in Flash. I'm writing a more Spark-like component set for FlexJS now. The issue is that in order to be lightweight and cross-compile, FlexJS doesn't want to base its all of its components off of the regular Flex SDK's UIComponent which is really heavy and has lots of Flash dependencies. And without that, certain integration issues like Focus Management might be an issue. Currently, the thinking is that folks would test out FlexJS by creating a branch of their current app and trying to cross-compile the whole thing. All of your AS code that doesn't have Flash dependencies has a good chance of cross-compiling and just working. Then, you have to look into replacements for where your AS code needs Flash. For MXML, you currently have to change out a fair amount of tags and attributes. The Spark-like component set should require fewer places to tweak but might result in a really fat and slow JS file. We'll see. > > >>...or skip using the SWF altogether and just use what we call "externs >swcs": a swc of empty API definitions. > >I don't understand this, what do you mean with "...skip using the SWF"? Some folks think they don't need/want a SWF version of their FlexJS app. They only want to work with the HTML/JS/CSS. Just like you shouldn't use Flash API's in a FlexJS app if you want it to cross-compile, you can't use low-level HTML/JS/CSS APIs in your FlexJS app either if you want it to create a runnable SWF. Basically FlexJS is trying to create a set of APIs that aren't Flash or JS specific so it can cross-compile into either SWF or HTML/JS/CSS. The advantage of having a SWF version is that you can test against a runtime that truly understands sealed class definitions and interfaces. This should catch a lot of errors much sooner than you would if you just test your HTML/JS/CSS. And you can deploy the SWF to older browsers that FlexJS won't support. HTH, -Alex
