You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2016/09/22 16:43:41 UTC
Re: [FLEXJS][FALCONJX] News on the Spark-like component set
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.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@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 <ke...@gmail.com>:
>
>> Sounds like great progress.
>>
>>
>> -Mark
>>
>> On Mon, Mar 28, 2016 at 5:37 PM, Alex Harui <ah...@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.
Re: [FLEXJS][FALCONJX] News on the Spark-like component set
Posted by OK <po...@olafkrueger.net>.
>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.
The main reason why I'm stick with Flex is because of its productivity.
We're able to create simple and complex apps in a very fast way cause of the
combination of typed ActionScript and MXML with the ability to create any
kind of reusable components you like, even very fast.
So if there's a real chance to reach the same productivity with FlexJS we
should invest time to create strands and beads and whatever is needed to
make FlexJS the same best in class framework as Flex is ;-)
Maybe it will be a hard switch to deal with strands and beads instead of fat
all-inclusive spark components
but at the end we would like to build performant apps so the FlexJS PAYG
probably makes much sense.
My strategy is to stick with Flex as long as it fits my needs and it is
foreseeable that there is any kind of runtime available and I'm able to make
sure that our users have installed it.
Instead of hoping to be able to compile my existing Flex Apps to JS anytime
I always take care to seperate my Flex views from the logic so that there
will be a fair chance to port my existing Flex Apps to FlexJS or whatever
technology at any time. This kind of port would be also a good chance to
renew getting old UIs.
Parallel to using Flex I'm looking forward to be able to build productive
apps with FlexJS.
It would be a dream to be able to use all these nice JS libs out there with
FlexJS! So lets try to complete FlexJS more and more by going the FlexJS way
and don't look back to mx or spark.
Just my 2 cents,
Olaf
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FLEXJS-FALCONJX-News-on-the-Spark-like-component-set-tp52004p55278.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FLEXJS][FALCONJX] News on the Spark-like component set
Posted by Alex Harui <ah...@adobe.com>.
On 9/22/16, 11:41 AM, "PKumar" <pr...@gmail.com> wrote:
>Great News Alex, now FlexJS will be backward-compatible and great
>milestone
>in converting existing Flex application to FlexJS.
Hi Prashant.
To be clear, FlexJS may not ever be fully backward-compatible. FlexJS is
relatively backward-compatible today because you can use most of your AS
business logic in converting your Flex app to FlexJS. I hope to see Harbs
and Yishay prove that soon. And FlexJS will only become more
backward-compatible with Flex if community members like yourself help
complete the port.
There are too many things that need to be done and not enough volunteers.
I am choosing to work on non-port stuff that I think will have a bigger
impact for my time since I think there are folks in the community who
could work on the port.
Thanks,
-Alex
Re: [FLEXJS][FALCONJX] News on the Spark-like component set
Posted by PKumar <pr...@gmail.com>.
Great News Alex, now FlexJS will be backward-compatible and great milestone
in converting existing Flex application to FlexJS.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FLEXJS-FALCONJX-News-on-the-Spark-like-component-set-tp52004p55267.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.