FlexJS is a good name for the framework, and changing it will cause unnecessary confusion. At this point, most people are going to be primarily targeting JavaScript anyway.
- Josh On Apr 22, 2016 4:55 PM, "jude" <flexcapaci...@gmail.com> wrote: > Flex JS conveys Flex as JavaScript framework but it's a hybrid really. > Could we reflect that Flex JS is a hybrid someway? > > Flex js is a sort of refactor. maybe: > > Flex Reactor > ReFlex > Flexo > Flex Nano > Flex Red > Flex Inc > Flexenstein > Flex Int > Flex passport > Flex Axiom > Flex Ion > Flex Action > > I don't know. > > There used to be a graph that showed how everything related to everything > else. But with Falcon, FlexJS, Falcon JX and so on it which have been added > after those graphs it can be confusing. Anyone want to draw something > updated under the new Apache Flex Platform? > > On Apr 21, 2016 9:41 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > > I think we’re all in agreement that FalconJX without the rest is an > important part even on its own. That’s what I meant by #1. > > > > I do think that naming is important. It helps “brand” a product. > Something like MXMLC2.0 is way too techie to be a “product”. > > > > I’ve been thinking of different ways to “brand” this, and I think I have > an idea which might work: > > > > Falcon and FalconJX and related toolchain which compiles AS and > optionally MXML into swc, swf and js could be branded as “FlexJS Core”. > > > > Everything else which is really about components and UI could be branded > as “FlexJS UI”. > > > > This is really similar to how JQuery did it with JQuery and JQuery UI. > > > > This would give a central brand, while preserving the concept that you > can use the compiler without the component sets (or even MXML at all). > > > > Harbs > > > > On Apr 20, 2016, at 8:02 AM, Alex Harui <aha...@adobe.com> wrote: > > > > > Good thoughts in this thread. > > > > > > My current thinking is this: > > > > > > FalconJX is a code name for the cross-compiler, but because there is an > > > Apache Falcon project, we need a better product name, and consider that > > > Falcon may someday compile SWFs for the Flex SDK. Adobe already used > > > ASC2.0, plus our version of Falcon handles MXML. We could use > MXMLC2.0, > > > but I'm not a huge fan of that. > > > > > > IMO, FlexJS has become a tool chain. It takes in MXML and AS and > outputs > > > SWFs or HTML/JS/CSS. We want to draw in every JS framework community > to > > > MXML-enable their components. Peter is hoping to finish a demo soon of > > > how much easier it is to learn and use CreateJS with MXML than with the > > > current CreateJS tutorials in JS. Maybe that will get the ball rolling > > > downhill. > > > > > > We will still build out a Basic component set for lowest-level > > > smallest-footprint apps. And we hope to build out MX and Spark-like > > > component sets to ease migration pain for existing Flex code bases. > > > > > > Yes, we have CreateJS, Jquery and GoogleMaps SWCs now, mostly as > > > proofs-of-concept. I hope to see the respective communities take over > > > development of these SWCs and expect them to do it outside of our > repos, > > > and have independent release schedules. > > > > > > So that's why I'm not sure a component set that targets Stage3D and > > > Starling has to be part of this community. It can certainly be a > customer > > > of the FlexJS tool chain, and we want it to be a customer, but we want > all > > > JS component set communities to be customers of FlexJS whether they > build > > > for SWF-first workflows or direct-to-JS workflows. > > > > > > Further down the road, once FlexJS grows to support distributed > > > development, we will be able to more clearly show the benefit of > SWF-first > > > workflows for those who need it. But that's for another thread > someday. > > > > > > My 2 cents, > > > -Alex > > > > > > On 4/19/16, 4:52 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > > > > >> I agree that FalconJX without the FlexJS framework is an important use > > >> case. That's basically why I'm here contributing to the project. I > want to > > >> champion the ActionScript language, and show how FalconJX will let you > use > > >> ActionScript anywhere that JavaScript is supported. That means (now or > > >> eventually) working with HTML, Node.js, Electron, and extensibility > APIs > > >> the like CEP panels that Harbs mentioned. > > >> > > >> For this use case, I think it's all about focusing on building a solid > > >> compiler. > > >> > > >> - Josh > > >> > > >> On Tue, Apr 19, 2016 at 4:04 PM, OmPrakash Muppirala > > >> <bigosma...@gmail.com> > > >> wrote: > > >> > > >>> We have an equally important component that is FalconJX. I envision > > >>> lot of > > >>> demand to work on non-FlexJS, pure FalconJX work. > > >>> > > >>> I think the Starling port falls under the category of pure FalconJX > work > > >>> and not FlexJS. We already have a game company working on making a > game > > >>> using the FalconJX compiler. > > >>> > > >>> Any thoughts on how we want to handle this use case? > > >>> > > >>> Thanks, > > >>> Om > > >>> > > >>> On Tue, Apr 19, 2016 at 3:44 PM, Harbs <harbs.li...@gmail.com> > wrote: > > >>> > > >>>> I missed a fifth item in my list of things we need: > > >>>> 5. We need tooling to pull in external swcs (externs and > > >>> cross-copiling > > >>>> ones) when compiling to Javascript. > > >>>> > > >>>> (I think we also need a naming convention for the two types of swcs. > > >>>> "definition swcs" and "code swcs”?) > > >>>> > > >>>> On Apr 20, 2016, at 1:37 AM, Harbs <harbs.li...@gmail.com> wrote: > > >>>> > > >>>>> Alex and Josh bring up good points. > > >>>>> > > >>>>> I’m thinking that I should step back and figure out what I was > > >>> trying > > >>> to > > >>>> accomplish by suggesting that we accept these APIs. > > >>>>> > > >>>>> In fact, I think it’s time we figure out exactly what FlexJS > > >>> actually > > >>> is. > > >>>>> > > >>>>> The motivation to accept the code into FlexJS was really to empower > > >>>> users to have access to great APIs and capabilities. However to say > > >>> that > > >>>> any cool functionality should become part of the core product > probably > > >>> does > > >>>> not make sense. Case in point: I’m currently working on FlexJS > support > > >>> for > > >>>> CEP panels in Adobe extensions. I think it’s great functionality, > but > > >>> I > > >>>> don’t believe it belongs in the Flex repo. > > >>>>> > > >>>>> To address the question of exactly what belongs in the FlexJS repo, > > >>> I > > >>>> think we need to address exactly what is the identity of FlexJS > > >>> actually > > >>>> is. Different folks would probably have different definitions, but > > >>> here’s > > >>>> what I think: > > >>>>> > > >>>>> 1. It’s the compiler which turns MXML and ActionScript into > > >>> Javascript. > > >>>>> 2. It’s the paradigm of composing apps using MXML. > > >>>>> 3. It’s a set (or sets) of components which is built with this > > >>> paradigm > > >>>> in mind. (similar to mx and spark components in the classic Flex > > >>> framework.) > > >>>>> 4. It’s the infrastructure which enables tools to take advantage of > > >>> this. > > >>>>> > > >>>>> I think that’s pretty much it. > > >>>>> > > >>>>> Based on this definition, drawing APIs are probably not “Flex > > >>> core”. In > > >>>> fact, some of the other packages which already exist are probably > also > > >>> not > > >>>> Flex core (such as GoogleMaps). > > >>>>> > > >>>>> These are all useful things, but trying to include all useful > things > > >>>> will cause a lot of bloat and actually probably stunt community > > >>> growth. > > >>>> Until our focus was how to grow the Apache Flex community. I think > > >>> we’ve > > >>>> come to a bit of a cross-roads here, and we need to figure out how > to > > >>> help > > >>>> grow the community OUTSIDE Apache. > > >>>>> > > >>>>> What would accepting these APIs accomplish? I think primarily three > > >>>> things: > > >>>>> 1. Give the APis visibility. > > >>>>> 2. Help promote others to work on them. > > >>>>> 3. Make it easy for clients to use them. > > >>>>> > > >>>>> These are generalized problems and I think we need to solve them in > > >>> a > > >>>> generalized way so the next person who comes up with some other > > >>> awesome > > >>>> classes will have these problems solved as well. If someone builds > > >>> some > > >>>> cool stuff around FlexJs, we should not need discussion to make them > > >>> useful > > >>>> and usable. > > >>>>> > > >>>>> Here’s some ideas I came up with while thinking about this: > > >>>>> > > >>>>> 1. We need a way to find tools and libraries that support FlexJS. > > >>>>> 2. We need to help external libraries automate builds of swcs. I > > >>> think > > >>>> it would be really useful to publish some docs with a recommended > > >>> workflow > > >>>> for Github to do this. > > >>>>> 3. We need some kind of central repository of FlexJS swcs outside > > >>>> Apache. There should probably be two classes of swcs. Ones that are > > >>>> strictly externs, and others which actually compile into Javascript > > >>> code. > > >>>>> 4. I think we need a system to create an automated build of > > >>> Definitely > > >>>> Typed definitions into FlexJS swcs into a centralized repo. I think > > >>> Github > > >>>> has hooks you can use to trigger things when their repo changes. > > >>>>> > > >>>>> If these four points are addressed, I think it’ll do a lot to build > > >>> the > > >>>> greater community without adding all kinds of peripherals into the > > >>> core > > >>>> FlexJS repo. (and much more effectively as well) It’s not necessary > > >>> for > > >>>> Apache Flex to address all these directly. If the community at large > > >>>> addresses some of them, that’s also fine (or maybe even better). > > >>>>> > > >>>>> Harbs > > >>>>> > > >>>>> On Apr 19, 2016, at 6:39 PM, Josh Tynjala <joshtynj...@gmail.com> > > >>> wrote: > > >>>>> > > >>>>>> I've always thought that someone implementing the Flash classes is > > >>> a > > >>>> good > > >>>>>> idea, but that it makes the most sense as an external project. In > > >>> other > > >>>>>> words, not included with Apache FlexJS. There's nothing wrong with > > >>>> external > > >>>>>> projects. In fact, they're a sign of a healthy community! We > > >>> should be > > >>>>>> encouraging them and promoting them. > > >>>>>> > > >>>>>> I agree with Alex's points that including the Flash classes in > > >>> FlexJS > > >>>> will > > >>>>>> set expectations of compatibility that may not be desirable from > > >>> our > > >>>> side. > > >>>>>> It also keeps FlexJS bound to the legacy of Flash, instead of > > >>> showing > > >>>> that > > >>>>>> the project is evolving into something new and interesting. > > >>>>>> > > >>>>>> - Josh > > >>>>>> > > >>>>>> On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui <aha...@adobe.com> > > >>> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 4/19/16, 12:01 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > >>>>>>> > > >>>>>>>> webgl is not a very good name, because a lot of the code is > > >>> actually > > >>>>>>>> canvas rather than webgl. > > >>>>>>> > > >>>>>>> OK. I realized that Lizhi has been calling it SpriteFlexJS. So > > >>> that > > >>>>>>> could be in the package name. > > >>>>>>> > > >>>>>>> Actually this might be a good time to discuss names in terms of > > >>>> business > > >>>>>>> models. Lizhi, I want to make sure you are aware that whatever > > >>> name > > >>> we > > >>>>>>> put on your code base will belong to Apache and you won't be able > > >>> to > > >>>> sell > > >>>>>>> software using that name. This is a public mailing list, so feel > > >>> free > > >>>> to > > >>>>>>> not answer or write me directly, but an important point is this: > > >>> I'm > > >>>> not > > >>>>>>> sure how you plan to keep contributing to the SpriteFlexJS code, > > >>> but > > >>>> if it > > >>>>>>> involves selling the software what most people do is come up with > > >>> two > > >>>>>>> names, one for the for-profit software and one for the open > source > > >>> code > > >>>>>>> base. For example, the Apache Subversion project doesn't let > > >>> other > > >>>>>>> for-profit products be called Subversion, but they can use SVN. > > >>> Adobe > > >>>>>>> PhoneGap is a for-profit product based on Apache Cordova. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> What might make more sense would be to keep all the flash > > >>> packages > > >>> as > > >>>>>>>> experimental, and if we can identify robust piece of the > > >>> package, we > > >>>> can > > >>>>>>>> repurpose some of the code to be in separate packages. > > >>>>>>> > > >>>>>>> Another option is that we don't bring in all of this code right > > >>> away. > > >>>>>>> Didn't this thread start based on interest in Lizhi's ByteArray? > > >>> Lizhi > > >>>>>>> could donate that one file and we could use it under a different > > >>>> package > > >>>>>>> name. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> I see value in keeping the flash packages as such, because it > > >>> will > > >>>> likely > > >>>>>>>> help spur more people who want complete “flash-like” APIs to do > > >>> work > > >>>> on > > >>>>>>>> it. As Lizhi points out, there are incomplete areas in his code. > > >>>>>>>> > > >>>>>>>> As far as demand for Flash and Starling goes: I expect that > folks > > >>> who > > >>>>>>>> want more support will have to help out in improving it. Again, > I > > >>> hope > > >>>>>>>> this will help attract more people to work on it. > > >>>>>>> > > >>>>>>> In short, I'm just wondering if the work on Flash and Starling is > > >>> Flex. > > >>>>>>> Should it have its own community? FlexJS will hopefully have > many > > >>>>>>> customers and not all of their code should be in our code base. > > >>>>>>> > > >>>>>>> -Alex > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > > > > >
