Back in 2021, someone asked me about supporting TypeScript in Royale. This was my response at the time:
My gut feeling is that adding TypeScript support would be a pretty huge job > that would probably take at least a year of work (at my current > availability per month) to get to a reasonable minimal viable product (we > should definitely expect rough edges for a long while after that too). > > I don't think that we'd want to write a parser for TypeScript. We should > use the existing TypeScript compiler and the years of work put into it by > Microsoft already. We don't have the resources to keep up. Basically, I > want to see a way to compile MXML to TypeScript, and then let the > TypeScript compiler compile the final JS. That alone is a lot of of work, > but relatively straightforward. > > Things get tricky when trying to allow TS to use JS previously compiled > from AS3/MXML. The first step, I think, would be to have our compiler > generate .d.ts files alongside our generated .js files. ActionScript is > smaller in scope than TypeScript in many ways, so the .d.ts files should > not be very complex at all. That's only part of the job, though. > > Our generated JS uses goog.provide()/goog.require() modules, which isn't > really used in the TypeScript ecosystem, as far as I know. I have heard > that Google is using more and more TS internally these days, though, so > maybe there's a way to integrate TS and Closure that hasn't crossed my > radar. That would make things easier. Regardless of how well TS/Closure > work together, I would want to seriously consider having our AS3 compiler > output native ECMAScript modules instead of goog.provide()/goog.require() > modules. I know for sure that Google Closure compiler can consume > ECMAScript modules, so the AS3 workflow should not change much if we were > to switch. Additionally, it would allow our generated code to work better > with other JS bundlers, like Webpack/Rollup/Parcel/etc. > > Allowing AS3 to access TS type information somehow would be the most > difficult requirement, in my opinion. The best workflow for our users would > be to compile TS to SWC files that contain both JS and AS3 bytecode. > Basically, similar to what we have today with AS3/MXML for JS SWCs. > Generating that bytecode would be the challenge here. I don't have much > experience writing raw ABC bytecode. Maybe it could involve creating .as > stubs from .d.ts files and compiling them instead. I've been down that road > with dts2as, and it was hard to keep up with the more complex syntax of TS, > which was also constantly evolving. The simplest MVP might do something > like type every method/property in the bytecode as Object or * to start > out, which isn't ideal, but still better than nothing. Or maybe TS > generated libraries can't be used by AS3 to start out, and only AS3 > generated libraries can be used by TS. Again, not ideal, but the smallest > scope possible seems important here. I still think that it would be a massive job, and I think over a year is still a reasonable estimate. Dropping AS3 and going pure TS could potentially make things easier from a compilation perspective, but that would basically require a full rewrite of everything on the framework side. Might as well start a brand new project that is similar to Royale, but can be its own different thing at that point. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Mon, Dec 9, 2024 at 10:28 AM Hugo Ferreira <hferreira...@gmail.com> wrote: > Yes Josh, I saw that now and it works :) > Thanks :) > I've been using VS Code for a while now and probably I started before that > feature or I didn't notice. > > But the TypeScript and a new MXML extension would have an important impact > (not for me) but will be far easier to talk about Royale to other > developers out there. > > Dev: What language did you use to build this application ? > Hugo: Royale. Do you know ? > Dev: No. What is it ? How is the sintaxe ? > Hugo: MXML for UI and ActionScript for code. > Dev: MXML I don't know but ActionScript is not the language of the old > Flash e MX não tem haver com a Macromedia ? > > Do you understand what I mean ? > > Now, if the answer was TypeScript, there is a big chance that the "Dev > person", answer, yes I know or even, yes I work with it. I will try on a > test project ! > > Many people ask me the same question and I know the answer upfront (every > single time) and it's always a dev that will not try Royale. > > You may say that is a marketing reason and it's true but it's a marketing > world and other frameworks compared to Royale, Royale would shade easily > are more popular because of that. > > This is my honest opinion. > > Best regards, > Hugo. > > > Josh Tynjala <joshtynj...@bowlerhat.dev> escreveu (segunda, 9/12/2024 à(s) > 16:41): > > > vscode-as3mxml provides an "ActionScript: Create New Project" command > that > > detects Royale SDKs and creates a simple Royale Basic project (Flex, AIR, > > and Feathers SDKs are also detected with their own templates). VSCode's > > Explorer also supports custom views when no workspace folders are open, > and > > a while back, I added a button there to create a new ActionScript > project. > > > > -- > > Josh Tynjala > > Bowler Hat LLC <https://bowlerhat.dev> > > > > > > On Mon, Dec 9, 2024 at 2:26 AM Hugo Ferreira <hferreira...@gmail.com> > > wrote: > > > > > Hi, > > > > > > These are probably crazy ideas that are unlikely to be implemented, > but I > > > would like to share them anyway: > > > > > > 1. One way to make Apache Royale more attractive to new blood is to > > provide > > > the compiler with not just 1 but 2 languages, that is, in addition to > > > ActionScript 3, support TypeScript. > > > New developers will never search for AS3 but instead for TS. > > > Also MXML should have another terminology. > > > > > > 2. Another suggestion is to somehow have aliases for the namespaces, > that > > > is, wherever the terms flash and adobe are still used. > > > I know in the past this could hurt sensibilities, but it has been many > > > years since Flash went extinct and its relationship with Adobe was > > severed. > > > This resolves some stigma that may still exist for new developers to > > come. > > > > > > 3. This suggestion is for VS Code: Make some kind of setup for VS Code > > that > > > helps create new projects for newcomers (templates out of the box). > > > > > > Best regards, > > > Hugo. > > > > > >
