RE: Royal-Js sdk and more...

[Idylog - Nicolas Granon]

Hi Serkan,

Welcome to the list, and welcome to this exciting project !

I do not belong to the Apache Royale "core team", but since you seems to be on 
the "application developer" side like me, I thought I could try to bring some 
information to you.
I do not have any "expertise" in Apache Royale, and maybe some of my comments 
are not accurate.
But, like you, we have Flex applications to migrate, and, at least, my comments 
reflect what we have understood so far.  

I apologize to all "core team" members for any wrong/inexact opinion in there. 
Also, it is possible that my English does not adequately reflects my thoughts.

At this time, the Apache Royale project in reaching the end of some major 
restructuring work. That might explain some difficulties in building the SDK.
For us, we do not compile the SDK ourselves : we only use the binaries 
distribution.
But we know that SDK compile-from-source process is not, right now, fully 
operational. From what I understand, it is a matter of days before it is fully 
operational again.
We are in kind of "intermediate" step until restructuring is fully achieved.

As of today, you could download the FlexJS (v.0.8) or the Apache Royale (v.0.9) 
SDK.
Obviously, the project name changed (and it also caused some delay in the 
availability of a full operational version) and is now "Apache Royale".
FlexJS (0.8) is more stable but since there were many name-changes I believe it 
is better to go with Royale 0.9 despites it is not fully operational as of 
today.


With Apache Royale you code mxml and as, like "before" (Flex).
The compiler is able to produce a SWF file (like before) *or* (more or less) 
equivalent javascript scripts. In the case of javascript output, the Flash 
Player is not needed at runtime.

You still can build with ant. The compiler name is still mxmlc (or compc for 
libraries). Most parameters are the same. Of course, some new parameters apply 
to javascript ouput.

Yes you can use FlashBuilder (this is what we do).
I have send one or two contribution to this list on how to setup FB.
As of today, there are still some minor issues, but I'm confident all will be 
resolved very quickly, as we approach to v.1.0.

As I understand your question about "application structure", and as far as I 
know, it is a very classic "javascript includes" structure (like angular, react 
and many other).
Debug output is human-readable, production (release) output is minified.
But since you can debug from (as3) source code, I believe you could totally 
ignore javascript output. 

As I see it, the project has really strong points :
The compiler is excellent
AS3 language syntax is fully preserved
MXML syntax is fully preserved
The "js side" output uses proven tools (google closures...)
The development team has excellent qualifications and they are very thoughtful 
and dedicated people.
The community is very supportive.
(strong point ? may be discussed !) It is really a community project without an 
official roadmap and without any "directing board". You can really engage in 
architectural and implementation discussion, express your opinion and make it 
prevail if it makes sense.
(I'm sure I'm forgetting some strong point !)

And also weak points :
It is not yet fully specified (work on theming, localization, UI components 
capabilities and other aspects is still in progress)
The initial goal was to have "almost full compatibility" between SWF (flash 
player) and JS output. In my eyes (it is only my personal opinion) this is not 
such a good goal (even if I understand the motivations). It adds much 
complexity but I'm pretty sure that very few people will need it. I feel that 
since a few weeks more people understand that outputting JS is more important 
than outputting SWF.
The community is not very large and web presence is small. This is normal for 
an emerging project which is not backed up by some mega corporation.
You cannot expect to have identical component names/API than in mx or spark. 
You will have to replace (when migrating an existing application) almost all 
component declaration and customization, and also most event management calls. 
However, non-UI code should only need minor adjustments.
(weak point ? may be discussed !) It is really a community project without an 
official roadmap and without any "directing board". You will not get a 
"packaged" solution, ready to consume.
(I'm sure I'm forgetting some weak point !)

I would like to encourage people like you to go with this project : it has very 
strong foundation and despites its current and temporary unstable state (which 
should resolve quickly) it offers to application developers like you and me a 
wonderful and modern tool for building "web-apps".
The more people like you we have on board, the more chances we have to get 
Apache Royale in the top-three app development SDKs.

May I remind again that I am not part of the sdk developing team, and that my 
opinions and assertions are under my own responsibi

Re: Royal-Js sdk and more...

[Piotr Zarzycki]

Hi Nicolas, Serkan,

If may add something. There is also possibility to work with project using
Maven which is currently perfectly working in case of building SDK. You can
right now do not wait for fix but could take an approach IDE agnostic.

1) You can build SDK by Maven
2) Prepare Maven pom for your hello world
3) Use working IDE for code editing - once you change something rebuild by
Maven.
4) SKD has changed - ok I'm pulling everything from the repo, rebuild SDK
by Maven and can use it!

I'm working on fix where you will have to do only #2 and #3, cause after
renaming something has been broken and you need to build locally SDK.

In the next couple of weeks probably I will describe such approach more
widely. I've been working like that for the past 3 years with FlexJS and
now Royale, only from time to time I was building applications by Moonshine
or VSCode.

Thanks, Piotr

2017-11-05 23:56 GMT+01:00 Idylog - Nicolas Granon :

> Hi Serkan,
>
> Welcome to the list, and welcome to this exciting project !
>
> I do not belong to the Apache Royale "core team", but since you seems to
> be on the "application developer" side like me, I thought I could try to
> bring some information to you.
> I do not have any "expertise" in Apache Royale, and maybe some of my
> comments are not accurate.
> But, like you, we have Flex applications to migrate, and, at least, my
> comments reflect what we have understood so far.
>
> I apologize to all "core team" members for any wrong/inexact opinion in
> there. Also, it is possible that my English does not adequately reflects my
> thoughts.
>
> At this time, the Apache Royale project in reaching the end of some major
> restructuring work. That might explain some difficulties in building the
> SDK.
> For us, we do not compile the SDK ourselves : we only use the binaries
> distribution.
> But we know that SDK compile-from-source process is not, right now, fully
> operational. From what I understand, it is a matter of days before it is
> fully operational again.
> We are in kind of "intermediate" step until restructuring is fully
> achieved.
>
> As of today, you could download the FlexJS (v.0.8) or the Apache Royale
> (v.0.9) SDK.
> Obviously, the project name changed (and it also caused some delay in the
> availability of a full operational version) and is now "Apache Royale".
> FlexJS (0.8) is more stable but since there were many name-changes I
> believe it is better to go with Royale 0.9 despites it is not fully
> operational as of today.
>
>
> With Apache Royale you code mxml and as, like "before" (Flex).
> The compiler is able to produce a SWF file (like before) *or* (more or
> less) equivalent javascript scripts. In the case of javascript output, the
> Flash Player is not needed at runtime.
>
> You still can build with ant. The compiler name is still mxmlc (or compc
> for libraries). Most parameters are the same. Of course, some new
> parameters apply to javascript ouput.
>
> Yes you can use FlashBuilder (this is what we do).
> I have send one or two contribution to this list on how to setup FB.
> As of today, there are still some minor issues, but I'm confident all will
> be resolved very quickly, as we approach to v.1.0.
>
> As I understand your question about "application structure", and as far as
> I know, it is a very classic "javascript includes" structure (like angular,
> react and many other).
> Debug output is human-readable, production (release) output is minified.
> But since you can debug from (as3) source code, I believe you could
> totally ignore javascript output.
>
> As I see it, the project has really strong points :
> The compiler is excellent
> AS3 language syntax is fully preserved
> MXML syntax is fully preserved
> The "js side" output uses proven tools (google closures...)
> The development team has excellent qualifications and they are very
> thoughtful and dedicated people.
> The community is very supportive.
> (strong point ? may be discussed !) It is really a community project
> without an official roadmap and without any "directing board". You can
> really engage in architectural and implementation discussion, express your
> opinion and make it prevail if it makes sense.
> (I'm sure I'm forgetting some strong point !)
>
> And also weak points :
> It is not yet fully specified (work on theming, localization, UI
> components capabilities and other aspects is still in progress)
> The initial goal was to have "almost full compatibility" between SWF
> (flash player) and JS output. In my eyes (it is only my personal opinion)
> this is not such a good goal (even if I understand the motivations). It
> adds much complexity but I'm pretty sure that very few people will need it.
> I feel that since a few weeks more people understand that outputting JS is
> more important than outputting SWF.
> The community is not very large and web presence is small. This is normal
> for an emerging project which is not backed up by some mega corporation.
> You cannot expec

Re: Royal-Js sdk and more...

[Serkan Taş]

Hi Piotr,

It is not a big deal to work on an editor and build with maven. I can 
live with it :)


Thanx


06.11.2017 02:10 tarihinde Piotr Zarzycki yazdı:

Hi Nicolas, Serkan,

If may add something. There is also possibility to work with project 
using Maven which is currently perfectly working in case of building 
SDK. You can right now do not wait for fix but could take an approach 
IDE agnostic.


1) You can build SDK by Maven
2) Prepare Maven pom for your hello world
3) Use working IDE for code editing - once you change something 
rebuild by Maven.
4) SKD has changed - ok I'm pulling everything from the repo, rebuild 
SDK by Maven and can use it!


I'm working on fix where you will have to do only #2 and #3, cause 
after renaming something has been broken and you need to build locally 
SDK.


In the next couple of weeks probably I will describe such approach 
more widely. I've been working like that for the past 3 years with 
FlexJS and now Royale, only from time to time I was building 
applications by Moonshine or VSCode.


Thanks, Piotr

2017-11-05 23:56 GMT+01:00 Idylog - Nicolas Granon >:


Hi Serkan,

Welcome to the list, and welcome to this exciting project !

I do not belong to the Apache Royale "core team", but since you
seems to be on the "application developer" side like me, I thought
I could try to bring some information to you.
I do not have any "expertise" in Apache Royale, and maybe some of
my comments are not accurate.
But, like you, we have Flex applications to migrate, and, at
least, my comments reflect what we have understood so far.

I apologize to all "core team" members for any wrong/inexact
opinion in there. Also, it is possible that my English does not
adequately reflects my thoughts.

At this time, the Apache Royale project in reaching the end of
some major restructuring work. That might explain some
difficulties in building the SDK.
For us, we do not compile the SDK ourselves : we only use the
binaries distribution.
But we know that SDK compile-from-source process is not, right
now, fully operational. From what I understand, it is a matter of
days before it is fully operational again.
We are in kind of "intermediate" step until restructuring is fully
achieved.

As of today, you could download the FlexJS (v.0.8) or the Apache
Royale (v.0.9) SDK.
Obviously, the project name changed (and it also caused some delay
in the availability of a full operational version) and is now
"Apache Royale".
FlexJS (0.8) is more stable but since there were many name-changes
I believe it is better to go with Royale 0.9 despites it is not
fully operational as of today.


With Apache Royale you code mxml and as, like "before" (Flex).
The compiler is able to produce a SWF file (like before) *or*
(more or less) equivalent javascript scripts. In the case of
javascript output, the Flash Player is not needed at runtime.

You still can build with ant. The compiler name is still mxmlc (or
compc for libraries). Most parameters are the same. Of course,
some new parameters apply to javascript ouput.

Yes you can use FlashBuilder (this is what we do).
I have send one or two contribution to this list on how to setup FB.
As of today, there are still some minor issues, but I'm confident
all will be resolved very quickly, as we approach to v.1.0.

As I understand your question about "application structure", and
as far as I know, it is a very classic "javascript includes"
structure (like angular, react and many other).
Debug output is human-readable, production (release) output is
minified.
But since you can debug from (as3) source code, I believe you
could totally ignore javascript output.

As I see it, the project has really strong points :
The compiler is excellent
AS3 language syntax is fully preserved
MXML syntax is fully preserved
The "js side" output uses proven tools (google closures...)
The development team has excellent qualifications and they are
very thoughtful and dedicated people.
The community is very supportive.
(strong point ? may be discussed !) It is really a community
project without an official roadmap and without any "directing
board". You can really engage in architectural and implementation
discussion, express your opinion and make it prevail if it makes
sense.
(I'm sure I'm forgetting some strong point !)

And also weak points :
It is not yet fully specified (work on theming, localization, UI
components capabilities and other aspects is still in progress)
The initial goal was to have "almost full compatibility" between
SWF (flash player) and JS output. In my eyes (it is only my
personal opinion) this is not such a good goal (even if I
understand the motivations). It adds much complexity but I

Re: Royal-Js sdk and more...

[Serkan Taş]

Hi Nikola,

Thank you for realy detailed response.

I have been application developer for long time but better like to do 
something in server side. Current flex UI need to be moved to 
flash-player-free version is the UI of Job Scheduler  named Pınara.


I do not perefer normally to compile the sdk myself, but it may be 
helpful because there may be some locale problems from local settings 
and i may face them as early as possible. But it is going to be very 
nice if your share the sdk binaries download link.


I am providing consultancy services during my day and only have time 
afterworks if i feel good,  so i can not fully involve on my migration plan.


And i share the same feeling with you about the importance of JS output :)

Serkan Taş


06.11.2017 01:56 tarihinde Idylog - Nicolas Granon yazdı:

Hi Serkan,

Welcome to the list, and welcome to this exciting project !

I do not belong to the Apache Royale "core team", but since you seems to be on the 
"application developer" side like me, I thought I could try to bring some information to 
you.
I do not have any "expertise" in Apache Royale, and maybe some of my comments 
are not accurate.
But, like you, we have Flex applications to migrate, and, at least, my comments 
reflect what we have understood so far.

I apologize to all "core team" members for any wrong/inexact opinion in there. 
Also, it is possible that my English does not adequately reflects my thoughts.

At this time, the Apache Royale project in reaching the end of some major 
restructuring work. That might explain some difficulties in building the SDK.
For us, we do not compile the SDK ourselves : we only use the binaries 
distribution.
But we know that SDK compile-from-source process is not, right now, fully 
operational. From what I understand, it is a matter of days before it is fully 
operational again.
We are in kind of "intermediate" step until restructuring is fully achieved.

As of today, you could download the FlexJS (v.0.8) or the Apache Royale (v.0.9) 
SDK.
Obviously, the project name changed (and it also caused some delay in the availability of 
a full operational version) and is now "Apache Royale".
FlexJS (0.8) is more stable but since there were many name-changes I believe it 
is better to go with Royale 0.9 despites it is not fully operational as of 
today.


With Apache Royale you code mxml and as, like "before" (Flex).
The compiler is able to produce a SWF file (like before) *or* (more or less) 
equivalent javascript scripts. In the case of javascript output, the Flash 
Player is not needed at runtime.

You still can build with ant. The compiler name is still mxmlc (or compc for 
libraries). Most parameters are the same. Of course, some new parameters apply 
to javascript ouput.

Yes you can use FlashBuilder (this is what we do).
I have send one or two contribution to this list on how to setup FB.
As of today, there are still some minor issues, but I'm confident all will be 
resolved very quickly, as we approach to v.1.0.

As I understand your question about "application structure", and as far as I know, it is 
a very classic "javascript includes" structure (like angular, react and many other).
Debug output is human-readable, production (release) output is minified.
But since you can debug from (as3) source code, I believe you could totally 
ignore javascript output.

As I see it, the project has really strong points :
The compiler is excellent
AS3 language syntax is fully preserved
MXML syntax is fully preserved
The "js side" output uses proven tools (google closures...)
The development team has excellent qualifications and they are very thoughtful 
and dedicated people.
The community is very supportive.
(strong point ? may be discussed !) It is really a community project without an official 
roadmap and without any "directing board". You can really engage in 
architectural and implementation discussion, express your opinion and make it prevail if 
it makes sense.
(I'm sure I'm forgetting some strong point !)

And also weak points :
It is not yet fully specified (work on theming, localization, UI components 
capabilities and other aspects is still in progress)
The initial goal was to have "almost full compatibility" between SWF (flash 
player) and JS output. In my eyes (it is only my personal opinion) this is not such a 
good goal (even if I understand the motivations). It adds much complexity but I'm pretty 
sure that very few people will need it. I feel that since a few weeks more people 
understand that outputting JS is more important than outputting SWF.
The community is not very large and web presence is small. This is normal for 
an emerging project which is not backed up by some mega corporation.
You cannot expect to have identical component names/API than in mx or spark. 
You will have to replace (when migrating an existing application) almost all 
component declaration and customization, and also most event management calls. 
However, non-UI code should only

Re: Royal-Js sdk and more...

[Piotr Zarzycki]

Hi Serkan,

Sorry for the delay. We have two packages of Royale so far. First [1] is
where you can build your created application to both SWF and JS version.
The second one [2] is for building your created application to JS only [2].
If you decide to go with Maven path you will be IDE agnostic and you will
be able to use IDE for coding only. I'm working like that in the most cases.

There are two IDE which supports Apache FlexJS and the teams working on
supports Apache Royale [3][4].

- Moonshine [5] will have partial support in the upcoming release 1.6.1
details in the issue on github. We are going to release very soon that
version.
- VSCode [6]  seems to be pretty close to also have Apache Royale support!

I hope that helps you to get engaged! Look forward to your questions!

[1]
http://apacheflexbuild.cloudapp.net:8080/job/royale-asjs/lastSuccessfulBuild/artifact/out/
[2]
http://apacheflexbuild.cloudapp.net:8080/job/royale-asjs-jsonly/lastSuccessfulBuild/artifact/out/
[3] https://github.com/prominic/Moonshine-IDE/issues/50
[4] https://github.com/BowlerHatLLC/vscode-nextgenas/issues/144
[5] https://nextgenactionscript.com/
[6] http://moonshine-ide.com/

Thanks, Piotr


2017-11-09 21:54 GMT+01:00 Serkan Taş :

> Hi Nikola,
>
> Thank you for realy detailed response.
>
> I have been application developer for long time but better like to do
> something in server side. Current flex UI need to be moved to
> flash-player-free version is the UI of Job Scheduler  named Pınara.
>
> I do not perefer normally to compile the sdk myself, but it may be helpful
> because there may be some locale problems from local settings and i may
> face them as early as possible. But it is going to be very nice if your
> share the sdk binaries download link.
>
> I am providing consultancy services during my day and only have time
> afterworks if i feel good,  so i can not fully involve on my migration plan.
>
> And i share the same feeling with you about the importance of JS output :)
>
> Serkan Taş
>
>
> 06.11.2017 01:56 tarihinde Idylog - Nicolas Granon yazdı:
>
> Hi Serkan,
>>
>> Welcome to the list, and welcome to this exciting project !
>>
>> I do not belong to the Apache Royale "core team", but since you seems to
>> be on the "application developer" side like me, I thought I could try to
>> bring some information to you.
>> I do not have any "expertise" in Apache Royale, and maybe some of my
>> comments are not accurate.
>> But, like you, we have Flex applications to migrate, and, at least, my
>> comments reflect what we have understood so far.
>>
>> I apologize to all "core team" members for any wrong/inexact opinion in
>> there. Also, it is possible that my English does not adequately reflects my
>> thoughts.
>>
>> At this time, the Apache Royale project in reaching the end of some major
>> restructuring work. That might explain some difficulties in building the
>> SDK.
>> For us, we do not compile the SDK ourselves : we only use the binaries
>> distribution.
>> But we know that SDK compile-from-source process is not, right now, fully
>> operational. From what I understand, it is a matter of days before it is
>> fully operational again.
>> We are in kind of "intermediate" step until restructuring is fully
>> achieved.
>>
>> As of today, you could download the FlexJS (v.0.8) or the Apache Royale
>> (v.0.9) SDK.
>> Obviously, the project name changed (and it also caused some delay in the
>> availability of a full operational version) and is now "Apache Royale".
>> FlexJS (0.8) is more stable but since there were many name-changes I
>> believe it is better to go with Royale 0.9 despites it is not fully
>> operational as of today.
>>
>>
>> With Apache Royale you code mxml and as, like "before" (Flex).
>> The compiler is able to produce a SWF file (like before) *or* (more or
>> less) equivalent javascript scripts. In the case of javascript output, the
>> Flash Player is not needed at runtime.
>>
>> You still can build with ant. The compiler name is still mxmlc (or compc
>> for libraries). Most parameters are the same. Of course, some new
>> parameters apply to javascript ouput.
>>
>> Yes you can use FlashBuilder (this is what we do).
>> I have send one or two contribution to this list on how to setup FB.
>> As of today, there are still some minor issues, but I'm confident all
>> will be resolved very quickly, as we approach to v.1.0.
>>
>> As I understand your question about "application structure", and as far
>> as I know, it is a very classic "javascript includes" structure (like
>> angular, react and many other).
>> Debug output is human-readable, production (release) output is minified.
>> But since you can debug from (as3) source code, I believe you could
>> totally ignore javascript output.
>>
>> As I see it, the project has really strong points :
>> The compiler is excellent
>> AS3 language syntax is fully preserved
>> MXML syntax is fully preserved
>> The "js side" output uses proven tools (google closures...)
>> The deve