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 be. 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, -Alex On 7/1/17, 3:40 PM, "Greg Dove" <greg.d...@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 >already. > >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 <aha...@adobe.com.invalid> >wrote: > >> Hi Greg, >> >> Thanks for writing this up. I took a quick read. I'll do a more >>careful >> read next week and have more detailed comments. One thing I wanted put >>up >> for discussion now is the notion of "defaults". Really, I'm trying to >>get >> away from the notion that there is one default we have to decide on. >>IMO, >> 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 >>is >> often no one right answer, so we build different component sets and >>folks >> will try them and decide for themselves. >> >> Thoughts? >> -Alex >> >> On 6/30/17, 3:29 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >> >> >Following on from other discussions, I have made a start on something >>here >> >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 >>believe >> >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 >>'resolution'/guidance. >> > >> >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 >>consensus. >> >I >> >think this should be do-able by simple discussions about specific >>topics, >> >maybe with informal voting if necessary. If there is no consensus then >>I >> >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 >>also >> >be helpful as part of the documentation for 1.0 when we get there, so >>it >> >could save someone time later on as well as being useful in the near >>term >> >(I hope). >> >>
