Aus Sicht der Laufzeitleistung interessiert mich

Auch experimentelle Tools wie AssemblyScript könnten eine Option für bestimmte sehr leistungskritische Teile des Quellcodes werden

Ich habe mit Three.js Core + WASM experimentiert.

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

Aus den Experimenten habe ich festgestellt, dass die Portierung des gesamten Kerns auf WASM die Laufzeitleistung verbessern kann, in meinem Beispiel 1,5x schneller, während die teilweise Portierung der kleinen Teile, zum Beispiel nur mathematische Codes (Vektor3, Matrix4, ...), keinen Vorteil bringt, weil großen JS-WASM-Overhead.

Aber ich hielt es wegen der Schwierigkeit der Wartung nicht für eine gute Idee, den gesamten Three.js-Kern in C++ oder Rust für Mitwirkende umzuschreiben, also habe ich nach alternativen Wegen gesucht. Mich interessiert, ob TypeScript + AssemblyScript für Three.js gut funktioniert.

Wie man anfängt? Sollen wir zunächst nur mit d.ts-Dateien beginnen oder komplett in TypeScript einsteigen?

Wir werden eine PR einreichen, die *.d.ts-Dateien zu Three.JS hinzufügt, hauptsächlich basierend auf @types/three (und damit diese Arbeit wiederverwenden.) Das ist ein großartiger Ausgangspunkt und lässt uns vorerst mit JS fortfahren. Es kann auch inkrementell erfolgen.

@takahirox schöne Arbeit :-) Ich bin immer wieder fasziniert, wie viel innovative Arbeit rund um Three.js passiert. Schade, dass diese Proof-of-Concepts so wenig Beachtung finden. Ich denke auch, dass es keine Option ist, alles in C++ oder Rust umzuschreiben. Vielleicht ist es AssemblyScript, aber ich habe AssemblyScript nicht ausprobiert, damit ich nur darüber sprechen kann, was ich über AssemblyScript gelesen habe. Aber vielleicht sollten wir auch AssemblyScript in Betracht ziehen, denn so wie ich es verstehe, ist es mehr oder weniger eine Untermenge von TypeScript

@bhouston Ich bin mir nicht sicher, ob das Verschieben der d.ts Dateien von @types/three in das three Repository sehr sinnvoll ist. Vor allem, weil diese d.ts Dateien aus den TypeScript-Dateien generiert werden könnten und dann immer synchron sind. Gibt es eine Möglichkeit sicherzustellen, dass die d.ts Dateien immer automatisch mit den js-Dateien synchronisiert sind? Wenn ja, dann würde ich denken, dass es von Vorteil sein könnte, die d.ts Dateien in das three Repository zu legen. Ich denke auch, dass es von der Entscheidung der Betreuer abhängt. Wenn sie TypeScript nicht übernehmen möchten, könnten auch die d.ts Dateien eine Option sein. Auch wenn sie sich entscheiden würden, TypeScript in einigen Jahren hinzuzufügen, könnten wir diese Zeit mit d.ts Dateien überbrücken. Ansonsten fürchte ich, dass es weniger Nutzen und mehr Arbeit gibt. Aber vielleicht übersehe ich nur etwas

@bhouston Ich bin mir nicht sicher, ob es sinnvoll ist, die d.ts-Dateien von @types/three in das Three-Repository zu verschieben. Vor allem, weil diese d.ts-Dateien aus den TypeScript-Dateien generiert werden könnten und dann immer synchron sind.

Wenn wir direkt zu TypeScript wechseln, werden keine *.d.ts-Dateien benötigt. Das Problem ist, dass das @types/three-Projekt derzeit mit Three.JS immer etwas veraltet ist, da es separat verwaltet wird. Außerdem spiegelt es die gebaute Struktur von Three.js statt einzelner Dateien und kann daher kein Tree-Shaking und andere Formen der Optimierung unterstützen. Daher verbessert das Hinzufügen von *.d.ts-Dateien das Projekt von seinem aktuellen Status aus erheblich, aber es ist nicht ganz so gut, wie direkt zu *.ts-Dateien zu wechseln.

Wenn wir direkt zu *.ts-Dateien wechseln können, ist dies die bessere Option. Ich war mir nicht sicher, ob es dafür Unterstützung gibt.

Ich verstehe, dass Three.JS Dinge gerne inkrementell macht, daher war dies eher eine inkrementelle Option als ein großer Knall.

@bhouston da stimme ich dir https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

Aber wie man an TypeScript herangeht, sollte von einem der Betreuer entschieden werden. Ich denke, beide Optionen ( d.ts Dateien oder das Mischen von ts- und js-Dateien) sind machbar. Und es ist mehr oder weniger eine Frage der persönlichen Vorlieben und des Stils.

@tschoartschi Ich würde dieses Thema gerne @mrdoob hat parallele *.d.ts-Dateien genehmigt. Ich würde gerne dorthin gehen, weil es den Leuten TypeScript nicht sofort aufzwingt und wir uns zurückziehen können, ohne alle Beiträge während der *.ts-Phase neu schreiben zu müssen. Und dann können wir immer noch *.js-Dateien inkrementell in *.ts-Dateien konvertieren, meistens indem ich sie mit den nebeneinander liegenden *.d.ts-Dateien zusammenfüge.

Ich denke, dass Side-by-Side *.d.ts-Dateien ein wirklich guter erster Schritt sind und es ist einfach zu tun. Ich würde es vorziehen, nicht zuzulassen, dass "Perfektion" uns davon abhält, schrittweise Fortschritte zu machen.

@bhouston cool 😎 Ich könnte auch helfen. Ich denke, es wäre sinnvoll, dass Sie und andere anfangen und ich dann mitmachen kann. Vielleicht könnten wir auch mit den Betreuern von @types/three sprechen. Sollen wir einen Slack-Kanal im Three.js-Workspace erstellen? So können wir uns schneller abstimmen und dieses Thema nicht mit chatähnlichen Gesprächen verunreinigen. Trotzdem würde ich einen Moment warten, bis @mrdoob seinen Standpunkt hinzufügt. Denn wenn er gegen TypeScript ist, sollten wir meiner Meinung nach keine Zeit investieren.

Ich bin bereit, dem Port Zeit zu widmen, sobald dieser den Segen von @mrdoob erhält.

Bis Browser TypeScript nicht nativ unterstützen, konzentriere ich mich lieber auf JavaScript ES6.

Ich verstehe, dass es in .js kompiliert werden kann, aber wir fangen gerade erst an, direkt aus src importieren zu können, und ich denke, das wird dem Projekt mehr helfen als die Konvertierung in TypeScript.

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

Das parallele Hinzufügen von *.d.ts-Dateien hört sich gut an, aber es braucht jemanden, der sie besitzt und auf dem neuesten Stand hält.

@mrdoob Ich glaube nicht, dass es eine Option ist, darauf zu warten, dass Browser TypeScript unterstützen. Ich habe von keinem Browserhersteller die Absicht gehört, TypeScript zu implementieren. Aber ich sehe deine Bedenken, vor allem bei den Beispielen. Ich habe mir die neuen Beispiele nicht angeschaut. Es ist großartig, dass es möglich ist, nur die Quelldateien in den Beispielen zu importieren.

Ich bin mir nicht sicher, was die beste Lösung wäre, um die Bibliothek in TypeScript zu erstellen und trotzdem die Möglichkeit zu behalten, JavaScript aus src zu importieren. Natürlich könnten wir die TypeScript-Dateien transpilieren und dann die entsprechende JavaScript-Datei nebeneinander haben (was die Standardeinstellung des TypeScript-Compilers ist), aber dies könnte Dinge wie Code-Versionierung usw. erschweren. Die Ordnerstruktur könnte so aussehen

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

Trotzdem erscheint mir dies etwas umständlich, da transpilierter Code irgendwo in einen dist , build oder bin Ordner abgelegt werden sollte. Aber das ist nur eine Meinung, keine harte Tatsache. Vielleicht gibt es einige TypeScript-Geeks, die eine bessere Lösung kennen.

Die andere Option ist die von @bhouston vorgeschlagene Datei d.ts . Aber wie @mrdoob erwähnte, könnte es schwierig sein, die d.ts Dateien auf dem neuesten Stand zu halten. Vor allem auf lange Sicht. Ist es wirklich überschaubar, sie für die nächsten Jahre aktuell zu halten? Ich könnte beim Einrichten der d.ts Dateien helfen, aber ich kann nicht garantieren, dass ich sie ständig aktualisieren werde. Für mich ist es viel schwieriger, kontinuierlich Zeit zu investieren, als einen One-Time-Slot zu blockieren und einige Dinge zu erledigen. Ich bin mir immer noch nicht sicher, ob es besser ist, das @types/three Projekt zu unterstützen oder d.ts Dateien direkt zum three Projekt hinzuzufügen. Das @types/three Projekt funktioniert bereits und erfüllt die gleichen Anforderungen wie der d.ts Ansatz. Es hat auch ähnliche Herausforderungen. Was im Grunde die Dinge auf dem neuesten Stand hält.

Meine Schlussfolgerung ist also, dass es für TypeScript in Three.js mittelfristig nicht allzu gut aussieht. Für mich ist das in Ordnung, obwohl ich mir eine stärkere Einführung von TypeScript wünschen würde.

Noch ein Vorschlag:
Das Phaser-Spiel-Framework verwendet seine Kommentare, um automatisch Typdefinitionen zu generieren. Ich denke, das Tool ist Open Source. So könnten TS-Definitionen generiert werden, indem /** Kommentare */ in korrekter Weise über den Funktionen hinzugefügt werden.

Das Phaser-Spiel-Framework verwendet seine Kommentare, um automatisch Typdefinitionen zu generieren...

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

Es könnte jedoch interessant sein, eine Dokumentation aus Kommentaren in *.d.ts Dateien zu generieren. 🤔

Das parallele Hinzufügen von *.d.ts-Dateien hört sich gut an, aber es braucht jemanden, der sie besitzt und auf dem neuesten Stand hält.

Wenn die Eingaben programmgesteuert mit der Quelle überprüft werden können, bin ich damit einverstanden. Wenn nicht, und wenn wir nicht vorhaben, die Codebasis schließlich in TypeScript umzuschreiben, halte ich es für keine gute Idee, die Typisierungen in das Repository zu verschieben. Wenn überhaupt, sind wir weniger bereit, sie hier zu pflegen – zumindest verwenden die derzeitigen Betreuer selbst TypeScript.

Es gibt auch dieses Projekt https://github.com/semleti/three.ts
Vielleicht lohnt es sich, einen Blick darauf zu werfen und es auf v100 zu bringen, anstatt ein neues zu starten?
Weil ich nicht sehe, dass Three.js in TypeScript umgeschrieben wird, es sei denn, es ist offensichtlich, wie viel schöner es ist, für ein so großes Projekt mit Typen zu arbeiten ... das ist im Browser nicht Standard.

@schoening Ich habe diese Diskussion begonnen, weil es einige @flyover erstellte Repo (https://github.com/flyover/three.ts, https://github.com/mrdoob/three.js/issues/11552#issuecomment-367026821) . Das Hauptproblem bei einer gegabelten Three.ts-Version besteht darin, auf dem neuesten Stand zu bleiben. Alle Repos sind einige Versionen hinterher und ich denke, das wird bei allen Projekten passieren, die nicht vom "Core"-Team betreut werden. Wenn das Three.js-Projekt TypeScript nicht unterstützt, denke ich, dass es am besten ist, dem @types/three- Projekt zu helfen, synchron zu bleiben. Ich denke, wir sollten uns dort zusammenschließen.

Wenn Three.js irgendwann in ferner Zukunft TypeScript unterstützen wird, wäre es großartig, darüber nachzudenken, wie eine solche Umstellung gelingen könnte. Wie @donmccurdy erwähnt hat, gibt es mehrere Ansätze, um eine bessere TypeScript-Kompatibilität zu erreichen. Ich denke, JSDoc könnte ein praktikabler Ansatz sein. Ich bin immer noch nicht von den *.d.ts Dateien überzeugt, da ich denke, dass es noch schwieriger ist, sie auf dem neuesten Stand zu halten als die JSDoc-Kommentare. Ich glaube auch nicht, dass es eine Möglichkeit gibt, programmgesteuert mit *.d.ts Dateien gegen den Quellcode zu prüfen. Aber vielleicht könnte @bhouston seinen Ansatz skizzieren, insbesondere die Bedenken, die Dinge auf dem neuesten Stand zu halten. Vielleicht gibt es für dieses Problem einige clevere Lösungen.

Die beste Erfahrung für mich bisher ist vscode + d.ts + JSDoc, alle im selben Projekt, daher ist es einfach, synchron zu bleiben.

Die neueste vscode-Version hat die Unterstützung von checkJs verbessert (kann in tsconfig.json aktiviert werden), was im Grunde ein TypeScript-Compiler ist, der JavaScript-Dateien überprüft, unter Verwendung der Typen von JSDoc plus Deklarationszusammenführung von d.ts für die "fortgeschritteneren" Typen, was in der JSDoc-Syntax hässlich wäre.

Da vscode alle Typen ableiten kann, kann es auch alle Arten von Typfehlern erkennen. Wenn also eine Umgestaltung durchgeführt wird, ist es einfach, die "fehlerhaften/alten" Typen von d.ts zu sehen und zu bearbeiten, so dass es ständig synchronisiert wird .

Das Schlimmste an TypeScript ist der zusätzliche Transpile-Schritt, der für jede einzelne Codeänderung einige Sekunden dauern kann. Kurz gesagt, JSDoc + d.ts in vscode hat alle Vorteile von Typen, aber nicht die Kehrseite des extra langsamen Transpilierschritts.

Das einzige Problem besteht darin, allem 100 % korrekten JSDoc-Typ hinzuzufügen, damit sich vscode darauf verlassen kann (nur Sachen wie @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

Ich wollte hier auch hinzufügen, dass @bhouston und @LuWangThreekit eine PR für *.d.ts Dateien erstellt haben. Weitere Informationen finden Sie in ihrer Anmerkung: https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 und/oder ihrer PR https://github.com/mrdoob/three.js/pull/ 15597

Randbemerkung: TypeScript in Browsern ist möglicherweise nicht weit entfernt, wenn sich Deno (ein auf V8 und Rust

Da wir Typdeklarationsdateien für den Kern und die Beispielmodule hinzugefügt haben, ist es meiner Meinung nach in Ordnung, das Thema vorerst zu schließen. Die Entwicklungserfahrung für TS-Benutzer sollte definitiv besser sein als im letzten Jahr.

Für alle, die sich für TypeScript interessieren...

Diese Three.js-inspirierte Bibliothek, an der @bhouston arbeitet, ist möglicherweise das, wonach Sie suchen:

https://threeify.org/

Threeify von @bhouston scheint ein großartiges Projekt zu sein 🤩 es hat SemVer und verwendet Semantic-Release. Es basiert auf TypeScript und seine Kernwerte scheinen Dinge wie Tree Shaking, Small Build Files usw. zu sein. Alles Dinge, die viele von uns auch gerne in Three.js sehen würden. Daher schätze ich die Arbeit, die in Threeify steckt, sehr

@bhouston @mrdoob Aber ist es wirklich notwendig, ein neues Projekt zu erstellen? Ist es sinnvoll, die Community zu spalten? Viele der großen Front-End-Frameworks schafften den Übergang zu Dingen wie SemVer, TypeScript, Tree Shaking usw. ohne eine Abspaltung ihres Codes und ihrer Community.

Ich glaube, @pailhead hat einen interessanten Artikel über die Arbeit mit Three.js geschrieben, ich glaube, es war der folgende: Working with different three.js versions . Ich denke, es gibt Leute in der Community, die helfen möchten, einige der Dinge zu übernehmen, die Threeify zu implementieren versucht. Ich denke, es wäre großartig, die Kräfte zu bündeln und Three.js zu verbessern, anstatt eine neue Bibliothek zu erstellen.

Wie viele Artikel im Internet ist der Artikel von Pailhead voreingenommen. Berücksichtigt keine anderen Nutzungen der Bibliothek.

Ich glaube nicht, dass es möglich ist, eine Bibliothek zu erstellen, die alle Arten von js-Entwicklern bedient, ohne den Entwicklungsworkflow des anderen zu stören.

Wir haben sehr ähnliche Erfahrungen wie @pailhead. Ich glaube nicht, dass sein Workflow ein Nischenworkflow ist. Ich denke, sein Workflow ist für Entwickler, die mit modernen Front-End-Frameworks wie Vue , Ember , React , Svelte , Angular ... arbeiten, sehr verbreitet.

Vielleicht sollten wir einen Blick darauf werfen, wie Vue das macht. Es hat eine Benutzerbasis, die von PHP-Programmierern reicht, die nur ihre Website verbessern möchten, bis hin zu Leuten, die anspruchsvolle Web-Apps entwickeln. Es biegt die Kurve zwischen diesen verschiedenen Benutzertypen sehr schön.

Auch zum Aktualisieren der vorhandenen Codebasis, ohne die Erfahrung für alle zu beeinträchtigen, gibt es großartige Beispiele. Wir konnten uns ansehen, wie Ember es geschafft hat, mit der Web-Community und ihren Industriestandards konsequent zu wachsen.

Ich würde es nicht für unmöglich halten, mit der modernen Webentwicklung auf dem Laufenden zu bleiben. Aber ich stimme voll und ganz zu, dass es viel Aufwand ist und wir uns viele Gedanken darüber machen müssen. Aus diesem Grund glaube ich, dass es besser ist, zusammenzuarbeiten, um ein modernes Erlebnis zu schaffen, als mehrere neue Projekte zu entwickeln.

Wenn Sie diesen Thread durchgehen, gibt es bereits zwei verschiedene Projekte, Three.ts und Threeify und wahrscheinlich gibt es noch viel mehr da draußen. Ich glaube wirklich, dass es für die gesamte Three.js-Community einen großen Vorteil gäbe, wenn wir zusammenarbeiten würden, anstatt Forks und separate Initiativen zu erstellen.

@mrdoob , wie wäre es mit einer Umfrage, um Daten zu sammeln? Die Verwendung von Typoskript ist eine Sache, und ich bin mir sicher, dass es andere qualitative Variablen gibt, die wir versuchen könnten, eine Schätzung zu erhalten.

@roomle-build können Sie die Nachteile der Konvertierung der Bibliothek in TypeScript auflisten?

Ich sehe keinen wirklichen Nachteil darin, TypeScript schrittweise für die Bibliothek zu übernehmen. Im Gegensatz dazu denke ich, dass es viele Vorteile bringen würde (deshalb konvertieren viele Projekte zu TypeScript). Dennoch gibt es natürlich einige Herausforderungen, zum Beispiel:

• Wie können wir Nicht-TS-Benutzern eine schöne Erfahrung bieten?
• Wie können Benutzer ohne integrierten Schritt die Bibliothek verwenden?
• und natürlich an alle anderen sachen die ich nicht gedacht habe

Aber wie gesagt, diese Fragen wurden auch in anderen Projekten gelöst und wir können diese Lösungen von dort kopieren (wie zum Beispiel Vue oder Ember ).

Aber das Wichtigste, was ich anmerken wollte, ist, dass ich es für gefährlich halte, wenn sich die Community auflöst und wir mehrere verschiedene Projekte und eine Gabel von einer Gabel von einer Gabel haben. Ich bin kein Fan von Fragmentierung und denke, dass es besser ist, zusammen zu arbeiten als gegeneinander. Natürlich gibt es andere Leute, die argumentieren, dass der Wettbewerb großartig ist und dass dies auch im Three.js-Projekt Innovation gedeihen würde, aber ich glaube eher an Zusammenarbeit 🙂

Ich denke, einer der größten Vorteile von three.js ist die Zugänglichkeit. Die Punkte, die @roomle-build aufgelistet hat, würden die Benutzerfreundlichkeit der Engine verschlechtern (insbesondere im Kontext von Anfängern). Ich stimme dafür, JavaScript weiterhin zu verwenden, es sei denn, eine alternative Programmiersprache wird nativ in Browsern unterstützt.

Ich bin kein Fan von Fragmentierung und denke, dass es besser ist, zusammen zu arbeiten als gegeneinander.

Mehr 3D-Engines im Web zu haben bedeutet nicht, dass die Entwickler gegeneinander arbeiten. Manchmal ist es sogar besser, wenn sich verschiedene Projekte auf verschiedene Dinge konzentrieren.

Ich denke, einer der größten Vorteile von three.js ist die Zugänglichkeit. Die Punkte, die @roomle-build aufgelistet hat, würden die Benutzerfreundlichkeit der Engine verschlechtern (insbesondere im Kontext von Anfängern).

Ich sehe das nicht so, weil andere Projekte ihren Code ohne Einfluss auf die Barrierefreiheit in TypeScript schreiben. Ich habe Vue und Ember bereits als Beispiele erwähnt. Vielleicht ist es sinnvoll, die Haltung gegenüber TypeScript zu überprüfen? Wir müssten nichts erfinden, wir müssten nur die erfolgreichen Ansätze aus anderen Projekten kopieren. Außerdem denke ich, dass TypeScript den Vorteil hätte, dass three.js für Mitwirkende leichter zugänglich wäre, da die IDE ihnen helfen könnte, schneller einen Überblick über das gesamte Projekt zu bekommen.

Ich stimme dafür, JavaScript weiterhin zu verwenden, es sei denn, eine alternative Programmiersprache wird nativ in Browsern unterstützt.

Ich denke, dass dies in absehbarer Zeit nicht passieren wird und daher denke ich, dass wir eine pragmatischere Sichtweise auf TypeScript haben sollten. Wie ich oben geschrieben habe, denke ich, dass es nur ein Problem ist, wie das Projekt und das Repository organisiert sind, und kein Kompromiss zwischen Benutzerfreundlichkeit und Entwicklererfahrung.

Ich denke, wir haben unsere Position klar gemacht.