On Tue, May 19, 2015 at 1:22 PM, Alex Harui <aha...@adobe.com> wrote:
> > > 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. > Well yeah, that was my point of getting into it is making a couple simple apps. :) > > 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. > Well, I used the same javascript dynamically in 1999, so I think it's why I don't use it today on anything large. :) I have always favored checks and balances over riding by the seat of your pants type programming. > > 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. > > Yes, it's the API contract that you are creating in AS that allows large projects to benefit, since they all would use that SWC API library and compile against it remotely. > > > >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. > See this is my problem, Randori was a straight cross compile with shims and worked awesome. So all my questions to you are like me "unlearning" what I spent 6+ months working on in that project. The compiler's emitter just puked out js and we locked in SWCs in the apps that used js API surfaces. Although, the one thing as you know was Mike disagreed with FlexJS's view in ActionScript because he said HTML/CSS designers should just do what they do and design in HTML/CSS. What is your take on that? Mike > Does that help? > -Alex > >
