Ein neues Element für HTML5: <main>

Wie sicher den Wenigsten entgangen ist, wird fleißig an einem neuen Element für HTML5 gearbeitet. Das <main>-Element soll for the identification of the main content area of a document genutzt werden und damit die bekannten HTML5-Elemente <section>, <header> und Konsorten ergänzen. Stand heute ist das Ganze eigentlich noch nichts weiter, als ein Vorschlag zur Erweiterung des bestehenden Standards, doch da weitgehend Konsens über die Einführung des neuen Elements besteht, kann man sich <main> durchaus schon genauer anschauen.

Wozu <main>?

Das neue Element bietet genau wie alle anderen neuen HTML5-Elemente zwei Dinge: zum einen ist es ein zusätzliches Sprachmittel für die Auszeichnung von Website-Teilbereichen, zum anderen hat es eingebaute ARIA-Funktionen, die wenn das neue Element korrekt benutzt wird, automatisch der Barrierefreiheit der Seite guttun. In Sachen Optik und Verhalten entspricht es genau wie <section> und Konsorten dem, was man vom guten alten <div> kennt.

Gedacht ist <main> für die Auszeichnung des jeweiligen Hauptinhalts einer Seite; im Falle eines Blogs wäre das zum Beispiel die Spalte mit allen Artikeln:

<!doctype html>
<meta charset="utf-8">
<title>Katzenbilder24.com</title>

<header>
  <h1>Katzenbilder-Blog</h1>
  <nav>
    <ul>
      <li><a href="/">Start</a></li>
      <li><a href="/about">Über</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <h2>Flauschiges Kätzchen</h2>
    <p>Text, Bild...</p>
  </article>
  <article>
    <h2>Pelziges Kätzchen</h2>
    <p>Text, Bild...</p>
  </article>
</main>

<aside>
  <section>
    <h2>Tagcloud</h2>
    <p>Tags, Tags, Tags</p>
  </section>
  <section>
    <h2>Blogroll</h2>
    <p>Links, Links, Links</p>
  </section>
</aside>

Anders als <section> hat <main> keinen Einfluss auf die Überschriftenstruktur (Outline) einer Webseite und es darf auch nicht in anderen Abschnitts-Elementen vorkommen – es soll den Hauptinhalt einer Seite markieren, nicht den Hauptinhalt eines Abschnitts der Seite. Ein korrekt verwendetes <main>-Element hat demnach keine <article>, <aside>, <footer>, <header> oder <nav>-Elemente als Vorfahren und ist das einzige Element seiner Art auf der Seite.

Als Bonus hat <main>, wie alle anderen neuen HTML5-Elemente auch, fest eingebaute ARIA-Eigenschaften. Das bedeutet im Endeffekt, dass man bei der korrekten Verwendung von <main> ohne zusätzlichen Aufwand eine zugänglichere Webseite erstellt, da das neue Element automatisch ein role="main" trägt. Dank <main> wird es in Zukunft ziemlich schwierig, diese Annotation zu vergessen.

Braucht man <main> überhaupt?

Einige haben argumentiert, dass man das neue Element gar nicht bräuchte, denn es wäre ja möglich, den Hauptinhalt einer Webseite einfach dadurch zu kennzeichnen, dass man ihn „den Rest“ sein lässt. Beispiel:

<!doctype html>
<meta charset="utf-8">
<title>Katzenbilder24.com</title>

<header>
  <h1>Katzenbilder-Blog</h1>
  <nav>
    <ul>
      <li><a href="/">Start</a></li>
      <li><a href="/about">Über</a></li>
    </ul>
  </nav>
</header>

<article>
  <h2>Flauschiges Kätzchen</h2>
  <p>Text, Bild...</p>
</article>
<article>
  <h2>Pelziges Kätzchen</h2>
  <p>Text, Bild...</p>
</article>

<aside>
  <section>
    <h2>Tagcloud</h2>
    <p>Tags, Tags, Tags</p>
  </section>
  <section>
    <h2>Blogroll</h2>
    <p>Links, Links, Links</p>
  </section>
</aside>

Auch ohne <main> ist klar, was hier der Hauptinhalt ist; alles, was nicht in <header> und <aside> steht, also die Ansammlung der Article-Elemente. Dank role-Attribut ist auch der Barrierefreiheit so viel Genüge getan, wie es mit dem neuen Element der Fall wäre. Es gibt aber vier gute Argumente, die für die Einführung des neuen Elements sprechen:

  • Ein Bereich, der der Hauptinhalt einer Webseite ist, kommt auf vergleichsweise vielen Webseiten vor. Vermutlich auf den meisten. Insofern ist es naheliegend, hierfür ein eigenes Element einzuführen, denn schließlich haben andere häufig auftretende Konstruktionen wie z.B. Navigationen ja auch ihre eigenen Elemente.
  • Aus eigener Erklärbär-Erfahrung kann ich berichten, dass HTML5-Neulinge, wenn man sie Markup schreiben lässt, fast immer den Hauptinhalt in ein Extra-Element Marke <section id="main"> kapseln. Es scheint so zu sein, dass es autorenfreundlich wäre, dafür ein passendes Werkzeug d.h. das neue Element bereitzustellen.
  • Es wäre zwar möglich, manuell role="main"-Attribute zu vergeben, aber es ist zu bezweifeln, dass das wirklich auf breiter Front passiert. Mit dem neuen Element kann das nicht mehr vergessen werden, was (korrekte Verwendung des Elements vorausgesetzt) ohne zusätzlichen Aufwand der Zugänglichkeit der Webseite guttäte – weniger Arbeit für den Autoren, mehr Spaß beim Benutzer.
  • Die HTML Design Principles sagen ganz klar: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity

Bis auf die theorietreue Sparsamkeitsfraktion würden also alle Beteiligten von der Einführung des <main>-Elements profitieren. Bleibt also nur die Frage: wann kommt die Einführung?

Welche Browser unterstützen <main>?

Zur Zeit gibt es das neue (wirklich sehr neue) Element nur als Experimental-Implementierung in Preview-Versionen von Firefox und Chrome. Das ist allerdings nicht zwingend ein Problem, da die Funktionalität von <main> händisch nachgerüstet werden kann. Vorausgesetzt der Browser verarbeitet das Element prinzipiell richtig (was alle Browser außer IE 6, 7 und 8 machen sollten), so muss es nur richtig formatiert und mit den passenden ARIA-Attributen versehen werden. Heißt also: display:block im CSS vergeben und bei der Benutzung in HTML nicht das Attribut role="main" vergessen. Dies wird zwar, sobald alle Browser das neue Element nativ unterstützen, doppelt gemoppelt sein, aber das ist, wenn überhaupt, ein Problem, dessen Lösung man sicher guten Gewissens auf diesen fernen Zeitpunkt vertagen kann.

Wie immer gilt aber, dass in Sachen HTML5-Markup keine übermäßige Eile geboten ist. Alle „alten“ Webseiten werden auch in Zukunft ohne <main> ganz wunderbar funktionieren – nur wenn ein Redesign ansteht, lohnt es sich, über den Einsatz des neuen Elements nachzudenken.

HTML 5 wird 2014 Webstandard - Was bedeutet das, was ändert sich?

Man liest, das W3C plane HTML 5.0 im vierten Quartal 2014 fertig, d.h. in einen stabilen Webstandard verwandelt zu haben. Features die sich nicht in diesen Zeitplan quetschen lassen, sollen nach HTML 5.1 verschoben werden, mit dem dann Ende 2016 zu rechnen ist. Das klingt erst mal recht unkompliziert, aber da allerorten mit dem Begriff „HTML5“ etwas unbedacht umgegangen wird (auch in dem W3C-Plandokument) ist etwas unklar, was konkret denn nun 2014 fertig sein soll. Und natürlich lohnt es sich zu fragen, welche Auswirkungen diese Erhebung zum Standard denn haben wird. Ich hatte das bereits in der letzten Folge von Working Draft aufgedröselt, aber der Vollständigkeit halber möchte ich hier nochmal aufschreiben, was es mit diesem Plan auf sich hat und was er für HTML5 zu bedeuten hat.

HTML5 oder HTML 5?

Man kann „HTML5“ entweder mit oder Leerzeichen vor der Fünf scheiben. Die Schreibweise ohne Leerzeichen ist im WHATWG-Lager usus, Freunde des W3C haben es lieber mit Leerzeichen. Die WHATWG ist, wir erinnern uns, jene Arbeitsgruppe der Browserhersteller, die ursprünglich die Entwicklung der ganzen schönen neuen Webtechnologien losgetreten hatten. Die HTML-Arbeitsgruppe des W3C befasst sich mit einem Teilaspekt der WHATWG-Spezifikationen – jenem, der sich vorrangig mit HTML5 im Sinne von HTML befasst. Von diesen beiden Arbeitsgruppen ist weiterhin der allgemeine Sprachgebrauch zu unterscheiden, der den Begriff HTML5 noch viel weiter fasst. Ein Bild sagt mehr als tausend Worte:

Grafik, die das Verhältnis von diversen Webtechnologie-Spezifikationen zueinander illustriert

Der große grüne Kreis ist die Spezifikation der WHATWG, und der große blaue Kreis innen ist die Spezifikation des W3C. Wenn man die Inhaltsverzeichnisse beider Spezifikationen vergleicht, wird der Unterschied klar: währen die WHATWG auch diverse JavaScript-APIs spezifiziert, enthält das W3C-Dokument fast nur HTML im Sinne von HTML. Das heißt aber nicht, dass das W3C sich nicht auch um die JS-Apis kümmern würde, nur ist es eben so, dass einiges, was bei der WHATWG Teil von HTML5 ist, beim W3C in einem eigenen Spezifikationsprozess bearbeitet wird (z.B. der Canvas 2D-Context bei WHATWG und W3C). Der große gelbe Kreis bildet den allgemeinen Sprachgebrauch ab, der unter HTML5 alles vereinigt, was es schönes neues im Browser gibt, von HTML-Tags bis hin zu clientseitigen Datenbanken. Das ist das, was Otto Normalverbraucher mit „HTML5“ meint.

Was wurde beschlossen (und wie schreibt man es)?

Das, was das W3C in seinem Plan für 2014 anpeilt, ist die Anfertigung eines Snapshots vom Dokument der W3C HTML-Arbeitsgruppe (großer blauer Kreis). Die Spezifikationen sollen bis Ende 2014 so weit stabilisiert werden, dass man es zur Recommendation, d.h. zu fertigen Standard erklären kann. Alle anderen Dokumente inklusive der HTML5-Spezifikationen der WHATWG sind davon nicht betroffen. Weil das W3C-Dokument sich vor allem um Parser und HTML-Tags und weniger um Browser-APIs dreht, würde dieser neue Webstandard dann auch tatsächlich eine neue Version von HTML darstellen. Dieser neue Standard hätte dann auch die Schreibweise „HTML 5“ verdient – hier wäre die 5 eine echte Versionsnummer und nicht wie bei „HTML5“ nur Teil eines Namens. Und wenn man schon wieder Versionsnummern hat, so spricht auch nichts mehr gegen Folgeversionen wie 5.1 und weiteres.

Es wäre natürlich praktisch, wenn sich die Welt darauf einigen könnte, die Schreibweise „HTML5“ für die Buzzword-Bedeutung der neuen Technologien zu reservieren und „HTML 5“ bzw. „HTML 5.0“ für die W3C-Spezifikationen zu verwenden (das W3C wirft beides in seinem Plan-Dokument wild durcheinander). So würde uns einerseits der liebgewonnene Oberbegriff erhalten bleiben, andererseits könnte man über die nächste Version einer Auszeichnungssprache sprechen (oder eher schreiben), ohne sich dem Verdacht auszusetzen, ein JavaScript-Supernerd oder gar ein überhypter Nichtsblicker zu sein. Ob es soweit kommt, wird die Zeit zeigen, aber ich werde dieses System auf jeden Fall in Zukunft verwenden.

Dokumente und Recommendations hin oder her: was ändert sich denn nun durch die Standardisierung einer neuen HTML-Version? Eigentlich nichts.

Was sind die Auswirkungen?

Webstandards sind praktisch immer deskriptiv und nicht normativ. Eine Technologie wird nicht zum Standard, indem das W3C sie aufschreibt und folgsame Browserhersteller sie implementieren, sondern es läuft fast immer umgekehrt. Die Programmierer von Browser A erfinden ein neues Feature, die Programmierer von Browser B implementieren etwas ähnliches, man einigt sich auf einen einheitlichen Kompromiss und das W3C schreibt das Endergebnis auf. Somit dürfte klar sein, dass in dem fertigen Standard nichts drin stehen wird, was neu ist, sondern er wird die dann bestehende Browser-Realität abbilden und für die Zukunft festschreiben.

Für Webentwickler gibt es also eigentlich nichts, was sich im Q4 2014 ändert. Falls auch dann jemand noch den Internet Explorer 8 unterstützen muss (Gott bewahre!), so wird er sich nichts davon kaufen können, dass es eine Recommendation für <section> gibt, denn dieses Feature wird der IE8 auch 2014 nicht unterstützen. Auch wird die Standardisierung von HTML 5.0 nicht das Ende des zur Zeit chaotischen Entwicklungsmodells oder des allgemein „unfertigen“ Eindrucks der Web-Plattform bedeuten. Zwar wird dann einiges in Browsern möglich sein, was heute nur in Chrome-Nightlies funktioniert, doch dafür werden sich die Browser-Programmierer bis dahin neue Features ausgedacht haben, über deren Nichtfunktionieren wir uns dann aufregen können.

Wenn also aus „HTML5“ demnächst „HTML 5.0“ wird und es mit dem Recommendation-Stempel versehen wird, heißt es also aus der Perspektive der Webentwickler mal wieder: Raider heißt jetzt Twix … sonst ändert sich nix.

Fragen zu HTML5 & Co beantwortet 8 – CORS, Z-Index, Drag & Drop, Default-Styles

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:

dropziel.ondragover = function(evt){
    evt.preventDefault();
};

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.

TypeScript (Teil 2/2): die Einordnung

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:

  1. Der Einsatz von TypeScript steht vor keiner großen Hürde
  2. 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.

Folgt mir!

Kauft mein Zeug!

Cover der HTML5-DVD
Infos auf html5-dvd.de, kaufen bei Amazon

Cover des HTML5-Buchs
Infos auf html5-buch.de, kaufen bei Amazon

Cover des CSS3-Buchs
Infos auf css3-buch.de, kaufen bei Amazon