flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: New Flex to JS project
Date Tue, 08 Jul 2014 11:18:12 GMT
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 <erik@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 <pent@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" <darkstone@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" <erik@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 <aharui@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" <erik@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 <aharui@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" <erik@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 <aharui@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message