Dari tampilan kinerja runtime, saya tertarik pada

Juga alat eksperimental seperti AssemblyScript dapat menjadi opsi untuk bagian kritikus kinerja tertentu dari kode sumber

Saya telah melakukan eksperimen Three.js core + WASM.

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

Dari eksperimen saya menyadari bahwa mem-porting seluruh inti ke WASM dapat meningkatkan kinerja runtime, 1,5x lebih cepat pada contoh saya, sementara mem-porting sebagian bagian-bagian kecil, misalnya hanya kode Matematika (Vector3, Matrix4, ...), tidak bermanfaat karena overhead JS-WASM besar.

Tapi saya tidak berpikir itu ide yang baik untuk menulis ulang seluruh inti Three.js ke C++ atau Rust untuk kontributor karena kesulitan pemeliharaan jadi saya telah mencari cara alternatif. Saya tertarik jika TypeScript + AssemblyScript berfungsi dengan baik untuk Three.js.

Bagaimana cara memulai? Haruskah kita mulai pada awalnya hanya dengan file d.ts atau melompat sepenuhnya ke TypeScript?

Kami akan mengirimkan PR yang menambahkan file *.d.ts ke Three.JS, terutama berdasarkan @types/three (sehingga menggunakan kembali pekerjaan itu.) Itu adalah titik awal yang bagus dan mari kita lanjutkan di JS untuk saat ini. Bisa juga dilakukan secara bertahap.

@takahirox kerja bagus :-) Saya selalu terpesona betapa banyak pekerjaan inovatif terjadi di sekitar Three.js. Sangat disayangkan bahwa pembuktian konsep ini kurang diperhatikan. Saya juga berpikir bahwa menulis ulang semuanya dalam C++ atau Rust bukanlah suatu pilihan. Mungkin AssemblyScript tapi saya tidak mencoba AssemblyScript jadi saya hanya bisa berbicara tentang apa yang saya baca tentang AssemblyScript. Tapi mungkin kita harus mempertimbangkan AssemblyScript juga karena seperti yang saya pahami, ini kurang lebih merupakan bagian dari TypeScript

@bhouston Saya tidak yakin apakah memindahkan file d.ts dari @types/three ke repo three sangat masuk akal. Terutama karena file d.ts dapat dihasilkan dari file TypeScript dan kemudian mereka selalu sinkron. Apakah ada cara untuk memastikan bahwa file d.ts selalu sinkron dengan file js secara otomatis? Jika ya maka saya pikir meletakkan file d.ts ke dalam repo three dapat bermanfaat. Juga saya pikir itu tergantung pada keputusan pengelola. Jika mereka tidak ingin mengadopsi TypeScript, file d.ts bisa menjadi pilihan. Juga jika mereka memutuskan untuk menambahkan TypeScript dalam beberapa tahun, kami dapat menjembatani kali ini dengan file d.ts . Kalau tidak, saya khawatir ada lebih sedikit manfaat dan lebih banyak pekerjaan. Tapi mungkin aku hanya mengabaikan sesuatu

@bhouston Saya tidak yakin apakah memindahkan file d.ts dari @types/three ke tiga repo masuk akal. Terutama karena file d.ts ini dapat dihasilkan dari file TypeScript dan kemudian selalu sinkron.

Jika kita pindah langsung ke TypeScript maka file *.d.ts tidak diperlukan. Masalahnya adalah bahwa saat ini proyek @types/three selalu ketinggalan zaman dengan Three.JS karena dikelola secara terpisah. Juga mencerminkan struktur yang dibangun dari three.js daripada file individual dan dengan demikian tidak dapat mendukung pengocokan pohon dan bentuk pengoptimalan lainnya. Jadi menambahkan file *.d.ts sangat meningkatkan proyek dari keadaan saat ini, tetapi tidak sebagus pindah ke file *.ts secara langsung.

Jika kita dapat beralih ke file *.ts secara langsung, itu adalah opsi yang lebih baik. Saya tidak yakin ada dukungan untuk itu.

Saya mengerti Three.JS suka melakukan sesuatu secara bertahap, jadi ini adalah opsi tambahan daripada big bang.

@bhouston Saya sangat setuju dengan Anda. Dan saya juga berpikir bahwa penulisan ulang big bang tidak mungkin jadi kita perlu mengadopsinya secara bertahap. Tetapi jika saya membaca dokumen TypeScript, sepertinya kita bisa memiliki file ts dan js secara berdampingan. Jadi kita bisa mulai mengonversi satu file ke ts. Untuk lebih jelasnya, Anda dapat membaca posting blog ini: https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

Tetapi cara mendekati TypeScript harus diputuskan oleh salah satu pengelola. Saya pikir kedua opsi (file d.ts atau mencampur file ts dan js) layak dilakukan. Dan ini kurang lebih merupakan pertanyaan tentang preferensi dan gaya pribadi.

@tschoartschi Saya ingin memajukan masalah ini. @mrdoob telah menyetujui file *.d.ts berdampingan. Saya ingin pergi ke sana karena itu tidak memaksa TypeScript pada orang segera dan kami dapat mundur tanpa harus menulis ulang semua kontribusi selama fase *.ts. Dan kemudian kita masih dapat mengonversi file *.js ke file *.ts secara bertahap sebagian besar saya menggabungkannya dengan file *.d.ts berdampingan.

Saya pikir file *.d.ts berdampingan adalah langkah pertama yang sangat bagus dan mudah dilakukan. Saya lebih suka untuk tidak membiarkan "kesempurnaan" menghalangi kita membuat kemajuan bertahap.

@bhouston keren Saya juga bisa membantu. Saya pikir masuk akal jika Anda memulai dan orang lain dan saya kemudian dapat bergabung. Mungkin kita juga dapat berbicara dengan pengelola @types/three . Haruskah kita membuat saluran Slack di ruang kerja Three.js? Jadi kami dapat menyelaraskan lebih cepat dan tidak mencemari masalah ini dengan percakapan seperti obrolan. Namun demikian, saya akan menunggu sebentar sampai @mrdoob menambahkan sudut pandangnya. Karena jika dia menentang TypeScript, saya pikir kita tidak perlu menginvestasikan waktu.

Saya rela menyempatkan waktu ke pelabuhan begitu mendapat restu dari @mrdoob.

Sampai browser tidak mendukung TypeScript secara asli, saya lebih suka fokus pada JavaScript ES6.

Saya mengerti itu dapat dikompilasi ke .js, tetapi kami baru mulai dapat mengimpor dari src secara langsung dan saya pikir itu akan membantu proyek lebih dari mengonversi ke TypeScript.

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

Menambahkan file *.d.ts secara berdampingan terdengar bagus, tetapi akan membutuhkan seseorang untuk memilikinya dan tetap memperbaruinya.

@mrdoob Saya tidak berpikir menunggu browser untuk mendukung TypeScript adalah sebuah pilihan. Saya tidak mendengar niat apa pun dari vendor browser mana pun untuk mengimplementasikan TypeScript. Tapi saya melihat kekhawatiran Anda, terutama dengan contoh-contohnya. Saya tidak melihat contoh-contoh baru. Luar biasa bahwa mungkin saja mengimpor file sumber dalam contoh.

Saya tidak yakin apa solusi terbaik untuk membuat perpustakaan di TypeScript dan masih menyimpan kemungkinan untuk mengimpor JavaScript dari src. Tentu saja, kita dapat mengubah file TypeScript dan kemudian memiliki file JavaScript yang sesuai secara berdampingan (yang merupakan pengaturan standar kompiler TypeScript) tetapi ini dapat memperumit hal-hal seperti pembuatan versi kode, dll. Struktur folder dapat terlihat seperti

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

Namun demikian, ini tampak agak canggung bagi saya karena kode yang di-transpilasikan harus masuk ke suatu tempat ke folder dist , build atau bin . Tapi itu hanya pendapat bukan fakta yang sulit. Mungkin ada beberapa Geeks TypeScript yang tahu solusi yang lebih baik.

Opsi lainnya adalah file d.ts disarankan oleh @bhouston. Tetapi seperti yang disebutkan @mrdoob , mungkin sulit untuk memperbarui file d.ts . Terutama pada pandangan jangka panjang. Apakah benar-benar dapat dikelola untuk membuat mereka tetap up to date untuk tahun-tahun berikutnya? Saya dapat membantu menyiapkan file d.ts tetapi saya tidak dapat menjamin bahwa saya akan terlibat dalam memperbaruinya sepanjang waktu. Bagi saya, jauh lebih sulit untuk melakukan waktu terus menerus daripada memblokir slot satu kali dan menyelesaikan beberapa hal. Saya masih tidak yakin apakah lebih baik mendukung proyek @types/three atau menambahkan file d.ts langsung ke proyek three . Proyek @types/three sudah bekerja dan melayani kebutuhan yang sama seperti pendekatan d.ts . Ini juga memiliki tantangan serupa. Yang pada dasarnya menjaga segala sesuatunya tetap up to date.

Jadi kesimpulan saya adalah, itu tidak terlihat terlalu bagus untuk TypeScript di Three.js di masa depan jangka menengah. Bagi saya itu bagus meskipun saya ingin melihat lebih banyak adopsi TypeScript.

Hanya saran lain:
Kerangka kerja game Phaser menggunakan komentarnya untuk menghasilkan definisi tipe secara otomatis. Saya pikir alat ini opensource. Jadi definisi TS dapat dibuat dengan menambahkan /** komentar */ di atas fungsi dengan cara yang benar.

Kerangka kerja game Phaser menggunakan komentarnya untuk menghasilkan definisi tipe secara otomatis...

Lihat https://github.com/mrdoob/three.js/issues/11550 dan https://github.com/mrdoob/three.js/issues/4725#issuecomment -41833647.

Meskipun, menghasilkan dokumentasi dari komentar di file *.d.ts mungkin menarik. 🤔

Menambahkan file *.d.ts secara berdampingan terdengar bagus, tetapi akan membutuhkan seseorang untuk memilikinya dan tetap memperbaruinya.

Jika pengetikan dapat diperiksa terhadap sumber secara terprogram, saya setuju dengan ini. Jika tidak, dan jika pada akhirnya kita tidak berencana untuk menulis ulang basis kode di TypeScript, saya rasa bukan ide yang baik untuk memindahkan pengetikan ke dalam repositori. Jika ada, kami kurang siap untuk memeliharanya di sini — setidaknya pengelola saat ini menggunakan TypeScript sendiri.

Ada juga proyek ini https://github.com/semleti/three.ts
Mungkin layak untuk dilihat dan ditingkatkan ke v100 daripada memulai yang baru?
Karena saya tidak melihat Three.js ditulis ulang dalam TypeScript kecuali jelas betapa lebih menyenangkan bekerja dengan tipe untuk proyek besar seperti itu ... Dan saya cukup mengerti mengapa itu mungkin tidak pernah terjadi karena itu akan bergantung pada bahasa yang tidak standar di dalam browser.

@schoening Saya memulai diskusi ini karena ada beberapa versi TypeScript proof-of-concept dari Three.js di luar sana. Ini adalah repo yang Anda tautkan , atau repo yang dilakukan oleh @types/three untuk tetap sinkron. Saya pikir kita harus bergabung di sana.

Jika Three.js akan mendukung TypeScript di beberapa titik di masa depan yang jauh, akan sangat bagus untuk memikirkan bagaimana transisi semacam itu bisa berhasil. Seperti yang disebutkan @donmccurdy ada beberapa pendekatan untuk mencapai kompatibilitas TypeScript yang lebih baik. Saya pikir JSdoc bisa menjadi pendekatan yang layak. Saya masih tidak yakin dengan file *.d.ts karena saya pikir lebih sulit untuk memperbaruinya daripada komentar JSDoc. Saya juga tidak berpikir ada cara untuk memeriksa sumber secara terprogram dengan file *.d.ts . Tapi mungkin @bhouston bisa menjelaskan pendekatannya, terutama kekhawatiran seputar menjaga segala sesuatunya tetap up-to-date. Mungkin ada beberapa solusi cerdas untuk masalah ini.

Pengalaman terbaik bagi saya sejauh ini adalah vscode + d.ts + JSDoc, semuanya dalam proyek yang sama, sehingga mudah untuk tetap sinkron.

Versi vscode terbaru telah meningkatkan dukungan checkJs (dapat diaktifkan di tsconfig.json ), yang pada dasarnya adalah kompiler TypeScript yang memeriksa file JavaScript, menggunakan tipe dari JSDoc ditambah deklarasi yang digabungkan dari d.ts untuk tipe yang lebih "maju", yang akan jelek dalam sintaksis JSdoc.

Karena vscode dapat menurunkan semua jenis, ia juga dapat mendeteksi semua jenis kesalahan jenis, jadi setiap kali pemfaktoran ulang selesai, mudah untuk melihat dan mengedit jenis "kereta/lama" dari d.ts , sehingga terus disinkronkan .

Hal terburuk tentang TypeScript adalah langkah transpile ekstra, yang dapat memakan waktu beberapa detik untuk setiap perubahan kode. Singkatnya, JSDoc + d.ts di vscode memiliki semua kelebihan tipe tetapi bukan kelemahan dari langkah transpile ekstra lambat.

Satu-satunya masalah adalah menambahkan 100% tipe JSDoc yang tepat untuk semuanya, jadi vscode dapat mengandalkannya (hanya hal-hal seperti @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

Saya juga ingin menambahkan di sini bahwa @bhouston dan @LuWangThreekit membuat PR untuk file *.d.ts . Untuk detail lebih lanjut, lihat catatan mereka: https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 dan/atau PR mereka https://github.com/mrdoob/three.js/pull/ 15597

Sidenote: TypeScript di browser mungkin tidak jauh jika Deno (Penerjemah TypeScript yang dibangun di atas V8 dan Rust dengan 32.000 bintang di GitHub) terbukti layak.

Karena kami menambahkan file deklarasi tipe untuk inti dan modul contoh, saya pikir tidak apa-apa untuk menutup masalah untuk saat ini. Pengalaman pengembangan untuk pengguna TS pasti lebih baik dari tahun lalu.

Bagi siapa pun yang tertarik dengan TypeScript ...

Pustaka yang terinspirasi Three.js yang sedang dikerjakan

https://threeify.org/

Threeify dari @bhouston sepertinya proyek yang hebat ia memiliki SemVer dan menggunakan rilis semantik. Itu dibangun di atas TypeScript dan nilai-nilai intinya tampaknya seperti Tree Shaking, Small Build Files dll. Semua hal yang banyak dari kita ingin lihat di Three.js juga. Jadi saya sangat menghargai pekerjaan yang masuk ke Threeify 👍

@bhouston @mrdoob Tapi apakah benar-benar perlu membuat proyek baru? Apakah masuk akal untuk memecah komunitas? Banyak kerangka kerja front-end besar berhasil melakukan transisi ke hal-hal seperti SemVer, TypeScript, Tree Shaking dll tanpa garpu kode dan komunitas mereka.

Saya pikir @pailhead menulis artikel menarik tentang bekerja dengan Three.js, menurut saya adalah sebagai berikut: Bekerja dengan versi three.js yang berbeda . Jadi saya pikir ada orang-orang di komunitas yang ingin membantu mengadopsi beberapa hal yang coba diterapkan oleh Threeify . Saya pikir akan sangat bagus untuk bergabung dan meningkatkan Three.js daripada membuat perpustakaan baru.

Seperti banyak artikel di internet, artikel Pailhead ini bias. Tidak memperhitungkan kegunaan lain dari perpustakaan.

Saya tidak berpikir itu mungkin untuk membuat perpustakaan yang melayani semua jenis pengembang js tanpa mengganggu alur kerja pengembangan satu sama lain.

Kami memiliki pengalaman yang sangat mirip dengan @pailhead, saya tidak berpikir alur Vue , Ember , React , Svelte , Angular ...

Mungkin kita harus melihat bagaimana Vue melakukannya. Ini memiliki basis pengguna mulai dari programmer PHP yang hanya ingin meningkatkan situs web mereka hingga orang-orang yang mengembangkan aplikasi web canggih. Ini membengkokkan kurva antara berbagai jenis pengguna dengan sangat baik.

Juga tentang memutakhirkan basis kode yang ada tanpa merusak pengalaman untuk semua orang, ada contoh bagus di luar sana. Kita bisa melihat bagaimana Ember berhasil tumbuh secara konsisten dengan komunitas web dan standar industrinya.

Saya tidak akan menganggap tetap up-to-date dengan pengembangan web modern tidak layak. Tapi saya sangat setuju bahwa ini membutuhkan banyak usaha dan kita perlu banyak memikirkan hal-hal itu. Inilah mengapa saya percaya lebih baik bekerja sama untuk menciptakan pengalaman modern daripada membuat beberapa proyek baru.

Saat Anda membaca utas ini, sudah ada dua proyek berbeda, Three.ts dan Threeify dan mungkin masih banyak lagi di luar sana. Saya benar-benar percaya bahwa akan ada manfaat besar bagi seluruh komunitas Three.js jika kita mau bekerja sama daripada membuat garpu dan inisiatif terpisah.

@mrdoob , bagaimana dengan survei untuk mengumpulkan beberapa data? penggunaan TypeScript adalah satu hal dan saya yakin ada variabel kualitatif lain yang bisa kita coba untuk mendapatkan perkiraan.

@roomle-build dapatkah Anda membuat daftar kerugian dari mengonversi perpustakaan ke TypeScript?

Saya tidak melihat kerugian nyata dari mengadopsi TypeScript secara bertahap untuk perpustakaan. Sebaliknya, saya pikir itu akan membawa banyak manfaat (inilah sebabnya banyak proyek mengonversi ke TypeScript). Meskipun demikian, ada beberapa tantangan tentunya, misalnya:

• bagaimana kami dapat memberikan pengalaman yang menyenangkan bagi pengguna non-TS?
• bagaimana pengguna tanpa langkah bawaan dapat menggunakan perpustakaan?
• dan tentu saja semua hal lain yang tidak saya pikirkan

Tetapi seperti yang saya katakan sebelumnya, pertanyaan-pertanyaan itu diselesaikan di proyek lain juga dan kami dapat menyalin solusi ini dari sana (seperti Vue atau Ember misalnya).

Tetapi hal utama yang ingin saya tunjukkan adalah, menurut saya berbahaya jika komunitas terpecah dan kami memiliki beberapa proyek yang berbeda dan fork of for fork. Saya bukan penggemar fragmentasi dan saya pikir lebih baik bekerja sama daripada melawan satu sama lain. Tentu saja ada orang lain yang akan berargumen bahwa persaingan itu hebat dan ini akan mengembangkan inovasi juga dalam proyek Three.js tetapi saya lebih percaya pada kolaborasi

Saya pikir salah satu keuntungan terbesar dari three.js adalah aksesibilitasnya. Poin yang telah dicantumkan @roomle-build akan memperburuk kemudahan penggunaan mesin (terutama dalam konteks pemula). Saya memilih untuk terus menggunakan JavaScript kecuali bahasa pemrograman alternatif didukung secara asli di browser.

Saya bukan penggemar fragmentasi dan saya pikir lebih baik bekerja sama daripada melawan satu sama lain.

Memiliki lebih banyak mesin 3D di web tidak berarti para pengembang bekerja melawan satu sama lain. Terkadang sebenarnya lebih baik jika proyek yang berbeda fokus pada hal yang berbeda.

Saya pikir salah satu keuntungan terbesar dari three.js adalah aksesibilitasnya. Poin yang telah dicantumkan @roomle-build akan memperburuk kemudahan penggunaan mesin (terutama dalam konteks pemula).

Saya tidak melihatnya seperti ini karena proyek lain membuat kode mereka dalam TypeScript tanpa pengaruh apa pun pada aksesibilitas. Saya menyebutkan Vue dan Ember sebagai contoh sebelumnya. Mungkin masuk akal untuk meninjau sikap terhadap TypeScript? Kami tidak perlu menemukan sesuatu yang kami hanya perlu menyalin pendekatan yang berhasil dari proyek lain. Selain itu, menurut saya TypeScript akan mendapat manfaat bahwa three.js akan lebih mudah diakses oleh kontributor karena IDE dapat membantu mereka mendapatkan gambaran umum keseluruhan proyek dengan lebih cepat.

Saya memilih untuk terus menggunakan JavaScript kecuali bahasa pemrograman alternatif didukung secara asli di browser.

Saya pikir ini tidak akan terjadi di masa mendatang dan oleh karena itu saya pikir kita harus memiliki pandangan yang lebih pragmatis tentang TypeScript. Seperti yang saya tulis di atas, saya pikir ini hanya masalah bagaimana proyek dan repo diatur dan bukan pertukaran antara kemudahan penggunaan dan pengalaman pengembangan.

Saya pikir kami telah membuat posisi kami jelas.