royale-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Royale vs other frameworks
Date Fri, 09 Nov 2018 18:00:54 GMT
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.


From: "Frost, Andrew" <>
Reply-To: "" <>
Date: Friday, November 9, 2018 at 8:04 AM
To: "" <>
Subject: RE: Royale vs other frameworks


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..



From: Alex Harui []
Sent: 08 November 2018 08:44
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,

From: "<>" <<>>
Reply-To: "<>" <<>>
Date: Wednesday, November 7, 2018 at 11:47 PM
To: "<>" <<>>
Subject: Re: Royale vs other frameworks


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.

Chemnitz, Germany<>

Von: Carlos Rovira <<>>
Gesendet: Mittwoch, 7. November 2018 23:54
Betreff: Re: Royale vs other frameworks

El mié., 7 nov. 2018 a las 21:09, Fréderic Cox (<<>>)
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<>

View raw message