Also, between the Closure Compiler's effectiveness in optimising and minifying code and the current state of internet speed available to users, I think that 'application size' is not a major reason to make drastic decisions when architecting a framework. The release version of DatabindingTest is currently 70 kb, which basically means that is about a 10th the size of an average Facebook post. I mean, even if my approach would double the size - doubtful given GCCs effectiveness - it would still be something which you can download as easily as a single image from any website.
EdB On Tue, Jul 8, 2014 at 1:03 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: > Peter, > > To be sure, I'm not criticising the work done on FlexJS - I did a fair bit > of it myself - I'm just (after Alex's insistence) stating the reasons I've > chosen to approach 'export to JS' from a different angle. > > EdB > > > > > On Tue, Jul 8, 2014 at 12:57 PM, Peter Ent <p...@adobe.com> wrote: > >> I'm sure Alex is composing a longer response, but I wanted to chime in >> having developed a number of beads and components of FlexJS. >> >> FlexJS is designed to be a pay-as-go system, keeping the app size as >> small as possible; even a small Flex app brings in a lot of code. >> >> I have to agree that beads should be more generic and easier to connect. >> The reason for many beads is so you can add on just the functionality you >> need. Perhaps having a reduced number of beads that are more generic would >> make it easier to choose. Then, if you found yourself using the same >> combination repeatedly, you would make this a custom component in your app. >> >> And yes, the examples only go so far and new things have appeared. This >> is at alpha stage so there will be iterations. We needed to get sufficient >> components together so we could survey how it all hangs together. >> >> We are hoping more people will join the project and help with the >> direction and development. >> >> I think the core idea is sound and could use some tweaking. >> >> Peter >> >> >> > On Jul 8, 2014, at 6:11 AM, "DarkStone" <darkst...@163.com> wrote: >> > >> > Hi Erik, >> > >> > Thank you very much for bringing this topic, it's the very topic I want >> to share my thoughts on. >> > >> >> 3 - Strands/Beads: it forces developers to know the insides of >> components, >> >> adding a level of complexity and a steeper learning curve to the >> framework >> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so >> much: >> >> it makes smaller projects unnecessarily complicated (e.g. all examples) >> > >> > I totally agree all the 5 points you've made, especially the 2 points >> above, I studied FlexJS' Strands/Beads MVC concept before, it forced me to >> do a restricted MVC application design. >> > >> > In most case, developers should have the abilities to design their own >> MVC concepts, rather than having to follow a pre-designed MVC concept. That >> is why Flex named itself "Flex", the flexibility is the soul of Flex, isn't >> it : ) >> > >> > I think Flex Spark's SkinnableComponent and Skin are good enough to >> separate a component's Logic and Skin. The Logic part of the component can >> then be divided into Model and Controller in anyway the developer want them >> to be, that is already the case in Flex Spark architecture, developers can >> decide how to design their own MVC concepts and apply them to their custom >> components, it's better this way. >> > >> > Besides, there are already a huge amount of projects based on the >> existing Flex Spark architecture, it will be much better if FlexJS can base >> on the Spark architecture, and makes the existing Flex projects much easier >> to transit to FlexJS. >> > >> > It took a very long time (over 10 years) to have Flex come this way, to >> make the Flex Spark architecture popular is already hard enough, so for the >> FlexJS, a smoother and easier transition from Flex to FlexJS is much needed! >> > >> > Well that is just my personal opinion, I know there are already a lot >> of hard works were put into the current FlexJS, and I am much appreciated, >> I will contribute what I can, when I can in the future, these months I'm >> gonna be very busy though. >> > >> > >> > DarkStone >> > 2014-07-08 >> > >> > >> > >> > At 2014-07-08 04:29:40, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >> OK, here goes - why I think the FlexJS concept can be improved upon >> (in no >> >> particular order): >> >> >> >> 1 - there is no migration path for existing Flex applications; this >> will >> >> make enterprise users reluctant to accept the new framework, even >> though >> >> during development FlexJS is limiting itself because it aims to please >> the >> >> enterprise user (IE 'old' support) >> >> 2 - FlexJS requires a brand new framework on both the AS and JS side >> (apart >> >> from some stuff that may cross compile), effectively doubling the >> effort to >> >> bring it up to speed with other frameworks - including regular Flex >> >> 3 - Strands/Beads: it forces developers to know the insides of >> components, >> >> adding a level of complexity and a steeper learning curve to the >> framework >> >> I - by the time there are enough components/strands and beads to >> have a >> >> useful framework, the set of beads will be too big to easily work with >> >> (e.g. "org.apache.flex.html.beads.DataItemRendererFactoryForArrayData" >> or >> >> >> "org.apache.flex.html.beads.controllers.ListSingleSelectionMouseController") >> >> II - making beads work on all strands makes beads complicated; making >> >> beads that don't work on all strands makes beads confusing for the >> developer >> >> 4 - forced MVC: as an option it would be great, as a 'feature' not so >> much: >> >> it makes smaller projects unnecessarily complicated (e.g. all examples) >> >> 5 - lack of direction: FlexJS is a collection of proofs of concept, >> created >> >> top down to make nice looking demos that are then abandoned or >> superseded >> >> by other proofs of concept or demos. >> >> >> >> I think we already have a pretty nice AS framework, the Flex SDK, >> which I >> >> intend to offer as-is. Rather, I plan to make the 'export to JS' >> feature a >> >> part of the regular Flex SDK. That way the user can open any Flex >> project, >> >> run the export and get a fully functional, identical looking >> application in >> >> JS, or, worst case, a nice list from the compiler explaining which >> >> components/properties don't (yet) work in JS and how to fix that. >> >> >> >> I'm interested to hear more about how you think this approach is >> related to >> >> FlexJS. If there is any synergy to be had, I'm all for it! >> >> >> >> EdB >> >> >> >> >> >> >> >>> On Mon, Jul 7, 2014 at 6:27 PM, Alex Harui <aha...@adobe.com> wrote: >> >>> >> >>> I'm not sure what you mean by "philosophical". I see more >> similarities >> >>> than differences between FlexJS and your approach of trying to mimic >> more >> >>> of the current SDK in JS. In fact, I still hope to convince you that >> what >> >>> you want to do is within the FlexJS charter so we can work together >> >>> instead appearing to work on separate efforts. And then what you are >> >>> working on would also be weakened by whatever it is you want to say. >> If >> >>> you have a killer argument why folks should not be trying to compile >> MXML >> >>> and AS to JS, I think the whole community will be better served by >> finding >> >>> out why now. >> >>> >> >>> -Alex >> >>> >> >>>> On 7/7/14 8:40 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>>> >> >>>> There are no technical issues per se that would need addressing to >> keep >> >>>> FlexJS healthy. I made sure of that. >> >>>> >> >>>> My argument is basically philosophical, and I think my ranting about >> it in >> >>>> public would weaken FlexJS' case, so I won't. >> >>>> >> >>>> EdB >> >>>> >> >>>> >> >>>> >> >>>>> On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui <aha...@adobe.com> >> wrote: >> >>>>> >> >>>>> I think it has to be in public. This is open development. I'm >> hoping >> >>>>> you >> >>>>> will save me time by doing so. If we are doing something we >> shouldn't >> >>>>> we >> >>>>> should correct it now otherwise we'll waste time and energy doing >> more >> >>>>> work in that direction only to find out that customers have the same >> >>>>> feedback. >> >>>>> >> >>>>> Not that all of your feedback is guaranteed to be addressed: there's >> >>>>> always a chance that what you don't like is philosophical rather >> than >> >>>>> technical. That's why there are dozens of JS frameworks already >> and why >> >>>>> you want to try a different approach. >> >>>>> >> >>>>> -Alex >> >>>>> >> >>>>>> On 7/3/14 12:00 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>>>>> >> >>>>>> You want to hear that in public, or do you want to take this off >> list? >> >>>>>> >> >>>>>> EdB >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>> On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui <aha...@adobe.com> >> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>>> I've been doing that as well for the last couple of years. I >> spent >> >>>>>>> most of >> >>>>>>>> my time getting FlexJS off the ground. But I don't agree with >> some >> >>>>> of >> >>>>>>> the >> >>>>>>>> basic assumptions and choices that FlexJS has made. I said >> little or >> >>>>>>>> nothing about it to give FlexJS a proper head start and to keep >> you >> >>>>> and >> >>>>>>>> Peter going. But now that I have re-evaluated what the project >> >>>>> means to >> >>>>>>>> me, >> >>>>>>>> and what I would like to spend my time on when contributing, and >> I >> >>>>>>> have to >> >>>>>>>> give my take on Flex to JS a try. >> >>>>>>> I'd love to hear your thoughts on what you don't agree with >> regarding >> >>>>>>> FlexJS. >> >>>>>>> >> >>>>>>> -Alex >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Ix Multimedia Software >> >>>>>> >> >>>>>> Jan Luykenstraat 27 >> >>>>>> 3521 VB Utrecht >> >>>>>> >> >>>>>> T. 06-51952295 >> >>>>>> I. www.ixsoftware.nl >> >>>> >> >>>> >> >>>> -- >> >>>> Ix Multimedia Software >> >>>> >> >>>> Jan Luykenstraat 27 >> >>>> 3521 VB Utrecht >> >>>> >> >>>> T. 06-51952295 >> >>>> I. www.ixsoftware.nl >> >> >> >> >> >> -- >> >> Ix Multimedia Software >> >> >> >> Jan Luykenstraat 27 >> >> 3521 VB Utrecht >> >> >> >> T. 06-51952295 >> >> I. www.ixsoftware.nl >> > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
