@Josh Just to add, the most practical situation would be, you prototype your basic framework using the library you need. Write the javascript that way it fits into the framework you are using, find the dependencies and irregularities early.
Once you have a hello world type prototype, I can then easily create the proper abstracted emitter and we build up from that ground. This way, we know the emitter is created to benefit your use case in a way there are no unnecessary abstractions and hacks in the emitter. We all save time this way. @Alex I am still totally interested in FlexJS, I can only imagine how Josh's UI framework could totally add to the validity of a developer taking the next step into a full fledged UI/Application framework like FlexJS. On that note, my intuition says that once the two frameworks start to mature, we will easily find a way to bridge the gap of MXML in a very logical fashion, enabling both frameworks to leverage MXML and IDE support in the same way. I see each framework having a use case, FlexJS HTML solution and Josh's totally geared for graphics and a high performance mobile type set like Feathers is today. Disclaimer, I may just be thinking to much right now. Giving people options and tiers is always good for technology. Mike On Sat, May 16, 2015 at 7:00 AM, Michael Schmalle <teotigraphix...@gmail.com > wrote: > > > On Fri, May 15, 2015 at 8:13 PM, Josh Tynjala <joshtynj...@gmail.com> > wrote: > >> On Fri, May 15, 2015 at 3:04 PM, Michael Schmalle < >> teotigraphix...@gmail.com >> > wrote: >> >> > >> > If I knew people like you were getting interested in these projects, I >> know >> > it's a catalyst for me because I met you back in 2005-2006(can't >> remember), >> > right when AIR(Apollo) was released at the Adobe component developer >> > summit. I know exactly why you are still using ActionScript. >> > >> >> Is that a hint that you want me to come out and say it directly? ;) >> >> If a standalone AS3 to JS transpiler were available, and it had someone >> actively working on it, I would put it through its paces. I want to build >> UI components similar to Feathers on top of canvas and/or WebGL. If I >> could >> reference an existing JS library (like CreateJS or something similar) in >> ActionScript and subclass its types, I would have everything I needed. If >> I >> had to provide some kind of shim to work with a particular JS library, I'd >> be willing to create it in whichever format the compiler expects. Even if >> I >> weren't writing code to be included directly in FlexJS, I'd be giving the >> transpiler a solid workout. >> > > > Yes, with me, I am a direct person so that was an indirect direct > question. :) > > Since I have been a component dev since who knows when my mind has always > thought in lego fashion. I remember when I got sick of trying to get > FalconJS to work/debug it I started to think back with my experience > writing the asblocks frameworks(read/write as dom in as and java). > > So after much talk on the list back when this project started, Alex said, > "Write your own!". I thought about that and was like why not. The hardest > part was getting the compiler front end code figured out, once I got how I > would "port" the front end from the MXMLC compiler I changed focus to the > backends and emitters. I named the new framework "FalconJX" as just another > name then FalconJS. I didn't actually think the name would stick. :) > > So I started unit testing from the expression and statement up into blocks > then classes. I knew in my paranoid mind, the cross compiler had to have > enough low level tests to be able to run it's paces. By creating this > composition in the different levels of the back end, the emitter was born. > > My first step in testing was to get the compiler to compile AS and emit > AS, those are the foundation tests for the walker/visitor framework that > exists now. Having these tests then made me feel comfortable to introduce > the first JS emitter because I knew that AS visitor pattern was recursing > correctly based on the AS to AS unit tests. > > What this means for FlexJS and a vanilla FlaconJX transpiler is, my future > work will benefit both frameworks at the same time. If we find bugs, it > will either be in the visitor/walker framework or js emitter. > > Right now, the JSEmitter is pretty abstract. In Randori I'm pretty sure I > wrote a mainly vanilla emitter which I can use that code to create a > JSCanavsEmitter or JSGLEmitter OR one that does the same thing, you get the > idea. > > If you say you want to make a UI componnet framework, and need this I can > say I have time to work on it. My business needs some type of HTML/JS > future since that is the way tech is going. > > So in summary, I can only see a project like this helping the Apache Flex > project as a whole and making it stronger by inforcing the fact we are > playing of ActionScript's strengths as a language for quick and tooled > development. > > Before I work on that part of the compiler, I think I really need to hear > your ideas about how you want to built the component framework, so I can > write the emitters correctly. > > > If I had to provide some kind of shim to work with a particular JS > library, I'd be willing to create it in whichever format the compiler > expects > > To answer this, you wouldn't have to. The emitter I would write should be > a complete abstraction of how anybody could do what you want to do with JS > and perform well with the JS created. This is also why I say, your needs > would dictate how the js should be created dealing with this emitter. > > Mike > > > >> >> - Josh >> > >
