On Fri, May 15, 2015 at 3:01 PM, Alex Harui <aha...@adobe.com> wrote:
> > > On 5/15/15, 11:26 AM, "Michael Schmalle" <teotigraphix...@gmail.com> > wrote: > > > >What I want to do in the next couple months is test the crap out of all > >the > >base UI components and make sure they work, JUST WORK from as to in the > >browser. > > That would be awesome. Be prepared, you’ll find lots of issues. > This was my point about me having to put time into learning some more abstract js and html aspects, which actually I have been putting off for years but this is the perfect excuse now. > > >Well, that is my ramble for today. I just hope we can keep some spirited > >devs that like working in the trenches where there isn't much "external > >validation" for a while, that is what it's going to take for this project > >to succeed and it really needs to happen before 2016. The whole ne ES6 and > >stuff, lots of change on the horizon. > > Sooner would certainly be better, but everyone working on FlexJS needs to > keep in mind that JS will probably continue to evolve after ES6 and some > ES7 will be even more like AS. The fact is that folks realize that > structure is needed to build enterprise-class applications. > I didn't mean "finished", just major progress. > > The assets Flex provides on top of JS becoming more like AS are things > like a declarative language, the way declarative and structured languages > make IDE use more efficient, a runtime verifier, the ability to work in > older browsers by deploying the SWF version. > > Yeah, JS evolutions will make it harder to differentiate from FlexJS over > time, but really, there is nothing stopping us from allowing folks to glue > their MXML together with some future version of JS and/or adjust our > emitters to emit strict ES6. > This was my point to Om, the compiler is so modular we can evolve with the technology. That is what my whole "rant" today was about, AS/MXML is an abstraction that is a constant. I may not evolve on a language level but it does abstract that evolution in JavaScript and HTML, which, our emitters might need to offer versions but, the developers AS is going to work the same and there is no porting to newer version of an already structured language. > > In my mind, we have: > -independence of corporate directives > -independence from browser vendors > -true open-ness (no big corp having undue influence) > -several IDEs to choose from > -the ability to work in old browsers > -declarative language > -structured but not too structured language > -tool chain > > Agreed and why I am here today. Mike > > -Alex > >
