Three.js: Google Closure Compiler "externs"-Datei für three.js ?

Nein, three.js hat keine externen Abhängigkeiten, daher war so etwas bisher nicht nötig.

Ich weiß, aber auch für eigene Projekte ist es sinnvoll THREE.js in eine kompilierbare Umgebung zu integrieren.

Wie würde eine solche Datei aussehen? Tut mir leid, wenn es bereits in dem von Ihnen geteilten Link erklärt wurde, ich fand die Seite etwas überwältigend (zu viel Text) und kann sie nicht lesen/verstehen.

@mrdoob , einige ihrer Beispiele finden Sie unter:

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fexterns

oder

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fcontrib%2Fexterns

und folgendes ist auch wichtig:

http://code.google.com/closure/compiler/docs/js-for-compiler.html

Kommentare/Überschriften? Ich denke, das würde das Lesen des Codes erschweren...

Ja, aber ich denke, es ist nur für diese externe Datei, nicht für den gesamten Code. Man kann es tun, aber es ist nicht notwendig.

Ich habe es mit http://www.dotnetwise.com/Code/Externs/index.html versucht. Aber es funktioniert nicht vollständig mit Three.js . Nicht alle Definitionen werden extrahiert.

Hier der Blogeintrag:

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

Scheint das this.method = function(){} Muster zu unterstützen, aber nicht die Prototypen...

@mrdoob , was ist Ihre Empfehlung, THREE.js in eine eigene Anwendung mit dem erweiterten Optimierer des Closure-Compilers zu integrieren? Stimmt es, dass das derzeit nicht möglich ist?

Soweit ich weiß, enthält der erweiterte Optimierer nur die verwendeten Klassen, oder? Theoretisch sollte es funktionieren... funktioniert es nicht?

Ich habe keine erweiterte Optimierung mit Three.js versucht, aber ich erinnere mich an andere Dinge, die den Code knackten. Im Allgemeinen war es nicht "sicher" - mit der einfachen Standardoptimierung funktioniert es immer, mit der erweiterten Optimierung manchmal nicht.

Es bricht den Code, wenn Sie als Bibliothek kompilieren, aber als Anwendung (mit Methoden, die aufgerufen werden und so weiter) sollte es funktionieren, oder?

@mrdoob Um eine Bibliothek mit kompiliertem (optimiertem) Code zu verwenden, benötigen Sie eine "externs"-Datei, um alle Klassen und Methoden der Bibliothek zu deklarieren. Ohne geht es nicht. Aber gibt es ein anderes Tool, das mit Three.js funktioniert? Ich brauche es, um meine Three.js-Anwendung zu verschleiern (zu verschleiern). Ein Kandidat ist: https://github.com/mishoo/UglifyJS . Aber ich habe es nicht probiert.

Google Closure externs ist eine Datei, die ganze Objekte beschreibt, die wir in unserem kompilierten Code verwenden.
Ohne diese Datei macht der Compiler nur aus Funktionsnamen etwas wie a() oder b().

Dies ist beispielsweise für JQuery: http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.7.js

Es wäre toll, wenn externs für drei.js verwendet wird.

Ich bin damit cool, aber ich kann es nicht selbst angehen. Da muss jemand anderes nachziehen.

@yurikor , wenn Sie node.js verwenden, können Sie node-browserify und uglify-js zusammen verwenden. Dann brauchen Sie nichts zu bauen.

@remoe Vielen Dank für den Rat. Ich werde es versuchen.

Dieses Problem ist seit einiger Zeit inaktiv, aber falls jemand dieses Problem in Zukunft angehen möchte, hier einige zusätzliche Informationen:

Für mein Projekt habe ich eine einfache Datei mit gerade genug Threejs-Exporten erstellt, um mein Projekt kompilieren zu können. Es enthält Typanmerkungen, die sehr nützlich waren, da der Closure-Compiler alle Typen überprüfen und einige Fehler in meinem Code finden konnte. Ich habe diese Datei manuell erstellt. Den Closure-Compiler nutze ich hauptsächlich zur Fehlerüberprüfung, für die eigentliche Minifizierung verwende ich die weniger mächtigen, aber sicheren uglifyjs .

Um zu verhindern, dass der Closure-Compiler meine öffentlichen Schnittstellensymbole umbenennt, musste ich außerdem mehrere Codezeilen hinzufügen (diese vier Funktionen sind die einzigen öffentlichen Funktionen meiner Bibliothek). Beachten Sie, dass der Closure-Compiler alle Eigenschaften umbenennt, auf die über blah.xyz zugegriffen wird, aber keine Eigenschaften berührt, auf die über blah["xyz"] zugegriffen wird.

Schließlich wurde die Zeile window['ColladaLoader2'] = ColladaLoader2 (beachten Sie erneut die Verwendung eines Strings) benötigt, um dem Closure-Compiler mitzuteilen, dass diese Klasse in den globalen Geltungsbereich exportiert werden soll.

Aber Sie verwenden keine Closure für die Produktion, sondern nur eine Fehlerprüfung? ich bin
unsicher, ob sich die Pflege der externen Datei dann lohnt. Einfach Schließung ausführen
ohne aggressive Optimierungen und dann brauchst du die externe Datei nicht
aber du bekommst immer noch die meiste Bestätigung, die ich glaube oder vielleicht sogar alle
Validierung. Vielleicht kannst du das klären?

Gesendet von meinem Handy, sorry für meine Grammatik und Kürze.
Am 12. Februar 2013 um 05:19 Uhr schrieb "Robert Carnecky" [email protected] :

Dieses Problem ist seit einiger Zeit inaktiv, aber falls es jemand möchte
dieses Problem in Zukunft anzugehen, hier sind einige zusätzliche Informationen:

Für mein Projekt habe ich eine einfache Datei https://github.com/crobi/ColladaAnimationCompress/blob/master/threejs-exports.js mit gerade genug Threejs-Exporten erstellt, um mein Projekt kompilieren zu können. Es kommt
mit Typanmerkungen, was sehr nützlich war, da es die Schließung ermöglichte
Compiler, um alle Typen zu überprüfen und ein paar Fehler in meinem Code zu finden. Ich habe
diese Datei manuell erstellt. Ich benutze den Closure-Compiler hauptsächlich für Fehler
Überprüfung, für die eigentliche Verkleinerung verwende ich die weniger leistungsstarke, aber sichere
uglifyjs https://github.com/mishoo/UglifyJS.

Um zu verhindern, dass der Closure-Compiler meine öffentliche Schnittstelle umbenennt
Symbole musste ich mehrere Codezeilen hinzufügen
dass der Closure-Compiler alle Eigenschaften umbenennt, auf die über blah.xyz zugegriffen wird,
berührt aber keine Eigenschaften, auf die über blah["xyz"] zugegriffen wird.

Schließlich die Zeilehttps://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3383 window['ColladaLoader2']
= ColladaLoader2 (beachten Sie erneut die Verwendung eines Strings) wurde benötigt, um den
Closure-Compiler, dass diese Klasse in den globalen Geltungsbereich exportiert werden soll.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/mrdoob/three.js/issues/341#issuecomment -13426131.

Soweit ich weiß, führt der einfache Modus überhaupt keine Validierung durch. Es benennt lokale Variablen um, und wenn es auf ein unbekanntes Symbol stößt, lässt es es unberührt, vorausgesetzt, es handelt sich um eine globale Variable.

Der erweiterte Modus verhält sich wie ein Compiler in einer stark typisierten Sprache (vorausgesetzt, Typinformationen sind verfügbar): Er warnt vor unbekannten Funktionen oder Eigenschaften, warnt, wenn Sie eine Funktion mit der falschen Anzahl von Argumenten aufgerufen haben oder wenn Sie einen String-Parameter verwendet haben, wobei a Zahl wurde erwartet.

Als Beispiel transformiert der einfache Modus den folgenden Code

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

ohne Vorwarnung in

function fn(){({}).bar()}fn();

was offensichtlich auf ({}).bar() abstürzt. Der erweiterte Modus gibt den folgenden Code aus

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

was immer noch abstürzt, aber der Compiler gibt auch eine Warnung aus

Property bar never defined on foo at line 3 character 0.

• Die gefundenen Fehler waren die Art von Fehlern, bei denen ich einen Tippfehler in einem Funktionsnamen hatte oder bei denen ich eine THREE.Vector3 an Matrix4.makeTranslation anstelle von drei separaten Zahlen für die x-, y- und z-Komponenten .
• Wenn ich eine vollständige Testabdeckung gehabt hätte (was ich nicht tue), hätte ich diese Fehler früher oder später gefunden. Manchmal sind sie jedoch schwer zu debuggen, wenn sie sich nicht sofort manifestieren.
• Wenn Threejs mit jeder neuen Version eine aktuelle Exportdatei mitliefern würde (großer Wartungsaufwand), würde der Closure-Compiler alle Probleme abfangen, die von einer sich ändernden API herrühren (wie es bei Matrix4.makeTranslation der Fall war).
• Das Einrichten des Closure-Compilers ist für mich zu viel Arbeit, da er eine Java-Laufzeit benötigt. Alle anderen Tools, die zum Erstellen meiner Bibliothek benötigt werden, basieren auf Node/Javascript.

Ich baue derzeit meine externes.js-Datei für die Closure-Bibliothek, um eine THREE.js-Anwendung in die Closure-Bibliothek zu integrieren. Im Wesentlichen versuchen wir herauszufinden:
Gibt es irgendwo eine Liste aller DREI.js-Klassen und der von ihnen implementierten Prototypmethoden? Die Liste sollte ungefähr so ​​aussehen:

DREI.Textur
THREE.Texture.constructor
DREI.Textur.klon
DREI.Textur.entsorgen
THREE.DataTexture.clone

(und so weiter...)

Ps- Three.js ist großartig, aber mit den richtigen jsDocs könnte diese Liste leicht extrahiert werden :)

Ich habe eine teilweise Umsetzung der Three.js Exporte hier (manuell geschrieben, so könnten einige Fehler enthalten).

@crobi : Warum hast du die Doc-Kommentare

@taoeffect : Die Kommentare beziehen sich hauptsächlich auf den erweiterten Modus des Closure-Compilers. Ich mag stark getippten Code.

@crobi , oh die Kommentare führen zu einer erzwungenen Eingabe? Das ist irgendwie cool, ich wusste nicht, dass das so ist.

Nur wenn Sie den Closure-Compiler verwenden, um auf Typfehler zu prüfen. Ähnlich wie Typoskript . Beide verarbeiten annotierte Javascript in einfaches Javascript. Es handelt sich also nur um eine Überprüfung zur Kompilierzeit.

Die meisten Kommentare zum erweiterten Optimierungsmodus von Closure hier sind ungenau.

Um das Hauptproblem zu beheben, können Sie das folgende Tool verwenden, um automatisch Closure-Externs für jede Bibliothek zu generieren http://www.dotnetwise.com/Code/Externs/

Wenn Sie sich außerdem dafür entscheiden, Three.js als Eingabe für Ihren Code zu verwenden, anstatt es einfach als externe Bibliothek zu verwenden, müssen Sie das Flag hinzufügen

--language_in=ECMASCRIPT5

Du solltest einen Blogbeitrag darüber schreiben, vielleicht eine Vorstellung machen
Kritisches Beispiel und sehen, ob es durch die Google-Schließung ausgeführt wird
Compiler mit guten Optimierungen macht einen Unterschied.
-ben

Am Mo, 13.01.2014 um 12:31 Uhr, Rodrigo Formigone <
[email protected]> schrieb:

Auch wenn Sie sich entscheiden, Three.js als Eingabe für Ihren Code zu verwenden, anstatt
Wenn Sie es einfach als externe Bibliothek verwenden, müssen Sie das Flag hinzufügen

--language_in=ECMASCRIPT5

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/mrdoob/three.js/issues/341#issuecomment -32191167
.

Mit freundlichen Grüßen,
Ben Houston
Stimme: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
http://Clara.io - Professionelle WebGL-basierte 3D-

Ich denke, ich könnte so einen Beitrag schreiben. Nur um es klarzustellen, der Grund, warum man Three.js durch Closure (mit oder ohne externe Datei) ausführen möchte, ist nicht unbedingt nur die Leistungsoptimierung. Closure soll Ihnen in erster Linie helfen, wartbaren Code in JavaScript zu schreiben (insbesondere sehr große Codebasen). Das Ziel ist es, Entwicklern zu helfen, JavaScript zu „zähmen“ (das native JS schreibt), anstatt es zu „vermeiden“ (mit GWT oder anderen ähnlichen Tools). Wenn Sie einfach versuchen, Three.js als Teil eines Closure-Projekts zu kompilieren, könnte der Compiler Sie anschreien, weil Three.js möglicherweise nicht einigen seiner Standards entspricht (vielleicht nicht genug JSDoc?). Die Verwendung des Compiler-Flags --language_in löst dies ab sofort, obwohl Sie einige Warnungen erhalten. Wenn Sie einfach Ihren eigenen JS-Code kompilieren möchten, aber Three.js als externe Bibliothek referenzieren (und damit die gesamte Codebasis von Three.js unberührt und nicht optimiert lassen), benötigen Sie die oben erwähnte externs-Datei. Ohne die Datei externs gibt Closure Kompilierungsfehler aus, die sagen, dass THREE.* nirgendwo deklariert ist usw.

Ich komme zwar nicht dazu, meinen Blog-Beitrag zu schreiben, in dem erklärt wird, wie und warum man Three.js in einem Closure-Projekt verwenden möchte, aber hier ist die beste Einführungspräsentation zu Google Closure-Tools, die ich gesehen habe: (von Google I/O 2011) https://www.youtube.com/watch?v=M3uWx-fhjUc (Ich weiß, dass es ein langes Video ist, aber es macht wirklich deutlich, was der Zweck des Compilers ist und was die verschiedenen Kompilierungsmodi tatsächlich tun. Es beschreibt auch warum Sie eine externe Datei benötigen).

Hallo, ich freue mich darauf, eine Anwendung mit Three.js zu entwickeln und wünsche mir daher die Unterstützung der Option ADVANCED_OPTIMIZATIONS.

Die Entfernung von totem Code funktioniert sehr gut, wenn die einbettende Anwendung nur einen Teil der Three.js-Funktionen verwendet.

Derzeit erfordert three.js jede einzelne entwickelte Funktion, da die beabsichtigte Verwendung auf "Nur erforderlich drei.min.js!" beschränkt ist. Dieser klassische Ansatz ist leicht zu verstehen, aber für Codes, die mit diesem Ansatz geschrieben wurden, können JavaScript-Minimierer Code reduzieren Größe nur durch Verkleinern von Variablennamen (nicht wirksam bei kurzen Variablennamen), Entfernen von Leerzeichen (nur wirksam bei Einrückungszeichen, Tabulatoren und Zeilenumbrüchen) und andere billige Tricks.

Durch die Verwendung der Option ADVANCED_OPTIMIZATIONS für einen Code mit "Closure-Compiler-Stil" kann er den gesamten "nicht benötigten Code" entfernen, der hauptsächlich große Bibliotheken gewichtet. Bibliotheken wie die Closure-Bibliothek waren groß geworden, aber Bibliotheksbenutzer und -entwickler kümmern sich nicht darum, weil sie wissen, dass der größte Teil des Codes beim Kompilieren entfernt wird.

Da three.js bereits im objektorientierten Stil geschrieben ist, denke ich, dass es (technisch) nicht schwierig ist, den gesamten Code auf Code im "Closure-Compiler-Stil" zu aktualisieren. Die Dinge, über die ich mir Sorgen mache...

• Der Closure-Compiler-Stil erfordert Anmerkungen für jede Funktion. Derzeit gibt es keine davon. Wie lange wird es dauern, alle jemals entwickelten Funktionen mit Anmerkungen zu versehen?
• Der Closure-Compiler erfordert strenge Typdefinitionen. Auch für null und undefined sollten Sie richtig arbeiten. Für Funktionen mit "null-erlaubten" Parametern, "undefiniert-erlaubten" Parametern, ... kann es eine harte Arbeit sein.
• Sie sollten eine geeignete externe Datei vorbereiten, wenn Sie sich darauf freuen, die von ADVANCED_OPTIMIZATIONS kompilierte "Vollversionsbibliothek" vorzubereiten.

Hai Zeitplan Xor,

Das ist eine schöne Idee. Könnten Sie einen kleinen Ausschnitt teilen, wie?
dies muss zu three.js hinzugefügt werden?

Mit Grüßen,

Ramsundhar Madhavan

Am Dienstag, 24. Juni 2014 um 16:23, Planen Sie Xor [email protected]
schrieb:

Hallo, ich freue mich darauf, eine Anwendung mit Three.js zu entwickeln, und
daher die Unterstützung der Option ADVANCED_OPTIMIZATIONS wünschen.

Die Entfernung von totem Code funktioniert stark, wenn die Einbettungsanwendung nur verwendet wird
ein Teil der Three.js-Funktionen.

Derzeit erfordert three.js jede einzelne entwickelte Funktion, da die
Die beabsichtigte Verwendung beschränkt sich auf "Nur erforderlich drei.min.js!".Dieser Klassiker
Ansatz ist leicht zu verstehen, aber für Codes, die mit diesem Ansatz geschrieben wurden,
JavaScript-Minimierer können die Codegröße nur reduzieren, indem sie Variablennamen verkleinern
(nicht wirksam bei kurzen Variablennamen), Leerzeichen entfernen (nur wirksam
zum Einrücken von Leerzeichen, Tabulatoren und Zeilenumbrüchen) und andere billige Tricks.

Durch Verwendung der Option ADVANCED_OPTIMIZATIONS für einen "Closure-Compiler-Stil"
Code, es kann die gesamten "nicht benötigten Codes" entfernen, die meistens gewichten
große Bibliotheken. Bibliotheken wie Closure library
https://developers.google.com/closure/library/ war groß geworden, aber
Bibliotheksbenutzer und Entwickler kümmern sich nicht darum, weil sie das wissen
Der größte Teil des Codes wird beim Kompilieren entfernt.

Da three.js bereits im objektorientierten Stil geschrieben ist, denke ich, dass es
(technisch) nicht schwierig, den gesamten Code auf "Closure-Compiler" zu aktualisieren
gestylten" Code. Die Dinge, über die ich mir Sorgen mache...

• Der Closure-Compiler-Stil erfordert Anmerkungen für jede Funktion.
  Derzeit gibt es keine davon. Wie lange dauert es, Anmerkungen hinzuzufügen?
  auf alle Funktionen, die jemals entwickelt wurden?
• Der Closure-Compiler erfordert strenge Typdefinitionen. Auch für null und
  undefined, sollten Sie richtig für sie arbeiten. Es könnte eine harte Arbeit sein für
  Funktionen mit "null-allowed"-Parametern, "undefined-allowed"
  Parameter, ...
• Sie sollten eine ordentliche externe Datei vorbereiten, wenn Sie sich freuen
  zur Vorbereitung der "vollversionierten Bibliothek" erstellt von
  ADVANCED_OPTIMIZATIONS.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mrdoob/three.js/issues/341#issuecomment -46957189.

@schedul-xor wir brauchen definitiv Hilfe dabei ... sind die Code-Anmerkungen wirklich erforderlich oder reicht es mit externs?

Hi,

Ich bin neu in dieser Community und würde mich freuen, diese beizutragen
Änderungen.

Mit Grüßen,

Ramsundhar Madhavan

Am Dienstag, den 24. Juni 2014 um 19:23 Uhr schrieb Mr.doob [email protected] :

@schedul-xor https://github.com/schedul-xor wir brauchen definitiv Hilfe
damit... sind die Code-Annotationen wirklich erforderlich oder reicht es damit?
extern?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mrdoob/three.js/issues/341#issuecomment -46973166.

Denken Sie daran, dass erweiterte Optimierungen einen bestimmten Codierungsstil erfordern oder Ihren Code beschädigen. Three.js mischt beispielsweise uniforms["diffuse"] und uniforms.diffuse , was bei erweiterten Closure-Optimierungen nicht zulässig ist. Siehe auch #3222.

Das Hinzufügen von strikten Typanmerkungen überall ist eine Menge Arbeit und fügt viele Kommentarzeilen hinzu (in meinem Projekt hat es die Zeilenanzahl um den Faktor 2 erhöht).

Es ist schön, externe Dateien für andere Web-Frameworks/Sprachen zu haben.

Gemäß dem Tutorial werden externs verwendet, um Variablen zu schützen, die nicht umbenannt werden sollen. Dies ist, was Sie verwenden möchten, wenn Sie Bibliotheken von Drittanbietern (im Stil eines Closure-Compilers) vor aggressiven Umbenennungen von Variablen schützen möchten, die Sie in Ihrem Projekt im Stil eines Closure-Compilers verwenden.

Ich bin mir nicht sicher, ob der Compiler immer noch versucht, toten Code zu schneiden, selbst wenn die externe Datei das einzige ist, was bereitgestellt wird. Es ist viel einfacher, wenn Sie nur externe Dateien schreiben sollten, anstatt Anmerkungen zu allen Funktionen zu schreiben ...

Auch wenn meiner Meinung nach das Schreiben von Anmerkungen zu jeder Funktion besser ist als das Schreiben von externen Dateien, da es schwierig wird, externe Dateien nachträglich zu synchronisieren, wenn sich Typdefinitionsdatei und Quellcode unterscheiden. Sie können sich vorstellen, wie ärgerlich es sein wird, wenn jeder Funktions-Fix ein externes Datei-Update erfordert. Jede Auswahl (externs oder /** */ Kommentar zu Funktionen) erfordert eine Annotation, in den meisten Fällen gewinnt die einfachere Methode.

Da es sich bei Three.js um ein großes Projekt handelt, überlege ich, wo ich zuerst arbeiten soll. Es ist besser, mit dem zu beginnen, was leicht zu tun ist.

Wie wäre es, Dateiheader zu setzen, den Funktionsdefinitionsstil für jede Funktion zu ändern?

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

↓

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

Es ist einfacher, alle Parametertypen zu beschränken und Werttypen auf Nicht-Null zurückzugeben. Dies macht es viel einfacher, ADVANCED_OPTIMIZATIONS-Kompilierungsfehler zu übergeben.

Hmmm, ich bin immer noch nicht so glücklich mit den vielen Kommentaren im Code. Manchmal frage ich mich, ob es nicht besser wäre, das Ganze stattdessen auf so etwas wie TypeScript zu portieren (zu schade, dass eines von Microsoft gehört).

Typescript fühlt sich für stark typisiertes Javascript viel besser an als Closure. Dies ist meine Erfahrung, nachdem ich einen mittelgroßen Collada-Loader zuerst in schließungskonformes Javascript und dann in Typoskript umgeschrieben habe. Beide Ansätze halfen beim Auffinden von Fehlern zur Kompilierzeit. Closure hat einige ziemlich nette Optimierungen (Inlining, Entfernung von totem Code) meines Codes durchgeführt und unterstützt NULL-fähige Typen. Andererseits war die große Menge an Kommentaren ablenkend und die IDE-Unterstützung (für die Codevervollständigung) war nicht so gut wie bei Typoskript. Außerdem ist das Schreiben von Klassen in Typoskript viel einfacher, da das ECMAScript6-ähnliche Schlüsselwort class .

Aber das ist nur eine persönliche Meinung. Noch wichtiger ist, dass Sie sicherstellen müssen, dass alle Eigenschaftszugriffe konsistent sind, bevor Sie das Schließen im erweiterten Kompilierungsmodus offiziell unterstützen. Eine externe Datei hilft nicht, der Zugriff auf die Eigenschaften muss für interne Objekte, die nicht exportiert werden, konsistent sein, da Sie diese aggressiv umbenennen/inline/entfernen _möchten_. Sie werden inkonsistente Eigenschaftszugriffe feststellen, wenn Sie jede Klasse und jede Variable mit Anmerkungen versehen, aber dies für die gesamte Three.js-Codebasis dauert mehrere Wochen (wenn ich hochrechne, wie lange ich für die Anmerkungen zu meinem Projekt gebraucht habe).

Schließlich sollte die Portierung eines so großen Projekts wie Three.js in eine andere Sprache/ein anderes Framework/einen anderen Codierungsstil ausführlich besprochen werden.

OK, ich stimme zu, dass Three.js enorm ist und das Hinzufügen von Anmerkungen zu jeder Funktion mehrere Wochen dauern kann. Es könnte bessere AltJSs als Closures geben. Dies muss genauer besprochen werden (wenn Sie sich darauf freuen, es auf etwas anderes zu portieren).

Entschuldigung, ich kann es kaum erwarten. Ich fork den aktuellen Commit und starte die Portierung.

Hi,

Ist es möglich, diese Anmerkungen automatisch hinzuzufügen? Wenn ja, können wir sie hinzufügen
zu build.py und fügen Sie es hinzu, kurz bevor wir die erweiterte Optimierung der Schließung aktivieren.

Mit Grüßen,

Ramsundhar Madhavan

Am Mittwoch, 25. Juni 2014 um 06:05 Uhr, Zeitplan für Xor [email protected]
schrieb:

OK, ich stimme zu, dass Three.js enorm ist, und füge daher Anmerkungen zu jedem hinzu
Funktionen können mehrere Wochen dauern. Es könnte bessere AltJSs geben als
Schließung. Dies muss besprochen werden (wenn Sie sich darauf freuen, es zu portieren
etwas anderes) tiefer.

Entschuldigung, ich kann es kaum erwarten. Ich fork den aktuellen Commit und starte die Portierung.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/mrdoob/three.js/issues/341#issuecomment -47047966.

@ramsundhar20 , meiner Meinung nach wird das Hinzufügen von Anmerkungen (ungenau? besser als nichts. kein großes Problem. es kann aktualisiert werden) zuerst die Automatisierung viel einfacher machen.

Three.js enthält derzeit 163 Javascript-Dateien mit 1354 definierten Funktionen. Ja, es ist riesig, aber es ist kein Ziel, das zu weit ist.

// Ich habe Angst, wenn dieses Thema fehl am Platz ist ...

@schedul-xor wieder, ich bin nicht wirklich ein Fan davon, einen Kommentar pro Funktion zu haben :/

@mrdoob OK, ich habe verstanden.

Unter Beachtung Ihrer Richtlinien möchte ich Kommentare pro Funktion nur in meinem Fork hinzufügen. Außerdem werde ich niemals Pull-Requests machen. Stattdessen portiere ich die ursprünglichen Three.js-Modifikationen auf meinen Closure-Style Fork. Ihre günstige Rücksichtnahme würde geschätzt.

Das klingt gut :)

Dankeschön! Ich werde anfangen, daran zu arbeiten.

Gibt es mindestens eine externe Datei der Basis drei.js, die mit dem Closure-Compiler verwendet werden soll? Das erfordert nicht, dass der Three.js-Quellcode zusätzliche Anmerkungen im Google-Stil enthält.

Ich bin auch sehr an einer qualitativ hochwertigen, vollständigen externen Datei für Three.js interessiert. Hier ist eine, aber sie ist nicht vollständig:

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

Ich nehme an, eine Möglichkeit besteht darin, mit diesem zu beginnen und Dinge, die Sie verwenden, manuell hinzuzufügen.

Ja, zähle meine Stimme. Idealerweise für einen im fortgeschrittenen Modus kompilierbaren, zu 100% typisierten Threejs - oder zumindest eine externe Datei.

Die Typinferenz ist besser geworden und die erforderliche Unordnung ist weniger geworden. Wenn Bereiche und Aliase vorhanden sind, muss der Code nicht so ausführlich gelesen werden wie die Closure-Bibliothek. Im Falle von sauberem Code kommt es ziemlich darauf an, getippte Inline-Dokumente zu schreiben. Sind diese wirklich schlimm genug, um alle Vorteile aufzuwiegen?

Superaggressive Einstellungen, d. h. erweiterter Modus + JS-Komprimierung + typbasierte Optimierungen, entfernen nicht nur toten Code, sondern können all die coolen Dinge tun, die ein optimierender Compiler tun kann:

Benannte Konstanten / Aufzählungen werden durch Ziffern ersetzt. Außerdem kann der Compiler Konstanz verfolgen, Berechnungen mit anderen Konstanten durchführen und schließlich eine einfache Zahl dort einfügen, wo sie benötigt wird. Die abhängige Flusskontrolle wird natürlich der Eliminierung von totem Code unterzogen. Funktionen, die nur eine aktive Aufrufstelle in der resultierenden Anwendung haben und deren komprimierte Form kleiner als ihre Definition ist, würden eingespart werden. Namensräume werden entfernt. Alle ungeschützten Namen werden auf ein Minimum verkleinert.

Die Suche in JavaScript ist vergleichsweise teuer. Die Kombination aus Umbenennen, ständigem Falten und Inlining entfernt viel Nachschlagen und zahlreiche Funktionsaufrufe. Darüber hinaus können mit einem entsprechenden Header (in der Closure-Bibliothek gibt es einen) alle standardisierten WebGL-Konstanten in den Renderer einbacken.

Das Ergebnis ist eine kleinere, schnellere, selbstdokumentierende und automatisch anpassbare Bibliothek. Der Compiler wird auch unter aggressiveren Einstellungen viel mehr Fehler abfangen - es wird wahrscheinlich die Codeüberprüfung erleichtern. Nicht zuletzt der Verschleierungseffekt: Das Zusammenfassen des Client-Codes mit der angepassten Bibliothek bietet einen viel besseren Schutz vor dem Diebstahl geistigen Eigentums als Code mit aufschlussreichen Symbolen, der mittels einer externen Datei gesichert wurde.

Ich kann die oben genannte Filiale nicht finden. Arbeitet noch jemand an einer getippten Version?

@mrdoob Hoffnung auf einen Sinneswandel bezüglich der Mainline?

Ich helfe gerne.

@mrdoob Hoffnung auf einen Sinneswandel bezüglich der Mainline?

Im Moment konzentriere ich mich auf das Refactoring von WebGLRenderer 😇

Kann die Konstanten in const anstatt in var ändern hat gute Unterstützung für alle WebGL-Browser https://kangax.github.io/compat-table/es6/ (const->basic) und js Engines beginnen mit der Optimierung für const Beschleunigen globaler Konstanten durch Optimierung mit festen Feldern

Interessant jedoch, da es nur anstelle von var funktioniert und nur auf einen sehr kleinen Bruchteil der Fälle anwendbar ist, von denen ich spreche - selbst wenn es sich nur um Konstanten handeln würde. Darüber hinaus sind JIT-Compiler per Definition in Eile, sodass sie natürlich nicht mit ganzen Programmoptimierungen konkurrieren können, die von einem Offline-Tool durchgeführt werden. Jede JS-Engine muss die Struktur des Codes respektieren und kann ihn nicht willkürlich umgestalten, da wir erwarten, dass wir beispielsweise die Konsole öffnen und das darin enthaltene Programm finden, eine bestimmte Funktion ersetzen können usw.

Zurück zur Unterstützung des Closure-Compilers: Ich habe etwas gelesen und experimentiert. Folgendes habe ich herausgefunden:

• Zum Ausführen des erweiterten Modus sind keine Anmerkungen erforderlich.
• Anmerkungen können nach und nach hinzugefügt werden, um das Optimierungsniveau zu erhöhen, und
• Der Lader braucht etwas Pflege, um zu funktionieren, aber es ist ziemlich einfach.

Grundsätzlich gibt es drei verschiedene Anwendungsfälle:

1. Die Modelle können zusammen mit der Anwendung und der Bibliothek komprimiert werden.
2. Die Anwendung und die Bibliothek sind komprimiert. Modelle werden zur Laufzeit geladen.
3. Die Bibliothek ist im Basismodus kompiliert und eine App im erweiterten Modus möchte sie verwenden.

Das dritte erfordert eine externe Datei für alle Three.js und ist viel Arbeit für zu wenig Nutzen IMO. Daher werde ich nur die ersten beiden diskutieren - dies sind sowieso die bevorzugten:

Wenn der Compiler sieht

anObject['aProperty']

es wird den Eigenschaftsnamen nicht berühren (keine Zeichenfolgen werden jemals geändert).

anObject.aProperty

Auf der anderen Seite kann der Compiler die Eigenschaft konsistent umbenennen, es sei denn, er weiß, dass anObject außerhalb der zu kompilierenden Anwendung liegt. Der Compiler kennt dies von eingebauten oder explizit bereitgestellten _externs_.

Hier kommt das Rezept:

• Wir sorgen dafür, dass der Loader konsistent mit der Punktnotation auf die Eigenschaften zugreift.
• Wir geben die Eingabe ein und schreiben eine externe Datei nur für die JSON .
• Das Kompilieren mit dieser externen Datei sollte alles sein, was Sie brauchen, um Anwendungsfall 2 zum Laufen zu bringen.
• Für Anwendungsfall 1 verwenden wir nicht die externs-Datei, sondern entfernen die Anführungszeichen aus den Objektschlüsseln im JSON:

{
    "camera": {
        "object": {
    // ...

würde einfach werden

{
    camera: {
        object: {
    // ...

Ganz einfach, nicht wahr?

Anwendungsfall 1 wird noch attraktiver, wenn das JSON-Format externe Binärdaten (roh oder komprimiert über webgl-loader oder o3dgc) zulassen würde - technisch natürlich ein weiteres Feature, das natürlich vollständig orthogonal zur Closure-Unterstützung ist.

Die Datei externs kann auch veraltete Wiki-Seiten ersetzen, die das Dateiformat dokumentieren :-).

Ich weiß, dass dieses Thema seit geraumer Zeit geschlossen ist. Ich hatte jedoch kürzlich das gleiche Problem mit Three.js in einem Closure-Compiler-Projekt und bin auf dieser Seite gelandet. Ich habe ein Tool geschrieben, das .d.ts (Typoskript-Deklarationsdateien) in eine Closure-Compiler-Datei umwandelt. Mit dem Tool und der großartig beschriebenen DefinitelyTyped/threejs-Deskriptordatei funktioniert es perfekt.
Das Tool: https://github.com/eredo/tsd2cce oder über npm install -g tsd2cce installieren

Hoffe das hilft...

@eredo das hat mir total geholfen. Allen anderen Generatoren, die ich ausprobiert habe, fehlten viele Methodendefinitionen für die Three.js-Bibliothek. Vielen Dank!

@eredo @Corkle oder jemand anderen, können Sie uns zeigen, wie man tsd2cce ? Das erste Argument ist eindeutig die .d.ts-Definitionsdatei, aber was ist das zweite Argument? Ich bekomme dieses Problem. https://github.com/eredo/tsd2cce/issues/6

Tatsächlich habe ich festgestellt, dass die Verwendung des r73 d.ts vom Februar mit tsd2cce gut funktioniert, r73 ist jedoch zu alt für mich.

Der richtige Weg, dies jetzt zu tun, wäre, tsickle zu verwenden, um aus d.ts-Dateien zu generieren.

Hallo zusammen,

Für die Nachwelt und zum Wohle aller habe ich beschlossen, hier über meine eigenen Versuche zu berichten, die Bibliothek mit ADVANCED_OPTIMIZATIONS von Google Closure Compiler und einigen anderen Optimierungen weiter zu verkleinern.

Ich habe eine extern.js erstellt, die Three.min.js mit aktivierten erweiterten Optimierungen ermöglicht. Es ist bei weitem nicht perfekt.

Um es zu erstellen, habe ich mit einer extern.js begonnen, die auf früheren Beispielen in diesem Thread basiert. Die Bibliothek wurde beim Kompilieren auf diese Weise beschädigt, da die Eigenschaften verstümmelt wurden, die nicht in dieser externen Datei enthalten waren. Mit der Option --property_renaming_report des Closure-Compilers habe ich die vollständige Liste der verstümmelten Eigenschaften erhalten. Nachdem ALLE dieser Eigenschaften zu extern.js hinzugefügt wurden, wurden die Eigenschaften nicht mehr verstümmelt und die Ausgabe war dieselbe wie bei SIMPLE_OPTIMIZATIONS. Von dort aus begann ich selektiv/manuell, Abschnitte der extern.js auszukommentieren und zu bestätigen, dass die Bibliothek noch in minimierter Form funktionierte.

Ich würde es LIEBEN, dieses Rate-and-Check zu automatisieren und eine perfekte extern.js zu erhalten, die so viele Eigenschaftsnamen wie möglich sicher verstümmelt. Ich hatte die Idee, die Unit-Tests für THREE.JS zu verwenden und programmatisch zu bestimmen, welche verstümmelten Propnames zu fehlgeschlagenen Tests führten, aber es scheint derzeit nicht möglich zu sein, die Unit-Tests über die Befehlszeile auszuführen, zum Beispiel mit phantomjs. (Wahrscheinlich wegen WebGL) ?

So oder so ist dies ein "Fortschritt" in Richtung einer kleineren minimierten Bibliothek, die mir hilft, meine gesamte SPA-Javascript-Größe zu verringern.

externs.js

Aktualisierter package.json build-closure-Befehl

Ich habe auch String-Replace-Befehle verwendet, um alle console.warn- und console.error-Meldungen aus der Bibliothek zu entfernen, wie Sie im Befehl build-closure sehen können. Damit und durch das Auskommentieren bestimmter Codeabschnitte habe ich die minimierte Bibliothek bisher um etwa 20 % verkleinert, und es gibt Raum für Verbesserungen.

@mrdoob Wenn Sie etwas wie meine Methode hier tun, könnten Sie schließlich eine extern.js bereitstellen, die ADVANCED_OPTIMIZATIONS ermöglicht, ohne den Code mit Anmerkungen zu überladen, die für diesen Compiler spezifisch sind, was Ihr Hauptanliegen zu sein schien.

@medmr1 Genial ! Haben Sie versucht, Ihre App mit der Three.js-Bibliothek in einem zu kompilieren? Dies würde die Notwendigkeit einer externen Datei im Idealfall verhindern.

Ich habe nicht versucht, das Ganze innerhalb der Schließung zu bauen, nein. Das mag gut funktionieren, aber ich vermute, dass es immer noch Probleme in Bezug auf das Verstümmeln einiger Eigenschaften geben wird, auf die programmgesteuert verwiesen wird. IE Sachen wie var thing = ShaderLib[ shaderType + "BumpMapFrag"] Aber vielleicht würde ich mir viel Ärger ersparen?

Ja, etwas wie var thing = ShaderLib[ shaderType + "BumpMapFrag"] wird mit erweiterten Optimierungen nicht funktionieren. Eigenschaftsreferenzen müssen statisch analysierbar sein. Sie könnten so etwas tun:

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

Das Erstellen einer korrekten externen Datei ist für das Projekt als Ganzes definitiv vorteilhafter, da die meisten Leute ihre App nicht mit Closure Compiler kompilieren, sondern nur die veröffentlichte minimierte Version verwenden.

Anstelle von externs können Sie auch die Annotation @export ausprobieren .
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-sometype