Thank you for your response. However, it doesnât fully address our concerns or solve the problem weâre facing. Let me break it down:
âTypeScript is simply a superset of JavaScriptâ
â While thatâs technically true, it misses the main point. The issue is not whether TypeScript can coexist with JavaScript, but that integrating a 1500-line TSX file without clear modularity into a pure JavaScript project is a monumental and, frankly, unnecessary task.
âYou can use JSX/TSX to write HTML directly in your componentsâ
â This underestimates the complexity of the environment we work in. While itâs possible to render TSX elements, we are not looking to rebuild our architecture to accommodate this approach. We need a practical and simple solution that works with what we already have.
Focus on NPM and modern tools
â For many developers, setting up NPM and tools like Webpack or Parcel isnât an issue. However, the real obstacle here is conceptual and structural. It assumes we can simply adopt this modern stack, but in reality, our current workflow is based on pure JavaScript, and switching to TypeScriptâeven if not mandatoryâadds unnecessary overhead to something that should be straightforward.
The claim that adopting TS is not required
â You state that TypeScript isnât required, but the example provided relies on TSX, JSX, and FSComponent. This still creates a barrier because adapting this to pure JavaScript is highly complex without a deep understanding of how everything works behind the scenes.
The Key Issue:
The problem lies in the fact that MapInstrument worked perfectly in MSFS2020, and now it doesnât in MSFS2024. We, as developers, are now forced to look for alternatives because of the decision to remove support for FS9 variables. While you mention these variables have been restored, the issues with mapinstrument persist.
Without a solution, many of us will continue developing projects for MSFS2020 that wonât be compatible with MSFS2024, simply because a working feature was removed.
The Challenges With Your Proposed Solution
Your documentation and approach require far more additional steps to achieve something as basic as rendering a map. For instance, even the example you provided:
FSComponent.Render(someComponent, document.querySelector(â#myDivâ))
âŠrequires installing frameworks, configuring modern tools, and reworking our projects to accommodate an entirely new architecture. This is neither practical nor accessible for developers currently working in JavaScript-only environments.
Please understand that we are not rejecting modern tools or resisting change, but your proposed solution doesnât fit the context of our current workflows. For those of us working in pure JavaScript, it creates more barriers than solutions.
What Weâre Asking For
-
Fix MapInstrument and FS9 problems related:
All weâre asking for is to restore something that already worked in MSFS2020 without requiring a complete restructuring or the adoption of new tools.
-
Provide a Pure JavaScript Alternative:
If the intention is to phase out mapinstrument, please provide a documented and functional alternative in pure JavaScript. Something modular, easy to use, and as simple as FS9 variables, without requiring frameworks or complex configurations.
-
Simplify the Process:
We need a practical solution that works with existing projects, not one that requires setting up new infrastructure.
To summarize: This is not about resisting TypeScript or modern tools; itâs about finding a solution that works for the context weâre in. Weâre not looking to rebuild our entire environments just to make a map work. Weâre simply asking for a straightforward and functional solution that allows us to keep working with our current tools and architecture.
Thank you for your understanding, and I hope this clarifies our position.
