Oliver Zeigermann http://zeigermann.eu JavaScript für Java-Entwickler
4 Vorurteile 1. JavaScript ist eine tote Sprache 2. Java als Sprache ist sauberer und klarerer als JavaScript 3. JavaScript-Anwendungen sind ein einziges Chaos 4. Es gibt keinen vernünftigen IDE- Support für JavaScript
Vorurteil: JavaScript ist tot Zitat (anonymer redhat-entwickler): JavaScript is doomed to die
Warum gerade jetzt JavaScript? Browser werden immer Standard konformer IE6 ist tot JS Engines immer reifer und schneller JS läuft auf jedem Device JS ist Bürger erster Klasse auf Windows 8 Seit ECMAScript 5 ist JavaScript als Sprache gut genug u.a. strict mode
HTML5 = HTML + CSS + JavaScript LocalStorage, SessionStorage, index DB, WebSql Canvas Web Workers DnD Web Sockets
Vorurteil: Java als Sprache ist sauberer und klarerer als JavaScript Zitat (anonymer Clean Coder): Dein JavaScript sieht aus wie ein Merge-Conflict
Grundlagen
Hello World #1 <!DOCTYPE html> <html> <head> <script> alert("hello World"); </script> </head> <body></body> </html>
Hello World #2 <!DOCTYPE html> <html> <body> <div id="log"></div> <script> var el = document.getelementbyid("log"); el.innerhtml = "<h1>hello World</h1>"; </script> </body> </html>
Hello World #3 node -e "console.log('hello World');"
Funktionen function f1(p1, p2) { return p1 + p2; } var result1 = f1(1,2); console.log(result1); // => 3 var result2 = f1(1); // WOW console.log(result2); // => NaN
Objekte var map = {key1: "value1", key2: 1}; var value1 = map.key1; var value2 = map["key2"]; map.key1 = true; map.f = function() { return "Cool!" }; for (var key in map) { console.log(key + ":" + map[key]); }
Ist JavaScript eine schlechte Sprache? Die hässlichen bzw. verwirrenden Teile von JavaScript sind offensichtlich und wohlbekannt 1. Scopes 2. Prototypische Vererbung 3. Wie wird this gesetzt? 4. Hoisting
Keine lexikalischen Scopes { } var shouldbelocal = "I am still here"; console.log(shouldbelocal); // => I am still here console.log(shouldbelocal); // => I am still here
Scopes mit IIFE (function () { var thatsthewaythecookiecrumbles = "I am gone"; console.log(thatsthewaythecookiecrumbles); // => I am gone })(); console.log(thatsthewaythecookiecrumbles); // => ReferenceError
Prototypische Vererbung extends(horse, Animal); function Horse(name) { Animal.call(this, name); } Horse.prototype.move = function () { alert("galloping..."); Animal.prototype.move.call(this, 45); }; var bb = new Horse( Black Beauty ); bb.move();
this this kann in JavaScript auf mindestens 5 Arten gesetzt werden 1. Globaler Scope 2. Konstruktor 3. Methodenaufruf 4. call / apply 5. bind Wie this gebunden wird, ist auch für erfahrene JavaScript-Programmierer nicht immer einfach
Hoisting console.log(doesnotexist); // Uncaught ReferenceError console.log(hoisted); // undefined var hoisted = 10; console.log(hoisted); // 10
... aber...
Ist Java eine klare und einfache Sprache? Bitte alle Arme nach oben Nun Arm runter wer nicht komplett versteht oder gar nicht weiß, wo das Problem liegen sollte Bitte ehrlich sein Boxing / Un-Boxing Generics Initialisierungsreihenfolge bei Klassen und Vererbung
Was ist hier falsch? public class GenericDatastoreServiceImpl<T extends HasId<String> & HasStringData, String> implements GenericDataService<String, T> { String wat = ; // Incompatible types }
These: JavaScript und Java haben beide ihre schlimmen Teile, aber an die von Java haben wir uns schon gewöhnt...
JavaScript ist nicht schlechter als Java, sondern anders
Fragen-Block #1 Timebox: 5 Minuten
Vorurteil: JavaScript-Anwendungen sind Chaos Zitat (anonymer GWT-Entwickler): JavaScript-Anwendungen sind unstrukturiertes Chaos und können nicht optimiert werden
Module var Module = {}; (function() { function InternalStuff() {...} function Person(name, age) { // uses class InternalStuff } Module.Person = Person; })(); var olli = new Module.Person("Olli", 42); Module.InternalStuff === undefined;
Live-Demo: Best Practices Entwicklungsprozess http://yeoman.io/
Zusammenfassung Live- Demo #1 1. Es gibt ein reifes Build-Tool (Grunt) für JavaScript, vergleichbar mit Gradle 2. Turnaround-Zeiten fast nicht vorhanden 3. Produktionsversionen können statisch zusammengestellt und optimiert werden
Zusammenfassung Live- Demo #2 4. Es gibt ein statisches (!) Abhängigkeitsmanagement (Bower), vergleichbar mit Maven / Ivy 5. Werkzeuge werden über node / npm installiert 6. Automatisierte Linter und Tests sind Standard
Vorurteil: Es gibt keinen vernünftigen IDE-Support für JavaScript Zitat (anonymer JavaScript- Entwickler): Die beste JavaScript-IDE ist vi
Live-Demo: JavaScript IDE WebStorm http://www.jetbrains.com/webstorm/
Zusammenfassung Live-Demo #1 1. Es gibt ausgereifte, mit JUnit vergleichbare Testframeworks 2. Testläufe und Code-Coverage in eng in IDE integriert 3. Umfangreiche Checks mit unterschiedlichen Tools möglich
Zusammenfassung Live-Demo #2 4. Code-Completion / Code-Analyse / Refactoring komfortabel aber nicht immer verlässlich 5. zusätzliche Typ-Deklarationen (TypeScript / Closure Compiler) bringen Verlässlichkeit
Best-Practices Refactoring JavaScript #1 1. Breite und sinnvolle Testabdeckung (noch wichtiger als in Java) 1. Unit 2. Integration 2. Möglichst kleine Module mit klaren Schnittstellen 3. Evtl. Event-Bus
Best-Practices Refactoring 4. Typen einführen JavaScript #2 Google Closure Compiler TypeScript 5. Keine komplexen Expressions in Templates 6. Mächtige IDE benutzen
Mehr Vorurteile Es gibt keinen Standard, jeder Browser implementiert seinen eigenen Dialekt JavaScript ist langsam JavaScript ist wie CSS und HTML für Designer, nicht für richtige Entwickler Große Projekte sind nicht möglich
Zusammenfassung JavaScript lebt JavaScript und seine Umgebung sind reif für echte Anwendungen Es gibt vernünftige JavaScript-IDEs JavaScript ist nicht hässlicher als Java, nur anders hässlich
Nathaniel Schutta, Dienstag, 5. November 2013-16:30 bis 17:30 http://jax.de/wjax2013/node/566 The JavaScript Developer's Toolchain
Kai Tödter, Mittwoch, 6. November 2013-10:15 bis 11:15 http://jax.de/wjax2013/node/452 TypeScript: Das neue JavaScript?
Ted Neward, Mittwoch, 6. November 2013-10:15 bis 11:15 http://jax.de/wjax2013/sessions/busy-developersguide-nodejs Busy Developer's Guide to NodeJS
Vielen Dank für die Aufmerksamkeit Fragen / Diskussion Oliver Zeigermann @DJCordhose http://zeigermann.eu
Bonus-Vorurteil: Mit JavaScript kann man keine großen, wartbaren Projekte umsetzen Zitat (anonymer Java-Architekt): Programmieren ohne ein starkes Typensystem ist wie ohne Bremsen auf der Autobahn fahren
Was ist ein großes Projekt? Viele Tausend (Hunderttausend?) Zeilen Code Viele (externe) Abhängigkeiten Viele Entwickler arbeiten daran Kommen und Gehen Es lebt viele Jahre (manchmal mehrere Jahrzehnte)
Was braucht ein großes Projekt? Der Code muss gut wartbar sein Modular Analysierbar Refactorbar Der Code muss gut lesbar sein Gute Dokumentation? Es muss ein brauchbares Abhängigkeitsmanagement geben Es muss ein Build-Management und CI geben Der Code muss gut getestet sein inkl. automatisierbarer Tests
AngularJS: Beispiel eines großen JavaScript-Projekts Anzahl JS-Zeilen 1.2.0 (ohne Tests): ~50k cd src; find. -name '*.js' xargs wc -l Tests: >30k Unit und e2e JavaScript braucht typischerweise deutlich weniger Code als Java für die gleich Aufgabe Interne Module ~10 > 20 Abhängigkeiten zu anderen Projekten u.a. jquery, selbst noch einmal so groß Lebt seit 2009 Kernteam bei Google > 10 > 300 externe Mitarbeiter am Projekt
Automatisiertes Build und CI Abhängigkeitesmanagement über node / npm und bower Build über grunt Integration in Travis und Jenkins
JsDoc Dokumentation ähnlich wie JavaDoc Generiert direkt die Webseite
Google Closure Compiler Statische Typinformation in Kommentaren Angeleht an JsDoc Erweitert um alle aus Java bekannten Konstrukte inkl. Sichtbarkeit Typinformation wird benutzt für Dokumentation Minifizierung Statische Checks Besseres Tree Shaking WebStorm-IDE Code-Completion Analyse Refactoring
Beispiel Closure Annotationen /** * @description Converts the specified string to lowercase. * * @param {string} string String to be converted to lowercase. * @returns {string} Lowercased string. */ function lowercase(string) { }
Tests Unit-Tests mit Jasmine E2E-Tests mit anguluar-scenario direkt auf den Code-Beispielen in der Dokumentation Automatische Ausführung auf jedem CI server Karma-Testrunner PhantomJS: Headless Browser
Exkurs: Brauchen wir Typen? Zitat (anonymer JavaScript-Hacker): Deklarierte Typen sind für ältere Leute, die mit dynamischen Sprachen überfordert sind
Welchen Vorteil haben deklarierte, statische Typen? Oft gehört: Man kann sich nicht verschreiben Der Compiler bietet durch sein Typensystem eine Reihe von automatischen Tests Das Programm enthält weniger Fehler
Welchen Vorteil haben sie wirklich? Wie schwer ist die Auswirkung? Wie schwer ist die Ursache zu finden? Allerdings: Ohne deklarierte, statische Typen gibt es keine verlässliche IDE- Unterstützung.
Wie gehen wir damit um? Option 1: Annehmen Wir wissen darum und stellen uns darauf ein Wir definieren Module mit sehr klaren Schnittstellen Wir halten diese Module klein Wir nutzen die bestmöglichen IDEs Wir haben eine sinnvolle Testabdeckung
Wie gehen wir damit um? Option 2: Deklarierte Typen Wir fügen JavaScript deklarierte Typen hinzu Dadurch erlangen wir IDE-Unterstützung vergleichbar mit der von Java Optionen sind Google Closure-Compiler und TypeScript Beide werden von WebStorm unterstützt
Live-Demo: Das Riesen-Projekt Angular.js Automatisches Build Automatische Tests Typen mit dem Closure-Compiler