On 6/4/17, 9:46 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >Sorry autocorrect seems to have got the better of me - correcting: > >I think you are forgetting the optimisation that goes on, yes the source >code has a few more lines of code, but hardly double the size. > >Perhaps we can come up with some rules/guildlines to what PAYG actually >is? Say no more than 5% or 10% final size or runtime cost? Since November of 2012, my vision has been to make it possible to eliminate all just-in-case code from a FlexJS customer's application. Sure, that may not be 100% achievable, but I want everyone to be role models for how this is attempted. No matter how you measure it, you have added just-in-case code for those who don't need to remove the PasswordInputBead. The vision has been to offer customers choices of beads. If we instead model that we can ignore this vision and just add 7% or 2%, we will just be repeating the same mistake we made in regular Flex and over time, FlexJS will be just as fat and slow as regular Flex. I can't tell you how many times we said in regular Flex "this is only adds a little bit of code". But when customers started rejecting Flex because it couldn't run as fast and small as they needed, we lost our chance to be part of solutions that people couldn't live without. If you have a different vision, you can execute that vision in another component set or fork FlexJS entirely. Please do not impose your vision on my vision. Thanks, -Alex
