実行時のパフォーマンスの観点から、私は興味があります

また、AssemblyScriptのような実験的なツールは、ソースコードの特定の非常にパフォーマンスの批評家の部分のオプションになる可能性があります

私はThree.jsコアとWASMの実験を行ってきました。

https://github.com/takahirox/three.wasm-experimental
https://twitter.com/superhoge/status/1071132448426262529

実験から、コア全体をWASMに移植すると、ランタイムパフォーマンスが向上し、私の例では1.5倍速くなりますが、数学コード（Vector3、Matrix4、...）などの小さな部分を部分的に移植してもメリットがないことがわかりました。大きなJS-WASMオーバーヘッドの。

しかし、メンテナンスが難しいため、Three.jsコア全体をC ++またはRustに書き直して貢献者を探すのは良い考えではないと思い、別の方法を探していました。 TypeScript + AssemblyScriptがThree.jsで正常に機能するかどうかに興味があります。

始める方法は？ 最初はd.tsファイルだけから始める必要がありますか、それともTypeScriptに完全にジャンプする必要がありますか？

主に@types / threeに基づいて* .d.tsファイルをThree.JSに追加するPRを提出します（したがって、その作業を再利用します）。これは素晴らしい出発点であり、今のところJSで続行できます。 段階的に行うこともできます。

@takahirox素晴らしい仕事:-)私は常にThree.jsの周りでどれほど革新的な仕事が行われているかに魅了されています。 これらの概念実証があまり注目されないのは残念です。 また、C ++やRustですべてを書き直すことはできません。 たぶんAssemblyScriptはそうですが、私はAssemblyScriptを試していないので、AssemblyScriptについて読んだことについて話すことができます。 しかし、私が理解しているように、AssemblyScriptは多かれ少なかれTypeScriptのサブセットであるため、AssemblyScriptも検討する必要があります。

@bhouston d.tsファイルを@types/threeからthreeリポジトリに移動することが理にわかりません。 特に、これらのd.tsファイルはTypeScriptファイルから生成でき、常に同期しているためです。 d.tsファイルが常に自動化された方法でjsファイルと同期していることを保証する方法はありますか？ もしそうなら、 d.tsファイルをthreeリポジトリに入れることは有益だと思います。 また、メンテナの判断次第だと思います。 TypeScriptを採用したくない場合は、 d.tsファイルもオプションになる可能性があります。 また、彼らが数年以内にTypeScriptを追加することを決定した場合、今回はd.tsファイルでブリッジすることができます。 そうでなければ、私はより少ない利益とより多くの仕事があるのではないかと心配しています。 でもたぶん私は何かを見落としているだけです

@ bhoustond.tsファイルを@types / threeから3つのリポジトリに移動することが理に

TypeScriptに直接移動する場合、*。d.tsファイルは必要ありません。 問題は、現在@ types / threeプロジェクトは、個別に保守されているため、Three.JSでは常に古くなっていることです。 また、個々のファイルではなく、three.jsの構築された構造を反映しているため、ツリーの揺れやその他の形式の最適化をサポートできません。 したがって、*。d.tsファイルを追加すると、プロジェクトは現在の状態から大幅に改善されますが、*。tsファイルに直接移動するほど良くはありません。

* .tsファイルに直接移動できる場合は、それがより適切なオプションです。 それに対するサポートがあるかどうかはわかりませんでした。

Three.JSは段階的に物事を行うのが好きなので、これはビッグバンではなく段階的なオプションでした。

@bhouston私はあなたに完全に同意します。 また、ビッグバンの書き換えは不可能だと思いますので、段階的に採用する必要があります。 しかし、TypeScriptのドキュメントを読むと、tsファイルとjsファイルを並べて使用できるようです。 したがって、単一のファイルをtsに変換し始めることができます。 詳細については、次のブログ投稿を読むことができます： https ：

しかし、TypeScriptにアプローチする方法は、メンテナの1人が決定する必要があります。 両方のオプション（ d.tsファイルまたはtsファイルとjsファイルの混合）が実行可能だと思います。 そして、それは多かれ少なかれ個人的な好みとスタイルの問題です。

@tschoartschiこの問題を前進させたいと思います。 @mrdoobは、*。d.tsファイルを

* .d.tsファイルを並べて表示することは、非常に優れた最初のステップであり、簡単に実行できると思います。 私は、「完璧」が私たちの漸進的な進歩を妨げることを許さないことを望みます。

@ bhoustoncool😎私もお手伝いできます。 あなたが始めて、他の人たちと一緒に参加できるのは理にかなっていると思います。たぶん、 @types/threeメンテナと話すこともできます。 Three.jsワークスペースにSlackチャネルを作成する必要がありますか？ そのため、より迅速に調整でき、チャットのような会話でこの問題を汚染することはありません。 それでも、 @ mrdoobが彼の視点を追加するまで

これが@mrdoobから祝福を受けたら、私はポートに時間を費やすことをいとわない。

ブラウザがTypeScriptをネイティブにサポートしなくなるまで、私はJavaScriptES6に焦点を当てることを好みます。

.jsにコンパイルできることは理解していますが、srcから直接インポートできるようになり始めたばかりであり、TypeScriptに変換するよりもプロジェクトに役立つと思います。

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L37 -L48

* .d.tsファイルを並べて追加するのは良いことのように聞こえますが、誰かがそれを所有して最新の状態に保つ必要があります。

@mrdoobブラウザがTypeScriptをサポートするのを待つことはオプションではないと思います。 TypeScriptを実装するブラウザベンダーの意図は聞いていません。 しかし、特に例については、あなたの懸念がわかります。 私は新しい例を見ていませんでした。 例のソースファイルをインポートするだけでよいのは素晴らしいことです。

TypeScriptでライブラリを作成し、それでもsrcからJavaScriptをインポートする可能性を維持するための最良の解決策が何であるかはわかりません。 もちろん、TypeScriptファイルをトランスパイルしてから、対応するJavaScriptファイルを並べて配置することもできます（これはTypeScriptコンパイラの標準設定です）が、これにより、コードのバージョン管理などが複雑になる可能性があります。フォルダ構造は次のようになります。

three/
├── src/
    ├── cameras
        ├── PerspectiveCamera.ts // authored code
        ├── PerspectiveCamera.js // generated code by TS compiler

それでも、トランスパイルされたコードはdist 、 buildまたはbinフォルダーのどこかにあるはずなので、これは少し厄介なようです。 しかし、それは単なる意見であり、難しい事実ではありません。 たぶん、より良い解決策を知っているTypeScriptオタクがいるでしょう。

もう1つのオプションは、@ bhoustonによって提案されたd.tsファイルです。 しかし、 @ mrdoobが述べたように、 d.tsファイルを最新の状態に保つのは難しいかもしれません。 特に長期的な視点で。 今後数年間、それらを最新の状態に保つことは本当に管理可能ですか？ d.tsファイルの設定を手伝うことはできますが、常にそれらの更新に関与することを保証することはできません。 私にとって、1回限りのスロットをブロックしていくつかのことを実行するよりも、継続的に時間をコミットすることははるかに困難です。 @types/threeプロジェクトをサポートするのが良いのか、 d.tsファイルをthreeプロジェクトに直接追加するのが良いのかはまだわかりません。 @types/threeプロジェクトはすでに機能しており、 d.tsアプローチと同じニーズに対応しています。 同様の課題もあります。 これは基本的に物事を最新の状態に保つことです。

ですから、私の結論は、中期的には、Three.jsのTypeScriptにはあまり良くないように見えるということです。 TypeScriptの採用をもっと見たいのですが、私にとってはそれで問題ありません。

ちょうど別の提案：
Phaserゲームフレームワークは、コメントを使用して型定義を自動生成します。 このツールはオープンソースだと思います。 したがって、TS定義は、関数の上に/ **コメント* /を正しい方法で追加することで生成できます。

Phaserゲームフレームワークは、コメントを使用して型定義を自動生成します...

https://github.com/mrdoob/three.js/issues/11550およびhttps://github.com/mrdoob/three.js/issues/4725#issuecomment-41833647を参照してください。

ただし、 *.d.tsファイルのコメントからドキュメントを生成することは興味深いかもしれません。 🤔

* .d.tsファイルを並べて追加するのは良いことのように聞こえますが、誰かがそれを所有して最新の状態に保つ必要があります。

プログラムでタイピングをソースと照合できる場合は、これで問題ありません。 そうでない場合、そして最終的にTypeScriptでコードベースを書き直す予定がない場合は、タイピングをリポジトリに移動することはお勧めできません。 どちらかといえば、ここでそれらを維持する準備はあまりできていません—少なくとも現在のメンテナはTypeScript自体を使用しています。

このプロジェクトもありますhttps://github.com/semleti/three.ts
おそらく、新しいものを開始するのではなく、見て、v100にアップグレードする価値がありますか？
そのような巨大なプロジェクトで型を操作することがどれほど優れているかが明らかでない限り、Three.jsがTypeScriptで書き直されているのを見ないので...そして、言語に依存しているので、なぜそれが決して起こらないのかをよく理解していますこれはブラウザ内では標準ではありません。

@schoeningこの議論を始めたのは、Three.jsの概念実証型のTypeScriptバージョンがいくつかあるからです。 リンクしたリポジトリ、または@flyoverによってリポジトリ（https://github.com/flyover/three.ts、https://github.com/mrdoob/three.js/issues/11552#issuecomment-367026821） 。 フォークされたThree.tsバージョンの主な問題は、最新の状態を維持することです。 すべてのリポジトリはいくつかのバージョンが遅れており、これは「コア」チームによって維持されていないすべてのプロジェクトで発生すると思います。 Three.jsプロジェクトがTypeScriptをサポートしない場合は、 @ types / threeプロジェクトの同期を維持するのが最善だと思います。 そこで力を合わせるべきだと思います。

Three.jsが遠い将来のある時点でTypeScriptをサポートする予定である場合、そのような移行がどのように成功するかを考えるのは素晴らしいことです。 @donmccurdyが述べたように、TypeScriptの互換性を向上させるためのいくつかのアプローチがあります。 JSDocは実行可能なアプローチになると思います。 *.d.tsファイルは、JSDocのコメントよりも最新の状態に保つのがさらに難しいと思うので、まだ確信が持てません。 また、 *.d.tsファイルを使用してプログラムでソースと照合する方法はないと思います。 しかし、おそらく@bhoustonは彼のアプローチ、特に物事を最新に保つことに関する懸念を概説することができます。 たぶん、この問題に対するいくつかの賢い解決策があります。

これまでのところ、私にとって最高のエクスペリエンスは、vscode + d.ts + JSDocであり、すべて同じプロジェクトに含まれているため、同期を維持するのは簡単です。

最新のvscodeバージョンでは、 checkJsサポートが改善されています（ tsconfig.jsonで有効にできます）。これは基本的に、JSDocの型とd.tsからの宣言を使用してJavaScriptファイルをチェックするTypeScriptコンパイラです。 JSDoc構文では醜い、より「高度な」タイプの場合。

vscodeはすべてのタイプを導出できるため、すべての種類のタイプエラーも検出できます。したがって、リファクタリングが行われるたびに、 d.tsから「バギー/古い」タイプを簡単に確認および編集できるため、同期が維持されます。 。

TypeScriptの最悪の点は、追加のトランスパイルステップです。これは、コードを変更するたびに数秒かかる場合があります。 要するに、vscodeのJSDoc + d.tsには、型のすべての利点がありますが、非常に遅いトランスパイルステップの欠点はありません。

唯一の問題は、100％適切なJSDocタイプをすべてに追加することです。これにより、vscodeはそれに依存できます（ @constructor 、 <strong i="16">@enum</strong> {number} 、 <strong i="18">@param</strong> {number} n Number of steps ）

また、 @ bhoustonと@LuWangThreekitが*.d.tsファイルのPRを作成したこともここに追加したいと思います。 詳細については、メモを確認してください： https ：//github.com/mrdoob/three.js/issues/11552#issuecomment-454881060および/またはPRhttps： //github.com/mrdoob/three.js/pull/ 15597

追記：あれば活字体のブラウザでは、遠くないかもしれません電王（GitHubの上の32,000星でV8と錆の上に構築されたA活字体インタプリタ）は立派であることが分かります。

コアモジュールとサンプルモジュールの型宣言ファイルを追加したので、今のところ問題を解決しても問題ないと思います。 TSユーザーの開発経験は、昨年よりも間違いなく良くなるはずです。

TypeScriptに興味のある人のために...

@bhoustonが取り組んでいるこのThree.jsに触発されたライブラリは、あなたが探しているものかもしれません：

https://threeify.org/

Threeify @bhoustonからは、それがSemVerを持っており、セマンティック・リリースを使用しています偉大なプロジェクト🤩のように思えます。 TypeScriptの上に構築されており、そのコアバリューはツリーシェイクやスモールビルドファイルなどのようです。私たちの多くがThree.jsでも見たいと思っているものはすべてあります。 だから私はThreeifyに入る仕事を本当に大切にしてい

@bhouston @mrdoobしかし、本当に新しいプロジェクトを作成する必要がありますか？ コミュニティを分割することは理にかなっていますか？ 大きなフロントエンドフレームワークの多くは、コードやコミュニティのフォークなしで、SemVer、TypeScript、TreeShakingなどに移行することができました。

@pailheadがThree.jsの操作について興味深い記事を書いたと思います。それは、次のようなものだったと思います。Threeifyが実装しようとしていることのいくつかを採用するのを手伝いたいと思っている人々がいると思います。 新しいライブラリを作成する代わりに、力を合わせてThree.jsを改善するのは素晴らしいことだと思います。

インターネット上の多くの記事と同様に、Pailheadの記事には偏りがあります。 ライブラリの他の使用法は考慮されていません。

お互いの開発ワークフローを中断することなく、すべてのタイプのjs開発者に対応するライブラリを作成することは不可能だと思います。

@pailheadと非常によく似た経験がありますが、彼のワークフローはニッチなワークフローではないと思います。 彼のワークフローは、 Vue 、 Ember 、 React 、 Svelte 、 Angularなどの最新のフロントエンドフレームワークを使用する開発者にとって非常に一般的だと思います。

たぶん、 Vueがそれをどのように行っているかを見てみる必要があります。 Webサイトを強化したいPHPプログラマーから、洗練されたWebアプリを開発する人々まで、さまざまなユーザーベースがあります。 それはそれらの異なるタイプのユーザー間の曲線を非常にうまく曲げます。

また、すべての人の経験を損なうことなく既存のコードベースをアップグレードすることについても、すばらしい例があります。 EmberがどのようにしてWebコミュニティとその業界標準とともに一貫して成長したかを見ることができます。

私は、最新のWeb開発を実行不可能な状態に保つことを考えていません。 しかし、それは大変な努力であり、私たちはそれらのことに多くのことを考える必要があることに完全に同意します。 そのため、いくつかの新しいプロジェクトを作成するよりも、一緒に作業して最新のエクスペリエンスを作成する方がよいと思います。

このスレッドを実行すると、Three.tsとThreeifyという2つの異なるプロジェクトがすでに存在し、おそらくさらに多くのプロジェクトがあります。 フォークや個別のイニシアチブを作成するのではなく、一緒に作業すれば、Three.jsコミュニティ全体に大きなメリットがあると心から信じています。

@mrdoob 、いくつかのデータを収集するための調査はどうですか？ typescriptの使用は1つのことであり、見積もりを取得するために試すことができる他の定性的変数があると確信しています。

@ roomle-buildライブラリをTypeScriptに変換することの欠点をリストできますか？

ライブラリにTypeScriptを徐々に採用することの本当の欠点はわかりません。 対照的に、それは多くの利点をもたらすと思います（これが多くのプロジェクトがTypeScriptに変換している理由です）。 それでも、もちろんいくつかの課題があります。たとえば、次のようになります。

• TSを使用していないユーザーに優れたエクスペリエンスを提供するにはどうすればよいでしょうか。
• ビルドステップのないユーザーはどのようにライブラリを使用できますか
• そしてもちろん、私が考えていなかった他のすべてのもの

しかし、前に述べたように、これらの質問は他のプロジェクトでも解決され、そこからこれらの解決策をコピーできます（たとえば、 VueやEmberなど）。

しかし、私が指摘したい主なことは、コミュニティが分裂し、いくつかの異なるプロジェクトとフォークのフォークがある場合、それは危険だと思うということです。 私は断片化のファンではないので、お互いに反対するよりも一緒に仕事をする方が良いと思います。 もちろん、競争は素晴らしく、これはThree.jsプロジェクトでもイノベーションを促進すると主張する人もいますが、私はコラボレーションを信じています🙂

three.jsの最大の利点の1つは、そのアクセシビリティです。 @ roomle-buildがリストしたポイントは、エンジンの使いやすさを悪化させます（特に初心者のコンテキストでは）。 ブラウザで代替プログラミング言語がネイティブにサポートされていない限り、JavaScriptの使用を継続することに投票します。

私は断片化のファンではないので、お互いに反対するよりも一緒に仕事をする方が良いと思います。

Webに3Dエンジンが多いからといって、開発者が互いに反対に取り組んでいるわけではありません。 異なるプロジェクトが異なることに焦点を合わせている方が実際に良い場合もあります。

three.jsの最大の利点の1つは、そのアクセシビリティです。 @ roomle-buildがリストしたポイントは、エンジンの使いやすさを悪化させます（特に初心者のコンテキストでは）。

他のプロジェクトがアクセシビリティに影響を与えることなくTypeScriptでコードを作成しているため、このようには見えません。 前に例としてVueとEmberについて触れました。 たぶん、TypeScriptに対するスタンスを見直すのは理にかなっていますか？ 他のプロジェクトから成功したアプローチをコピーするだけでよいものを発明する必要はありません。 さらに、TypeScriptには、寄稿者がthree.jsアクセスしやすくなるという利点があると思います。これは、IDEがプロジェクト全体の概要をより早く把握するのに役立つためです。

ブラウザで代替プログラミング言語がネイティブにサポートされていない限り、JavaScriptの使用を継続することに投票します。

これは近い将来には起こらないと思うので、TypeScriptについてもっと実用的な見方をする必要があると思います。 上で書いたように、それはプロジェクトとリポジトリがどのように編成されているかという問題であり、使いやすさと開発経験の間のトレードオフではないと思います。

私たちは自分たちの立場を明確にしたと思います。