Desde el punto de vista del rendimiento en tiempo de ejecución, me interesa

Además, las herramientas experimentales como AssemblyScript podrían convertirse en una opción para ciertas partes del código fuente que son muy críticas para el rendimiento.

He estado haciendo experimentación con Three.js core + WASM.

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

A partir de la experimentación, me di cuenta de que migrar todo el núcleo a WASM puede mejorar el rendimiento en tiempo de ejecución, 1.5 veces más rápido en mi ejemplo, mientras que migrar parcialmente las partes pequeñas, por ejemplo, solo códigos matemáticos (Vector3, Matrix4, ...), no es un beneficio porque de gran sobrecarga JS-WASM.

Pero no pensé que fuera una buena idea reescribir todo el núcleo de Three.js en C ++ o Rust para los contribuyentes debido a la dificultad de mantenimiento, así que he estado buscando formas alternativas. Me interesa si TypeScript + AssemblyScript funciona bien para Three.js.

¿Cómo empezar? ¿Deberíamos comenzar al principio solo con archivos d.ts o saltar completamente a TypeScript?

Enviaremos un PR que agrega archivos * .d.ts a Three.JS, basado principalmente en @ types / three (reutilizando ese trabajo). Ese es un gran punto de partida y nos permite continuar en JS por ahora. También se puede hacer de forma incremental.

@takahirox buen trabajo :-) Siempre me ha fascinado la cantidad de trabajo innovador que ocurre en Three.js. Es una pena que estas pruebas de conceptos reciban menos atención. También creo que reescribir todo en C ++ o Rust no es una opción. Tal vez AssemblyScript lo sea, pero no probé AssemblyScript, así que puedo hablar sobre lo que leí sobre AssemblyScript. Pero tal vez deberíamos considerar AssemblyScript también porque, según tengo entendido, es más o menos un subconjunto de TypeScript

@bhouston No estoy seguro de si mover los archivos d.ts de @types/three al repositorio three tiene mucho sentido. Especialmente porque estos archivos d.ts se pueden generar a partir de los archivos TypeScript y luego siempre están sincronizados. ¿Hay alguna manera de asegurar que los archivos d.ts estén siempre sincronizados con los archivos js de forma automatizada? Si sí, entonces yo creo que poner los d.ts archivos en el three repo podría ser beneficioso. También creo que depende de la decisión de los mantenedores. Si no quieren adoptar TypeScript, los archivos d.ts podrían ser una opción. Además, si decidieran agregar TypeScript en algunos años, podríamos salvar este tiempo con archivos d.ts . De lo contrario, me temo que hay menos beneficios y más trabajo. Pero tal vez solo estoy pasando por alto algo

@bhouston No estoy seguro de si mover los archivos d.ts de @ types / three al repositorio de tres tiene mucho sentido. Especialmente porque estos archivos d.ts se pueden generar a partir de archivos TypeScript y luego siempre están sincronizados.

Si nos movemos directamente a TypeScript, no habría necesidad de archivos * .d.ts. El problema es que actualmente el proyecto @ types / three siempre está un poco desactualizado con Three.JS porque se mantiene por separado. También refleja la estructura construida de three.js en lugar de archivos individuales y, por lo tanto, no admite la agitación de árboles y otras formas de optimización. Por lo tanto, agregar archivos * .d.ts mejora enormemente el proyecto desde su estado actual, pero no es tan bueno como avanzar directamente hacia archivos * .ts.

Si podemos movernos hacia archivos * .ts directamente, esa es la mejor opción. No estaba seguro de que hubiera apoyo para eso.

Entiendo que a Three.JS le gusta hacer las cosas de forma incremental, por lo que esta fue una opción incremental en lugar de una gran explosión.

@bhouston Estoy totalmente de acuerdo contigo. Y también creo que una reescritura del Big Bang no es posible, por lo que debemos adoptar gradualmente. Pero si leo los documentos de TypeScript, parece que podríamos tener archivos ts y js uno al lado del otro. Entonces podríamos comenzar a convertir archivos individuales en ts. Para obtener más detalles, puede leer esta publicación de blog: https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

Pero uno de los mantenedores debe decidir cómo abordar TypeScript. Creo que ambas opciones ( d.ts archivos o mezclar archivos ts y js) son factibles. Y es más o menos una cuestión de preferencias personales y estilo.

@tschoartschi Me gustaría avanzar en este tema. @mrdoob ha aprobado archivos * .d.ts en paralelo. Me gustaría ir allí porque no obliga a las personas a usar TypeScript de inmediato y podemos dar marcha atrás sin tener que volver a escribir todas las contribuciones durante la fase * .ts. Y luego todavía podemos convertir archivos * .js a archivos * .ts de forma incremental, principalmente fusionándolos con los archivos * .d.ts lado a lado.

Creo que los archivos * .d.ts lado a lado son un primer paso realmente bueno y es fácil de hacer. Preferiría no permitir que la "perfección" nos impida hacer progresos incrementales.

@bhouston cool 😎 También podría ayudar. Creo que tendría sentido que tú comiences y otros y luego yo pueda unirme. Quizás también podríamos hablar con los mantenedores de @types/three . ¿Deberíamos crear un canal de Slack en el espacio de trabajo de Three.js? Para que podamos alinearnos más rápido y no contaminar este problema con conversaciones tipo chat. Sin embargo, esperaría un momento hasta que @mrdoob agregue su punto de vista. Porque si está en contra de TypeScript, creo que no deberíamos invertir tiempo.

Estoy dispuesto a dedicar tiempo al puerto una vez que reciba la bendición de @mrdoob.

Hasta que los navegadores no admitan TypeScript de forma nativa, prefiero centrarme en JavaScript ES6.

Entiendo que se puede compilar en .js, pero recién estamos comenzando a poder importar desde src directamente y creo que eso ayudará al proyecto más que convertirlo a TypeScript.

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

Agregar archivos * .d.ts uno al lado del otro suena bien, pero necesitará que alguien lo posea y lo mantenga actualizado.

@mrdoob No creo que esperar a que los navegadores admitan TypeScript sea una opción. No escuché ninguna intención de ningún proveedor de navegadores de implementar TypeScript. Pero veo sus preocupaciones, especialmente con los ejemplos. No eché un vistazo a los nuevos ejemplos. Es increíble que sea posible importar los archivos fuente en los ejemplos.

No estoy seguro de cuál sería la mejor solución para crear la biblioteca en TypeScript y aún así tener la posibilidad de importar JavaScript desde src. Por supuesto, podríamos transpilar los archivos TypeScript y luego tener el archivo JavaScript correspondiente en paralelo (que es la configuración estándar del compilador TypeScript) pero esto podría complicar cosas como el control de versiones de código, etc. La estructura de la carpeta podría verse así

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

Sin embargo, esto me parece un poco incómodo, ya que el código transpilado debería ir en algún lugar de una carpeta dist , build o bin . Pero esa es solo una opinión, no un hecho contundente. Tal vez haya algunos fanáticos de TypeScript que conozcan una solución mejor.

La otra opción es el archivo d.ts sugerido por @bhouston. Pero como mencionó @mrdoob , podría ser complicado mantener actualizados los archivos d.ts . Especialmente en una visión a largo plazo. ¿Es realmente manejable mantenerlos actualizados durante los próximos años? Podría ayudar a configurar los archivos d.ts pero no puedo garantizar que estaré involucrado en actualizarlos todo el tiempo. Para mí, es mucho más difícil dedicar tiempo de forma continua que bloquear un intervalo de tiempo único y hacer algunas cosas. Todavía no estoy seguro de si es mejor admitir el proyecto @types/three o agregar archivos d.ts directamente en el proyecto three . El proyecto @types/three ya está funcionando y satisface las mismas necesidades que el enfoque d.ts . También tiene desafíos similares. Lo que básicamente es mantener las cosas actualizadas.

Entonces, mi conclusión es que no se ve muy bien para TypeScript en Three.js en el futuro a mediano plazo. Para mí está bien, aunque me encantaría ver una mayor adopción de TypeScript.

Solo otra sugerencia:
El marco del juego Phaser utiliza sus comentarios para generar automáticamente definiciones de tipo. Creo que la herramienta es de código abierto. Entonces, las definiciones de TS podrían generarse agregando / ** comentarios * / encima de las funciones de la manera correcta.

El marco del juego Phaser usa sus comentarios para generar automáticamente definiciones de tipo ...

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

Aunque, generar documentación a partir de comentarios en archivos *.d.ts puede ser interesante. 🤔

Agregar archivos * .d.ts uno al lado del otro suena bien, pero necesitará que alguien lo posea y lo mantenga actualizado.

Si los mecanografiados se pueden comparar con la fuente mediante programación, estoy de acuerdo con esto. Si no es así, y si no estamos planeando reescribir eventualmente la base de código en TypeScript, no creo que sea una buena idea mover las mecanografías al repositorio. En todo caso, estamos menos preparados para mantenerlos aquí, al menos los mantenedores actuales están usando TypeScript.

También existe este proyecto https://github.com/semleti/three.ts
¿Quizás valga la pena echarle un vistazo y llevarlo a v100 en lugar de comenzar uno nuevo?
Porque no veo que Three.js se reescriba en TypeScript a menos que sea obvio cuánto mejor es trabajar con tipos para un proyecto tan grande ... Y entiendo por qué nunca sucederá ya que dependería de un lenguaje eso no es estándar dentro del navegador.

@schoening Comencé esta discusión porque hay algunas versiones TypeScript de prueba de concepto de Three.js. Es el repositorio que vinculó o el repositorio realizado por @flyover (https://github.com/flyover/three.ts, https://github.com/mrdoob/three.js/issues/11552#issuecomment-367026821) . El principal problema con una versión bifurcada de Three.ts es mantenerse actualizado. Todos los repositorios tienen versiones anteriores y creo que esto sucederá con todos los proyectos que no sean mantenidos por el equipo "central". Si el proyecto Three.js no es compatible con TypeScript, creo que es mejor ayudar al proyecto @ types / three a mantenerse sincronizado. Creo que deberíamos unir fuerzas allí.

Si Three.js va a admitir TypeScript en algún momento en el futuro lejano, sería genial pensar cómo podría tener éxito tal transición. Como mencionó @donmccurdy, existen varios enfoques para lograr una mejor compatibilidad con TypeScript. Creo que JSDoc podría ser un enfoque viable. Todavía no estoy convencido por los archivos *.d.ts ya que creo que es aún más difícil mantenerlos actualizados que los comentarios de JSDoc. Además, no creo que haya una manera de verificar la fuente mediante programación con archivos *.d.ts . Pero tal vez @bhouston podría describir su enfoque, especialmente las preocupaciones sobre mantener las cosas actualizadas. Quizás haya algunas soluciones inteligentes para este problema.

La mejor experiencia para mí hasta ahora es vscode + d.ts + JSDoc, todo en el mismo proyecto, por lo que es fácil mantener la sincronización.

La última versión de vscode ha mejorado el soporte de checkJs (se puede habilitar en tsconfig.json ), que básicamente es un compilador de TypeScript que verifica archivos JavaScript, utilizando los tipos de JSDoc más la declaración que se fusiona desde d.ts para los tipos más "avanzados", lo que sería feo en la sintaxis JSDoc.

Dado que vscode puede derivar todos los tipos, también puede detectar todo tipo de errores de tipo, por lo que siempre que se realiza la refactorización, es fácil ver y editar los tipos "con errores / antiguos" desde d.ts , por lo que se sigue sincronizando .

Lo peor de TypeScript es el paso de transpilación adicional, que puede tardar unos segundos en cada cambio de código. En resumen, JSDoc + d.ts en vscode tiene todas las ventajas de los tipos pero no la desventaja del paso de transpile extra lento.

El único problema es agregar el tipo JSDoc 100% adecuado a todo, por lo que vscode puede confiar en él (solo cosas como @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

También quería agregar aquí que @bhouston y @LuWangThreekit crearon un PR para archivos *.d.ts . Para obtener más detalles, consulte su nota: https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 y / o su PR https://github.com/mrdoob/three.js/pull/ 15597

Nota al margen: TypeScript en los navegadores puede no estar muy lejos si Deno (un intérprete de TypeScript construido en V8 y Rust con 32,000 estrellas en GitHub) demuestra ser digno.

Dado que agregamos archivos de declaración de tipo para el núcleo y los módulos de ejemplo, creo que está bien cerrar el problema por ahora. La experiencia de desarrollo para los usuarios de TS debería ser definitivamente mejor que el año pasado.

Para cualquier persona interesada en TypeScript ...

Esta biblioteca inspirada en Three.js en la que está trabajando

https://threeify.org/

Threeify de @bhouston parece un gran proyecto 🤩 tiene SemVer y usa la liberación semántica. Está construido sobre TypeScript y sus valores centrales parecen ser cosas como Tree Shaking, Small Build Files, etc. Todo lo que a muchos de nosotros también nos gustaría ver en Three.js. Entonces realmente valoro el trabajo que se dedica a Threeify 👍

@bhouston @mrdoob ¿ Pero es realmente necesario crear un nuevo proyecto? ¿Tiene sentido dividir la comunidad? Muchos de los grandes frameworks de front-end lograron hacer la transición a cosas como SemVer, TypeScript, Tree Shaking, etc.sin una bifurcación de su código y comunidad.

Creo que @pailhead escribió un artículo interesante sobre cómo trabajar con Three.js, creo que fue el siguiente: Trabajar con diferentes versiones de three.js . Así que creo que hay personas en la comunidad a las que les gustaría ayudar a adoptar algunas de las cosas que Threeify intenta implementar. Creo que sería genial unir fuerzas y mejorar Three.js en lugar de crear una nueva biblioteca.

Como muchos artículos en Internet, el artículo de Pailhead está sesgado. No tiene en cuenta otros usos de la biblioteca.

No creo que sea posible hacer una biblioteca que atienda a todo tipo de desarrolladores js sin interrumpir el flujo de trabajo de desarrollo de los demás.

Tenemos experiencias muy similares a las de @pailhead . No creo que su flujo de trabajo sea un flujo de trabajo de nicho. Creo que su flujo de trabajo es muy común para los desarrolladores que trabajan con marcos frontales modernos como Vue , Ember , React , Svelte , Angular ...

Tal vez deberíamos echar un vistazo a cómo lo está haciendo Vue . Tiene una base de usuarios que va desde programadores PHP que solo quieren mejorar su sitio web hasta personas que desarrollan aplicaciones web sofisticadas. Dobla muy bien la curva entre esos diferentes tipos de usuarios.

También sobre la actualización de la base de código existente sin romper la experiencia para todos, hay excelentes ejemplos por ahí. Podríamos echar un vistazo a cómo Ember logró crecer constantemente con la comunidad web y sus estándares de la industria.

No consideraría inviable estar al día con el desarrollo web moderno. Pero estoy totalmente de acuerdo en que es un gran esfuerzo y tenemos que pensar mucho en esas cosas. Por eso creo que es mejor trabajar juntos para crear una experiencia moderna que crear varios proyectos nuevos.

Cuando revisa este hilo, ya hay dos proyectos diferentes, Three.ts y Threeify y probablemente hay muchos más por ahí. Realmente creo que sería un gran beneficio para toda la comunidad Three.js si trabajáramos juntos en lugar de crear bifurcaciones e iniciativas separadas.

@mrdoob , ¿qué tal una encuesta para recopilar algunos datos? el uso de mecanografiado es una cosa y estoy seguro de que hay otras variables cualitativas sobre las que podríamos intentar obtener una estimación.

@ roomle-build ¿puede enumerar las desventajas de convertir la biblioteca a TypeScript?

No veo una desventaja real de adoptar gradualmente TypeScript para la biblioteca. Por el contrario, creo que traería muchos beneficios (es por eso que muchos proyectos se están convirtiendo a TypeScript). Sin embargo, existen algunos desafíos, por supuesto, por ejemplo:

• ¿Cómo podemos ofrecer una experiencia agradable a los que no son usuarios de TS?
• ¿Cómo pueden los usuarios sin un paso integrado utilizar la biblioteca?
• y por supuesto todas las demás cosas en las que no pensé

Pero como dije antes, esas preguntas también se resolvieron en otros proyectos y podemos copiar estas soluciones desde allí (como Vue o Ember, por ejemplo).

Pero lo principal que quería señalar es que creo que es peligroso si la comunidad se divide y tenemos varios proyectos diferentes y la bifurcación de una bifurcación de una bifurcación. No soy fanático de la fragmentación y creo que es mejor trabajar juntos que uno contra el otro. Por supuesto, hay otras personas que argumentarán que la competencia es excelente y que esto haría prosperar la innovación también en el proyecto Three.js, pero yo creo más en la colaboración 🙂

Creo que una de las mayores ventajas de three.js es su accesibilidad. Los puntos que @ roomle-build ha enumerado empeorarían la facilidad de uso del motor (especialmente en el contexto de los principiantes). Voto a favor de seguir usando JavaScript a menos que los navegadores admitan de forma nativa un lenguaje de programación alternativo.

No soy fanático de la fragmentación y creo que es mejor trabajar juntos que uno contra el otro.

Tener más motores 3D en la web no significa que los desarrolladores trabajen unos contra otros. A veces es mejor si diferentes proyectos se enfocan en diferentes cosas.

Creo que una de las mayores ventajas de three.js es su accesibilidad. Los puntos que @ roomle-build ha enumerado empeorarían la facilidad de uso del motor (especialmente en el contexto de los principiantes).

No lo veo de esta manera porque otros proyectos crean su código en TypeScript sin ninguna influencia en la accesibilidad. Mencioné Vue y Ember como ejemplos antes. ¿Quizás tenga sentido revisar la postura contra TypeScript? No necesitaríamos inventar algo, solo necesitaríamos copiar los enfoques exitosos de otros proyectos. Además, creo que TypeScript tendría la ventaja de que three.js sería más accesible para los contribuyentes porque el IDE podría ayudarlos a obtener una descripción general de todo el proyecto más rápido.

Voto a favor de seguir usando JavaScript a menos que los navegadores admitan de forma nativa un lenguaje de programación alternativo.

Creo que esto no sucederá en un futuro previsible y, por lo tanto, creo que deberíamos tener una visión más pragmática sobre TypeScript. Como escribí anteriormente, creo que es solo un problema de cómo se organizan el proyecto y el repositorio y no una compensación entre la facilidad de uso y la experiencia de desarrollo.

Creo que hemos dejado clara nuestra posición.