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://clicktime.symantec.com/a/1/Z6dn14MIqUIvhZqA2h-Noh2wJ6coFaIJwEGxFSQxrhY=?d=6buWLCu34nmhI4HzTUcvagAlUc4vaLZg5Lzdaqw4OHXFdf7lSt5UzmYsBtTHnHVw2DM7saa9vp1CRJEMCoc3jF4WYmHkAUuBQOUpwdo9dj7kLzJxjPFH04ZxZFz1BPWIHCLHoFadReI_SbWmWNnKSPfaw9spZmmSd-U4_DVjytmsiH4uTwnSmmkx6V_EA5NLD91o8uOOD0n6HDUXD2HMQuubvRKOkrHezZWVd5Y-VZ6Xq4XqFxHcJSNyL8JAQrtlKHnEMTDM_NqNV3o5ApeQDL7rMtyNhDQ89aY5eXR6D47qwJjg0AqhftOp7qGx8EAIV49u9dFTjIZNu3nuGK5oE7_UFB8xQZ7fT2cNA_1_mwuFNZ0iuFkuD9nAHI1A18IAXJBwrL0Yr9TDZgQcCFq6fKyhhEWmXmv_XDwmuA%3D%3D&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.carnet-gmbh.de%252F%26data%3D02%257C01%257Caharui%2540adobe.com%257Cb9d6f3655d5f4062defd08d6454e5f15%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636772600241049370%26sdata%3DMWAivJPeL3UA79kw7U0XJc%252Bj3%252Fxtqe0Q5B797aB50JM%253D%26reserved%3D0>
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://clicktime.symantec.com/a/1/NirvXtLDnXLEXnBVuDAw6w4sCq_J9nSGchb4t2cHkgU=?d=6buWLCu34nmhI4HzTUcvagAlUc4vaLZg5Lzdaqw4OHXFdf7lSt5UzmYsBtTHnHVw2DM7saa9vp1CRJEMCoc3jF4WYmHkAUuBQOUpwdo9dj7kLzJxjPFH04ZxZFz1BPWIHCLHoFadReI_SbWmWNnKSPfaw9spZmmSd-U4_DVjytmsiH4uTwnSmmkx6V_EA5NLD91o8uOOD0n6HDUXD2HMQuubvRKOkrHezZWVd5Y-VZ6Xq4XqFxHcJSNyL8JAQrtlKHnEMTDM_NqNV3o5ApeQDL7rMtyNhDQ89aY5eXR6D47qwJjg0AqhftOp7qGx8EAIV49u9dFTjIZNu3nuGK5oE7_UFB8xQZ7fT2cNA_1_mwuFNZ0iuFkuD9nAHI1A18IAXJBwrL0Yr9TDZgQcCFq6fKyhhEWmXmv_XDwmuA%3D%3D&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fabout.me%252Fcarlosrovira%26data%3D02%257C01%257Caharui%2540adobe.com%257Cb9d6f3655d5f4062defd08d6454e5f15%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636772600241059379%26sdata%3Dmlk8Xk7vgQQ%252BZkH7j1p8cAjHf3e%252FyyOrc15kKJVGvE8%253D%26reserved%3D0>
