Open Harbs opened 4 years ago
cottage14
commented
4 years ago @carlosrovira and I are tracking documentation improvements in Projects in the royale-docs repository. For each item we create a "card" and track the cards on a modified Kanban layout. Is it helpful to duplicate that material here?
Harbs
commented
4 years ago No, but I was not aware of those Projects, so I'm linking to them: FlexJS cwiki: https://github.com/apache/royale-docs/projects/1 Missing Pages and TOC: https://github.com/apache/royale-docs/projects/2 Royale In a Week Videos: https://github.com/apache/royale-docs/projects/3 Migrating FlexJS docs: https://github.com/apache/royale-docs/projects/4
carlosrovira
commented
4 years ago Hi @Harbs, thanks for open this issue:
I added "Fix Build Server Release Scripts" since was broken when improving maven build and release process. I was working on that but was difficult to me. I must go over there again as I complete other things requested for clients.
carlosrovira
commented
4 years ago About "Binding Issues".
Some tickets was opened in the last weeks/months. Some was solved but I think we still have some. For example @piotrzarzycki21 rise one recently (#639), I think other is #456. Other less important is #322
In general, maybe we are very close to have bindings working good, or maybe we fail to check other important options. The important here is to understand that binding was the main point of pain and suffer for our migration, we needed to do some weird things at that time. Just recently a function bindings was implemented (we lack of this feature until a client rise it).
So, by fixing the first two issues will have Bindings at a good level to reach 1.0? (the third bug will be desirable)
carlosrovira
commented
4 years ago About "Critical Missing Components".
I think this is more a Mx/Spark emulation need. Since I don't use it, can't say much more. Others like Alex, Pashmina, Piotr or Yishay could say more. A part from "functional" I think "look and feel" should be taken into account for emulation, but maybe there's no people working on that for now, so maybe that's something we could not try to get for 1.0. Don't know.
For Jewel, I think DataGrid was maybe the most needed, but I was hired to do some others a client needs: Contextual Menu / Menu, Tree and More improvements on DataGrid. That's where I'll be working in the next months for now. I think fixing Jewel Table API (removing selectedItemProperty) is maybe the most important to me for Jewel to call it 1.0, so probably try to do this soon.
carlosrovira
commented
4 years ago About "Improved CSS Support":
Here our compiler can accept some CSS legal selectors:
[attribute*=value]I think people that try Royale 1.0, will soon starting to use CSS and will try rules like this with no doubt (thinking they will not do is simply not realistic), the same I tried, and will find Royale breaks in a loudly way, so we should try to support as much as we can. If we left this as is, we'll get a bad first good impression.
aharui
commented
4 years ago IMO, having a recent successful migration in production on MXRoyale is the key to 1.0 and new users. That's why that is the only thing I'm working on (because others are thankfully working on PAYG in Basic). Fancy CSS doesn't matter to MXRoyale migration because it didn't exist in Flex, so I won't be working on that.
I am not a marketing/business person nor a fortune-teller, but my guess is that our new users in 2020 will be folks migrating Flex projects. The reason I focus on MXRoyale is because, as every day ticks off the calendar in 2020, the time left to migrate gets shorter. Every bug I fix in MXRoyale makes the time to migrate shorter.
While I am glad that Carlos and others have worked on Jewel, work on Jewel does not shorten the time to migrate as much as work on MXRoyale. Folks who use Jewel must have the time/money to rethink their UI. Fewer people will have that time in 2020.
I am hopeful we will get enough of MXRoyale running to get someone into production early in 2020 and attract more users. Then I would encourage those users that when they have time to give their app a new look to use Jewel, or if they like Royale and want to start new projects to use Jewel. And hopefully some will start new projects and start talking about how great Jewel and Royale are and that will bring in folks without any footprint in Flex.
Of course, I could be wrong. Anyway, back to MXRoyale bugs...
carlosrovira
commented
4 years ago Hi @aharui, as you, I think more people should come by 2020, but moreover, more people should come after browsers cut off flash at the end of 2020. So in 2021 I suppose will see migrations in a hurry, since many people use time will caught them.
Anyway, I understand your point of view, but don't think we really must to wait for a concrete successful migration with MXRoyale UI Set. Emulation components are a part of the Royale ecosystem and doesn't represent Royale in its globality. We already have other production Apps with Basic and Jewel (and maybe MDL?). So IMHO, that's not a point that should stop a 1.0, since many of us even doesn't work on that part of the technology (and that's another point that shows that is not a crucial part).
So making 1.0 wait for that milestone could be something that happen sooner or later and depending on that can be good or bad for Royale. Currently the migration with emulation sets we depend on, is the one from @alinakazi and @pashminakazi. But couldn't say much more about how their migration goes. Will be ready in 1 month? in 6? in 12? Maybe they could bring more light on this on how metrics they have about it.
For me 1.0 is about having a solid tech that people can build without pain and use without find problems at each step they do, or not finding some component they need (I mean core components), and something we can release at least each two months without much pain. MX/Spark, will be desirable, but not should stop us.
To end, I think people migrating from Flex will be users, but our real interest should be all other users that use any other tech out there, even React or Angular. Check the actual React users, that's a real big number to try to capture. Our big goal should be to attract React users to Royale. Numbers are pretty significant. I don't want we to fail for people that know and use React. Since that market is the one we should go for. The Flex migration market is small and each day getting smaller with people choosing React over the rest of techs. We are not listed here [1], we need to start appearing in webs like that as a real alternative.
Anyway, thinking a bit more in 1.0 needs. I found a couple of more things that would be good to have in 1.0:
1.- Separate MXRPC and other non visual classes from MXRoyale, since these are the things that not doing now will make people to refactor their configs at later time. So I think we should do this before 1.0. 2.- Finish Jewel Themes for plain and dark flavors
aharui
commented
4 years ago The currently active users I know about are reporting pain about MXRoyale. That's why that's what I'm working on.
You are welcome to try to attract React users. I am going to stick with Flex users for now.
Harbs and you have had success with Basic and Jewel but current users are using emulation in hopes that it reduces time/effort. So that's what I'm working on.
greg-dove
commented
4 years ago Based on my experience working with React/React Native, I believe it will be much harder to attract React users than it will be to continue to focus on Flex migration users. I'm not saying that it won't be possible, just saying that I think it will be much harder. I think we have a better chance of achieving some growth from other JS frameworks if we build community first, and IMO it will still be easier to build that with Flex migration users (while we still have some).
I do have substantial experience with marketing/business planning and implementation. But I left that behind some time ago and I freely admit I am not applying much more than general experience and instinct here. Without conducting research it's pretty hard for anyone to do much more I think. The only thing I have really considered in my thinking that is 'marketing-ish' is the notion of applying something like the 'adoption curve' model to the Flex migration process itself (not specifically for migrating Flex to Royale, but for migrating away from Flex by whatever means). I suspect that most of the proactive/forward-thinking 'customers' of the migration process have already done it. Those of you who have migrated your own apps to Royale are some of those people. Some may have chosen to retire their apps. Many others have chosen React, Angular, or other approaches. I'm hopeful that there are still quite a few left who have decided to re-assess Royale early this year before making the final selection and committing (I am aware of 2 in this position). But I can't imagine people leaving it much longer than that for anything that is important to their business. If you leave it so that completion of migration is after it no longer works in flash (2021) then it seems to me that it is either not important to your business or you are not really doing a great job looking after your business. I think it is logical to assume that the majority may have already gone through this process and that from middle of this year onwards we will be left only with 'laggards' category. These are generally (it is 'categorization', after all) reluctant people who, even if they choose Royale, will be less likely to act as advocates for Royale afterwards than the more 'innovative' people in earlier adoption categories.
I also believe that we will get a lot more exposure, kudos and boost for Royale as a technology and as a brand for each external-facing app that can be migrated and associated with Royale compared with only internal-facing apps (e.g. intranet Dashboards etc) that relatively few people really get to know about (or that take a lot more effort to be able to share as 'success stories'). External facing apps are usually more business-critical and are already likely to be in migration planning and many will be underway if indeed they have not already been completed. From our perspective in terms of marketing, 'Case studies' can be a lot more powerful if they are something you can visit via a url and see 'something' live (even if you can't see the more complex functionality that is only available via login). The same would be true for any newly developed app and not just for Flex migration apps, of course.
You could argue 'chicken-or-egg' for any of this in terms of what should come first. But in simple terms my rationale for quick 1.0 release is:
/2 cents
carlosrovira
commented
4 years ago Hi @greg-dove I agree with the points you posted. About React, it's clear that you have long experience with real work, and understand that you consider it difficult to attract React users, what it's not clear to me is the reason behind that. Maybe is due to actual adoption, long community? Or there are other technical points to take into account?. Thanks
piotrzarzycki21
commented
4 years ago Hi @greg-dove I agree with the points you posted. About React, it's clear that you have long experience with real work, and understand that you consider it difficult to attract React users, what it's not clear to me is the reason behind that. Maybe is due to actual adoption, long community? Or there are other technical points to take into account?. Thanks
One of the simplest reason why not is that - people who knows JS and hear about AS3 - think about it as an old and deprecated technology and connects it to Flash environment. <- This statement came from real cases. I don't see right now any way of spreading good things about Royale than trough migration for Flex application. This maybe the gate, cause if company X decided to use Royale and successfully migrate it's application - They may want to extend teams and "force" some of their non-Flex devs to learn Royale. - Otherwise we don't have enough power to attract user. - It's my opinion. :)
greg-dove
commented
4 years ago @carlosrovira I will go into a bit of detail about why I think the way I do about React etc., but I don't really want to 'promote' it :) just to speak plainly about why I think the way I do. Please don't doubt my commitment to Royale.
Anyway, I will say just a few things: I think @piotrzarzycki21 expressed some of my thoughts. When I look at the local React community I see it is larger and more active locally than we were 10 years ago with Flash/Flex, just observing the number of events and participation levels (I joined some local online community groups a few years back so see the activity). The community is self-sustaining/self-supporting at many levels.
At a technical level, (and less specific to React) many of the original advantages that FlexJS would have had if it were released 7-8 years ago (in current state of Royale, for example) have since been eroded. JS development is no longer the 'wild west' that we used to think of it as Flex developers back then. It is now disciplined, can be strongly typed (even at runtime for debug builds with React), and is easy to setup for testing, etc. We have focused a lot on 'smallest possible code' with Royale. While that is definitely given consideration in the projects I worked on, I have seen far more emphasis on code quality and maintainability (think: Flex PMD/SonarQube etc), and all of this support seems well integrated into workflows and IDEs.
Some of these changes to js development may have been natural evolution of js development itself, but I think certain practices also became emphasized after NodeJS and with more back-end developers entering the full stack category, bringing with them some of their 'quality' practices (sometimes this does not always work well in front-end, but I think in general it has advanced JS development a lot).
The technical reality is that because JS development has evolved, as3 has less advantages over JS than it did 7-8 years ago. So that is something I think adds a bit to what Piotr said. Outside that general impression, React includes functional coding style, with emphasis on immutable global state, so people who are committed to that paradigm will probably find it strange to go back to more 'loose' object oriented approach. I can say that I found it strange to 'get my head' into React paradigm, but once you do, it is interesting to know about.
The work I did with React was coding directly in es6+, so the code itself is actually not bad. I only know for sure what I have experienced and I focused more on Royale during the last year (I did do some React/RN coding, but much less), so I am sure things continue to change and evolve for React/ReactNative - 'moving fast and breaking things' was sometimes a frustrating part of the experience with React Native particularly, it was not all easy!) but I assume coding in at least es6 might be considered 'minimum standard' now. It was being transpiled to es5 for IE11 support with what I was working on. But it can be more minified if es6 is retained in the output so that is another form of future proofing that we don't yet have. Another advantage for React is React Native. Obviously React itself could be used via WebView/Cordova etc similar to Royale. But React Native gives closer to 'native' performance and has 'view' and 'code' running on different threads. Until Royale has more targets to match that, I think that would also probably be used as a justification against us by React people.
Again, this is again all just my opinion. Hopefully it is more clear why I think the way I do. I really don't want to talk more about React now :)
carlosrovira
commented
4 years ago Hi @greg-dove, very useful info here. I think I'll ask for just one more point, again based on your knowledge of both worlds. It make sense to continue developing Royale? I mean, React is conquering the world, I even think Angular is not competence since few years. What makes Royale (at least for you) still be an option? I ask about all of this to try continue understanding current eco-systems and see (openly) what's our strengths and our weaks. I continue thinking that our code is more cleaner, organized, but maybe that's no more the case. Thanks!
greg-dove
commented
4 years ago Please don't get the wrong impression Carlos. I personally prefer as3/mxml.... and I still think it is faster to build an app using as3 + mxml, based on my experience with React, so I did not want to give an impression that it does not make sense. I think the discussion here is more about what is the best way to grow the community (I am concerned that if we don't do that soon, then it may be extremely difficult for Royale longer term). I still think we can grow and evolve Royale but I think the best growth platform in the short/near term remains Flex migration. And I'm only outlining why I think the way I do about all this.... just opinion - I could be quite wrong.
I think 'clean and organized' code is largely a matter of discipline no matter what you code in, but is easier to achieve with application archetypes and IDE support/tools. As I mentioned, JS development in general has evolved in these areas. The work I did in React seems very convention-based and I think that is considered 'normal'. Sometimes it felt very 'boiler-plate' to set up common 'container' and 'view' type variations between React and React Native for example (it was in the same codebase, but we tended to have different view components between React and React Native instead of shared view component, although it is possible to use or create view components to abstract the lower level differences between the 2 target types in some cases. Rarely views were split even more granular : iOS vs android). But that same 'boiler-plate' feeling was present in parts of many Flex apps I worked on in the past and I know those approaches added to maintainability, and that is a common priority in most projects. It's why I believe that apps with some sort of MVC architecture are easier to port to Royale than those without, for instance.
I think @joshtynjala has done some work with React too, so may have some insights to share. And I know Josh has added some JSX support into Royale, which I am really curious about, but did not try to find info on or explore yet. Maybe there are other ways to bridge the gap?
carlosrovira
commented
4 years ago Hi @greg-dove, thanks for your comments on that. I think are very useful that people working on both worlds and choosing Royale instead of React or other tech out there (as a personal election) seems to me that Royale has its place, other thing is work needs, thatI think is another kind of evaluation.
I think @joshtynjala as you was involved in React and tried with one of his apps but he announces he was letting React world. I suppose he he returned to AS3, Royale, haXe and Feathers was due to his technical preferences in all those technologies instead of React.
Anyway, it encourages me to follow up improving Royale, since I prefer this AS3/MXML world to the other one based in all what I saw to date.
Thanks!
maimoy
commented
4 years ago Except from your magnificent work that you have already done i think that it is very important to have the versions that can be downloading updated and fully working even with the bugs that need to be addressed. Is the current npm version working as expected? I also think that the maven procedure to build a project is not the easier that a programmer not know anything about this to be familiar as you to want be involved with. I think also that examples needed for work with Server and examples for real-rime sync and messaging (I was using weborb)
Thank you Appreciate your work. Waiting for the version 1
Στις Κυρ, 5 Ιαν 2020 στις 11:10 π.μ., ο/η Carlos Rovira < notifications@github.com> έγραψε:
Hi @greg-dove https://github.com/greg-dove, thanks for your comments on that. I think are very useful that people working on both worlds and choosing Royale instead of React or other tech out there (as a personal election) seems to me that Royale has its place, other thing is work needs, thatI think is another kind of evaluation.
I think @joshtynjala https://github.com/joshtynjala as you was involved in React and tried with one of his apps but he announces he was letting React world. I suppose he he returned to AS3, Royale, haXe and Feathers was due to his technical preferences in all those technologies instead of React.
Anyway, it encourages me to follow up improving Royale, since I prefer this AS3/MXML world to the other one based in all what I saw to date.
Thanks!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apache/royale-asjs/issues/648?email_source=notifications&email_token=AAOVS6MG7HYVGBUVXVBB5NTQ4GPZDA5CNFSM4KCFZMT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDR4DA#issuecomment-570891788, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOVS6OGYLZ3ZKNYM2G6JRLQ4GPZDANCNFSM4KCFZMTQ .
carlosrovira
commented
4 years ago Hi @maimoy thanks for express your points. Very appreciated.
I think the current contributors are giving options: Ant, Maven, npm, asconfigc, Moonshine IDE,... I use to concentrate in particular in Maven, but others try to focus in other build systems. I think we need the help of community (like you) to get all possible configs for different examples and code working in our flavors. It's the only way to get all working in all different options. For NPM I think 0.9.6 has an issue. Moonshine IDE has a workaround for it, and the solution can be found in our mailing list.
About Real-Time: Are you talking about RTMP protocol? We still don't have that protocol support. I saw JS implementations but I'm afraid very few people has requested that to this time. So I don't see this coming soon unless someone wants to make this real and contract someone to do it. For now AMF is the only web orb protocol supported, and you should be able to use it without problem.
Thanks!
We should focus on what still needs to be done to call a release a "1.0" release. Here we should compile a list and document the tasks. I'm willing to help, but I don't know exactly what to do.