Re: [FLEXJS][FALCONJX] News on the Spark-like component set
>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.247.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
On 9/22/16, 11:41 AM, "PKumar"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
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.247.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.
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: 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" > 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"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 : > >> Sounds like great progress. >> >> >> -Mark >> >> On Mon, Mar 28, 2016 at 5:37 PM, Alex Harui
Re: [FLEXJS][FALCONJX] News on the Spark-like component set
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: > 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 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
Man, I would have never guessed my little tissy about FalconJS and just starting FalconJX would have got to this point that FlexJS is with all the different outputs and things being compiled with it and how you guys are not even writing js anymore, giving you time to do stuff like this. :) I will note that when I wrote the Randori compiler I was still using FalconJX right up to the end and it did the Hungry Heros and Starling cross compile so there were a huge amount of little nit pick bugs I got out of it then. Right on Alex! I am so glad Adobe is still letting you work on this and trying to get it to a point more people find it. Mike On Mon, Mar 28, 2016 at 5:37 PM, Alex Haruiwrote: > 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 > >
[FLEXJS][FALCONJX] News on the Spark-like component set
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