Concerning AIR I never hit a wall where I felt overhead. Whenever I need native performances I switch on the ANE side which fulfill the all my requirements.

If one doesn't know C++ he can always rely on Haxe for his base code and code his ANE in AS3 like language and transpile it to C++ and hook that code into a dummy ANE project to output an. ANE file.

IMHO the overhead starts with the developer's competencies and creativity. 

Electron is a bloated platform that came to existence with the HTML/_javascript_ hype that some giant companies pushed forward in their fear of seeing the web taken over by one ingenious tech which is the Flash platform. Even still today nothing matches the capabilities of what AIR is offering. To prove that you can look at Flutter from Google and Swift from Apple which both are a rip off of AS3 for the syntax or for the language name.

VSCode is not a good example because all the heavy load of work is still done in the background in C++. Only the UI is communicating with the backend languages server and all the results are then just shown in the editor.

I'm not really impressed by VSCode. When a product comes with Electron I don't install it because it slows down my computer. 

I hope that helps. 

Best regards

08:01, August 7, 2019, Alex Harui <aha...@adobe.com>:

IMO, cross-platform development usually has some overhead compared to native code.  AIUI, even AIR, after JIT-compiling, still has limitations around workers and probably some other things.  If that weren’t true, everyone would have long ago abandoned separate code bases for Mac vs Win.

 

AFAIK, some folks are quite happy with the overhead of Electron and Cordova.  Others are not.

 

Royale’s goal is to enable library developers to package up common code patterns in AS and output them in target languages.  Right now we are mainly focused on JS.  Nothing stops volunteers from creating some other emitter that outputs native code.  I would recommend that those volunteers disallow some of the AS scoping rules when targeting native output, but that is only a suggestion.

 

HTH,

-Alex

 

From: Greg Dove <greg.d...@gmail.com>
Reply-To: "users@royale.apache.org" <users@royale.apache.org>
Date: Tuesday, August 6, 2019 at 7:35 PM
To: "users@royale.apache.org" <users@royale.apache.org>
Subject: Re: Migrate to Royale Apache

 


Thanks for the explanation. It does however seem to be in use for quite a few prominent projects, including VSCode.

 

I did try googling 'why Electron is a bad choice' as you suggest and to be honest, it looks (on balance) to be neutral or even favorable just quickly reviewing those results.

If I limit search results to the last year, there are perhaps more negative ones. But there is also some more guiding content like 'THE SECRET OF GOOD ELECTRON APPS' and 'Pro Tips and Tricks'. So it seems to me that (like many things) it can be good or bad, and it may suit some applications more than others.

 

However, like I said, I can't personally vouch for Electron. If your experience is mainly negative, so be it!

 

 

On Wed, Aug 7, 2019 at 11:07 AM Ramazan Ergüder Bekrek <e.bek...@yandex.com> wrote:

Electron was used by many companies for various project but at the end they had to revert back to native apps because of the inconveniences that Electron was providing as features. Electron is a memory hog and _javascript_ apps are slow as hell so both combined gives an explosive mix.

 

I never trusted the _javascript_ ecosystem for many reasons and I didn't bite the _javascript_ hype that everyone promoted. On the other end I developed an OSGi framework based on Apache Flex and developing Desktop apps became easier than ever. Plus the framework provide a mechanism to split your app into many bundles that are loaded dynamically at runtime and when there is new versions of each bundles the UI and the workers are hot swapped without having to close the app which is running. That brings a whole new paradigm of development and maintenance possibilities. Up until now no other framework allows to do byte code hot swapping at runtime than OSGi. It is inspired from the Java version of OSGi.

 

I think that Apache Royale will put an end to the _javascript_ Fatigue syndrome that everyone is suffering from. Just Google _javascript_ Fatigue and why Electron is a bad choice. You will find plenty of real case stories. 

 

I hope it helps. 

 

Best regards 

00:40, August 7, 2019, Greg Dove <greg.d...@gmail.com>:


To be clear: I was not recommending Electron, just answering the question: 'Is it possible to do that with Apache royale'. The swf side support in Royale is not as advanced as the _javascript_, so using the _javascript_ output via Electron is an option that might be easier than trying to use AIR via Royale. I have never used Electron, so cannot vouch for it, but it seemed relevant to the question. It would however be helpful to understand why you think Electron is (presumably) never a good option.

 

If I understand the original requirements correctly, I would however recommend using Flex + AIR to make the desktop builds. I think this is quite common as an option.

 

 

On Wed, Aug 7, 2019 at 10:18 AM Ramazan Ergüder Bekrek <e.bek...@yandex.com> wrote:

I would never recommend Electron to anybody please be carefull lol. 

22:07, August 6, 2019, Greg Dove <greg.d...@gmail.com>:


Hi Isabelle.

 

I think the mentions about Android were correct but they may not answer your original question which is focused on desktop (Windows and Mac) builds.

 

'I need to convert my adobe air application (using Flex 4.6.0.) into 64 bit desktop application (Mac OS and Windows). '

'Is it possible to do that with Apache royale'

 

It might be - I saw a post recently about someone using Electron to create desktop apps with Apache Royale, so if Electron can create 64bit builds, then it could be an option for that. But that is probably not necessary if I interpret your objectives correctly.

 

If all you want to do is create desktop apps from your original Flex app, you can do that with Flex 4.6 (or more recent Apache Flex version) and a recent AIR SDK, and this is a common approach.

Windows 64bit desktop builds were supported with Adobe AIR sometime last year iirc, and I assume this will continue to be supported into the future versions via Harman.

Windows 64bit is only via captive runtime build iirc.  Adding an installer was extra work iirc. I can't recall for Mac, I think it might be 64bit via the external AIR runtime, but I'd suggest that even so you probably want a captive runtime build for that as well.

 

Using AIR sdk is not unusual as one approach to extending the life of a Flex web-based project by avoiding the flash player plugin - so long as the users of your app are happy to have an installed app instead of using the browser.

Apache Royale is a really good option if you want to migrate the browser based Flex app to html5 and have a version of your app continue to work in the browser.

 

 

 

 

 

 

On Tue, Aug 6, 2019 at 9:32 PM Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote:

Hi Isabelle,

 

You don't need to convert your application to 64bit Android app yet [1] - google moved that date farther. Harman will provide you an Air SDK which will be capable of do that translation before that date. 

 

In Royale there wasn't any volunteers who was focused on Flash sight of Royale. We are mostly focus on getting stuff done in web browser, so translation ActionScript to JS/HTML.

 

 

Thanks,

Piotr

 

wt., 6 sie 2019 o 11:28 Carlos Rovira <carlosrov...@apache.org> napisał(a):

Hi Isabelle,

 

maybe your case is about Adobe AIR for Android and the problem in Google Store and for this reason your need to have Adobe AIR 64bit?

 

thanks

 

 

 

 

El mar., 6 ago. 2019 a las 11:25, Isabelle LOYER (<i.lo...@intersystemes.fr>) escribió:

Hi, 
I need to convert my adobe air application (using Flex 4.6.0.) into 64 bit desktop application (Mac OS and Windows).

Is it possible to do that with Apache royale ?

If YES, could you explain how to do.


Best regard

-- 
Isabelle LOYER
InterSystemes
********************************
20 rue de Montubois
95840 Bethemont la Foret
********************************
Tel : 33 +1 34 69 22 66
Gsm : 33 +6 75 72 82 93
Fax : 33 +1 34 69 26 28
email : i.lo...@intersystemes.fr
www.intersystemes.fr
*********************************


 

--

Carlos Rovira

 


 

--

Piotr Zarzycki 

Patreon: https://www.patreon.com/piotrzarzycki



--
Sent from Yandex.Mail for mobile



--
Sent from Yandex.Mail for mobile



--
Sent from Yandex.Mail for mobile

Reply via email to