I should add: My previous post shouldn't necessarily be interpreted to imply that I would currently be willing to work on such a project. It's more of an off-the-cuff summary of the hurdles that would be hypothetically involved.
-- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Mon, Dec 9, 2024 at 10:50 AM Josh Tynjala <joshtynj...@bowlerhat.dev> wrote: > 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. >> > > >> > >> >
