An update: After 9 months of fiddling, I finally got a "Hello World" up and running using MX components. The app is essentially:
<mx:Application xmlns:fx="http://ns.adobe.com/mxml/2009"; xmlns:mx="library://ns.apache.org/flexjs/mx" xmlns:js="library://ns.apache.org/flexjs/basic" applicationComplete="runTests()" width="500" height="375" usePreloader="false" preloader="mx.preloaders.DownloadProgressBar" > <fx:Script> <![CDATA[ import org.apache.flex.core.IUIBase; public function runTests() : void { var foo:Object = this as IUIBase; } ]]> </fx:Script> <mx:Label text="Hello World" /> </mx:Application> The debug version is running here: http://home.apache.org/~aharui/FlexJS/HelloWorld/FlexJS_MX/ It will take a while to load the first time because there is 3.4MB of JS to download. I expect it would minify down to about 200K since for the FlexJS HelloWorld, the js-debug is 1.6MB and minifies down to 92K. (The 92K should be much smaller, and will be fixed shortly). For comparison, the debug version of FlexJS HelloWorld is here: http://home.apache.org/~aharui/FlexJS/HelloWorld/FlexJS/ The work involved commenting out lots of optional existing Flex SDK code and injecting the FlexJS framework between Flash and the Flex SDK code. I commented out all 3D support, multi-version support (The Marshall Plan), multi-SWF support, modules and RSL support, Dictionary and Weak Reference usage, and more. And still, the result effectively doubles the size of an app for no obvious additional functionality. In order to bring these features back in, JS equivalents would have to be written and the size of HelloWorld will grow. Lots of bugs will need to be fixed in order to get better backward compatibility, and that will make things fatter too. And this is just MX (more like Flex 3). Even more work and size must be added to do a Spark version. I will say this: the browsers are fast. If you click to re-load hello world from the browser cache, it runs that 3.4MB very quickly. There is more work ahead just to get this to run as minified code. And I'd estimate 5 to 10 person-years of development to reach near-parity with the Flex SDK. I don't think we can currently get to full-parity. We wouldn't have an answer for Dictionary and Weak References so the apps would leak memory or you'd have to do some migration work and use different APIs to free up memory. Given that Harbs and Yishay look like they will be successful with the much smaller "basic" FlexJS framework, and the fact that we don't have many folks in our community who can work on FalconJX, and the fact that it wasn't very much fun working on this port, I am going to stop working on it and focus on the backlog of issues building up for FalconJX and the core of FlexJS. I think I've done the hardest part of inserting FlexJS between Flash and Flex and getting something to work. My thinking is that if folks really want to see a version of the Flex SDK code ported to FlexJS, there are way more folks in our community who can work on that, because they already are familiar with the Flex SDK. If you have a huge Flex app and are considering porting it to some other JS framework, you could always do what Harbs and Yishay are doing by rewriting your UI on top of the FlexJS UI components but preserving the vast majority of your AS code, or maybe you could build a coalition with other companies who would prefer a "near-zero-migration" and contribute folks (or hire contractors) to finish up the port. I will help debug really hard problems and fix compiler issues that the port will expose. If 5 companies each contribute one full-timer, you might be able to run your existing Flex apps on JS in a year or two, which might be much less work and risk than a full port to some other JS framework. On the other hand, I think Harbs and Yishay are going to show that in about one person-year, they ported an existing app to FlexJS using the new FlexJS UI widgets. And it should be even easier for other folks now that the trail has been blazed. Much of their time is still being spent on framework features and not on their actual migration. And if your app is old enough, it might be time for a UI upgrade anyway. I'm going to leave the code in the spark branch for now and not merge it into develop until we see what kind of response we get on this thread. Thanks, -Alex On 3/30/16, 2:53 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote: >Amazing. When FlexJS started, the key mantra was always go for a new >framework without looking back. >I continue thinking that trying to compile old Flex applications with >FlexJS is science-fictions...but now, with the progress >that Alex report...maybe it could be possible in part. > >Great work Alex!! > >Carlos > > >2016-03-29 3:17 GMT+02:00 Mark Kessler <kesslerconsult...@gmail.com>: > >> Sounds like great progress. >> >> >> -Mark >> >> On Mon, Mar 28, 2016 at 5:37 PM, Alex Harui <aha...@adobe.com> wrote: >> >> > Hi, >> > >> > As you may know, I've been exploring what it would take to create a >>set >> of >> > components for FlexJS that more closely match the Spark (and MX) APIs >> from >> > the regular Flex SDK. >> > >> > Today, I reached an early milestone: I got a subset of UIComponent to >> > subclass the FlexJS UIBase and cross-compile with zero errors. It >> doesn't >> > run yet, but it gives us information about the effort and patterns >> > involved and some early idea of the size. >> > >> > In order to create a manageable subset, I commented out all code in >> > UIComponent related to: >> > >> > -accessibility >> > -rotation >> > -scale >> > -3D and Transforms and other AdvancedLayoutFeatures >> > -designLayer >> > -BlendModes and BlendShaders >> > -Filters >> > -doubleClick >> > -cacheAsBitmap, cachePolicy and cacheHeuristic >> > -AdvancedStyleClient >> > -Repeater >> > -XML DataBinding >> > >> > Most of what is in the list is stuff related to "fancy" visuals. IMO, >> you >> > can build many apps without these features. >> > >> > In addition, I changed some weak reference listeners to strong >>listeners >> > since we don't have weak reference support on the JS side so any code >> that >> > does a lot of discarding of UIComponents is going to leak (for now). >>The >> > only idea I have for dealing with lack of weak references going >>forward >> is >> > to add a dispose() call to UIComponent and other objects similar to >>what >> > you already have to do for Bitmaps and XML. >> > >> > It turns out that it still took some 212 files to compile UIComponent. >> > That's how complex the web of interdependencies are in the Flex SDK. >>But >> > interestingly, the cross-compiled output minified down to "only" an >> > additional 140K! I was thinking it would be 10 times as big. >> > >> > So that's promising, and means I will continue pushing on getting >>this to >> > run and port more code. I think the next milestone is to port >> > mx:Container, mx:Label, mx:Application just to see a Hello World run. >> > Then start porting Spark. How long that will take is unknown. The >>key >> > question is how many touch-points there are with Flash, especially >>APIs >> > with good names that shouldn't be renamed (like 'parent'). Maybe >> > UIComponent (and UITextField) are the primary points of contact with >>the >> > Runtime and higher-level components will port more cleanly. >> > >> > But first, I have slides and demos and hopefully a release (without >>this >> > stuff) to finish by next Monday. >> > >> > Feel free to ask questions, >> > -Alex >> > >> > >> > > > >-- > >Carlos Rovira >Director General >M: +34 607 22 60 05 >http://www.codeoscopic.com >http://www.avant2.es > > >Este mensaje se dirige exclusivamente a su destinatario y puede contener >información privilegiada o confidencial. Si ha recibido este mensaje por >error, le rogamos que nos lo comunique inmediatamente por esta misma vía y >proceda a su destrucción. > >De la vigente Ley Orgánica de Protección de Datos (15/1999), le >comunicamos >que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC >S.A. La finalidad de dicho tratamiento es facilitar la prestación del >servicio o información solicitados, teniendo usted derecho de acceso, >rectificación, cancelación y oposición de sus datos dirigiéndose a >nuestras >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación >necesaria.
