Thanks Alex, That was informative and enlightening. I had no idea the SWF output was that valuable overall for testing.
I would not push for pixel-perfect representation; there are certain browser quirks and differences that are just not going to be worth it. On Thu, Sep 7, 2017 at 5:22 PM, Alex Harui <aha...@adobe.com.invalid> wrote: > Hi Adam, > > Thanks for your input. Many of us want to make sure SWF output is viable > for several reasons 3 of which quickly come to mind: > 1) There is a runtime verifier in the Flash Player. When you run your > code in Flash/AIR it is literally running 1000's of tests that the browser > doesn't run and won't catch until something way more serious blows up. > Flash runtimes are way more likely to catch the error at the point of > failure. > 2) If you are allowed to deploy a SWF there should be much less > cross-browser testing and bug fixing required. > 3) The Flash debugger understands types and access protection. > > I attended a presentation where a guy was live-coding a demo in some JS > framework. He ran the app, typed in something like "10000000000" and hit > a button. The demo failed because he got an exception trying to save that > value in the database. The problem was that the JS runtime would not > autoconvert that String to a int (via parseInt, IIRC) because it was out > range, but instead of it being caught at input time, it wasn't caught > until it got all the way to the commit to the backend. > > Even more important for large apps that use modules written by different > teams, the Flash Player will check at module load time if your module > conforms to the interface expected by the loading application. If one > team or the other changes the interface, without Flash you won't know > until some other bug happens. > > Can you live without using Flash to test your app? Yes, of course, but > we're just trying to give you as many ways to optimize your developer > productivity. We may not put as much emphasis on making the Flash version > pixel-for-pixel the same as JS. It isn't perfect now and depending if we > see folks interested in #2, we may just limit the effort to getting > bounding boxes for the UI widgets to line up well enough to essentially > serve as mocks for your test harnesses. > > Thanks, > -Alex > > > On 9/7/17, 3:43 PM, "Adam Malejko" <a...@malejko.com> wrote: > > >This sounds great! > > > >In our use cases, we don't have a need for SWF output when doing FlexJS > >projects, and we suspect that we are not alone. For those that want JS and > >SWF output, what is the appeal or need? > > > >The existing Apache Flex compiler (with AIR if needed for mobile) works > >fine for our current projects. For the new ones and upcoming conversions, > >an Apache-only and therefore Adobe-free framework sounds awesome. Also, > >yes > >to ant, and no to bash scripts for us. > > > > > >On Thu, Sep 7, 2017 at 2:30 PM, Olaf Krueger <m...@olafkrueger.net> > wrote: > > > >> >If this sound good to folks.. > >> > >> This sounds really good, Alex!! > >> I think it's an important thing to get rid of some dependencies and to > >>ease > >> the FlexJS setup. > >> > >> Thanks, > >> Olaf > >> > >> > >> > >> > >> > >> -- > >> Sent from: > >>https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fapache-fl > >>ex-development.2333347.n4.nabble.com%2F&data=02%7C01%7C% > 7Cde37fb9d9fa24bd > >>3570808d4f641ff7d%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C6364042107 > >>60660905&sdata=%2BvIXdHHekLGyvE%2F9S6gouQaoRGH7fEiZ8dOQ4m8vo4E > %3D&reserve > >>d=0 > >> > >
