search

apache / royale-asjs

Apache Royale ASJS
Apache License 2.0
370 stars 116 forks source link

ActionScript conversion examples? #360

Closed vbhayden closed 5 years ago

vbhayden commented 5 years ago

Sorry ahead of time for the soon-to-be-closed question.

I've been looking around at transpiler options to move a few ActionScript3 projects over to standardized HTML5, but there seem to be scarce examples for doing this with the asjsc command. Taking the lines from royale.apache.org:

npm install -g @apache-royale/royale-js
asjsc <path to main.as file>

which works fine for scripts that don't use Flash libraries. But something whose main.as extends something like flash.display.MovieClip throws

Warning: Definition flash.display.MovieClip could not be found.

Is there a way to specify a Flash SDK to resolve this, or to target a main.fla file? Thanks!

aharui commented 5 years ago

From a migration from SWF to JS perspective, Royale's main focus is on migrating Flex apps. in Flex, the use of flash.. classes was theoretically unnecessary. IOW, a Flex Application instance instead of flash.display.MovieClip is your entry point, and there is a "systemManager" property that means you can pretty much avoid referencing Flash "root" or "stage" properties.

This allows Royale to escape any obligation to be backwards compatible with Flash. Creating the equivalent of Flash in the browser is, IMO, a huge project, and the Flash API s are tuned to Flash's runtime with deferred rendering and frames and other concepts that don't map well to other runtimes. Thus, by not emulating Flash, Royale frees itself from a particular runtime and allows for abstractions that can target other runtimes someday. IOW, it is easier to reproduce an Application and "systemManager" property on most other runtimes than it is to reproduce "enterFrame" and ensure that when you modify a property it isn't drawn on-screen right away.

So, when migrating a Flash app, you have to decide what trade-offs you want to make. If the Flash app is not heavily reliant on Flash-specific APIs (frame-based animation, lots of custom graphics interleaved through the UI layers, ApplicationDomains, etc) then you might want to rewrite the Flash app in Royale and make, for example, org.apache.royale.core.Application the entry point instead of MovieClip. This will mean a lot of renaming of classes in your code-base and modifying other code, but the result will be the smallest, fastest, app.

If you have lots of ActionScript calling Flash APIs, you can try the Royale emulation components and use mx.core.Application as the entry point. There will still be a lot of renaming of classes, but probably less and more straightforward. The emulation components have a mx.display.Graphics class that will replace flash.display.Graphics. But only a few Flash classes have mx.display equivalents and there is no goal of 100% backward compatibility.

There is another project called OpenFL that is trying to replicate more of the Flash classes. You can visit them and see if they can help you. You can use Royale to transpile your code using their SWCs. They are taking on the task of shooting for higher and higher Flash backward-compatibility. This can result in fewer changes to your code, but if you need to target some other runtime someday, you may regret still having Flash-isms in your code.

Fundamentally, there is no one right answer. Royale is here to do the transpiling and offer some choices of component sets to use. But we welcome third-parties like OpenFL who want to offer other approaches to the problem.

ROBERT-MCDOWELL commented 5 years ago

A lot of projects won't be able to touch a code working since years, for various reasons:

vbhayden commented 5 years ago

Thanks for the information!

aharui commented 5 years ago

@ROBERT-MCDOWELL Yes, there are risks around stability and costs. There are also risks around security. What will you do if someone finds a vulnerability in the legacy browser you are using?

Royale is somewhat agnostic about those risks. All we are doing is preparing libraries so that folks will have to touch their code as little as possible, but I don't think we will ever get it to a "no-touch" level, certainly not in 2 years. If you see the number of changes to the actual source of TourDeFlex, you will see that we have a significant amount of it working with only a few changes to the source. Almost all of the work is in the Royale components.

As more people use (and hopefully help debug and fix) the Royale components, the stability will improve. And it will improve faster if folks get involved now instead of waiting for the end of 2020.

Another way to think about it is: If you have to get off of Flash and run in the browser, you will have to run JavaScript. You can make that happen by changing lots of your code, or change less of your code by using Royale and leveraging the testing of the Royale code paths by others.

ROBERT-MCDOWELL commented 5 years ago

well, a lot of companies are ready to take the "risks" you are talking about, especially in a time of serious unstable economy, and btw, usually hackers or virus just target the "most used" on internet, usually last OS and browser versions (all stats show it). Secondly, javascript is going to die too soon or late, wasm is evolving very fast and has the advantage to transpile any kind of language, so it will (maybe) avoid companies to spend a huge amount of money to rewrite a code that already running in production since years, which is from a business approach a total absurdity. for the last 20 years of internet development we had the habit to make thing evolves, but with this story of Adobe forcing people to rewrite their project in javascript is just an heresy....

ROBERT-MCDOWELL commented 5 years ago

In conclusion, I just hope that all protagonists who decided to stop browser plugins know what they are doing or for sure it will be a full mess after 2020

aharui commented 5 years ago

Well, I work for Adobe, but I am not an official spokesperson, so this is not an Adobe statement. In my personal opinion, the whole point of Royale is to address your second point. We don't want you to have to rewrite every line of existing AS and MXML. Royale is trying to let you keep your code in AS and MXML with very minimal changes.

And by choosing Royale and making those minimal changes, you will be future-proofing your app because it should be possible to write a transpiler from AS/MXML to WASM or even Java or C++ or ObjectiveC or really, anything (with certain restrictions) and again take advantage of sharing tested code paths with others. instead of rewriting lots of lines of code.

I wish we could predict how messy it will be after 2020. I have a feeling lots of people did rewrite their code already. It would be great if folks would tell us how many bytes of SWF they are still using. I don't think the browser vendors get good analytics from folks running Flex apps inside the corporate firewall.

ROBERT-MCDOWELL commented 5 years ago

Sounds promising.

I wish we could predict how messy it will be after 2020 This is the point, no one can predict, but we can easily guess it will because many users/companies just don't care or don't have money or resources to modify their app/project/platform, as long as it works since years. Example, I manage a RIA project involving 3 million lines of AS2,AS3, plus Flash Pro CS components, AMS, actionscript server side script etc... developed in 11 years, costing to them 6 millions. Do you really think that the are ready to change it?

aharui commented 5 years ago

@ROBERT-MCDOWELL Feel free to not answer, but I'm curious to know what your maintenance budget is for an app of this size and whether the app is considered "under development" or "in maintenance". You don't have to give dollar values, just general terms like "half of a test engineer and one junior programmer" or things like that. Because, IMO, the ground underneath your app has always been subject to change. Every browser release, every Flash release, could impact an app of this size, and someone probably had to verify that the app still worked after these runtime updates. Of course, one possible answer is that there is no budget and you just prayed you didn't get broken.

There was always some risk that, in order to close a security hole, some Flash API would change in a way that was not backward-compatible. In some ways, the Flash2020 impact is this risk finally becoming reality.

Royale is attempting to become the lowest cost solution in this reality. We won't be 100% backward-compatible, although we are trying to get closer every day. That said, there is currently no way the few folks working on it will get close to 90% in two years, but we are prioritizing the most common code paths that folks are using and will get those production ready shortly. I recommend to anyone to not wait for this small team to get closer, but to get involved now to find out where your app needs things that don't yet exist in Royale and help get them done. By starting now, you will gain expertise in the Royale code base and thus insure yourself for the future and not rely on an Adobe or other company to keep you up and running.

One last comment about my prior post about future-proofing: I highly recommend using ActionScript without anonymous/named function objects if possible. The AS/JS scoping rules are not guaranteed to be efficiently supported on future runtimes.

ROBERT-MCDOWELL commented 5 years ago

@aharui // I'm curious to know what your maintenance budget well, you can easily imagine that I signed long time ago a confidential contract, btw it's not the subject. // whether the app is considered "under development" or "in maintenance". You it's not an app, it's an entire platform with hundred of thousands users // IMO, the ground underneath your app has always been subject to change. yes of course, several IT are maintaining it since years, but there is a big difference between maintain, fix the bugs and new issue from Flash update and rewrite the entire platform with another language (even if JS is close to actionscript but you know more than me that browser compatibilities and behavior are completely different)

ROBERT-MCDOWELL commented 5 years ago

btw, Adobe has plenty of money to hire more developers to fix it right? Rather than to hope guys with free time happy to contribute to convert a non open source plugin to an open source project, unless they just want to loose their credibility and work only on a niche market....

ROBERT-MCDOWELL commented 5 years ago

Also Security holes are everywhere on computers, starting with data grabbed without consent by thousands softwares, systems and so on. then JS has also plenty of sercurity holes. This is the same story of guys saying "to make peace we need wars"....

aharui commented 5 years ago

Again, I am not an official spokesperson for Adobe, so this is just my personal understanding and opinion. I'm pretty far removed from the decision makers.

AIUI, Adobe did not make this decision independently from the browser vendors. Instead, my understanding was that it was a collaborative decision. Adobe and the browser vendors are mainly for-profit companies and have to decide where to put their energy and the decision was a group decision that fixing browser and JS security holes without also having to deal with Flash security holes was the best business decision going forward.

So sure, the browsers and JS have security holes, but the browser vendors have committed to fixing those issues, but don't want to also spend money on dealing with Flash issues. And that was my point earlier, that it might be less risk to stay on supported technology layers. And thus, Royale sees an opportunity to hide you from the ugliness of JS and let you continue to code in AS and run on supported runtimes.

AIUI, open sourcing the Flash code was considered and deemed not practical. People have been trying Flash alternatives for years and never got it going. The OpenFL folks may succeed, you never know.

I'm not sure what you want Adobe to hire more developers to fix, but whatever it is, it is up to Adobe's customers to convince Adobe that more developers are needed somewhere. If Royale turns out to be the hot new way to create browser apps, I'm still not sure that Adobe will see a business opportunity in Royale. And, IMO, you are better off being part of an Open Source community than relying on a corporation to support some technology forever. Recently, I was trying to update an old DOS 640K app I wrote 10 years ago. None of the tools I used 10 years ago are available today.

I don't know the multicast side of Flash at all, but a quick internet search indicates that there is at least one offering that doesn't require Flash. IMO, if there is a great enough need, someone will come up with a replacement. It still ends up being bits on the wire, AIUI. Royale has AMF working. Whether RTMFP is actually used or not, the abstractions above it are most important. If you've written code against the higher-level abstractions, then it makes it easier to replace. Royale has wrapped Material Design Lite, the ACE editor, and more. If you find a good non-Flash replacement, it might be able to be presented as an AS API.

carlosrovira commented 5 years ago

The real reality would be to release the flash plugin open source to let users decide what to change or not, with clear and transparent long term agenda

@ROBERT-MCDOWELL , I was in that boat some years ago. I thought Adobe fails on donating Flash to some foundation around 2005 to 2010, so all the big players will "control" the most ubiquitous piece of code on the internet to show client content and make it a true standard that works cross all browsers. At that time Adobe didn't do that, that makes Apple and Steve Jobs start a marketing thread that initiated the reallity we live today.

Nowadays, is useless think about open sourcing Flash Plugin, since is a plugin and Browser vendors doesn't want a plugin, so even making it Open Source, will not solve the Flash Plugin reality, that is to turn year after year in an obsolete piece of code. Today is already a nightmare to develop and debug against Flash. That's a fact, and nothing will make that change.

So as Alex's says, to all people out there, not only you, the only real path that could make you work against something that will build up for the future is to join us, and help this effort (or other that you consider the best option for you). In my experience doing several hours working in Royale is that you can migrate with some plan in mind. It will cost many time, It's not easy at all. But you can do it, and regretting about something none of use can control, is not making things change, just loose your time, as we did all this years complaining. Another important point is that, in my humble opinion, all people that wants to migrate will need to get involved in this project, since they will need to work in the things they need, while others do other tasks. But is impossible that our current team could do 100% of the things people currently need. So the only real path is to join and start assuming hours and cost to this project. In the long term, that cost will proven as needed. That's what we did at Codeoscopic and I think we're getting to migrate from Flash with 70-80% of the original code, taking into account that we want to update our clients with latest UX and UI conventions that are not in Flex (Drawers, responsiveness, mobile-table-desktop...)

I think is a good time to join us. My advice is: Get on Board now! we have a technology that is working nowadays. We'll be putting our first royale client migrated from Flex in a month or so. We have it at 90%, so is clear is possible...doesn't make sense to me regretting about how things will done by companies and take this opportunity to control your future, now exporting to JS and some day to WASM, when we work in that target.

ROBERT-MCDOWELL commented 5 years ago

well, it's your opinion, not mine and mine is not the opinion of millions users and developers.

Harbs commented 5 years ago

Sure, if Adobe hires me with a salary like you guys I will.

FYI, the only one here who's an Adobe employee is Alex. The rest of us are working on Royale because we think it's good for our own businesses. I think Alex is sticking with it because he believes in the project.

ROBERT-MCDOWELL commented 5 years ago

ok so why not Apache hires for this so important Royale project that can bring all the Adobe developers to Apache? Correct me if I'm wrong, but Apache has a lot of prestigious partners isn't it? http://www.apache.org/foundation/thanks.html https://www.apache.org/board/plan.html Don't tell me they cannot hire and pay developers to make Royale a royal software... No, the problem is political, not technical.

ROBERT-MCDOWELL commented 5 years ago

And btw, during this 24 years of internet development, many times some corporations dreamed to control the internet tech, but it will never happen, because the real controllers are users and developers, and if they realize (like today with major social media corporations) that something wrong with their freedom so for sure they will find a way to create something new.

carlosrovira commented 5 years ago

I don't agree Flash is obsolete, many of my experiments and tests against javascript or other language make it still performant and fluid.

I always (and now) love Flash and the technology behind, but that's not the point here. The point is that it doesn't matter what you or I love/want/believe...the true fact is that Flash will be removed from browsers and will only be found in Adobe AIR (for now), and all will be JS and then (maybe) WASM...so assuming that's the true reality, the real question for you is: What do you want to do with that true fact?: As I see now there's only 2 ways now: 1) package your Flex in AIR a continue living as an App, 2) Try to migrate to JS or other tech, with Apache Royale or any other option out there.

ROBERT-MCDOWELL commented 5 years ago
ROBERT-MCDOWELL commented 5 years ago

@aharui

aharui commented 5 years ago

@ROBERT-MCDOWELL Re: Perl. I could be wrong, but I believe Perl is interpreted. Which means that Perl's future was based on the source being interpret-able on future platforms. That is what Royale is attempting to do: get as much of your source code to work on future platforms.

Meanwhile, I believe there are tons of old binaries that do not work on Windows 10, and tons more 16-bit Windows 2.x apps that one day became obsolete when Windows went all 32-bit. It totally sucks to have to make changes to your code to adapt to changing runtime requirements, but AFAICT, it has happened several times throughout history.

But being able to re-use as much of your source as possible should ease the burden, and that's what Royale is attempting to do, and Adobe has generously donated my time to help build a community around Royale. But Adobe has pretty much gone all-in on Creatives and isn't quite so interested in developers anymore, which is why it isn't hiring more people to work on Royale or thinking about creating a product on top of Royale.

And again, after getting burned by changing corporate objectives, I would think an Apache project, given that all Apache projects are run independent of corporate influence, would be the safest play for your future. Otherwise you are subject to their decision-making which is almost always going to be profit-oriented.

We will see over the next two years if there will be a revolt. I expected the revolt to happen two summers ago with the Flash 2020 announcement. But maybe you are right that folks just kept waiting and hoping something magical would happen before 2020. Royale is about the only thing that has been attempted to help with the migration. If there are more folks like you who are unhappy with the current situation, they should speak up ASAP, especially if they are big Adobe customers.

ROBERT-MCDOWELL commented 5 years ago
aharui commented 5 years ago

Apache doesn't pay people to write software. It is "all volunteers". If you can get enough people to ask Adobe to build whatever it is you want them to build, Adobe will probably build it, but IMO, you will need to show them it is worth 100's of millions of $'s to them. Adobe donated Flex to Apache because they couldn't build a profitable business around Flex.

There might be some other company that wants to step into this gap and build what you want and be happy with a few millions of $.

I think you can still use Flash Builder to build your code for Royale. You can certainly use Ant with pretty much the same build file as you used in Flex.

ROBERT-MCDOWELL commented 5 years ago

never used flex but flas pro 15 years...

aharui commented 5 years ago

Well, then you may be stuck like folks with Windows 2.x apps many years back. At some point, MS said they would need to be rewritten and anybody with lots of low-level stuff assuming the 16-bit memory model had more work to do.

If your code assumes the Flash API, you can see if OpenFL or CreateJS can reproduce enough of the Flash APIs for your needs.

ROBERT-MCDOWELL commented 5 years ago

that shows you clearly how political it is and not technical, neither financiall... Flex was free, Flash pro was not....

ROBERT-MCDOWELL commented 5 years ago

I won't touch one line of JS anymore, this language is not clean at all, no typing, compatibility problems etc.. It will take ages and cost too much to reprogram everything. So I will let them know that they have been hijacked...

aharui commented 5 years ago

I'm not sure why you think it is "political". Sure, these big companies have money and could spend it on continuing some technology, but big companies also consider "opportunity cost". It takes office space and even more people to manage production of a technology and sometimes they choose to sacrifice some customers for the gain of (hopefully way more) others.

There have been fans of just about every McDonald's menu item, but that doesn't keep them from dropping some. These are business/financial decisions.

If whoever you report to has further questions, they are welcome to discuss with us here. We work in the public. I will respond to a private query if absolutely necessary.

The point I don't think I got across to you is that Royale is about not requiring you to touch JS. Royale committers do not write JS. We also didn't like it and gave up on it years ago. You can write all of your JS using AS so our compiler will type-check at compile-time. And if we had a few more folks, we would make sure that you could use AIR (or Flash for a few more years) to type-check your code at runtime, so you have better faith that the results will be type-safe in the browser.