Oliver Zeigermann JavaScript für Java-Entwickler

Transkript

1 Oliver Zeigermann JavaScript für Java-Entwickler

2 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

3 Vorurteil: JavaScript ist tot Zitat (anonymer redhat-entwickler): JavaScript is doomed to die

4 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

5 HTML5 = HTML + CSS + JavaScript LocalStorage, SessionStorage, index DB, WebSql Canvas Web Workers DnD Web Sockets

6 Vorurteil: Java als Sprache ist sauberer und klarerer als JavaScript Zitat (anonymer Clean Coder): Dein JavaScript sieht aus wie ein Merge-Conflict

7 Grundlagen

8 Hello World #1 <!DOCTYPE html> <html> <head> <script> alert("hello World"); </script> </head> <body></body> </html>

9 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>

10 Hello World #3 node -e "console.log('hello World');"

11 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

12 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]); }

13 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

14 Keine lexikalischen Scopes { } var shouldbelocal = "I am still here"; console.log(shouldbelocal); // => I am still here console.log(shouldbelocal); // => I am still here

15 Scopes mit IIFE (function () { var thatsthewaythecookiecrumbles = "I am gone"; console.log(thatsthewaythecookiecrumbles); // => I am gone })(); console.log(thatsthewaythecookiecrumbles); // => ReferenceError

16 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();

17 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

18 Hoisting console.log(doesnotexist); // Uncaught ReferenceError console.log(hoisted); // undefined var hoisted = 10; console.log(hoisted); // 10

19 ... aber...

20 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

21 Was ist hier falsch? public class GenericDatastoreServiceImpl<T extends HasId<String> & HasStringData, String> implements GenericDataService<String, T> { String wat = ; // Incompatible types }

22 These: JavaScript und Java haben beide ihre schlimmen Teile, aber an die von Java haben wir uns schon gewöhnt...

23 JavaScript ist nicht schlechter als Java, sondern anders

24 Fragen-Block #1 Timebox: 5 Minuten

25 Vorurteil: JavaScript-Anwendungen sind Chaos Zitat (anonymer GWT-Entwickler): JavaScript-Anwendungen sind unstrukturiertes Chaos und können nicht optimiert werden

26 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;

27 Live-Demo: Best Practices Entwicklungsprozess

28 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

29 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

30 Vorurteil: Es gibt keinen vernünftigen IDE-Support für JavaScript Zitat (anonymer JavaScript- Entwickler): Die beste JavaScript-IDE ist vi

31 Live-Demo: JavaScript IDE WebStorm

32 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

33 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

34 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

35 Best-Practices Refactoring 4. Typen einführen JavaScript #2 Google Closure Compiler TypeScript 5. Keine komplexen Expressions in Templates 6. Mächtige IDE benutzen

36 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

37 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

38 Nathaniel Schutta, Dienstag, 5. November :30 bis 17:30 The JavaScript Developer's Toolchain

39 Kai Tödter, Mittwoch, 6. November :15 bis 11:15 TypeScript: Das neue JavaScript?

40 Ted Neward, Mittwoch, 6. November :15 bis 11:15 Busy Developer's Guide to NodeJS

41

42 Vielen Dank für die Aufmerksamkeit Fragen / Diskussion Oliver

43 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

44 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)

45 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

46 AngularJS: Beispiel eines großen JavaScript-Projekts Anzahl JS-Zeilen (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

47 Automatisiertes Build und CI Abhängigkeitesmanagement über node / npm und bower Build über grunt Integration in Travis und Jenkins

48 JsDoc Dokumentation ähnlich wie JavaDoc Generiert direkt die Webseite

49 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

50 Beispiel Closure Annotationen /** Converts the specified string to lowercase. * {string} string String to be converted to lowercase. {string} Lowercased string. */ function lowercase(string) { }

51 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

52 Exkurs: Brauchen wir Typen? Zitat (anonymer JavaScript-Hacker): Deklarierte Typen sind für ältere Leute, die mit dynamischen Sprachen überfordert sind

53 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

54 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.

55 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

56 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

57 Live-Demo: Das Riesen-Projekt Angular.js Automatisches Build Automatische Tests Typen mit dem Closure-Compiler