Du point de vue des performances d'exécution, je suis intéressé par

Des outils expérimentaux comme AssemblyScript pourraient également devenir une option pour certaines parties du code source très critiques en termes de performances.

J'ai fait l'expérimentation de Three.js core + WASM.

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

D'après l'expérimentation, j'ai réalisé que le portage de l'intégralité du noyau vers WASM peut améliorer les performances d'exécution, 1,5 fois plus rapidement sur mon exemple, tout en portant partiellement les petites parties, par exemple uniquement des codes mathématiques (Vector3, Matrix4, ...), n'est pas avantageux car de gros frais généraux JS-WASM.

Mais je ne pensais pas que c'était une bonne idée de réécrire l'intégralité du noyau Three.js en C++ ou Rust pour les contributeurs en raison de la difficulté de maintenance, j'ai donc cherché des moyens alternatifs. Je souhaite savoir si TypeScript + AssemblyScript fonctionne correctement pour Three.js.

Comment commencer? Devrions-nous commencer d'abord uniquement avec les fichiers d.ts ou sauter complètement dans TypeScript ?

Nous soumettrons un PR qui ajoute des fichiers *.d.ts à Three.JS, basé principalement sur @types/three (réutilisant ainsi ce travail.) C'est un excellent point de départ et nous permet de continuer en JS pour le moment. Cela peut aussi se faire de manière incrémentale.

@takahirox beau travail :-) Je suis toujours fasciné par la quantité de travail innovant qui se produit autour de Three.js. C'est dommage que ces preuves de concept retiennent autant l'attention. Je pense aussi que tout réécrire en C++ ou en Rust n'est pas une option. Peut-être que AssemblyScript l'est, mais je n'ai pas essayé AssemblyScript, donc je peux juste parler de ce que j'ai lu sur AssemblyScript. Mais peut-être devrions-nous également envisager AssemblyScript car, si je comprends bien, il s'agit plus ou moins d'un sous-ensemble de TypeScript

@bhouston Je ne sais pas si déplacer les fichiers d.ts de @types/three vers le référentiel three a beaucoup de sens. Surtout parce que ces fichiers d.ts peuvent être générés à partir des fichiers TypeScript et qu'ils sont alors toujours synchronisés. Existe-t-il un moyen de garantir que les fichiers d.ts sont toujours synchronisés avec les fichiers js de manière automatisée ? Si oui, je pense que mettre les fichiers d.ts dans le three pourrait être bénéfique. Je pense aussi que cela dépend de la décision des responsables. S'ils ne souhaitent pas adopter TypeScript, les fichiers d.ts pourraient également être une option. De plus, s'ils décidaient d'ajouter TypeScript dans quelques années, nous pourrions combler cette fois-ci avec des fichiers d.ts . Sinon, j'ai peur qu'il y ait moins d'avantages et plus de travail. Mais peut-être que je néglige quelque chose

@bhouston Je ne sais pas si déplacer les fichiers d.ts de @types/three vers les trois repo a beaucoup de sens. Surtout parce que ces fichiers d.ts peuvent être générés à partir des fichiers TypeScript et qu'ils sont alors toujours synchronisés.

Si nous passons directement à TypeScript, les fichiers *.d.ts ne seraient pas nécessaires. Le problème est qu'actuellement, le projet @types/three est toujours légèrement obsolète avec Three.JS car il est maintenu séparément. De plus, il reflète la structure construite de three.js plutôt que des fichiers individuels et ne peut donc pas prendre en charge le tremblement d'arbre et d'autres formes d'optimisation. Ainsi, l'ajout de fichiers *.d.ts améliore considérablement le projet par rapport à son état actuel, mais ce n'est pas aussi bon que de passer directement aux fichiers *.ts.

Si nous pouvons aller directement vers les fichiers *.ts, c'est la meilleure option. Je n'étais pas sûr qu'il y ait un soutien pour cela.

Je comprends que Three.JS aime faire les choses progressivement, c'était donc une option incrémentielle plutôt qu'un big bang.

@bhouston je suis tout à fait d'accord avec toi. Et je pense aussi qu'une réécriture big bang n'est pas possible donc nous devons adopter progressivement. Mais si je lis la documentation TypeScript, il semble que nous pourrions avoir des fichiers ts et js côte à côte. Nous pourrions donc commencer à convertir des fichiers uniques en ts. Pour plus de détails, vous pouvez lire cet article de blog : https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

Mais la façon d'aborder TypeScript doit être décidée par l'un des responsables. Je pense que les deux options (fichiers d.ts ou mélange

@tschoartschi J'aimerais faire avancer ce problème. @mrdoob a approuvé les fichiers *.d.ts côte à côte. J'aimerais y aller car il n'impose pas immédiatement TypeScript aux gens et nous pouvons le retirer sans avoir à réécrire toutes les contributions pendant la phase *.ts. Et puis nous pouvons toujours convertir les fichiers *.js en fichiers *.ts de manière incrémentielle, principalement en les fusionnant avec les fichiers *.d.ts côte à côte.

Je pense que les fichiers *.d.ts côte à côte sont une très bonne première étape et c'est facile à faire. Je préférerais ne pas permettre à la « perfection » de nous empêcher de faire des progrès incrémentiels.

@bhouston cool 😎 Je pourrais aussi aider. Je pense qu'il serait logique que vous commenciez et d'autres et que je puisse ensuite participer. Peut-être pourrions-nous également parler aux responsables de @types/three . Doit-on créer une chaîne Slack dans l'espace de travail Three.js ? Nous pouvons donc nous aligner plus rapidement et ne pas polluer ce problème avec des conversations de type chat. Néanmoins, j'attendrais un moment que @mrdoob ajoute son point de vue. Parce que s'il est contre TypeScript, je pense que nous ne devrions pas investir de temps.

Je suis prêt à consacrer du temps au port une fois que cela aura reçu la bénédiction de @mrdoob.

Jusqu'à ce que les navigateurs ne prennent pas en charge TypeScript nativement, je préfère me concentrer sur JavaScript ES6.

Je comprends qu'il peut être compilé en .js, mais nous commençons tout juste à être en mesure d'importer directement depuis src et je pense que cela va aider le projet plus que la conversion en TypeScript.

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

L'ajout de fichiers *.d.ts côte à côte semble bien, mais il faudra que quelqu'un le possède et les maintienne à jour.

@mrdoob Je ne pense pas qu'attendre que les navigateurs prennent en charge TypeScript soit une option. Je n'ai entendu aucune intention de la part d'un fournisseur de navigateur d'implémenter TypeScript. Mais je vois vos inquiétudes, surtout avec les exemples. Je n'ai pas regardé les nouveaux exemples. C'est génial qu'il soit possible d'importer simplement les fichiers source dans les exemples.

Je ne sais pas quelle serait la meilleure solution pour créer la bibliothèque en TypeScript tout en gardant la possibilité d'importer du JavaScript à partir de src. Bien sûr, nous pourrions transpiler les fichiers TypeScript et ensuite avoir le fichier JavaScript correspondant côte à côte (qui est le paramètre standard du compilateur TypeScript), mais cela pourrait compliquer des choses comme la gestion des versions de code, etc. La structure des dossiers pourrait ressembler à

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

Néanmoins, cela me semble un peu gênant car le code transpilé devrait aller quelque part dans un dossier dist , build ou bin . Mais c'est juste une opinion pas un fait dur. Peut-être qu'il y a des geeks de TypeScript qui connaissent une meilleure solution.

L'autre option est le fichier d.ts suggéré par @bhouston. Mais comme @mrdoob l'a mentionné, il pourrait être difficile de maintenir les fichiers d.ts à jour. Surtout dans une vision à long terme. Est-il vraiment gérable de les tenir à jour pour les prochaines années ? Je pourrais aider à configurer les fichiers d.ts mais je ne peux pas garantir que je serai impliqué dans leur mise à jour tout le temps. Pour moi, il est beaucoup plus difficile de consacrer du temps en continu que de bloquer un créneau unique et de faire certaines choses. Je ne sais toujours pas s'il vaut mieux prendre en charge le projet @types/three ou ajouter des fichiers d.ts directement dans le projet three . Le projet @types/three fonctionne déjà et répond aux mêmes besoins que l'approche d.ts . Il a également des défis similaires. Ce qui consiste essentiellement à maintenir les choses à jour.

Ma conclusion est donc que cela ne semble pas très bon pour TypeScript dans Three.js à moyen terme. Pour moi, c'est bien, même si j'aimerais voir plus d'adoption de TypeScript.

Juste une autre suggestion :
Le framework de jeu Phaser utilise ses commentaires pour générer automatiquement des définitions de type. Je pense que l'outil est open source. Ainsi, les définitions TS pourraient être générées en ajoutant des commentaires /** */ au-dessus des fonctions de manière correcte.

Le framework de jeu Phaser utilise ses commentaires pour générer automatiquement des définitions de type...

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

Cependant, générer de la documentation à partir de commentaires dans des fichiers *.d.ts peut être intéressant. ??

L'ajout de fichiers *.d.ts côte à côte semble bien, mais il faudra que quelqu'un le possède et les maintienne à jour.

Si les frappes peuvent être vérifiées par rapport à la source par programmation, cela me convient. Sinon, et si nous ne prévoyons pas de réécrire éventuellement la base de code en TypeScript, je ne pense pas que ce soit une bonne idée de déplacer les saisies dans le référentiel. Si quoi que ce soit, nous sommes moins préparés à les maintenir ici - au moins les mainteneurs actuels utilisent eux-mêmes TypeScript.

Il y a aussi ce projet https://github.com/semleti/three.ts
Cela vaut peut-être la peine d'y jeter un coup d'œil et de l'amener à la v100 plutôt que d'en commencer une nouvelle ?
Parce que je ne vois pas Three.js être réécrit en TypeScript à moins qu'il ne soit évident à quel point il est plus agréable de travailler avec des types pour un projet aussi énorme... Et je comprends tout à fait pourquoi cela pourrait ne jamais arriver car il s'appuierait sur un langage ce n'est pas standard dans le navigateur.

@schoening J'ai commencé cette discussion car il existe des versions TypeScript de preuve de concept de Three.js. C'est le référentiel que vous avez lié, ou le référentiel fait par @types/three à rester synchronisé. Je pense que nous devrions unir nos forces là-bas.

Si Three.js prend en charge TypeScript dans un avenir lointain, ce serait formidable de penser à la manière dont une telle transition pourrait réussir. Comme @donmccurdy l'a mentionné, il existe plusieurs approches pour obtenir une meilleure compatibilité TypeScript. Je pense que JSDoc pourrait être une approche viable. Je ne suis toujours pas convaincu par les fichiers *.d.ts car je pense qu'il est encore plus difficile de les tenir à jour que les commentaires JSDoc. De plus, je ne pense pas qu'il existe un moyen de vérifier la source par programme avec des fichiers *.d.ts . Mais peut-être que @bhouston pourrait décrire son approche, en particulier les préoccupations concernant la mise à jour des choses. Il existe peut-être des solutions intelligentes à ce problème.

La meilleure expérience pour moi à ce jour est vscode + d.ts + JSDoc, le tout dans le même projet, il est donc facile de rester synchronisé.

La dernière version de vscode a amélioré la prise en charge de checkJs (peut être activée dans tsconfig.json ), qui consiste essentiellement en un compilateur TypeScript vérifiant les fichiers JavaScript, en utilisant les types de JSDoc plus la déclaration de fusion de d.ts pour les types plus "avancés", ce qui serait moche dans la syntaxe JSDoc.

Étant donné que vscode peut dériver tous les types, il peut également détecter toutes sortes d'erreurs de type, donc chaque fois que la refactorisation est effectuée, il est facile de voir et de modifier les types "buggés/anciens" de d.ts , donc il continue d'être synchronisé .

Le pire à propos de TypeScript est l'étape de transpile supplémentaire, qui peut prendre quelques secondes pour chaque changement de code. En bref, JSDoc + d.ts en vscode a tous les avantages des types mais pas l'inconvénient de l'étape de transpile extra lente.

Le seul problème est d'ajouter 100% du type JSDoc approprié à tout, afin que vscode puisse s'y fier (juste des trucs comme @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

Je voulais aussi ajouter ici que @bhouston et @LuWangThreekit ont créé un PR pour les fichiers *.d.ts . Pour plus de détails, consultez leur note : https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 et/ou leur PR https://github.com/mrdoob/three.js/pull/ 15597

Note : TypeScript dans les navigateurs n'est peut-être pas loin si Deno (un interpréteur TypeScript construit sur V8 et Rust avec 32 000 étoiles sur GitHub) s'avère digne.

Étant donné que nous avons ajouté des fichiers de déclaration de type pour le noyau et les modules d'exemple, je pense que vous pouvez clore le problème pour le moment. L'expérience de développement pour les utilisateurs de TS devrait être nettement meilleure que l'année dernière.

Pour toute personne intéressée par TypeScript...

Cette bibliothèque inspirée de Three.js sur laquelle travaille

https://threeify.org/

Threeify de @bhouston semble être un excellent projet 🤩 il a SemVer et utilise la version sémantique. Il est construit sur TypeScript et ses valeurs fondamentales semblent être des choses comme Tree Shaking, Small Build Files, etc. Toutes choses que beaucoup d'entre nous aimeraient voir dans Three.js également. Donc j'apprécie vraiment le travail qui va dans Threeify

@bhouston @mrdoob Mais est-il vraiment nécessaire de créer un nouveau projet ? Est-il judicieux de diviser la communauté ? De nombreux grands frameworks frontaux ont réussi à faire la transition vers des choses comme SemVer, TypeScript, Tree Shaking, etc. sans un fork de leur code et de leur communauté.

Je pense que @pailhead a écrit un article intéressant sur le travail avec Three.js, je pense que c'était le suivant : Working with different three.js versions . Je pense donc qu'il y a des gens dans la communauté qui aimeraient aider à adopter certaines des choses que Threeify essaie de mettre en œuvre. Je pense que ce serait formidable de joindre les forces et d'améliorer Three.js au lieu de créer une nouvelle bibliothèque.

Comme de nombreux articles sur Internet, l'article de Pailhead est biaisé. Ne prend pas en compte les autres utilisations de la bibliothèque.

Je ne pense pas qu'il soit possible de créer une bibliothèque qui s'adresse à tous les types de développeurs js sans perturber le flux de travail de développement des autres.

Nous avons des expériences très similaires à celles de @pailhead. Je ne pense pas que son flux de travail soit un flux de travail de niche. Je pense que son workflow est très courant pour les développeurs travaillant avec des frameworks front-end modernes comme Vue , Ember , React , Svelte , Angular ...

Peut-être devrions-nous jeter un œil à la façon dont Vue le fait. Il a une base d'utilisateurs allant des programmeurs PHP qui souhaitent simplement améliorer leur site Web aux personnes qui développent des applications Web sophistiquées. Il courbe très bien la courbe entre ces différents types d'utilisateurs.

Aussi sur la mise à niveau de la base de code existante sans casser l'expérience pour tout le monde, il existe d'excellents exemples. Nous pourrions jeter un œil à la façon dont Ember a réussi à se développer de manière cohérente avec la communauté Web et ses normes de l'industrie.

Je ne considérerais pas impossible de rester à jour avec le développement Web moderne. Mais je suis tout à fait d'accord pour dire que c'est beaucoup d'efforts et que nous devons beaucoup réfléchir à ces choses. C'est pourquoi je pense qu'il est préférable de travailler ensemble pour créer une expérience moderne que de créer plusieurs nouveaux projets.

Lorsque vous parcourez ce fil, il existe déjà deux projets différents, Three.ts et Threeify et il y en a probablement beaucoup d'autres. Je crois vraiment qu'il y aurait un énorme avantage pour l'ensemble de la communauté Three.js si nous travaillions ensemble au lieu de créer des forks et des initiatives séparées.

@mrdoob , que diriez-vous d'un sondage pour collecter des données ? l'utilisation de dactylographes est une chose et je suis sûr qu'il existe d'autres variables qualitatives sur lesquelles nous pourrions essayer d'obtenir une estimation.

@roomle-build pouvez-vous énumérer les inconvénients de la conversion de la bibliothèque en TypeScript ?

Je ne vois pas de réel inconvénient à adopter progressivement TypeScript pour la bibliothèque. En revanche, je pense que cela apporterait beaucoup d'avantages (c'est pourquoi de nombreux projets se convertissent en TypeScript). Néanmoins, il y a bien sûr quelques défis, par exemple :

• comment pouvons-nous offrir une expérience agréable aux non-utilisateurs de TS ?
• comment les utilisateurs sans étape intégrée peuvent-ils utiliser la bibliothèque
• et bien sûr toutes les autres choses auxquelles je n'ai pas pensé

Mais comme je l'ai déjà dit, ces questions ont également été résolues dans d'autres projets et nous pouvons copier ces solutions à partir de là (comme Vue ou Ember par exemple).

Mais la principale chose que je voulais souligner est que je pense que c'est dangereux si la communauté se sépare et que nous avons plusieurs projets différents et la fourchette d'une fourchette d'une fourchette. Je ne suis pas fan de la fragmentation et je pense qu'il vaut mieux travailler ensemble que les uns contre les autres. Bien sûr, il y a d'autres personnes qui diront que la concurrence est formidable et que cela favoriserait l'innovation également dans le projet Three.js, mais je suis plus partisan de la collaboration 🙂

Je pense que l'un des plus gros avantages de three.js est son accessibilité. Les points énumérés par @roomle-build aggraveraient la facilité d'utilisation du moteur (en particulier dans le contexte des débutants). Je vote pour continuer à utiliser JavaScript à moins qu'un langage de programmation alternatif ne soit pris en charge nativement dans les navigateurs.

Je ne suis pas fan de la fragmentation et je pense qu'il vaut mieux travailler ensemble que les uns contre les autres.

Avoir plus de moteurs 3D sur le Web ne signifie pas que les développeurs travaillent les uns contre les autres. Parfois, c'est en fait mieux si différents projets se concentrent sur des choses différentes.

Je pense que l'un des plus gros avantages de three.js est son accessibilité. Les points énumérés par @roomle-build aggraveraient la facilité d'utilisation du moteur (en particulier dans le contexte des débutants).

Je ne le vois pas de cette façon car d'autres projets créent leur code en TypeScript sans aucune influence sur l'accessibilité. J'ai déjà mentionné Vue et Ember comme exemples. Peut-être est-il judicieux de revoir la position contre TypeScript ? Nous n'aurions pas besoin d'inventer quelque chose, nous n'aurions qu'à copier les approches réussies d'autres projets. De plus, je pense que TypeScript aurait l'avantage que three.js serait plus accessible pour les contributeurs car l'IDE pourrait les aider à avoir une vue d'ensemble de l'ensemble du projet plus rapidement.

Je vote pour continuer à utiliser JavaScript à moins qu'un langage de programmation alternatif ne soit pris en charge nativement dans les navigateurs.

Je pense que cela ne se produira pas dans un avenir prévisible et je pense donc que nous devrions avoir une vision plus pragmatique de TypeScript. Comme je l'ai écrit ci-dessus, je pense qu'il s'agit uniquement d'un problème d'organisation du projet et du référentiel et non d'un compromis entre la facilité d'utilisation et l'expérience de développement.

Je pense que nous avons clairement exprimé notre position.