Post on 20-Jan-2015
description
transcript
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 JavaScript #2
4. Typen einführen – 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-developers-guide-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
Dokumentation
• JsDoc – ä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