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
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
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.
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
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...
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;
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. 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. Vorurteil:
Es gibt keinen vernünftigen
IDE-Support für JavaScript
Zitat (anonymer JavaScriptEntwickler):
Die beste JavaScript-IDE ist vi
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
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 2013 16:30 bis 17:30
http://jax.de/wjax2013/node/566
The JavaScript Developer's Toolchain
39. Kai Tödter, Mittwoch, 6. November 2013 - 10:15 bis
11:15
http://jax.de/wjax2013/node/452
TypeScript: Das neue JavaScript?
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.
42. Vielen Dank für die
Aufmerksamkeit
Fragen / Diskussion
Oliver Zeigermann
@DJCordhose
http://zeigermann.eu
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 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
47. Automatisiertes Build und CI
• Abhängigkeitesmanagement über
node / npm und bower
• Build über grunt
• Integration in Travis und Jenkins
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
/**
* @description Converts the specified string to
lowercase.
*
* @param {string} string String to be converted
to lowercase.
* @returns {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 IDEUnterstü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