senäh

17senäh und so…

Web Components

HTML/CSS/JS
10. Jun 2013
Kommentare: 5

Die Wahl des richtigen Web GUI Frameworks

Kategorien: HTML/CSS/JS | 10. Jun 2013 | Kommentare: 5

Das letzte Jahr war für JavaScript-Entwickler sicherlich eines der produktivsten. Es war überfüllt mit Reviews zu MVC- und GUI-Frameworks, welche nahezu täglich aus dem Boden sprießen. GUI-Frameworks sind bei mir auf der Arbeit ebenfalls ein heißes Thema. Wir planen unsere alte GUI-Architektur zu modernisieren und diese Umsetzung unterliegt einer strengen Evaluierung. Dies ist generell kein leichtes Unterfangen und wird durch einen großen Faktor beeinflusst: wir haben einen klassischen Java Enterprise Hintergrund!

Erwartet von mir heute nicht das 100. JS-Framework-Review. Besucht dafür andere Quellen. Wenn ihr aber Interesse am klassischen Konflikt Gut gegen Böse,  Server- gegen Clientarchitektur, statische gegen dynamische Typisierung und Frameworks gegen Webstandards habt, dann lest unbedingt weiter. Vielleicht erwartet euch am Ende die ein oder andere Erkenntnis und ein Blick in die Zukunft!

Der Underdog

Seit ich programmiere scheine ich mich in der Rolle des Underdogs wiederzufinden. Jemand, der von echten Programmierern nicht so richtig wahrgenommen wird. Zuerst lerne ich programmieren auf der sterbenden Flash-Plattform, welche nur für Klicki-Bunti bekannt ist, und anschließend spezialisiere ich mich auf eine dynamisch typisierte und klassenlose Sprache. (Ihr wisst welche ich meine…)

Aus meiner Laufbahn heraus habe ich zudem mit vielen eher kleinen prototypischen Projekten Erfahrungen gemacht. Summa summarum bin ich aber immer mit meinen Entscheidungen erfolgreich gewesen. Was Projekte angeht bin ich deswegen stark parteiisch, da ich…

  • nicht von Altlasten abhänge
  • deswegen keinen Kontakt zum (Java-)Backend habe
  • deswegen keine Abhängigkeiten zu Eclipse und Co besitze
  • release early, release often bevorzuge 1
  • kleine Projekten bevorzuge 2
  • im Web- und nicht der Enterpriseentwicklung zu Hause bin
  • naiv bin 3

1 Dadurch bevorzuge ich u.a. lieber einen extra Bugfix zu schieben und programmiere schneller dynamisch typisiert, als mir den Bugfix zu sparen und langsamer statisch typisiert zu programmieren. Neben release early, release often  bin ich auch Fan der Regel choose the right tool for the right job. Da ich häufig an Prototypen arbeite, hat Schnelligkeit hier eine höhere Priorität als bspw. Codestabilität. Im umgekehrten Fall ist statisch typisiertes programmieren möglicherweise zu bevorzugen. Nichtsdestotrotz habe ich eine weit geringere – sprich gar keine – Ablehnung gegenüber dynamisch typisierten programmieren, einfach weil ich es gewohnt bin. Und nur der Vollständigkeitshalber: Neben Stabilität hat Typisierung auch viele andere Vorteile wie bessere code completion, auf die ich hier nicht weiter eingehe, da ich nur klar machen wollte, dass ich kein Feind des typenlosen oder dynamisch typisierten Programmierens bin.

2 Wenn jemand bspw. behauptet ein Framework wäre für ein Projekt nicht geeignet, weil es zu groß sei, frage ich mich erst, ob die Größe des Projektes nicht das eigentlich Problem ist und es in zwei oder mehr kleinere Projekte zerteilt werden müsste, anstatt ein anderes Framework zu nehmen. Generell halte ich die Größe eines Projektes in vielen Belangen für den eigentlichen Ursprung vieler Probleme. Passend zu release early, release often halte ich refactoring für einen integralen kontinuierlichen Bestandteil der Softwareentwicklung und nicht für einen notwendigen Schritt bei einem 5 Jahre alten Projekt. Nennt mich blauäugig, aber wenn ich während der Arbeit an einem Projekt an einem Punkt gelange an dem ich sage „Ein Refactoring würde jetzt aber sehr aufwendig werden.“, dann sollte man sofort mit der Implementation neuer Features aufhören und die alte Codebasis aufräumen, ggf. das Projekt splitten. Das sollte meiner Meinung nach eine Notbremse sein, die jeder Entwickler nach eigenem Ermessen ziehen darf. Es wäre bspw. super, wenn ein Entwickler einen Epos bei JIRA auf den Status Refactoring setzen könnte und die Bearbeitung anderer Tickets zur Implementation neuer Features wäre für das Marketing strikt gesperrt.

3 Ein Entwickler, der mit JavaScript arbeitet? So einer kann nur naiv sein! ;)

All diese Faktoren führen dazu, dass ich in meiner Rolle des Underdogs extreme Meinungen annehmen kann, welche sich teilweise stark vom gängigen Meinungsbild unterscheiden. (Break points? Tss… in 99% der Fälle reicht mir ein console.log!) Dies mag auf keinen Fall die bessere Meinung sein, dient aber der Diskussion.

Wenn ihr mit dem Obengenannten nicht übereinstimmt, den warne ich ein letztes Mal vor: Wer weiter liest, der liest auf eine Gefahr! Aber vor Gefahr habt ihr doch keine Angst oder? Ich wollte nur klarstellen, dass ich jetzt nicht immer in Fußnoten auf Vor- oder Nachteile meines Vorgehens eingehe, sondern dieses einfach in den Raum stelle. Damit möchte ich den Lesefluss nicht unnötig erschweren. Bevor ihr sagt „Der spinnt doch!“ hinterlasst also einen Kommentar und fragt nach ;)

Früher war alles schlechter

Ich werde hier jetzt keine tiefgreifende Geschichte über die Entstehung des Internets aufschreiben. Ihr wisst alle, dass das Internet früher nur statische Inhalte darstellte. Eine Internetseite zeigte nur Text und Bilder an und besaß keine größere Logik. Es war technisch nicht möglich komplexe Logik in eine Webseite einzubauen – dafür war JavaScript viel zu langsam. Ebenso waren Browser zu langsam für komplexe Layouts. Zur Darstellung von einfachem Text und einfachen Bildern bedarf es nicht viel, weswegen sich die HTML und CSS Standards nur langsam entwickelten. Zuständig dafür ist die W3C, welche Webtechnologien standardisiert. Anstatt an neuen Features für HTML zu arbeiten, schlug man sich viele Jahre damit herum zu entscheiden, ob es <br> oder doch eher <br /> heißen muss. Ein zusätzliches Problem waren die Nachwehen des ersten browser wars in welchem jeder Browserhersteller (insbesondere Microsoft mit dem IE) nicht-standardisierte Features in ihre Browser eingebaut haben.

internetz

internetz

Hier kommen die ersten Frameworks ins Spiel. Entworfen von Webentwicklern, die mehr mit ihren Internetseiten machen wollten. Dazu gehörten vor allem serverseitige Frameworks (z.B. basierend auf PHP oder Java), um Internetseiten dynamisch zu generieren, Layouts zu modularisieren (<?php include 'header.php'; ?>), etc. Serverseitig deswegen, weil man clientseitig ja nicht viel machen konnte.

Erst mit der Entwicklung von jQuery kam Bewegung ins Frontend. jQuery vereinfachte das Handling mit dem DOM und vereinheitlichte unterschiedliche Browser-APIs. Ajax ermöglichte das Nachladen von Inhalten ohne Aktualisierung des Browserfensters. jQuery wurde indes so populär, dass man sich jQuery-Entwickler schimpfte, aber manchmal keine Ahnung von JavaScript hatte oder wusste wo der Unterschied lag. (Ein ähnliches Verhältnis hatte Ruby on rails teilweise zu Ruby.) So gibt es immer wieder Entwickler, die mit jQuery.delay Dinge ausführen wollen, die man eigentlich ganz simpel nativ mit setTimeout machen würde – ohne Abhängigkeiten zu einem Framework. (Und diese Verwirrung ist absolut berechtigt – so habe ich auch angefangen!)
Die Popularität von jQuery war Fluch und Segen zugleich. Frontend-Entwicklung wurde endlich ernst genommen, da sie weniger kompliziert war und über verschiedene Browser hinweg funktionierte. Auf der anderen Seite war plötzlich alles jQuery, obwohl es eigentlich JavaScript war.

Nun wurde u.a. mit der Einführung von Chrome ein neuer browser war entfacht, welcher sich dieses Mal aber etwas anders gestaltete. So waren im zweiten browser war Standardisierung und Schnelligkeit die ausschlaggebenen Verkaufsargumente und nicht Spezialisierung und Abgrenzung. JavaScript wurde durch V8 sehr viel schneller und konnte für komplexere Logiken verwendet werden. Dummerweise konnte niemand mehr JavaScript, sonder nur noch jQuery ;) Und schon musste jQuery für Dinge herhalten, für die es nie konzipiert wurde: Applikationsarchitekturen abbilden. Würg.
Das Resultat ist unglaublicher Spaghetticode…

Aber um einen Schlusssatz zu finden: Webseiten wurde auch clientseitig dynamisch und aus Webseiten wurden Webapplikationen.

Aus Webseiten wurden Webapplikationen

Google mischte das Web gehörig auf. Nicht nur das Chrome und V8 komplexe Webapps zuließen und die Konkurrenz unter Druck setzten, sie zeigten mit eigenen Diensten wie Gmail auch wie eine gute Webapp auszusehen hat. Und da Google nicht direkt mit Chrome Geld verdient, sondern damit möglichst viele Menschen ins Web und auf ihre Dienste zu locken versuchen sie mit Hochdruck das Web weiterzuentwickeln und zu standardisieren. Dies stimmt mit den Zielen von Mozilla überein – nur das Mozilla aus sozialen Motiven handelt, nicht wirtschaftlichen -, wodurch sich eine gewisse Eigendynamik entwickelte. Chrome wurde beliebter und Mozillas Firefox verlor Anteile, also versuchte man bei Mozilla Dinge die Chrome auszeichneten (regelmäßige Auto-Updates!) ebenfalls zu übernehmen, um seinen eigenen Browser wieder attraktiver zu machen.
Schon gab es zwei Browser, welche viel Wert auf Standards und schnelle iterative Entwicklung legten und damit sehr erfolgreich waren. Safari, Opera und IE gerieten in Zugzwang!

Welche Auswirkungen hatte das auf Webstandards? Für die Browserhersteller verlief die Standardisierung seitens der W3C zu langsam und sie wollten sich nicht am Streit HTML vs. XHTML beteiligen. Deswegen gründeten sie 2004 – also bereits vor der Erstveröffentlichung von Chrome – eine eigene inoffizielle Standardisierungsinstitution namens WHATWG, um den HTML-Standard voranzutreiben. Das Ende der Geschichte kennen wir: HTML5 wurde geboren. Die W3C musste sich eingestehen, dass ihr Weg der falsche war und übernahm 2008 kurzerhand den Entwurf von WHATWG. Mittlerweile haben beide Institutionen ihre Arbeitsweise etwas angepasst, um schneller Ergebnisse zu erzielen. Die WHATWG verzichtet mittlerweile komplett auf eine Versionierung von HTML. Damit wird es nie eine Art HTML6 geben. Stattdessen spricht WHATWG vom HTML Living Standard. Die W3C wiederum arbeitet mit vielen kleinen einzelnen Spezifikation1, welche unabhängig von einander weiter entwickelt werden. (Sie haben gelernt, dass große Projekte in kleine Projekte unterteilt werden müssen. ;))
Nur der Vollständigkeit halber: Die CSS Spezifikationen gehen einen ähnlichen Weg.

Aber noch etwas hat sich verändert. Die W3C hat erkannt, dass sie das aktive Feedback der Webentwickler braucht. Es war Webentwicklern vorher schon möglich sich am W3C-Standardisierungsprozess zu beteiligen, aber jetzt sucht die W3C von sich aus Feedback. So beteiligen sich eben jene, denen wir die eingangs erwähnten Frameworks verdanken, am Standardisierungsprozess.2 Und: Die W3C ist sich bewusst, dass aus den ehemaligen einfachen Webseiten komplexe Webapplikationen wurden.3

1, 2, 3 Summa summarum: Mittlerweile gibt es bspw. eine eigene Spezifikation/ein eigenes Gremium zur Untersuchung der Webapplikationsarchitektur (Technical Architecture Group), in welchem u.a. Yehuda Katz (Ember.js, Ruby on Rails, jQuery…) sitzt. Diese versucht auch die Koordination mit der TC93, der Standardisierungsinstitution von JavaScript, zu verbessern.

Was nehmen wir aus diesem Artikel mit? Webstandards werden schneller, werden mit Rücksicht auf Entwickler und Browserhersteller und in Hinblick auf komplexe Applikationen hin entwickelt.

Ihr habt noch nicht genug Argumente? IE10 ist extrem standardkonform (keine conditional comments, etc.) und IE11 wird vermutlich noch standardkonformer (WebGL?!), Opera basiert jetzt auf Chromes Rendering Engine Blink, Mozilla hat ein komplettes Betriebssystem basierend auf offenen App-orientierten Web APIsentwickelt, Windows und damit IE erhalten einen ~1jährlichen Updatezyklus anstatt den vorigen ~3jährlichen, wie es mit Safari weitergeht werden wir wohl heute auf der WWDC erfahren, hört was Yehuda Katz innerhalb der W3C umsetzen will

Ich brauche die Standards aber sofort!

Ja ja, schon gut. Keiner kann auf den IE11 warten und wir plagen uns immer noch (teilweise) mit IE7 herum, also müssen wir weiter jQuery nutzen. Falsch! Es kommt auf die richtige Philosophie an. Wie bereits erwähnt wird jQuery heute meiner Meinung nach häufig falsch eingesetzt. Es wurde entwickelt, um DOM Manipulationen, Queries und andere notwendige Features wie AJAX zu vereinfachen und über verschiedene Browser hinweg zu vereinheitlichen. Ich weiß ich wiederhole mich…

Aber: Dafür brauchen wir jQuery nicht mehr. Wir nutzen jQuery nur noch, weil wir an dessen API gewöhnt sind. Anstatt jQuery('.myClass') können wir mittlerweile document.querySelector('.myClass') nutzen, anstatt $element1.append($element2) geht element1.append(element2)! Siehe auchDOM4.

Jetzt höre ich euch wieder sagen „Aber element1.append(element2) funktioniert nicht im IE7! Dafür brauchen wir jQuery!„. Klar, dass würde gehen. Aber wer sagt, ob jQuery in 10 Jahren noch relevant ist, wenn wir heutzutage mit jQuery schon so viel Spaghetticode produzieren. Die W3C Spezifikation wird da mit größerer Wahrscheinlichkeit noch Relevanz haben. Die Alternative heißen polyfills! Zum Beispiel der DOM4 polyfillPolyfills bringen – soweit technisch möglich – neue standardisierte APIs in alte Browser.

Vorteile: keine Framework Abhängigkeiten, kein großer Wartungsaufwand, mehr Sicherheit und Stabilität, zukunftssicherer…

Wir wissen ja wie das ist, wenn man sich auf ein Framework versteift, eine riesen Codeabhängigkeit dazu entwickelt und wenn das Framework veraltet ist, dann finden wir keine neuen Entwickler mehr, die sich damit auseinander setzen möchten und können. Wenn Entwickler jetzt JavaScript-Entwicklung neu lernen und dadurch Frameworks wie Ember.js, AngularJS und Co. kennen lernen, dann brauchen sie nicht mehr zwangsläufig jQuery. Es ist jetzt Zeit sich von jQuery zu trennen!

Aber halt! Choose the right tool for the right job! Es gibt immer noch Dinge, die jQuery extrem gut macht und besser als der offizielle Standard. Zum Beispiel $.ajax. Wenn ihr nicht gerade ein anderes Framework wie Angular benutzt, ist es durchaus sinnvoll für Ajax auf jQuery zu setzen. Aber wenn ihr nur einen Teil von jQuery nutzt, dann integriert auch nur diesen Teil. Dies ist seit kurzem durch custom builds möglich.

Ist das nicht widersprüchlich? Auf der einen Seite sage ich davon Abhängigkeiten zu jQuery zu verringern und auf der anderen Seite erwähne ich die Nutzung von Angular und anderen Frameworks?

?

?

Die Wahl des richtigen Frameworks

Frameworks haben immer noch ihre Daseinsberechtigung! Nicht alles kann mit vanilla JavaScript und plain HTML/CSS erledigt werden. Gott bewahre! Ich wollte nur klarstellen, dass sich die Anforderungen an clientseitige Frameworks stark verändert haben und das diese mitunter serverseite Frameworks ersetzen können. Unsere heutigen Anforderungen an Frameworks sind andere als die, die wir früher hatten als jQuery entstand. Als Beispiel sei two-way data binding genannt. Deswegen benötigen wir neue spezielle dafür entworfene Frameworks, anstatt jQuery dafür zurecht zu biegen.

Neue clienseitige GUI Frameworks gibt es wie Sand am Meer. Ich habe drei davon intensiver getestet: Sencha/Ext, Ember, Angular. Jedes hat Vor- und Nachteile und am Ende bin ich bei Angular gelandet und – nach meinem jetzigen Wissensstand – empfehle ich jedem die Nutzung von Angular. Es gibt Dinge an Angular, die ich mag und sehr spezifisch sind (dependency injection), aber um die geht es hier nicht. Der Hauptgrund, warum ich Angular empfehle, ist ein ganz anderer.

Und jetzt kommt der Punkt an dem wir weise werden, an dem wir aus unseren Fehlern lernen, an dem es plötzlich (hoffentlich!) Sinn macht, dass ich euch so eine ewig lange Herleitung geschrieben habe. ;)

wisdom - I haz it

wisdom – I haz it

Angular hat eine ganz besondere Philosophie. Angular wurde unter der Vorstellung entwickelt, wie das Web aussehen würde, wäre es von Anfang an für Applikationen und nicht Dokumente designt. D.h., dass Angular sehr nah an Browserstandards arbeitet und vornehmlich Features implementiert, welche so in naher Zukunft nativ im Browser sein könnten.
Außerdem versucht Angular nicht unbedingt Dinge in den Client zu holen, die dort nicht hingehören. Angular setzt sehr auf das REST Pattern und holt seine Daten als JSON über eine REST-API. Genauso behandelt Angular seine Models – als simple JavaScript Objekte! (Ein kurzer Vergleich: In Angular ist var model = {}; ein Model, in Ember ist App.Model = DS.Model.extend(); ein Model.) Bei anderen aktuellen MVC Frameworks wie Ember befindet sich viel Logik im Model. Viel Logik, welche ohnehin noch einmal auf dem Server gespiegelt ist (Validierung, etc.). Diesen Weg geht Angular nicht… Natürlich möchte trotzdem in einem Inputfeld bspw. bei der Eingabe der PLZ den Benutzer auf max. 5-stellige Zahlen beschränken. Wie würde man das mit Angular machen? Mit Angular selbst gar nicht, stattdessen würde man zum standardisierten pattern Attribut greifen! (Polyfill gefällig?)

Das ist generell eine schöne Grundeinstellung und Angular-Entwickler sind bestimmt nicht die ersten, die so denken, aber entscheidend ist, dass Google hinter Angular steht und Angular-Entwickler direkt Feedback zur Entwicklung neuer Standards geben können bzw. vermutlich interne Details zu verschiedenen Spezifikationen kennen.
Natürlich wird Angular in seiner jetzigen Form nicht nativ im Browser laufen. Soll es auch gar nicht! Es gibt wie eingangs erwähnt sehr spezifische Angular-Features wie dependency injection. Aber viele andere Features werden nicht nur irgendwann standardisiert werden, sie werden genau jetzt standardisiert!

In Angular kann man eigene HTML Elemente erstellen → wie auch in der Custom HTML Spezifikationbeschrieben. Das Markup hinter diesen Element ist manipulierbar → wie bei der Shadow DOM Spezifikation. Angular nennt das Directives → die W3C Web Components. Partials bei Angular → ganz ähnlich zur HTML Imports Spezifikation. Templates in Angular sind im Vergleich zu allen anderen JS-MVC-Frameworks nicht String-basiert, sondern bauen komplett auf den DOM auf! Konfigurationen arbeiten designerfreundlich deklarativ, anstatt imperativ.

Wer Angular lernt, lernt nicht einfach nur irgendein Framework, sondern bereitet sich bestmöglich auf zukünftige Standards vor! Angular kann sofort produktiv eingesetzt werden! Kein warten auf zukünftige Standards. Es befindet sich seit 2009 in Entwicklung und ist schon lange stabil genug für den Produktiveinsatz.

Die Zukunft: Web Components

Wo man Angular immer noch als Framework ansieht – es gibt eine MVC Architektur vor, etc. -, geht dasPolymer Projekt von Goole noch weiter. Es versucht die oben genannten Spezifikationen und noch weiter möglichst nahe an der standardisierten API mit jetzigen Mitteln zu implementieren. Man spricht hier von einem forward polyfill. Dies ist noch sehr experimentell und man muss beachten, dass sich die Spezifikationen noch in Entwicklung befinden und ändern können und dem entsprechend Änderungen bei Polymer hervorrufen. Angular abstrahiert hier die standardisierte API zu einer eigenen. So wie jQuery() bspw. document.querySelector() abstrahiert, geht auch Angular vor, wohingegen Polymer näher an der Browserimplementation sitzt. (Der Vollständigkeit halber: Polymer arbeitet in mehreren Schichten und es gibt auch eine abstrahierende Schicht um Polymer eher wie ein Framework zu nutzen. Die unterste Schicht arbeitet jedoch als forward polyfill.)

So wie Angular ~drei Jahre für die Entwicklung gebraucht hat, muss auch Polymer noch reifen. Es kann aber gut sein, dass man in drei Jahren komplett auf Polymer umsteigen möchte – oder auf Framework XYZ. Der Umstieg von Angular zu Polymer oder etwas ähnlichem würde aber definitiv leichter werden als von Ember zu Polymer oder einem serverseitigen Framework zu irgendetwas anderem. Es ist sogar möglich bei Frameworks kombiniert zu benutzen: Architektur und data binding von Angular, Komponenten für die View von Polymer.

Will man denn überhaupt die W3C Standards verwenden anstatt einem komplett anders aufgebauten, aber guten Framework? Ja, man will! Falls ihr mal eine ruhige Minute habt, schaut euch die aktuellen Einführungsvideos zu Web Components an (12).
Shadow DOM liefert bspw. echte Markup und Style Kapselung! Damit sind echte Widgets möglich. Ihr kennt <video controls></video>. Platziert man dieses Element im HTML, dann zeigt der Browser ein Video an und der Browser fügt Steuerungen zum Anhalten/Abspielen/etc. ein. Diese Steuerung ist nix anderes als ein Shadow DOM, welcher intern vom Browser genutzt wird! Aus <video controls></video>  wird intern etwas wie <video><div><button id="play">Play</button></div></video>. Mit Shadow DOM kann so etwas nun jeder Entwickler umsetzen.
Ich sehe hier zum Beispiel Einsatzzwecke für Widgets in Backends wie die Metaboxen bei WordPress. Wenn diese einheitlich angezeigt werden sollen, dann ist Shadow DOM perfekt, da die Styles im Shadow DOM gekapselt sein können und – zumindest wenn man dies wünscht – von außen nicht überschreibbar sind. Packt man das ganze in einen HTML Import, dann kann man eigene Buttons und Formular Elemente in allen Bereichen von Mercateo verwenden und der Design hat Style und Markup komplett in der Hand, aber nicht den Inhalt! Wenn man irgendetwas am Style ändert, muss man nur die Datei ändern, auf die HTML Import verweist und man muss nichts an den Stellen ändert, an denen die Elemente eingesetzt werden.

Schlussfolgerung

Die Wahl des Frameworks sollte heutzutage sehr viel zukunftsorientierter ausfallen, als noch vor einigen Jahren, da die Entwicklung der Webstandards schneller voranschreitet. Die Entwicklung von der HTML4 Recommendation zur HTML5 Recommendation dauert(e) von 1997 bis voraussichtlich 2014. Ich lehne mich mal aus dem Fenster und behaupte so etwas wird es nicht noch einmal geben. Stichwort: HTML Living Standard, mehrere kleine Spezifikation, etc. Gleichzeitig werden viele Aufgaben für die ein Entwickler früher ein Framework benötigt hat mittlerweile durch native Funktionen abgelöst.

Selbst wenn ein Framework eine bestimmte Aufgabe etwas schöner löst als es die native Implementation macht, sollte man sich zweimal überlegen, ob man diese schönere Lösung gegen ein feste Abhängigkeit zum Framework eintauschen möchte.

Nun habe ich einen Fakt bisher außen vor gelassen: Die Wahl eines serverseitigen Frameworks ermöglicht die Nutzung anderer Technologien als auf der Clientseite, was ein gutes Argument für die Nutzung dieser darstellen kann. Dies stellt jedoch wieder eine gewisse Barriere dar, da man eine komplett andere Sprache einführt. Der Erfolg von Node zeigt bspw. wie schön es ist die Anzahl an Technologien zu verringern (- mit Node spart man sich bspw. Apache und PHP ein und arbeitet mit der „gleichen“ Technologie wie im Client). Warum möchte man aber eventuell nicht Clienttechnologien nutzen? Was JavaScript angeht, so sind viele vom dynamisch typisierten und schlechten modularen Arbeiten abgeschreckt. Dies ist ein Diskussionspunkt für sich und einen ebenso langen Artikel wie diesen Wert. Sind dies aber wirklich Ausschlusskriterien für JavaScript, dann gibt es meiner Meinung nach nur eine Lösung: TypeScript.
TypeScript ist ein superset zu JavaScript. Jeder JS Code ist valider TS Code und bestehender JS Code kann so problemlos in TS weiterverwendet werden. Der Vorteil von TypeScript ist die Einführung von statischen Typen im compile Schritt – danach erhält man wieder sehr leserlichen JS Code. Die Vorteile liegen auf der Hand: schnelle Migration von, aber auch wieder zurück zu JS durch bekannte Syntax – und trotzdem typisiertes Arbeiten mit allen Vorzügen wie code completion. IDE? WebStorm! Andere Alternativen wie Dart sind meiner Meinung nach schon wieder zu weit weg von JavaScript. Denn – man mag es kaum glauben – auch TypeScript ist extrem standardorientiert. Während das Typensystem eine Eigenentwicklung ist, sind viele andere Vorteile von TypeScript wie bspw. das Modulsystem nichts anderes als eine Vorschau auf den kommenden JavaScript Standard. Wenn man es so formulieren möchte, ist TypeScript in vielen Bereichen ein forward polyfill für den nächsten JavaScript Standard.

Nur als kleiner Gedanke: Wenn man auf eine zusätzliche Sprache wie TypeScript setzen möchte, weil einem dynamisch typisiertes JavaScript nicht gefällt, warum setzt man dann nicht analog auch auf eine zusätzliche Sprache wie Jade um Nesting-Fehlern im HTML vorzubeugen? Oder konsequent auf Less/Sass/Stylus anstatt CSS? (Nur das ihr mich nicht falsch versteht: Ich bin großer Fan von Jade und Less/Sass/Stylus. Ich möchte nur zeigen, dass man nur zu einer anderen Sprachen greifen sollte, weil man ihre Features braucht und nicht weil man ihre Features gewohnt ist.)

Und wer weiß, ob JavaScript in seiner übernächsten Version nicht Typen erhält…? Zumindest eine Alternative zu Typen könnte seinen Weg in JS finden…

Jetzt heißt es nur noch – immer schön auf dem Laufenden bleiben. Das ist leichter gesagt als getan, da sich die Standards so rapide entwickeln. Hier hilft eventuell der Artikel How to keep up to date on front-end technologies?, welcher genau diese Frage zu beantworten versucht!

Und selbst? Mit welcher Strategie fahrt ihr so?

Autor: Pipo

...kommt ursprünglich aus der Designerecke, ist aber im Laufe seines Studiums in die Webentwicklung gestolpert. Kann sich seit dem nicht so richtig entscheiden wo er hingehört und wagt deswegen vielleicht die Flucht nach vorne in ein komplett neues Gebiet. Vielleicht Management? Niemand weiß es. Auch er nicht.

Kommentare (5)

  1. Meine Gedanken niedergeschrieben. Good job!
    Ich entschied mich nach langer Überlegung ebenfalls aus folgendem Grund für Angular: Google.
    Zu wissen, dass Google solch ein Projekt finanziell und mit professionellen Entwicklern unterstützt, sorgt bei mir für immenes Vertrauen.
    Bei neuen Frameworks gibt’s dann immer die Kinderkrankheiten und man muss irgendwie „rumtricksen“. Man googelt nach einer Lösung und findet:
    http://www.bennadel.com/blog/2441-Nested-Views-Routing-And-Deep-Linking-With-AngularJS.htm
    und gleichzeitig:
    http://jan.varwig.org/archive/how-to-do-nested-views-in-angularjs-hint-dont
    Was ich damit sagen möchte: Früher gab es HTML und CSS und das war’s. Da gab es so gut wie keine Entscheidungen zu treffen. Heute muss man Entscheidungen treffen, kann diese selber selten direkt erarbeiten, wodurch man googelt. Und dann ist man schon wieder schlauer und dümmer zugleich. Man überlegt das Projekt doch wieder anders anzugehen.
    Daraus folgt, was mir am meisten Sorgen bereitet: Die Zukunft und die rasante Entwicklung. Was lernt man heute für morgen? Widmet man sich noch weiter PHP? Gibt man Node.js eine Chance? Muss man sich Ruby ansehen? Das gleiche gilt für die zahlreichen Frameworks für die Sprachen….
    Kurz: Heute ein größeres Projekt (einfach) anzufangen ist nicht einfach!

  2. Schon einmal vielen Dank, dass du dich durch diesen langen Artikel gewühlt hast ;)

     

    „Heute muss man Entscheidungen treffen, kann diese selber selten direkt erarbeiten.“ Das ist ein wirklich großes Problem durch die schiere Menge an Frameworks. Ich hatte eingangs bereits  einen Link zu TodoMVC versteckt, deren Ziel es ist möglichst viele verschiedene MVC Frameworks zu testen und zu vergleichen. Nun ist die Wahl des MVC Frameworks ja nicht die einzige technische Frage, die man sich stellen muss. Die Jungs und Mädels hinter TodoMVC haben deswegen ein neues Projekt namens TasteJS, welches noch komplett in den Kinderschuhen steckt. Dort wollen sie analog zu TodoMVC viele verschiedene Frameworks für komplexere Probleme (Authentication, Backend, etc.) testen und vergleichen. Da bin ich schon sehr gespannt drauf. Das könnte einen so einiges an Arbeit abnehmen.

  3. Wer sich für ein 2D WebGL Framework interessiert, ich baue es derzeit für ein Spiel in Kombination mit pixi.js, es ist nicht nur für Spielobjekte sondern dann auch fürs Userinterface mit Window/Layoutmanager, Interaktionsmanager bringt pixi.js der wird noch etwas optimierter eingebunden usw …. hab erst gestern mit den richtigen Frameworkklassen angefangen, nachdem ich eine relative brauchbare Testimplementation für UI-Fenster gemacht hatte.
    https://github.com/mctteam/mct/tree/934446c7ac6a77a1b291f2794c15e69c97803cf4/lib/MCT (Framework Ordner)
    https://github.com/mctteam/mct/blob/934446c7ac6a77a1b291f2794c15e69c97803cf4/lib/display/window.js (Window Builder)

  4. Pingback: Die Geschichte der CSS-Konventionen und mein aktueller Workflow | senäh