Es hat etwas gedauert, aber ich habe wieder vier Fragen und Antworten zu HTML5, CSS3 und Konsorten für euch zusammengekratzt. Warum kriege ich in letzter Zeit so wenig Fragen? Ihr wisst doch: eine E-Mail oder ein Tweet genügen!
How to CORS?
Ich möchte einen XMLHttpRequest an eine API machen, von der ich einen JSON-String abfragen werde. Wie bekomme ich das hin, dass ich keine Probleme mit Cross-Domain bekomme?
Normalerweise werden durch die Same-Origin-Policy (also durch den Browser) Zugriffe unterbunden, die von einer Webseite aus auf eine andere Webseite mit andere Domain unternommen werden. Die Technologie um das zu ändern heißt Cross-Origin Resource Sharing (CORS) und wird bereits von vielen Bowsern unterstützt. Um sie zu aktivieren muss man aber am Server Hand anlegen und einen speziellen Header verschicken – enable-cors.org erklärt wie das geht. Möchte man auch alte Internet Explorer mitschleifen, braucht man neben dem normalen Ajax-Code auch das IE-spezifische XDomainRequest-Objekt. Genaueres dazu weiß das CORS-Tutorial von HTML5 Rocks.
Z-Index und Opacity
Ich bin gerade mit dem nachlesen der siebten Fragerunde zu HTML5 und Co auf deinem Blog fertig geworden. Zum Thema, Transformation und z-Index war ich sehr verwundert, konnte mich aber an ein ähnliches Problem erinnern. Ich habe einfach mal die transformation-Anweisungen durch eine opacity-Angabe ersetzt. Siehe da ich habe das selbe Problem. Frage nun: ist es aus dem selben Grund? Gibts sowohl für die eine oder andere einen Workaround?
Ja, das ist in der Tat ganz ähnlich. Die Mechanik hinter Transformationen und Opacity ist fast die gleiche: die Kindelemente eines betroffenen Elements werden mit dem Elternelement zusammengerendert und nur dieses Gesamtwerk wird transformiert bzw. von Opacity-Effekt betroffen. Zitat Spezifikationen:
Conceptually, after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering [...] Since an element with opacity less than 1 is composited from a single offscreen image, content outside of it cannot be layered in z-order between pieces of content inside of it. For the same reason, implementations must create a new stacking context for
any element with opacity less than 1. If an element with opacity less than 1 is not positioned, implementations must paint the layer it
creates, within its parent stacking context, at the same stacking order that would be used if it were a positioned element with
z-index:0 and opacity:1.
Von einem Workaround ist mir nichts bekannt. Das Außer-Kontext-Rendern ist offenbar ein unumgängliches Funktionsprinzip von Transformationen und Opacity.
Drag & Drop – kein Drop-Event im Firefox
Hast du eine Idee, wieso das Drop-Event von HTML5 Drag & Drop im Firefox nicht gefeuert wird? In Chrome funktioniert es ohne Probleme.
Kurze Antwort: das Problem lässt sich lösen, indem man das dragover-Event abfängt und mit preventDefault() abbricht, in etwa so:
Lange Antwort: während einer Drag-Operation feuert eine ganze Menge Events und viele von denen muss man, wenn man die API verwenden möchte, einfach abbrechen, damit andere Events funktionieren. Das klingt erst mal verquer, hat aber schon so seinen Sinn. Es sollen schließlich die meisten Elemente in einer Seite keine Ziele für Drag & Drop sein und es ist ganz sinnvoll, auf diesen gar nicht erst drop-Events zuzulassen. Um ein Element zum potenziellen Ziel zu machen muss daher zunächst das dragover-Event abgebrochen werden.
Warum das neuerdings in Chrome nicht mehr nötig ist, darüber kann ich nur spekulieren. Entweder ist das ein Bug oder die Chrome-Entwickler finden ganz einfach diese Event-Abbrechen-um-Events-stattfinden-zu-lassen-Geschichte so blöde, dass sie sich bewusst dagegen entscheiden. Ich würde ihnen daraus auch keinen übergroßen Vorwurf stricken, denn die API ist im Originalzustand einfach zu bekloppt.
Wo stehen die Default-Styles?
Gibt es irgendwo eine Übersicht, welches Default-Styling für welche HTML5-Elemente existiert?
Diese Übersicht gibt es praktischerweise direkt in den HTML5-Spezifikationen. HTML5 hat den Anspruch, neben Tags und Attributen auch das ganze im Browser befindliche Drumherum zu spezifizieren – von URL-Parsern über Download-Algorithmen bis hin zu DOM-Features ist alles dabei. Und da dürfen die Default-Styles natürlich nicht fehlen.
Weitere Fragen?
Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.
Wie wir gesehen haben, ist TypeScript nichts weiter als eine JavaScript-Erweiterung, die ein statisches Typsystem sowie Klassen und einige andere Features aus der näheren ECMAScript-Zukunft mit sich bringt. Das Release von TS kann man zum Anlass nehmen, um eine ganze Reihe von Fragen aufzuwerfen. Braucht man sowas? Wird sich das durchsetzen? Und warum macht sich Microsoft die Mühe? Die Beantwortung dieser Fragen ist natürlich zu einem gewissen Grad Kaffeesatzleserei, aber ich glaube ich habe eine halbwegs originelle Idee zu dem Ganzen. Also an die Arbeit!
Ist Typescript überhaupt ernst zu nehmen?
Die wichtigste Frage vorweg: hat Typescript überhaupt die Chance, jemals etwas anderes zu werden als ein Dart-artiges Ghetto? Aus zwei Gründen möchte ich das nicht ausschließen:
Der Einsatz von TypeScript steht vor keiner großen Hürde
Ich vermute, dass es eine echte Nachfrage nach den Features von TS gibt
Der erste Punkt ist ziemlich offensichtlich. Während Dart das Ziel hat, irgendwann eine eigene Laufzeitumgebung in jedem Browser zu haben (was nie passieren wird) und bis dahin JavaScript als Krücke benutzt, ist bei TypeScript das Endziel JavaScript selbst. Der Vergleich hinkt also ziemlich. Wie wir gesehen haben, produziert der TS-Compiler schönes normales JS, das in jedem Browser läuft und das man so ähnlich auch von Hand schreiben würde. Die Idee, mit TypeScript ein Programm zu schreiben, ist also erst mal nicht wesentlich verrückter, als das gleiche mit CoffeeScript zu machen. Und das ist immerhin die elftpopulärste Sprache auf Github. Dem Einsatz steht also an sich nichts im Wege.
Das mit der Nachfrage ist etwas komplizierter. Zwar bin ich selbst schon der Meinung, dass man als Webentwickler diesen ganzen Typsystem-Krams und auch einige ES6-Features nicht wirklich braucht, aber ich weiß auch, dass es da draußen sehr sehr viele Entwickler gibt, die das ganz anders sehen.
Webentwickler sind vom Mars, C#-Entwickler von der Venus
Als ich vor zwei Jahren angefangen habe, den HTML5-Erklärbären zu spielen, durfte ich vor allem Webentwicklern und -Designern die Wunder von HTML5 erklären. Mittlerweile habe ich vor allem das Vergnügen mit „normalen“ Softwareentwicklern, die ganzen Tag lang Java oder C# schreiben … und die stammen aus einem ganz anderen Universum als der durchschnittliche JS-Ninja.
Das Arbeitsgerät des typischen (Frontend-) Webentwicklers ist ein Texteditor, wahlweise nerdig (Vim, Ecmacs) oder etwas stylisher (Sublime Text, TextMate) aber eben ein Texteditor. Außerhalb von Frontend-Kreisen wird so etwas als vielleicht zum Schreiben von Einkaufszetteln geeignet angesehen, aber zum Programmieren nimmt man doch bitte eine richtig dicke IDE mit integriertem Debugger und toller Autovervollständigung und Refactoring-Tools und und und. Ein Frontend-Nerd erwartet von seinen Zielplattformen (Browsern) gar nicht erst, dass sie sich einheitlich oder überhaupt berechenbar verhalten und jongliert entsprechend mit einen ganzen Reihe von Workarounds, Polyfill-Scripten oder speziellen Techniken wie Progressive Enhancement oder Responsive Design. Ist man das nicht gewohnt, bekommt man sehr schnell den Eindruck, es herrsche einfach nur absolutes Chaos, verglichen mit z.B. der heilen Silverlight-Welt, in der alles (Sprache, API, IDE, Dokumentation) aus einer Hand kommt und entsprechend aufeinander abgestimmt ist. Während der Frontend-Entwickler so etwas wie $() für eine komplett ausreichende API hält, fragen sich andere, wie sie denn von diesem Ding eine Klasse ableiten können. Und zu guter letzt sind außerhalb der Webentwickler-Welt viele Dinge rund um Softwareentwicklung quasi-standardisiert. Man arbeitet objektorientiert (d.h. mit Klassen) in entweder Java, C# oder etwas, das den beiden eher ähnlich ist. Jedenfalls arbeitet man nicht mit so einem komischen Scheme-Abkömmling wie JavaScript oder so einem komplett eigenen Dingens wie CSS.
Es besteht einfach ein gewisser kultureller Unterschied. Und TypeScript ist, würde ich behaupten, Microsofts Versuch, dem Otto Normalsoftwareentwickler das Thema Webentwicklung bekömmlicher zu gestalten, den kulturellen Graben etwas überbrückbarer zu machen. Irgend etwas in der Richtung musste man bei Microsoft machen, denn bisher geriet die Kommunikation zum Thema HTML5 (und damit Webentwicklung) äußerst unglücklich.
Die Kommunikation Microsofts zu HTML5 und TypeScript
Wie wir ja alle wissen ist HTML5 das nächste große Ding. Das erzählen jedenfalls alle und auch Mircosoft hat fleißig an der Hypemaschine mitgekurbelt. So erklärte man 2011 HTML5 und JavaScript zu „first class citizens“ von Windows 8, kündigte für die Zukunft einen pluginfreien IE an und überhaupt sei HTML5 ja das nächste große Ding. Das alles mag ja soweit auch stimmen, was allerdings als Botschaft bei vielen Entwicklern angekommen ist, ist: bald gibt es auf Windows nur noch HTML5. Das wird so extrem sicher nicht der Fall sein, aber das ist eben das, was viele verstanden haben. Ich weiß das, weil die, die das so verstehen (oder deren Chefs es so verstehen) am Ende bei mir am Telefon oder im HTML5-Seminar auftauchen.
Diese Entwickler sehen sich dann, wenn sie zum ersten Mal so richtig mit Frontend-Entwicklung in Kontakt kommen, einem ganzen Haufen von Unglaublichkeiten ausgesetzt:
Nichts funktioniert in allen Browsern (und schon gar nicht HTML5)
Es gibt keine Tools und keine (mit der Realität in näherer Verbindung stehende) Dokumentation von „offizieller Seite“. Nicht mal eine definitive „offizielle Seite“ gibt es!
Die einzige zur Verfügung stehende Programmiersprache ist ein verbuggter Scheme-Abkömmling
Essentials wie Modulsysteme oder eine brauchbare DOM-API müssen mit komischen Open-Source-Libraries hingewürgt werden
Wenn man glaubte, in die goldene Zukunft aufzubrechen und sich stattdessen erst mal mit diesen Problemen konfrontiert sieht, fragt man sich natürlich, ob man da nicht gewaltig verschaukelt wurde. Damit kann man vielleicht einen News-Ticker scripten, aber eine richtige Webapp bauen, das kann doch gar nicht funktionieren! Natürlich kann das funktionieren und wenn es der Zeitplan hergibt, demonstriere ich das auch immer mit Erfolg, doch die Gelegenheit bietet sich eben nicht immer. Und dann gibt es Ärger. Und ich schätze mal, dass Microsoft selbst noch sehr häufiger Ärger abbekommt als ich.
Der Unmut entsteht nicht, weil die Web-Plattform/HTML5 zu nicht taugt, sondern weil der Problemkomplex Web-Frontend ein eigenes Universum darstellt – und wenn man darauf nicht vorbereitet ist, wird es eben schwer. Diese „Vorbereitung“ könnte einerseits natürlich darin bestehen, althergebrachte Vorstellungen und Herangehensweisen über Bord zu werfen und viel neues zu lernen … oder wenn der Berg nicht zum Propheten kommt, kommt eben der Prophet zum Berg. Heißt in diesem Fall: statisches Typsystem, Klassen und Module kommen nach JavaScript.
TypeScript wird von MS als „application scale“ betitelt, weil es „application scale“ für viele Entwickler einfach vorstellbarer macht. Braucht man als alteingesessener JavaScript-Ninja diese Vorstellbarmachung nicht mehr, braucht man TypeScript auch nicht.
Braucht man das Typsystem von Typescript? Braucht man die ES6-Features?
Nein, aber wie wir gesehen haben, geht es auch nicht darum. Ziel ist vielmehr, allen Entwicklern, die nicht auf der Web-Ecke kommen, einen gemütlicheren Zugang zur Webentwicklung zu verschaffen. TypeScript ist ein recht eleganter Weg, auf eigene Faust Dinge wie Klassen und ein statisches Typsystem umzusetzten und trotzdem ein Endprodukt zu schaffen (kompliliertes JavaScript) das sich wunderbar in die offene Web-Plattform einfügt.
Im Detail kann man natürlich darüber streiten, ob die Features von TS jetzt wirklich alle total überflüssig sind. Je nachdem wie man drauf ist, sind Klassen und native Module auch JS-Ninjas schon ganz wünschenswert oder total überflüssig. Vermutlich würden aber trotzdem die wenigsten freiwillig mit einem Entwickler zusammenarbeiten, der ohne seinen Babysitter-Compiler seine Datentypen nicht unter Kontrolle bringt. Das alles unterstelle ich jetzt einfach mal – wiedersprecht mir in den Kommentaren wenn ihr es anders seht.
Aber wenn jemand glaubt, Klassen, statische Typen und eine IDE wären eine total absolut unverhandelbare Grundvoraussetzung um vernünftig („application scale“) zu entwickeln, dann ist TypeScript sicher etwas, das ihm ein besseres Gefühl gibt. Und genau das scheint mir das Ziel zu sein, eine angenehmere Umgebung für Besucher aus dem anderen Universum.
Fazit
So wie ich das sehe, soll TypeScript alle jenen das Leben erleichtern die aus anderen Universen in den Webfrontend-Bereich vordringen. Dass hier unterstützende Maßnahmen durchaus gefordert sind, kann ich bestätigen und daher kann ich mir auch gut vorstellen, dass TypeScript eine rege Nutzerschaft finden wird. Ob nun eine eigene Extra-Programmiersprache die bestmögliche Hilfestellung ist, würde ich mal offen lassen. Theoretisch könnte eine Inflation an Projekten wie TypeScript die JavaScript-Welt fragmentieren und vielleicht wäre das ungut. Und an sich könnte man selbst als kulturgeschockter Entwickler schauen, wie denn der Rest der Welt mit der Webplattform klarkommt, statt es sich im vertrauteren TypeScript gemütlich zu machen. Könnte!
Ich persönlich habe jedenfalls nicht das Gefühl, TypeScript zu brauchen. Aber da es ja auch nicht für mich gemacht ist und nicht meine Probleme zu lösen versucht, passt das schon.
Microsoft hat TypeScript veröffentlicht, laut offizieller Ansage eine Programmiersprache for application-scale JavaScript development. Meiner Wahrnehmung nach wurde TypeScript in der Webentwickler-Welt mit einer gewissen Skepsis aufgenommen, was ich spontan durchaus nachvollziehbar finde – immerhin ist es eine Technologie für das Web von Microsoft und das kollektive Gedächtnis der Webentwickler vergisst kleine Sünden wie den IE6 und andere Untaten nicht so schnell.
Aber da ich es in meinen HTML5-Seminaren immer öfter mit Entwicklern aus der Microsoft-Ecke zu tun habe, komme ich nicht umhin, mir TypeScript mal vorurteilsfrei reinzuziehen, denn irgendwer wird bestimmt mal danach fragen. Das Reinziehen ist gar nicht mal so trivial, denn leider versteckt die die offizielle Webseite viele nützliche Informationen zugunsten von eher Marketing-fokussierter Prosa (auf deren Inhalt sich dann auch die meisten der hämischen Kommentare beziehen). Ich habe es aber trotzdem mal anhand der Specs versucht. In diesem ersten Teil will ich versuchen, die wichtigsten Fakten rund um TypeScript herauszuarbeiten, mein Kommentar zu dem Ganzen folgt dann in einem zweiten Artikel.
Was ist TypeScript?
TypeScript ist ein Superset von JavaScript – jedes gültige JavaScript-Programm ist auch ein (syntaktisch) gültiges TypeScript-Programm. Die Erweiterungen von TS werden vom Compiler in stinknormales JavaScript umgewandelt, so dass man TypeScript mit jedem Browser der Welt oder auch mit Node.js benutzen kann, solange man es vorher kompiliert. Der Vergleich mit Googles ungleich ambitionierterem Dart ist also weniger zutreffend als z.B. mit CoffeeScript. Bei Dart ist die JavaScript-Kompilierung nur eine Krücke, bei TypeScript das Endziel.
Die Features, die TypeScript neu einführt, fallen in zwei Kategorien: einerseits gibt es ein optionales Typsystem, andererseits sind mehrere Funktionen aus ECMAScript 6 übernommen worden. Das Typsystem erlaubt es, Variablen fest einen Typ zuzuweisen. Diese Information können Compiler und IDEs benutzen, um Fehler zu schmeißen bzw. bessere Autovervollständigung anzubieten. Die ES6-Features ermöglichen es, so zu programmieren, als sei der neue JavaScript-Standard (bzw. Teile davon) bereits fertig und in allen Browsern zu finden. Das Endprodukt ist trotz all dieser Features immer komplett normales JS, so wie man es auch händisch schreiben würde. Selbst wenn man volles Rohr auf TS-Features setzt …
class Auto {
private kilometer: number = 0;
constructor(public modell, public baujahr){}
public fahren(km: number){
this.kilometer += km;
}
public getKilometer(){
return this.kilometer;
}
}
interface Fahrzeug {
modell: string;
baujahr: number;
getKilometer: () => {};
}
var karre = new Auto('VW Käfer', 1984);
karre.fahren(20);
function describe(auto: Fahrzeug) {
return "Ein " + auto.baujahr + "er " + auto.modell +
" mit " + auto.getKilometer() + "km auf der Uhr";
}
… ist das Endprodukt so normales JavaScript, dass es selbst im IE6 laufen würde:
var Auto = (function () {
function Auto(modell, baujahr) {
this.modell = modell;
this.baujahr = baujahr;
this.kilometer = 0;
}
Auto.prototype.fahren = function (km) {
this.kilometer += km;
};
Auto.prototype.getKilometer = function () {
return this.kilometer;
};
return Auto;
})();
var karre = new Auto('VW Käfer', 1984);
karre.fahren(20);
function describe(auto) {
return "Ein " + auto.baujahr + "er " + auto.modell + " mit " + auto.getKilometer() + "km auf der Uhr";
}
Was also ist Typescript? Es ist kein Dart, sondern eigentlich nur ein JavaScript-Dialekt, dessen Compiler ein Typsystem und einen ES6-Transpiler implementiert und dessen Endprodukt stinknormales JavaScript ist.
How to Typescript
Der TypeScript-Compiler ist (natürlich) in TypeScript geschrieben und fluppt daher in jeder handelsüblichen JavaScript-Umgebung. Als Open-Source-Software (Apache License) lässt sich das gute Stück entweder über CodePlex (eine Art Github für MS) oder via npm install -g typescript in Node.js beschaffen. Die Datei foo.ts kompiliert man dann durch den Aufruf tsc foo.ts und erhält dafür die Datei foo.js.
JavaScript ist eine Sprache mit einem schwachen, dynamischen Typsystem. Das lässt sich komödiantisch ausschlachten (ab 01:20), hat aber primär den Effekt, dass ein JS-Programmierer dem Interpreter weder vorbeten muss, welche Datentypen gewisse Objekte haben noch sich manuell um deren ggf. nötige Umwandlung kümmern muss. Die JS-Engine erkennt die Art der verwendeten Datentypen selbstständig (Duck Typing) und wenn zwei Objekte unterschiedlichen Typs aufeinander treffen, wird einer der beiden Unfallgegner automatisch konvertiert:
// Das sieht wie ein String aus
var s = "Hallo Welt";
// Das sieht wie eine Zahl aus
var n = 1337;
// String plus Zahl geht nicht, also wird die Zahl
// gemäß der JS-Regeln vor der Operation umgewandelt
var x = s + n; // Ergibt den String "Hallo Welt1337"
Dieses Feature lässt allerdings nicht wenigen Programmieren die Haare zu Berge stehen. Einerseits befürchten sie, dass bei versehentlichen Typumwandlungen schwer zu diagnostizierende Bugs entstehen und sie hätten es lieber, wenn bei der Kollision zweier Typen ein Fehler gemeldet wird. Andererseits soll ein dynamisches Typsystem auch die Entwicklung von IDEs mit intelligenter Autovervollständigung und anderen fortschrittlichen Funktionen schwerer machen. Als Antwort auf diese Bedenken führt TypeScript ein statisches Typsystem ein, das alle Wünsche der Haare-zu-Berge-Fraktion erfüllt.
In TypeScript-Code kann bei Variablen angegeben werden, welchen Typ sie haben sollen:
// Ein String
var s: string = "Hallo Welt";
// Eine Zahl
var n: number = 1337;
Diese Typannotationen sind optional. Fehlen sie, findet der TS-Compiler selbst heraus, welchen Datentyp ein Objekt hat (Typinferenz). Sinn des Ganzen ist, dass Tools (und Entwickler) sofort erkennen können, welche Sorte von Objekt in einer Variable vorkommen sollte und der Compiler kann Alarm schlagen, wenn diese Regeln mißachtet werden:
// Der Compiler meldet: "Cannot convert 'number' to 'string'"
var s: string;
s = 42;
// Der Compiler meldet: "Supplied parameters do not match any signature of call target"
function sagHallo(name: string){
return "Hallo " + name;
}
sagHallo(42);
Das Ganze funktioniert einerseits mit den aus JS bekannten Primitiven (String, Number usw.), kann aber auch auf Objekte angewendet werden. So lässt sich zum Beispiel ein Array definieren, das nur Strings enthalten darf:
var arr: string[] = [];
Für Eigenbau-Objekte lässt sich ein Interface definieren, dass festlegt, wie ein Objekt aufgebaut sein muss:
Auch Funktionen können als Typ angegeben werden … mitsamt der Argumente, die die Funktion übergeben bekommen soll. Das erscheint besonders bei Callbacks sinnvoll:
function fireCb(callback: (i: number) => {}){
for(var i = 0; i < 5; i++){
callback(i);
}
}
// Klappt
fireCb(function(i){
console.log(i);
});
// Klappt nicht, da das Argument "foo" nicht gewünscht ist
// Supplied parameters do not match any signature of call target:
// Call signatures of types '(i: any,foo: any) => any' and '(i: number) => {}' are incompatible:
// Call signature expects 1 or fewer parameters
fireCb(function(i, foo){
console.log(i);
});
In diesem Code fällt der etwas befremdlich aussehende Schnipsel (i: number) => {} ins Auge. Dabei handelt es sich um eine neue Schreibweise für Funktionen, die in ECMAScript 6 eingeführt werden soll und die in Typescript bereits unterstützt wird.
Die ES6-Features
ECMAScript 6 ist die kommende Ausbaustufe von JavaScript (zu der ich rein zufällig eine Artikelserie parat habe) und befindet sich in einem Zustand höchster Unfertigkeit. Ungeachtet dessen gibt es bereits einige Programme, die ES6-Code in heute schon funktionierendes JavaScript übersetzen – die sogenannten Transpiler. Auch in TypeScript steckt ein solcher Transpiler und manches ES6-Feature kann hier schon benutzt werden.
Die etwas komisch aussehende Funktionssystax entspringt (das ist kein Witz) primär dem Wunsch, nicht mehr das lange Wort function ausschreiben zu müssen. Und wenn man schon dabei ist, könnte man die neue Form doch auch gleich mit einem besonderen Scope-Binding ausstatten. So ging man also hin, borgte sich von CoffeeScript den fat arrow und schon war man fertig:
var fn = () => {
console.log(this.foo);
};
// Entspricht (und kompiliert in TypeScript zu):
var _this = this;
var fn = function () {
console.log(_this.foo);
};
Ebenfalls in ES6 geplant und in Typescript umgesetzt ist ein Klassensystem, das zwar recht simpel ist, aber grundsätzlich alles an Bord hat, was man so erwarten würde:
class Auto {
private kilometer: number = 0;
constructor(public modell: string, public baujahr: number){}
public fahren(km: number){
this.kilometer += km;
}
public getKilometer(){
return this.kilometer;
}
}
var karre = new Auto('VW Käfer', 1984);
karre.fahren(20);
var tacho = karre.getKilometer(); // 20
Der Code, den der Typescript-Compiler hieraus erzeugt, ist eine relativ simple Constructorfunktion nebst Prototype, bei dem die private-Properties nicht besonders (z.b. durch Closure-Versteckspiele) geschützt sind:
var Auto = (function () {
function Auto(modell, baujahr) {
this.modell = modell;
this.baujahr = baujahr;
this.kilometer = 0;
}
Auto.prototype.fahren = function (km) {
this.kilometer += km;
};
Auto.prototype.getKilometer = function () {
return this.kilometer;
};
return Auto;
})();
Allein der Compiler verhindert, dass ein direkter Zugriff auf private Objekte wie karre.kilometer erfolgt.
Wer Klassen haben will, möchte diese vermutlich auch in Modulen organisieren natürlich haben ES6 und TypeScript entsprechende Funktionalität an Bord:
// modul.ts
export class Auto {
private kilometer: number = 0;
constructor(public modell: string, public baujahr: number){}
public fahren(km: number){
this.kilometer += km;
}
public getKilometer(){
return this.kilometer;
}
}
// main.ts
import fahrzeug = module("modul");
var karre = new fahrzeug.Auto('VW Auto', 1984);
karre.fahren(20);
Der Compiler baut aus modul.ts wahlweise CommonJS-Module für den Einsatz in Node.js und anderen serverseitigen Umgebungen …
var Auto = (function () {
function Auto(modell, baujahr) {
this.modell = modell;
this.baujahr = baujahr;
this.kilometer = 0;
}
Auto.prototype.fahren = function (km) {
this.kilometer += km;
};
Auto.prototype.getKilometer = function () {
return this.kilometer;
};
return Auto;
})();
exports.Auto = Auto;
… oder AMD-Module für RequireJS und Konsorten:
define(["require", "exports"], function(require, exports) {
var Auto = (function () {
function Auto(modell, baujahr) {
this.modell = modell;
this.baujahr = baujahr;
this.kilometer = 0;
}
Auto.prototype.fahren = function (km) {
this.kilometer += km;
};
Auto.prototype.getKilometer = function () {
return this.kilometer;
};
return Auto;
})();
exports.Auto = Auto;
});
Wenn eines Tages ES6-Module wie geplant Einzug in die JavaScript-Engines dieser Welt finden, wird diese Übersetzung dann vermutlich überflüssig.
Fazit
Zusammengefasst ist TypeScript also ein JavaScript-Superset, das JS um Features aus der ECMAScript-Zukunft sowie ein eigenes Typsystem erweitert. Da all diese Features ausschließlich im Compiler stattfinden und das Endprodukt normales JavaScript ist, sind keine Browser-Updates oder Polyfill-Scripts nötig um mit TS loszulegen.
Die Preisfrage ist nun: braucht man das? Wenn ja, wer braucht das? Will man das überhaupt in der JavaScript-Welt herumgeistern sehen? Und wird TypeScript eine Nutzerschaft finden oder in der Bedeutungslosigkeit versinken? Meine Meinung dazu gibt es die Tage in Teil 2.
Ich bin die nächsten Wochen und Monate fast durchgehend auf Achse und das Gute daran ist: das meiste ist öffentlich! Wenn ihr euch mal original druckbetanken lassen möchtet, habe ich folgende Termine im Angebot:
11. - 13. September in München: HTML5-Camp. Drei mal 12 Stunden HTML5 am Tag. Wenn ihr meint, dass ihr das aushaltet, könnte das Camp was für euch sein. Das Programm auf der Webseite ist nicht meins, sondern das von den anderen Nasen die da auch Trainings machen. Ich mache lieber 2 Tage Programm on demand vor Ort mit abschließendem Workshop-Tag. Das Ganze findet nochmal vom 19. bis zum 21. November statt.
19. September in Hamburg: HTML5-Workshop bei der WebDev Con. Falls ihr wissen wollt, wie man mit Libraries, Frameworks viel HTML5 in kurzer Zeit eine kleine Grafikbearbeitungs-Webapp baut, seid ihr hier richtig. Es sind nicht mehr viele Plätze frei!
8. - 10. Oktober in München: HTML5-Schulung bei der Open Source School. Mein bewährtes dreitägiges HTML5-Standardprogramm stattet die Teilnehmer im Druckbetankungsverfahren mit so gut wie allem aus, was man zu HTML5 wissen muss. Von semantischem Markup bis hin zu Canvas-Frameworks ist alles dabei. Geboten wird ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch gibt es obendrein. Nächster folgender Termin ist der 5. - 9. November.
11. und 12. Oktober in München: CSS3 bei der Open Source School. Mein zweitägiges CSS3-Standardprogramm katapultiert die Teilnehmer in das CSS3-Zeitalter, in dem Webfonts und Farbverläufe fließen. Einen großer Praxisanteil, kleine Arbeitsgruppen und ein Buch als Bonus gibt es auch hier. Nächster folgender Termin ist der 10. und 11. November.
