JavaScript für Java-Entwickler W-JAX 2013

1.264 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.264
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
15
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

JavaScript für Java-Entwickler W-JAX 2013

  1. 1. Oliver Zeigermann| http://zeigermann.eu JavaScript für Java-Entwickler
  2. 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 IDESupport für JavaScript
  3. 3. Vorurteil: JavaScript ist tot Zitat (anonymer redhat-Entwickler): JavaScript is doomed to die
  4. 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. 5. HTML5 = HTML + CSS + JavaScript •  LocalStorage, SessionStorage, index DB, WebSql •  Canvas •  Web Workers •  DnD •  Web Sockets
  6. 6. Vorurteil: Java als Sprache ist sauberer und klarerer als JavaScript Zitat (anonymer Clean Coder): Dein JavaScript sieht aus wie ein Merge-Conflict
  7. 7. Grundlagen
  8. 8. Hello World #1 <!DOCTYPE html> <html> <head> <script> alert("Hello World"); </script> </head> <body></body> </html>
  9. 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. 10. Hello World #3 node -e "console.log('Hello World');"
  11. 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. 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. 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. 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. 15. Scopes mit IIFE (function () { var thatsTheWayTheCookieCrumbles = "I am gone"; console.log(thatsTheWayTheCookieCrumbles); // => I am gone })(); console.log(thatsTheWayTheCookieCrumbles); // => ReferenceError
  16. 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. 17. this •  this kann in JavaScript auf mindestens 5 Arten gesetzt werden 1.  2.  3.  4.  5.  Globaler Scope Konstruktor Methodenaufruf call / apply bind •  Wie this gebunden wird, ist auch für erfahrene JavaScript-Programmierer nicht immer einfach
  18. 18. Hoisting console.log(doesNotExist); // Uncaught ReferenceError console.log(hoisted); // undefined var hoisted = 10; console.log(hoisted); // 10
  19. 19. ... aber ...
  20. 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. 21. Was ist hier falsch? public class GenericDatastoreServiceImpl<T extends HasId<String> & HasStringData, String> implements GenericDataService<String, T> { String wat = ““; // Incompatible types … }
  22. 22. These: JavaScript und Java haben beide ihre schlimmen Teile, aber an die von Java haben wir uns schon gewöhnt...
  23. 23. JavaScript ist nicht schlechter als Java, sondern anders
  24. 24. Fragen-Block #1 Timebox: 5 Minuten
  25. 25. Vorurteil: JavaScript-Anwendungen sind Chaos Zitat (anonymer GWT-Entwickler): JavaScript-Anwendungen sind unstrukturiertes Chaos und können nicht optimiert werden
  26. 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. 27. Live-Demo: Best Practices Entwicklungsprozess http://yeoman.io/
  28. 28. Zusammenfassung LiveDemo #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. 29. Zusammenfassung LiveDemo #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. 30. Vorurteil: Es gibt keinen vernünftigen IDE-Support für JavaScript Zitat (anonymer JavaScriptEntwickler): Die beste JavaScript-IDE ist vi
  31. 31. Live-Demo: JavaScript IDE WebStorm http://www.jetbrains.com/webstorm/
  32. 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. 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. 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. 35. Best-Practices Refactoring JavaScript #2 4.  Typen einführen –  Google Closure Compiler –  TypeScript 5.  Keine komplexen Expressions in Templates 6.  Mächtige IDE benutzen
  36. 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. 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. 38. Nathaniel Schutta, Dienstag, 5. November 2013 16:30 bis 17:30 http://jax.de/wjax2013/node/566 The JavaScript Developer's Toolchain
  39. 39. Kai Tödter, Mittwoch, 6. November 2013 - 10:15 bis 11:15 http://jax.de/wjax2013/node/452 TypeScript: Das neue JavaScript?
  40. 40. 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
  41. 41. Vielen Dank für die Aufmerksamkeit Fragen / Diskussion Oliver Zeigermann @DJCordhose http://zeigermann.eu
  42. 42. 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
  43. 43. 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)
  44. 44. 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
  45. 45. 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
  46. 46. Automatisiertes Build und CI •  Abhängigkeitesmanagement über node / npm und bower •  Build über grunt •  Integration in Travis und Jenkins
  47. 47. Dokumentation •  JsDoc –  ähnlich wie JavaDoc •  Generiert direkt die Webseite
  48. 48. 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
  49. 49. 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) { … }
  50. 50. 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
  51. 51. Exkurs: Brauchen wir Typen? Zitat (anonymer JavaScript-Hacker): Deklarierte Typen sind für ältere Leute, die mit dynamischen Sprachen überfordert sind
  52. 52. 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
  53. 53. 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 IDEUnterstützung.
  54. 54. 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
  55. 55. 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
  56. 56. Live-Demo: Das Riesen-Projekt Angular.js •  Automatisches Build •  Automatische Tests •  Typen mit dem Closure-Compiler

×