flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: [FlexJS] PAYG definitions and guidance, Please participate
Date Sun, 02 Jul 2017 06:44:40 GMT
Hi Greg,

You could be right that folks are just too used to the old Flex way of
thinking.  If you've never hit the performance and size issues I've seen
then maybe you can't understand the motivation behind it, but that might
mean the active committers are self-selected.  I don't think we have
representatives from big enterprise app development teams amongst our
active committers and it could be that the big enterprises that have been
burned by old Flex's size and performance are no longer active Flex
customers.  Beads and PAYG is my solution to the problems I saw during the
Adobe Flex days so if we do get interest in FlexJS from big enterprises,
we have a better chance of turning them into customers and committers and
that will have much more impact on the Flex ecosystem than those of us who
are currently writing code for FlexJS.

And, it is also just good computer science.  Abstraction, separation of
concerns, composition, are all good design principles.  The regular Flex
SDK violated a lot of those principles for historic reasons.  AS2 object
creation was slow so it encouraged you to write big monolithic classes,
then when AS3 came out, we didn't have time or want to take the risk to do
a rewrite, nor were we sure what AS3's performance characteristics would

I'm not sure it is right to think of this under the lens of the 80/20
(pareto) rule.  Express is supposed to be a pre-packaging of code in
Basic.  In theory, there should be no new beads in the Express source
folder.  It should only composite or aggregate beads from Basic.  And
thus, if 80% of developers use Express, 80% of developers are using code
in Basic.  And the important thing is, if someone needs to shave size or
improve performance, that someone can switch back from Express to Basic,
and start tossing beads they don't need.

I remember a survey done by Lotus 123 Spreadsheet folks back in the 90's.
At that time Lotus 123 shipped something like 100 @functions (like @Sum,
@Average).  The survey showed that something like 90% of folks only used 5
@functions.  90% of those folks use @Sum, but no other @function was used
by more than 5% of the users.  But every @function was being used by
somebody.  It was probably ok for a spreadsheet to be bundled with lots of
@functions, but it isn't good when a framework makes you include 95
functions in your app that you aren't going to use.

We have focused on Basic so far in order to prove that we can create
useful, small and performant examples and hopefully soon, useful small and
performant applications by compositing small pieces.  It may be that we
can focus more on Express going forward.  And there might be other "sweet
spots" in between Express and Basic as well and yet another component set
will arise.  We won't know until more customers actual try to migrate
real-world applications and put them into production.

Documentation is always a good thing, but as I've said several times, this
is bleeding-edge development.  I'm just not sure we are ready to start
paving roads and putting up street signs.  In Flex 0.8.0, we overhauled
the Layout subsystem and there are still things I don't like about it.
I'll bet there is one more overhaul coming up.  I'm also pretty sure that
layout gets called too often but I won't know how to optimize until Harbs
or others get to the "last mile" and really start focusing on performance.

I go back and forth between thinking we are ready to stop writing code and
start writing doc and thinking that we just need a few more folks who know
how to work on the bleeding edge to push forward at a fast pace and let
those who may be better at paving roads form the second wave that follows
after us.  Having those of us who are writing the most code slow down and
smooth out the trail behind us may keep us from getting to critical points
in time.  Nobody I know of has bet long term on FlexJS.  Adobe can pull me
off at any time.  If we can attract a big corporation with a multi-person
development team to join in the FlexJS effort, they might bring in
professional doc writers and do a much better job than I would.  So today,
I think we're better off if I produce a TitleWindow for this new customer
that showed up yesterday than document the layout subsystem. My managers
would much rather that I help one or two customers migrate their code than
write documents so 100 folks can migrate on their own because we still
have enough bugs and missing features that the 100 would have little
chance of being successful, and making one or two folks successful is
likely to happen sooner than spreading energy over 100 customers and might
bring in that one big customer with the resources to really "move the
needle" and pave the roads for us.   And having a successful customer
improves the chances that Adobe will continue to pay me to work on FlexJS.
 Also, we don't have to agree.  If anyone thinks documentation is more
important, go write the documentation.  The key is to pursue your goals
without negatively impacting others.

Thanks again for working on this stuff,

On 7/1/17, 3:40 PM, "Greg Dove" <greg.dove@gmail.com> wrote:

>Thanks Alex,
>I look forward to your feedback. It would be great to see  (from you or
>anyone else) -  within this thread - suggested improvements/corrections or
>other topics that should be added, or questions that should be addressed.
>I know there are areas that need improvement in a number of areas of the
>document, but I'm hoping that this will be 'fixed' by making it a shared
>goal and getting input from others, not by me kludging away in the
>background. I wanted to get something up that is a starting point only.
>I do understand the avoidance of the 'swiss army knife' approach to base
>classes in Flex 4, but had wondered about whether we were focusing on the
>19% of functionality that might be useful for 5% of developers (Basic) vs.
>the 20% of that will suit 80% of developers (e.g. express) -I'm not saying
> that the pareto relationships there are correct, just using it for
>'relative' comparison. But I think it is just a case of getting used to a
>new way to thinking, which is different to Flex4 (and Flex3). It would be
>really great if you can lead a thread specifically about this.
>I also suspect there will be no 'one true way' to make incremental
>functionality beads either. But documenting the pros and cons of each
>approach (which we already started in one of the other threads) might
>provide useful guidance about when to choose which approach (inheritance
>and/or utility functions etc). I'm looking forward to that discussion
>because I think I was getting a lot out of the earlier discussion on that
>In the end writing these things in a document is not something I call fun.
>"I'd much rather be coding". But I do believe that having 'team-sourced'
>content, as an output of focused list discussions, could make the
>generation of the document content a much easier process, and that the
>process itself could help  improve decision quality, build consensus, and
>provide resources that will be useful for team alignment and future
>reference info for others. I think any one of those reasons is enough for
>me to stop trying to create more of the content myself!
>On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <aharui@adobe.com.invalid>
>> Hi Greg,
>> Thanks for writing this up.  I took a quick read.  I'll do a more
>> read next week and have more detailed comments.  One thing I wanted put
>> for discussion now is the notion of "defaults".  Really, I'm trying to
>> away from the notion that there is one default we have to decide on.
>> that's another old way of thinking from Flex.  FlexJS is designed to
>> support multiple component sets.  Express will have different defaults.
>> MDL has different defaults.  The Basic set has a particular design goal
>> (feature parity with SWF) and thus will have different defaults.  There
>> often no one right answer, so we build different component sets and
>> will try them and decide for themselves.
>> Thoughts?
>> -Alex
>> On 6/30/17, 3:29 PM, "Greg Dove" <greg.dove@gmail.com> wrote:
>> >Following on from other discussions, I have made a start on something
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fcwiki.apa
>> >che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%
>> 3D71013028&data=02
>> >%7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3%
>> 7Cfa7b1b5a7b34438794aed2c178de
>> >cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf%
>> 2BQ2wyJxgqmguZ18T
>> >Zng2jGcWIkY%3D&reserved=0
>> >
>> >In the end this will only work if people want to do it. But I do
>> >that one way of getting everyone on the same page here (and we do have
>> >clear signs that not everyone is), is to, quite literally, get
>>everyone on
>> >the same page :).
>> >
>> >It is currently half content, half notes. There is more to harvest from
>> >list discussions I think, some topics have progressed further than
>>when I
>> >started trying to capture ideas, so please correct any mistakes in the
>> >definitions or add topics and questions that need
>> >
>> >I personally would like to see some concrete guidance in the 'How does
>> >PAYG
>> >get implemented' section. There were definitely the beginnings of some
>> >healthy discussions around some of the options for beads for example.
>> >(DRY,
>> >inheritance, utility functions etc).
>> >
>> >The goal here is to turn any list discussions around
>> >uncertainties/misunderstandings into something that represents
>> >I
>> >think this should be do-able by simple discussions about specific
>> >maybe with informal voting if necessary. If there is no consensus then
>> >guess PMC could do a formal vote? (I don't know what makes sense here)
>> >
>> >Beyond work on the SDK, this type of information (in some form) might
>> >be helpful as part of the documentation for 1.0 when we get there, so
>> >could save someone time later on as well as being useful in the near
>> >(I hope).

View raw message