@rmassaioli I would like to chime in on this point and say that in my opinion good Typescript support or even better a TS-first approach is hugely important for Forge and should be a no-brainer - please read on.
In my opinion, deferring this decision to the community to wait and see who shouts the loudest is a pretty weak move. Atlassian should take the lead with this, set the standards and decide on their own what it takes to write enterprise-level apps and is best for the community and the ecosystem.
If Atlassian decides static typing leads to better software and better apps it should provide curated high-quality TS templates and great documentation to showcase what a basic high-quality Forge app looks like. I am convinced that the community will adopt and follow the lead - which will be for the benefit of everyone. However, this mindset has to exist within Atlassian otherwise it will not work.
To your point on which language has more developers, I think the point is irrelevant. TS as a superset of JS will very likely always have fewer developers. Following the same argument, I guess every TS developer can also be counted as a JS developer.
It is clear that I am sitting in the TS camp and I am happy to chat more about this. I have sent @JordanKoukides an email a while back (in response to his post) with some more concrete points and observations regarding the current state of TS support. I will copy those (slightly modified) below for reference.
Forge DX - TS support
… I have shared this before with other teams but I am convinced that precise typings for Forge are one of the key features to building enterprise-grade Forge apps. For my taste, the current typings still have way too many “any” references. This is convenient for Forge platform developers but does not help the end-user at all. In many cases, precise types can often compensate for lacking documentation.
To give you a concrete example:
The method getContext in the custom UI bridge is currently typed as () => Promise<FullContext> with FullContext being typed as FullContext = {}. As a Typescript developer, I am getting almost no type information from this declaration. I just also noticed that the docs on getContext contain a deprecation warning regarding the extensionContext property being deprecated. Again, if there were precise types for FullContext, then the extensionContext property could be marked as @deprecated and all Typescript library consumers would know that they should fix their apps.