[GitHub] aharui commented on issue #360: ActionScript conversion examples?

[GitBox <gi...@apache.org>]

aharui commented on issue #360: ActionScript conversion examples?
URL: https://github.com/apache/royale-asjs/issues/360#issuecomment-450275074
 
 
   From a migration from SWF to JS perspective, Royale's main focus is on migrating Flex apps.  in Flex,  the use of flash.*.* classes was theoretically unnecessary.  IOW, a Flex Application instance instead of flash.display.MovieClip is your entry point, and there is a "systemManager" property that means you can pretty much avoid referencing Flash "root" or "stage" properties.
   
   This allows Royale to escape any obligation to be backwards compatible with Flash.  Creating the equivalent of Flash in the browser is, IMO, a huge project, and the Flash API s are tuned to Flash's runtime with deferred rendering and frames and other concepts that don't map well to other runtimes.  Thus, by not emulating Flash, Royale frees itself from a particular runtime and allows for abstractions that can target other runtimes someday.  IOW, it is easier to reproduce an Application and "systemManager" property on most other runtimes than it is to reproduce "enterFrame" and ensure that when you modify a property it isn't drawn on-screen right away.
   
   So, when migrating a Flash app, you have to decide what trade-offs you want to make.  If the Flash app is not heavily reliant on Flash-specific APIs (frame-based animation, lots of custom graphics interleaved through the UI layers, ApplicationDomains, etc) then you might want to rewrite the Flash app in Royale and make, for example, org.apache.royale.core.Application the entry point instead of MovieClip.  This will mean a lot of renaming of classes in your code-base and modifying other code, but the result will be the smallest, fastest, app.
   
   If you have lots of ActionScript calling Flash APIs, you can try the Royale emulation components and use mx.core.Application as the entry point.  There will still be a lot of renaming of classes, but probably less and more straightforward.  The emulation components have a mx.display.Graphics class that will replace flash.display.Graphics.  But only a few Flash classes have mx.display equivalents and there is no goal of 100% backward compatibility.
   
   There is another project called OpenFL that is trying to replicate more of the Flash classes.  You can visit them and see if they can help you.  You can use Royale to transpile your code using their SWCs.  They are taking on the task of shooting for higher and higher Flash backward-compatibility.  This can result in fewer changes to your code, but if you need to target some other runtime someday, you may regret still having Flash-isms in your code.
   
   Fundamentally, there is no one right answer.  Royale is here to do the transpiling and offer some choices of component sets to use.  But we welcome third-parties like OpenFL who want to offer other approaches to the problem.
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services