Warum wir auf Ember.js setzen

In einer Welt, in der sich alles um Digitalisierung und die dazugehörigen Prozesse dreht, reichen einfache Websites meist nicht mehr aus. Und genau deshalb bauen wir komplette Applikationen fürs Web, die im Grunde alles Mögliche abbilden können. Von Facebook über Netflix bis hin zu internen Webtools, die Prozesse optimieren und den Mensch dahinter unterstützen.

Webapps?

Wer Facebook kennt, der weiß: umfangreiche Applikationen fürs Web sind nichts Neues. Was sich aber in den letzten Jahren durchsetzte, sind Single-Page-Applications (SPAs). Mit einer SPA passiert ein Großteil der Geschäftslogik nicht auf dem Server, sondern im Browser – und das mithilfe von JavaScript. Mit einer SPA wird zu Beginn ein einziges Bundle ausgeliefert, welchen dann z. B. einen Seitenwechsel ermöglicht, und dynamisch Inhalte nachlädt - ganz ohne das erneute Laden des Browser-Fensters. Subjektiv fühlt sich das natürlich richtig gut und vor allem schneller an. Außerdem, wer starrt schon gerne auf einen weißen Bildschirm, weil der Server die nächste Seite zuschickt? Genau, niemand.

Hey JavaScript!

Mithilfe von Javascript, einer Programmiersprache, die nativ von Browsern ausgeführt werden kann, können nun also komplette Webapps erstellt werden. #juhu

Kurzer Exkurs: den Anfang machten damals Backbone, Knockout und Angular.

Angular kam 2010 auf den Markt und gewann schnell an Nutzer:innen – nicht zuletzt, da die ganz Großen ihre Finger im Spiel haben, denn Angular wird von Google höchstpersönlich entwickelt. Kurz danach ging 2011 auch Ember.js an den Start – erst zwei Jahre später, 2013, kam Facebook mit seiner eigenen Bibliothek “React” auf den Markt. Und genau diese ist heute eine der meist genutzten Bibliotheken.

Bis heute hat Angular noch einen großen Marktanteil #dankegoogle. Trotzdem lief nicht immer alles rund. Insbesondere der Versionssprung von 1 auf 2 war heikel. Die Breaking Changes waren so umfangreich und tiefgreifend, dass sich Entwickler:innen zu der Zeit stattdessen auf andere Frameworks stürzten. Und da kommt Ember ins Spiel.

Eine Ode an Ember.

Ember als Urgestein, setzt seit jeher auf Support und priorisiert seine Nutzer. Genau da zeigt es seine Stärken. Zwar ist hier nicht die größte Community am Start, aber viele große Unternehmen wie LinkedIn oder Microsoft unterstützen das Projekt aktiv – mit Geld und/oder Entwicklung. Ember ist, ähnlich wie Angular, ein komplettes Framework mit dem Leitsatz “convention over configuration”. Durch eine vorgegebene Applikationsstruktur beschreibt es klar, welche Strukturen und Konventionen verwendet werden. So muss das Rad nicht immer neu erfunden werde und Nutzer können sich ganz easy auf das Wesentliche konzentrieren.

Das kann einschränkend erscheinen, ist aber tatsächlich eher befreiend. Sobald ein:e Entwickler:in fit in Ember ist, kann er auch in jedem Ember-Projekt eingesetzt werden, da die Projekte grob alle dieselbe Struktur nutzen. Darüber hinaus, ist nicht nur die UX ist von Bedeutung, auch eine gewisse DX (=Developer Experience) ist heute extrem wichtig: bei komplexen Anwendungen und Probleme, sollen die Werkzeuge der Entwickler:innen eine Hilfe und Unterstützung sein, nicht totale Frustration auslösen.

Daneben legt das Ember-Team großen Wert darauf, lange abwärtskompatibel zu sein (ja, das Angular Desaster sitzt tief). Heißt soviel wie: neue Versionen werden ältere Projekte nicht zerstören. Außerdem wird frühzeitig informiert, welche Features in der Zukunft nicht mehr verfügbar sein werden, wie man sich von diesen lösen kann und welche Alternativen es gibt.

All das passiert mithilfe eines CLIs, also eines Interface auf der Kommandozeile, mit dem vieles automatisiert werden kann – von der Code-Erstellung bis zur Ausführung der Test-Suite. Dieses Feature haben sich inzwischen viele andere Frameworks und Libraries abgeguckt. Im Gegenzug, schnappt auch Ember positives von anderen auf. Wer jetzt panisch an Urheberrecht und Co. denkt, keine Panik. Dieses Geben und Nehmen entspricht ganz der modernen Open-Source-Kultur.

Aus diesem Grund ist es auch völlig egal, dass Ember nicht der letzte Schrei auf dem Markt ist. Es wird aktiv weiterentwickelt und was sich etabliert, landet früher oder später auch in Ember. Natürlich ist Ember kein Silverbullet, also DIE Lösung für alles. Die Entscheidung, welches Framework wir nutzen, hängt immer ganz individuell vom Projekt ab.

Also: man kann auch einfach produktiv bleiben anstatt immer dem Hype-Train hinterher zu laufen.

Zu guter Letzt: This page is unaffiliated with the Ember project. Ember is a trademark of Tilde Inc.