On Tue, May 19, 2015 at 10:36 AM, Michael Schmalle < teotigraphix...@gmail.com> wrote:
> 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. > I disagree fundamentally with this idea. For one, HTML/CSS is a terrible terrible paradigm. No designer is happy with the way things work today. I would rather provide a better way of doing the visuals via MXML+FXG (like we do in Flex's spark skins) and cross compile them over to JS + SVG + Canvas as needed. Even the HTML/JS world is waking up to this idea. This presentation [1] does a great job of explaining why SVG is better than CSS for interfaces building. FlexJS is in a great position to provide this out of the box to developers. Thanks, Om [1] http://slides.com/sarasoueidan/building-better-interfaces-with-svg#/ > > What is your take on that? > > Mike > > > > > Does that help? > > -Alex > > > > >
