I agree with everything Andrew said. I want to comment on a couple of things.
1. With the current team size, we don’t have the resources to max out on compatibility any time soon by going through the Flex APIs one at a time. I would bet that there is at least one API in Flex that nobody who has a Flex app to migrate has ever used, and a bunch more that don’t add significant value to your application (certain animations), and another group that aren’t really required to get your app off of Flash (drop shadows?). So my approach almost has to be “on-demand” mixed with some prioritization. Folks simply need to start migrating and tell us what APIs don’t exist in the emulation set. Then we’ll discuss whether there is a workaround, or whether you really need it to get into “early-production”, and whether you can develop the missing capability yourself and contribute it back. It is inefficient for us to guess what APIs you need and be wrong. So that’s why the way Royale gets developed has to be different than when Adobe was investing lots of money in Flex. 2. I am hopeful that Andrew and Harman will reach a point where they feel comfortable promoting their Royale support to a wider audience. In talking to some large enterprises in the past, having an established brick-and-mortar business that can provide 24/7 support is a major factor in which frameworks they are willing to choose. Sending email to this list and hoping someone answers is not good enough. It would be great for many folks to be able to start new consultancies or otherwise make a living from Royale consulting, but some enterprises will not bet on new consultancies for support, but they may bet on new folks for development expertise. So, if you have a Flex app to migrate, and are concerned about ongoing support for Royale, speak up here or contact Andrew off-list. Thanks, -Alex From: "Frost, Andrew" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, November 9, 2018 at 8:04 AM To: "[email protected]" <[email protected]> Subject: RE: Royale vs other frameworks Hi Adding some of our thoughts into this .. we’ve been looking at Royale since April (when I had an introduction to it from Alex) and although it took us a while to get started, I’ve come to really appreciate the approach and structure for this. I’m more in favour of the strands/beads approach to creating the functionality, rather than trying to reproduce the whole of the old Flex framework with its complexity – to the point where, when we come across a component that we need from the MX library (e.g. ViewStack), we’re more inclined to just create a very simple specialisation of a ContainerBase to do this for us rather than to use the emulation component which has other dependencies that would be pulled in. Our current work is to migrate an existing Flex app, and we are using some of the emulation components, but mostly the utility classes rather than the visual UI components.. I would agree with Alex about the contribution model and how this would work; we’re a slightly odd case though as we’re at consultancy firm (at least, the bit of Harman that I work for) and so we have been doing migration services for Flash/Flex apps to HTML/JavaScript. Our larger commercial projects so far have been using other JavaScript frameworks (notably Angular) but these are re-writes rather than migrations, and have significant differences from the original apps (as well as taking a lot of effort and having new bugs being introduced during the re-write). Royale has a great advantage in keeping much of the same application source code which (hopefully!) has more maturity. We’ve also invested somewhat in some internal tools that are helping us to migrate code across and allow us to convert from Flex APIs to Royale APIs in a semi-automated way, and as we progress further in our current migration project, the tool then gets refined to work even better. Contributing back updates/changes helps other folk; we’ve done a few contributions so far and have a few more we need to sort out and upstream. Documentation is another area I think we could help with – e.g. having to research how to make the data binding work properly for state-based components cost us a day or so of effort recently. We’ve worked extensively on open/shared source code initiatives in the past, and as a commercial consultancy firm it works best for us if there’s a paying customer who wants to have their application created and is happy for us to then upstream any changes into the shared source community (normally our customers own all the IPR that we create for them). We retain our competency and experience, but can help improve the general ecosystem, and it tends to work very well. So coming back to the specific points raised by Ulrich: · Work towards 1.0 release. Create a features/release plan. § Good idea but tricky to do in a community-led project, where different contributors have different goals… · Max out compatibility to currently existing Flex projects in the IT industry. Many many companies have customer tailored Adobe Flex applications. Easyly transfering them to web would bring alot of support. § Agree on this but am not 100% sure that it’s feasible to bring all of the Flex framework into Royale without a lot of work, plus extra baggage/complexity etc. I think there’s a middle ground where some of the commonly used components are emulated fully (e.g. BorderContainer) but some of the other functionality could be stripped back/removed. If you wanted to just ship your Flex application as-is, then we can just provide the Flash/AIR runtime and turn it into an out-of-browser application… · Improve stability before adding features. The developers love the maturity of Flex. § Definitely agree with this – but tricky to do without more test cases and also real-world application that find out about the bugs. The other complexity is in making changes: with any change made, if it changes the functionality then it may introduce a fault into an existing application that might rely upon the existing behavior.. · Find more contributers § Agree with Alex: companies that want to use Royale should plan to contribute back too… · Find more users § … which should come with the improving maturity of Royale and with the increase in companies wanting to migrate their Flex apps… § Also probably helped if we can improve the “getting started” documentation and demonstrating how to get up and running using the various IDEs.. · May be create a company around Royale offering consultancy services and addon components. And it would most importantly open Royale up for investors. § Not sure we need a new company (we provide consultancy services around Flash/AIR/Royale..!) although it’s an interesting point about investors … surely that only works if you’re looking to monetize it; if that would happen through the consultancy services then I would think it’s a fairly risky proposition – although equally, it might be a very good route to improve the maturity! It's an interesting project though, and one I hope will continue to develop and improve. In the six months that I’ve following these posts, I do think that the interest in it has increased and the work being done on it has really helped to increase its usability and usefulness.. thanks Andrew From: Alex Harui [mailto:[email protected]] Sent: 08 November 2018 08:44 To: [email protected] Subject: [EXTERNAL] Re: Royale vs other frameworks Hi Ulrich, While it would be great if we could do all of these things in the order you listed, it is important to understand that Royale is not a corporate-driven product like Flex was at Adobe. I’m the only person who is currently able to contribute full-time. Everyone else contributes when they can. Apache projects are volunteer-driven. There is no way a team of part-time volunteers can commit to a release plan or max out Royale’s compatibility with Flex any time soon. Or even test Royale like Adobe tested Flex. Instead, the contribution model has to change. Every person wanting to migrate their Flex app to Royale should plan to have at least one person under their control learn how to fix bugs and write tests and add compatibility features to Royale. Doing so gives you control over the future of Royale. There won’t be some “other corporation” you have to plead with to have them fix a bug or add a feature. Instead, those of you who are stakeholders because you have Royale apps will be able to make the changes you need when you need it, and no “other corporation” can suddenly take almost all of the developers away from the project. IMO, we need more contributors first, in order to make the rest happen, and the best source of these new contributors are the folks using Royale. Yes, that makes it harder in some ways than just using Royale, but if you are one of the early experts in Royale, and Royale becomes popular, you will have a competitive advantage over everyone else. My 2 cents, -Alex From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, November 7, 2018 at 11:47 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: Royale vs other frameworks Hello, I think before including other technologies there are more important things: · Work towards 1.0 release. Create a features/release plan. · Max out compatibility to currently existing Flex projects in the IT industry. Many many companies have customer tailored Adobe Flex applications. Easyly transfering them to web would bring alot of support. · Improve stability before adding features. The developers love the maturity of Flex. · Find more contributers · Find more users · May be create a company around Royale offering consultancy services and addon components. And it would most importantly open Royale up for investors. Currently we are also exploring Royale to 1. convert existing apps and 2. give our dev team something they are used to. Ulrich Müller Dipl. Inf. CARNET GmbH Chemnitz, Germany www.carnet-gmbh.de<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FZ6dn14MIqUIvhZqA2h-Noh2wJ6coFaIJwEGxFSQxrhY%3D%3Fd%3D6buWLCu34nmhI4HzTUcvagAlUc4vaLZg5Lzdaqw4OHXFdf7lSt5UzmYsBtTHnHVw2DM7saa9vp1CRJEMCoc3jF4WYmHkAUuBQOUpwdo9dj7kLzJxjPFH04ZxZFz1BPWIHCLHoFadReI_SbWmWNnKSPfaw9spZmmSd-U4_DVjytmsiH4uTwnSmmkx6V_EA5NLD91o8uOOD0n6HDUXD2HMQuubvRKOkrHezZWVd5Y-VZ6Xq4XqFxHcJSNyL8JAQrtlKHnEMTDM_NqNV3o5ApeQDL7rMtyNhDQ89aY5eXR6D47qwJjg0AqhftOp7qGx8EAIV49u9dFTjIZNu3nuGK5oE7_UFB8xQZ7fT2cNA_1_mwuFNZ0iuFkuD9nAHI1A18IAXJBwrL0Yr9TDZgQcCFq6fKyhhEWmXmv_XDwmuA%253D%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttp%25253A%25252F%25252Fwww.carnet-gmbh.de%25252F%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257Cb9d6f3655d5f4062defd08d6454e5f15%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636772600241049370%2526sdata%253DMWAivJPeL3UA79kw7U0XJc%25252Bj3%25252Fxtqe0Q5B797aB50JM%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C003af98c76884b60abc008d6465cf70b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636773762427548618&sdata=uMY3jceyzTxwoQXLnTFz7M41e6bYypmZHCzhbnjQCO4%3D&reserved=0> Von: Carlos Rovira <[email protected]<mailto:[email protected]>> Gesendet: Mittwoch, 7. November 2018 23:54 An: [email protected]<mailto:[email protected]> Betreff: Re: Royale vs other frameworks Hi, El mié., 7 nov. 2018 a las 21:09, Fréderic Cox (<[email protected]<mailto:[email protected]>>) escribió: Thanks for clarifying this a bit more Carlos, it is an interesting topic for me as the company I work for is in some trouble and if I should find a new job (unsure at the moment) then it can be that I need to use typescript, react or angular .. as the entire dev community seems to use these days. Nobody has heard of Royale, so I'm planning to look into also because I like the workflow with AS3 and MXML. is clear that now the game is Angular, React and VueJS. Royale will need more time to be considered by more people. I expect that as me and others can get real apps written in Royale, people will want to enter Royale. I can say that I think now is a good time. But if you are making a change, I'm afraid you'll need to go with the stablished JS frameworks. Consultancy companies shell what is hot, since is what clients demand. In my company, since we shell products and services (not technology itself), we can go with Royale, since our clients don't know how is done, and it doesn't matter for them, while works ;) So for us, Royale is the clear winner. I see similar concepts so far in those Js frameworks I recently started to pick up, I'm not very skilled in them yet so can't compare it yet. Truth is there are not that many actionscripts developers anymore so I think part of Royale's succes would be to embrace typescript. I'm with you, Royale will be a real option with two things: 1) TypeScript support 2) More NodeJS support (We support NodeJS, but I think we need real world testers that know Royale and signal if we need to improve things, and I'm sure will be some things to improve for sure) How would such a thing be achieved? I wouldn't know where to start at this point to be honest :-) If you refer to add TS support, you can start it as a hobby project trying to get some fun. Some points I'll do: 1) you'll need to be confortable with Royale, install repos, build with Maven and ANT, build SDK from repos. Use VS Code with you SDK and try some example, for example Jewel Example. I think this is a must, don't know how much of this you still know, if not invest some time trying it. I think is funny 2) Browser compiler code and localize AS3 grammar, and related classes and read in the wiki how compiler works with this. I think Alex wrote something in the wiki. You can always ask here. I still does not have the knowledge in that field (hope to acquire at some time as I end my work in other parts), but others could help you 3) now TS: I think TypeScript grammar should be probably available in a license that we can use so the work should be to bring it to the project and wire it in the compiler, so .ts files will be recognized and could be analyzed, processed and compiled. Don't know how much time/effort could be this, but again, you can ask here. If you take that seriously and make some PRs with some quality and people see your commits are reliable (don't break things, and don't need to editing, or few editing) you can become committer and continue on your own. If I have time, I think that would be a very cool and fun task to do, but I'm buried in other tasks, and I think I have work in Royale for years, and others too, so I think we need help on that field to make that happen. Thanks and hope you're encouraged to participate! :) -- Carlos Rovira http://about.me/carlosrovira<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FNirvXtLDnXLEXnBVuDAw6w4sCq_J9nSGchb4t2cHkgU%3D%3Fd%3D6buWLCu34nmhI4HzTUcvagAlUc4vaLZg5Lzdaqw4OHXFdf7lSt5UzmYsBtTHnHVw2DM7saa9vp1CRJEMCoc3jF4WYmHkAUuBQOUpwdo9dj7kLzJxjPFH04ZxZFz1BPWIHCLHoFadReI_SbWmWNnKSPfaw9spZmmSd-U4_DVjytmsiH4uTwnSmmkx6V_EA5NLD91o8uOOD0n6HDUXD2HMQuubvRKOkrHezZWVd5Y-VZ6Xq4XqFxHcJSNyL8JAQrtlKHnEMTDM_NqNV3o5ApeQDL7rMtyNhDQ89aY5eXR6D47qwJjg0AqhftOp7qGx8EAIV49u9dFTjIZNu3nuGK5oE7_UFB8xQZ7fT2cNA_1_mwuFNZ0iuFkuD9nAHI1A18IAXJBwrL0Yr9TDZgQcCFq6fKyhhEWmXmv_XDwmuA%253D%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttp%25253A%25252F%25252Fabout.me%25252Fcarlosrovira%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257Cb9d6f3655d5f4062defd08d6454e5f15%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636772600241059379%2526sdata%253Dmlk8Xk7vgQQ%25252BZkH7j1p8cAjHf3e%25252FyyOrc15kKJVGvE8%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C003af98c76884b60abc008d6465cf70b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636773762427558627&sdata=vHT1nf9wz4nnuelpFgbABh%2FOaZvvi16K8B3vdRGdO0w%3D&reserved=0>
