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="";
                   width="500" height="375"
                        import org.apache.flex.core.IUIBase;
            public function runTests() : void
                                var foo:Object = this as IUIBase;
        <mx:Label text="Hello World" />

The debug version is running here:

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:

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.


On 3/30/16, 2:53 PM, " on behalf of Carlos Rovira"
< on behalf of> 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!!
>2016-03-29 3:17 GMT+02:00 Mark Kessler <>:
>> Sounds like great progress.
>> -Mark
>> On Mon, Mar 28, 2016 at 5:37 PM, Alex Harui <> wrote:
>> > Hi,
>> >
>> > As you may know, I've been exploring what it would take to create a
>> 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
>> > 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).
>> > only idea I have for dealing with lack of weak references going
>> is
>> > to add a dispose() call to UIComponent and other objects similar to
>> > 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.
>> > 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
>> > question is how many touch-points there are with Flash, especially
>> > with good names that shouldn't be renamed (like 'parent').  Maybe
>> > UIComponent (and UITextField) are the primary points of contact with
>> > Runtime and higher-level components will port more cleanly.
>> >
>> > But first, I have slides and demos and hopefully a release (without
>> > stuff) to finish by next Monday.
>> >
>> > Feel free to ask questions,
>> > -Alex
>> >
>> >
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>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
>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
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación

Reply via email to