This is reply for moonbit author.
https://twitter.com/bobzhang1988/status/1784065637092089951
I have a slightly different opinion.
TypeScript was an ecosystem that combined a universal escape hatch called any with incremental typing. The community-based DefinitelyTyped provided an experience that, from a personal perspective, expanded the world of typing just by sleeping on it. This is an experience that Flow and ReScript did not provide. Unfortunately.
I think our mindset as front-end developers was "if it's any better than it is now, we'll grasp at straws, but if we're not allowed to do what we can do now, whatever it is, we're not allowed to do it. The front end in 2014 was calling jQuery plugins that we didn't really want to use from React's componentDidMount at the behest of clients and UX designers. Of course I am aware that it makes no sense.
When I was considering AltJS in 2014, there really didn't seem to be many languages that could bind to the commonjs/ESM ecosystem. I think Elm would have been the best if everything worked ideally. Scala.js was very strong, but the amount of utilities, mainly collection type utilities, did not fit into a realistic build size (40MB for a simple code). ReScript was very close, but could not integrate seamlessly with the JS ecosystem.
It was really only TypeScript that could do it. It was not cool, but it was practical.
Of course, I don't think a newly designed language should take the same approach as TypeScript. I'm sick and tired of the agonizing record types like type Action = { type: 'a', payload: number } | { type: 'b', payload: string } There is a proposal for pattern matching and record types in TC39, but I don't think it should be adopted and used in TypeScript. I'm frankly sick and tired of thinking about the day when vscode will work with semantic parsing in TypeScript.
I believe that TypeScript's excessive expressiveness was a necessary evil to force jQuery, which was conceived outside of the type world, into the type world. Without it, there was no business excuse.
Sorry for the abruptness and length of this post. I believe Moonbit is in the best position to give a solution to this problem. So I got a little heated.
Translated with www.DeepL.com/Translator (free version)
original japanese version
私は少し違う意見を持っています。少々長くなるので Gist に書きました。
TypeScriptは any という万能な脱出ハッチと、漸進的型付けが組み合わさったエコシステムでした。コミュニティベースの DefinitelyTyped によって、個人の視点としては寝ているだけで型がつく世界が広がっていく、という体験が提供されました。これは Flow や ReScript では得られなかった体験です。残念ながら。
我々フロントエンド開発者としてのマインドセットは、「今より少しでも良くなら藁だって掴むが、今できることが許可されないのはなんであろうが許されない」だったと思います。2014年のフロントエンドは本当は使いたくない jQuery プラグインを、クライアントやUXデザイナーの要求によって React の componentDidMount から呼び出していました。もちろん筋が悪いことは自覚しています。
私が2014年にAltJSを検討した時、commonjs/ESMエコシステムとのバインディングができる言語が本当に少なかったように思っています。すべてが理想通りにいくなら、一番優れていたのは Elm だったと思います。でも Elm は一部のコードだけを Elm 内に許容して、それ以外を port という仕組みで外のJSに追い出しました。Scala.js は非常に協力でしたが、主にコレクション型のユーティリティの多さで、現実的なビルドサイズに収まりませんでした(簡単なコードで40MBになりました)。ReScript は、非常に惜しかったんですが、JSエコシステムとシームレスな統合ができませんでした。
それができたのは、本当に TypeScript だけだったんです。格好が悪かったんですが、現実的でした。
もちろん、新しく設計する言語が TypeScript と同じようなやり方を取るべきだと思いません。 type Action = { type: 'a', payload: number } | { type: 'b', payload: string } のような苦し紛れのレコード型に私はうんざりしています。TC39 にパターンマッチやレコード型の提案はありますが、それが採択されて TypeScript 上の意味解析ともに vscode で動く日がいつになるか考えると、正直うんざりしてしまいます。
TypeScript の過剰とも言える表現力は、言ってしまえば型の世界の外で考えられた jQuery を無理矢理型の世界に内包するための必要悪だったと思っています。それがないと、ビジネス的な言い訳ができませんでした。
突然の長文失礼しました。この問題に対する解を与えるのに一番よいポジションにいるのが Moonbit であると思っています。なので少々熱くなってしまいました。