On 5/19/15, 9:59 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>I am a dreamer, so I dream up things I want to do; right now, I don't feel >the boundaries of what FlexJS is capable of abstracting. Obviously I can >google all the things I want to do with HTML/JS, search if it works on >mobile etc. In other words, I don't feel what I can't do with FlexJS right >now, hence my trying to understand the javascript part of the framework, >the non cross compiled part. Well, right now, you can’t do much with FlexJS except build and run the examples. Of course, we want folks to try porting or creating apps in FlexJS so we can make it do more things. In theory, FlexJS should someday be able to create any HTML/JS/CSS app that you could write yourself using any of the popular JS frameworks that try to still make what you write look like code. Those frameworks try to make things that look like classes, and as long as they don’t break rules of what classes in JS “should" look like, it should be possible to mock up an AS class that maps to the same API surface. Other frameworks try to completely change the way you code. I’m not interested in those right now. The problem most JS app developers face is that they make mistakes writing the JS code that glues the Jquery (or whatever framework) components together. The promise of TypeScript and ActionScript is that it reduces the number of ways you can screw yourself over. But the Flash runtime will also prove your API surfaces are valid before you even run every code path, so that’s why I suggest testing using the SWF version before trying the cross-compile. The current JS tools are great at checking everything you can bring into one compilation session, but folks who have built enterprise-class applications know that isn’t always practical. The whole point of modular development is to have asynchronous, loosely-coupled development teams. When your app scales to that point where you are dynamically loading stuff you couldn’t gather together for a huge compile, how will you know if there was an API mismatch? Flash will tell you much sooner than the browser will. Or think of it this way: what the handwritten JS does is take some existing browser or JS framework API and wrap it just enough to make it conform to what the FalconJX cross-compile from some AS code calling it would want to see. We don’t want to add more than that if possible. Like I said, we’ll be compared on download size with apps written in HTML/JS/CSS. > >I am trying to figure out what is real using AS, what has to be written in >JS, what shims are necessary, what are my limitations of the cross >compiling. > >So basically, I am searching for the end of the road sign in the >ActionScript development paradigm. Where it stops and only things can be >done in JS. It's like when I feel this line, I can then start putting >together all these ideas in my head, using mobile, web audio or whatever. Josh’s idea of a standalone FalconJX was compelling because it could mean that FlexJS could be written entirely in AS. The most or all of the handwritten JS could actually just be cross-compiled AS written against a different set of libraries (native HTML DOM APIs). I may explore this idea a bit more over the next week or so. I’d expect there’s still be some handwritten JS to shim something the cross-compiler doesn’t do that well or to hack some existing browser class, but it could greatly reduce the amount of JS we write and speed up development greatly. We make many more mistakes writing JS than AS, although it may be more painful to debug the JS and then adjust the AS than just adjust the JS. Other limitations are where AS doesn’t map cleanly to JS and if you want to use HTML/JS/CSS things we can’t or don’t do well in AS and/or Flash. Does that help? -Alex
