Hi, > Nothing specific at this time. Mainly, I will be willing to break > compatibility to achieve a significant goal, whether it is performance, DI, > unit-testing, cross-compilation to HTML/CSS/JS, accessibility, size, etc. I have no issue with that as long as the upgrade/conversion path is relatively easy and/or well documented. Which I'm sure it will be.
> For sure, making the porting effort too large would cause folks to not port. > But my thoughts after the summit was that if Flex is at one extreme and > HTML/CSS/JS is at the other and we are clearly hearing the pain of going > from one to the other, I believe we could find a midpoint (not necessarily > at 50%) where all of the above goals and more are achieved such that it is > worth making a significant (although much less significant) port effort than > going the whole distance. The issue is here that people often see than if we have to go to some effort to convert we might as well go all out and change everything. Logically it makes no sense but I've seen it happen time and time again.My view (and others will disagree but that's fine) is that we need to initially make any changes to the SDK easy to swallow Long term I'm all for anything that makes a major improvement even if it break backwards compatibility. > And I hope that with a composition-based framework, you can make your own > trade-offs as to where the midpoint is. Yep I'm all for that. > This is a good opportunity to point out one of the counter arguments to my > philosophy: these kinds of frameworks tend to require more configuration and > make it less approachable to newbies. Good documentation (and code examples) can help there. It's great to see the thinking/reasoning behind in where you want to take the framework, it's something we wouldn't of seen in the old Adobe way of deciding future versions of the SDK. Thanks, Justin
