JavaScript für Java-Entwickler W-JAX 2013

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

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

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

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

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

Vorurteil:
Es gibt keinen vernünftigen
IDE-Support für JavaScript
Zitat (anonymer JavaScriptEntwickler):
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-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

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 IDEUnterstü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

JavaScript für Java-Entwickler W-JAX 2013

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a JavaScript für Java-Entwickler W-JAX 2013

Similar a JavaScript für Java-Entwickler W-JAX 2013 (20)

JavaScript für Java-Entwickler W-JAX 2013