Yes, it has become very clear to me that it will never happen or at least the probability is reduced to almost certainly that it will not happen.
Thank you anyway for clarifying me. Josh Tynjala <joshtynj...@bowlerhat.dev> escreveu (segunda, 9/12/2024 à(s) 19:00): > 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. > >> > > > >> > > >> > > >
