Lassen Sie uns ein Missverständnis gleich zu Beginn ausräumen. Elm wird oft als Liebhabersprache für Entwickler abgetan – als eine Kuriosität der funktionalen Programmierung für Leute, die so etwas mögen. Diese Sichtweise verkennt jedoch das Wesentliche für jeden, der ein Produkt verantwortet. Die Zuverlässigkeit des Front-ends ist in erster Linie ein geschäftliches Problem, erst in zweiter Linie ein technisches.
Wenn eine Weboberfläche in der Produktion einen Laufzeitfehler verursacht, kommt die Rechnung nicht in Form eines dramatischen Ausfalls. Sie tröpfelt herein. Support-Tickets, Notfall-Fixes, verschobene Releases, QA-Stunden, die damit verbracht werden, einen Fehler zu jagen, den der Compiler hätte abfangen können, bevor das Produkt ausgeliefert wurde. Bei einem großen JavaScript-Front-end zieht sich dieses Tröpfeln über Jahre hin. Eine stille Steuer auf die Entwicklungsgeschwindigkeit.
Wägen wir also die Programmiersprache Elm so ab, wie Sie jede andere Investition bewerten würden: Was bringt sie Ihnen, was kostet sie, wie sieht der Weg dorthin aus und wo passt sie hinein? Teams, die Elm einsetzen, berichten meist von denselben drei Dingen: Weniger Bugs. Weniger Vorfälle in der Produktion. Weniger Zeitaufwand für QA-Prozesse, die nur dazu dienen, Abstürze abzufangen.
Elm ist ein Framework und eine typisierte funktionale Programmiersprache für das Frontend. Funktionale Programmierung bedeutet vereinfacht gesagt, dass Software durch die Kombination reiner Funktionen entsteht: kleine Einheiten, deren Ausgabe ausschließlich von den Eingabewerten abhängt und die im Hintergrund keine unerwarteten Änderungen vornehmen. Elm orientiert sich an Haskell, lässt jedoch die komplizierten Aspekte weg und bleibt nah an dem, was JavaScript-Entwickler bereits kennen.
Es wird zu JavaScript kompiliert und läuft in jedem Browser. Was es besonders macht, ist die Kombination aus einem statischen Typsystem, bei dem der Compiler jeden Wert prüft, bevor der Code veröffentlicht wird, und einer Laufzeitumgebung, die Seiteneffekte im Hintergrund für dich verwaltet. Zusammen garantieren sie Sicherheit, die in JavaScript sonst von Disziplin und Testabdeckung abhängt. Falls dein Team bereits mit Redux gearbeitet hat, wird dir das Konzept bekannt vorkommen: Redux hat sich stark bei Elm bedient, nicht umgekehrt (diese Herkunft beleuchten wir in unserem Artikel über React Hooks vs. Redux).
Die gesamte Philosophie geht auf den Schöpfer von Elm, Evan Czaplicki, und seinen Vortrag Let's be mainstreamzurück. Er entwickelte die Sprache für eine bestimmte Zielgruppe: den praktizierenden JavaScript-Entwickler. Sein Rat: „Vergiss alles, was du über funktionale Programmierung gehört hast“ – all das Fachchinesisch und die Theorie – und behalte nur die Aspekte bei, die die tägliche Arbeit zuverlässiger machen.
Vergessen wir für einen Moment die Eleganz. Die entscheidende Frage für Sie ist, ob Elm die Kennzahlen verbessert, für die Sie tatsächlich geradestehen: Vorfallrate, QS-Aufwand, Einarbeitungszeit und die laufenden Kosten für den Betrieb eines Frontends, das mit dem Unternehmen wächst. Drei Effekte erzielen hier die Wirkung.
Elm ist so konzipiert, dass es keine Laufzeitfehler gibt. Ein Team bei NoRedInk betrieb ein Elm-System mit 100.000 Zeilen Code in der Produktion mit null Laufzeitfehlern seit 2015. Diese Zahl stammt nicht von den Entwicklern der Sprache, sondern von einem Engineering-Team, das auf der QCon in London über seine eigenen Ergebnisse berichtete.
In einer JavaScript-Codebasis existiert ein Großteil der Tests aus einem einzigen Grund: um sicherzustellen, dass das System bei fehlerhaften Eingaben oder fehlenden Daten nicht abstürzt. Elm überträgt diese Aufgabe an den Compiler. Das Team von Pivotal Tracker beschrieb diesen Wechsel als Übergang von testgetriebener Entwicklung zu einer Methode, die sie typgetriebene Entwicklung nannten – eine ganze Kategorie von Tests muss schlichtweg nicht mehr geschrieben oder gewartet werden.
Da Elm seine eigenen Konventionen durchsetzt, bleibt eine Codebasis, an der über Jahre hinweg ein Dutzend Entwickler gearbeitet haben, konsistent. Teams berichten davon, wie sie ein Elm-Projekt nach Jahren wieder öffnen und feststellen, dass es immer noch problemlos kompiliert und läuft. Jeder, der schon einmal versucht hat, einen JavaScript-Abhängigkeitsbaum wieder zum Leben zu erwecken, weiß, wie selten das ist und wie direkt sich dies auf technische Schulden.
Sie müssen das alles nicht einfach glauben. Erstellen Sie eine Basislinie. Notieren Sie vor einem Pilotprojekt zwei Kennzahlen für das betreffende Modul: die Anzahl der Frontend-Laufzeitfehler pro Monat und die QS-Stunden, die für jeden Release anfallen, um die Stabilität der Schnittstelle zu prüfen. Führen Sie ein begrenztes Pilotprojekt in Elm durch. Vergleichen Sie die Ergebnisse. Die öffentlichen Zahlen geben Ihnen eine Vorstellung vom Potenzial – null Laufzeitfehler bei 100.000 Zeilen bei NoRedInk, Einarbeitungszeiten von wenigen Tagen bei Pivotal Tracker –, aber es ist Ihr eigener Vorher-Nachher-Vergleich, der einen Finanzdirektor überzeugen wird.
Bei Imaginary Cloud entwickeln wir Front-End- und Integrationssoftware für Unternehmen. Nach 16 Jahren zeigt sich ein Muster immer wieder: Fehler im Front-End liegen selten an einem schlechten Framework. Sie entstehen, wenn Schnittstellen ohne ein klares Verständnis der Menschen und Systeme entwickelt werden, die sie nutzen sollen. Eine sicherere Sprache hilft zwar, aber nur, wenn die Entscheidung für sie bewusst getroffen wurde.
Wenn uns ein Kunde also fragt, ob er Technologien wie Elm einsetzen sollte, prüfen wir dies anhand von drei Fragen. Nennen wir es die Perspektive von Zuverlässigkeit, Passgenauigkeit und Veränderungskosten.
Elm schneidet bei der Zuverlässigkeit gut ab, bei der Passgenauigkeit mittelmäßig und erfordert eine sorgfältige Betrachtung der Veränderungskosten. Der Rest dieses Artikels geht auf jeden dieser Punkte ein.
Sicherheit ist das zentrale Versprechen von Elm. Sie basiert auf einem Typsystem mit drei Konsequenzen, die sich direkt in der Produktion bemerkbar machen: keine Laufzeitfehler, keine Null-Werte und eine zwingende Behandlung aller Fälle in Kontrollstrukturen.
Die meisten Sprachen betrachten Fehler als integriertes Feature: Exceptions, Errors, Try-and-Catch. Elm bietet nichts davon. Stattdessen ist die Möglichkeit eines Fehlers direkt in den Typen verankert, die eine Funktion zurückgibt. Etwas, das möglicherweise keinen Wert liefert, gibt ein Maybe (entweder „etwas“ oder „nichts“) oder ein Result (entweder Erfolg oder eine beschriebene Fehlermeldung) zurück, und der Compiler verweigert das Kompilieren, solange Ihr Code nicht beide Möglichkeiten abdeckt. Fehler werden so zu etwas, das man einplant – und nicht zu etwas, das einen um 2 Uhr morgens überrascht.
Derselbe Mechanismus sorgt dafür, dass Elm auf Null-Werte verzichtet. Es gibt kein „null“ in der Sprache, daher gibt es auch keine Null-Referenz-Fehler – die häufigste Ursache für Abstürze in gängigen Programmiersprachen. Stellen Sie sich „null“ wie eine offene Falltür in einem Boden vor, über den alle laufen; früher oder später fällt jemand hindurch. Tony Hoare, der 1965 die Null-Referenz in eine Sprache einführte, bezeichnete dies später als seinen „Milliarden-Dollar-Fehler“ und gab zu, er habe einfachder Versuchung nicht widerstehen können, eine Null-Referenz einzubauen“. Elm vernagelt diese Falltür: Wenn ein Wert fehlen könnte, gibt der Typ dies an, und der Compiler zwingt Sie dazu, diesen Fall zu behandeln.
Elm ist eine rein funktionale Sprache, daher muss jeder Zweig einer Bedingung einen Wert zurückgeben, und jeder case muss jede mögliche Eingabe abdecken. Wenn Sie später eine neue Variante zu einem Typ hinzufügen, zeigt Ihnen der Compiler sofort jede Stelle an, die nun angepasst werden muss. Refactoring ist kein Glücksspiel mehr, bei dem man hofft, alle betroffenen Stellen gefunden zu haben. Der Compiler liefert Ihnen einfach die Liste.
So sieht das in der Praxis aus. Fügen Sie eine fünfte OrderStatus -Variante zum unten stehenden Typ hinzu, und Elm wird nicht kompilieren, bis statusLabel erledigt das ebenfalls:
-- An order status arriving from the surrounding JavaScript app.
-- Add a variant here and the compiler flags every `case` that has
-- not caught up yet. No forgotten branch ever ships.
type OrderStatus
= Draft
| Submitted
| Approved
| Rejected String -- carries the reason, so it cannot go missing
statusLabel : OrderStatus -> String
statusLabel status =
case status of
Draft ->
"Draft"
Submitted ->
"Awaiting review"
Approved ->
"Approved"
Rejected reason ->
"Rejected: " ++ reasonDas Fazit für ein Team wie Pivotal Tracker war eindeutig: „Wir hatten null Laufzeitfehler“. Das Management ordnete daraufhin an, dass neuer Code ausschließlich in Elm geschrieben werden muss.
Elm lehnt sich an Haskell an, ist aber wesentlich leichter zu erlernen – und dieser Unterschied ist beabsichtigt. Czaplicki entwickelte die Sprache nach dem Prinzip des nutzerorientierten Designs: Man geht vom Anwender und dessen Bedürfnissen aus und fügt nur die Funktionen hinzu, die sich ihren Platz auch wirklich verdienen.
Das deutlichste Beispiel ist etwas, das Elm bewusst weglässt: Typklassen. (Eine Typklasse ist ein Haskell-Mechanismus, um eine Funktion zu schreiben, die für viele verschiedene Datentypen funktioniert. Mächtig, ja, aber sie bringt einen ganzen Rattenschwanz an mathematischem Vokabular mit sich.) Elm verzichtet komplett darauf. Das kann die Sprache, weil sie ein begrenzteres Problem löst. Haskell ist eine Allzwecksprache; Elm ist eine Sprache für das Frontend – und für nichts anderes. Vieles von dem, was Typklassen regeln müssen, wie Seiteneffekte und Zustandsänderungen, wird in der Elm-Laufzeitumgebung gehandhabt, anstatt es dem Entwickler aufzubürden.
Ein weiterer Punkt, der die Einstiegshürde senkt, sind die Fehlermeldungen von Elm. Das Typsystem weiß genau, was es erwartet hat und was tatsächlich geliefert wurde – ohne dass Typklassen den Blick vernebeln. Deshalb sagt dir der Compiler ganz direkt, was schiefgelaufen ist. Er geht sogar noch einen Schritt weiter: Er rät, was du wahrscheinlich meintest, und schlägt eine Lösung vor. Für ein Team, das zum ersten Mal mit funktionaler Programmierung in Berührung kommt, wirkt der Compiler weniger wie ein Türsteher, sondern eher wie ein geduldiger Lehrer. Das ist ein wesentlicher Grund dafür, warum die meisten Entwickler bei Pivotal Tracker in weniger als zwei Tagen produktiv waren.
Zuverlässigkeit ist nur die halbe Miete. Die andere Hälfte ist, wie schnell ein Team arbeitet, sobald sich Elm nicht mehr ungewohnt anfühlt.
Die Entwicklung durchläuft immer dieselben vier Phasen: Nachdenken, Tippen, Kompilieren, Testen. Beim Testen summieren sich die Stunden und die Monotonie. Elm verlagert einen Großteil dieses Aufwands in den Kompilierungsschritt. Man verbringt also etwas mehr Zeit damit, den Build zum Laufen zu bringen, und deutlich weniger Zeit mit dem Testen. Denn dann stellt sich nur noch die Frage, ob die Software das tut, was das Unternehmen verlangt, und nicht, ob sie abstürzt. Fehler werden früher erkannt. Und das ist kostengünstiger.
Die Syntax von Elm ist schlank: zwei Kontrollstrukturen, eine Handvoll reservierter Wörter, alles konzentriert auf die Funktion. Definitionen kommen ohne spezielle Zeichen aus, Typ-Signaturen sind optional und werden abgeleitet, und jede Funktion ist curried. Das bedeutet, man kann ihr einige Argumente jetzt und den Rest später übergeben, was Code höherer Ordnung übersichtlich hält. Pipe- und Kompositionsoperatoren ermöglichen es, Transformationen aneinanderzureihen, statt in verschachtelten Klammern zu ertrinken.
Starten Sie ein Elm-Projekt und vieles ist bereits fertig konfiguriert, ohne dass eine Toolchain mühsam zusammengestellt werden muss:
Wenn Sie bereits ein Produkt betreiben, stellt sich eigentlich nicht die Frage: „Ist Elm gut?“, sondern: „Wie kommen wir dahin, ohne alles neu schreiben zu müssen?“ Die gute Nachricht: Elm ist für eine schrittweise Einführung konzipiert. Man stellt fast nie eine komplette Anwendung auf einmal um.
Der übliche Weg besteht darin, Elm in die bestehende Umgebung einzubetten. Ein Elm-Programm wird zu einem JavaScript-Modul kompiliert, das Sie einfach in eine einzelne Komponente, eine Seite, ein Widget, ein neues Dashboard, ein komplexes Formular oder eine Reporting-Ansicht integrieren können, während der Rest unverändert bleibt. Stellen Sie es sich so vor, als würden Sie einen neuen Flügel an ein Haus anbauen, während die Familie darin wohnen bleibt. Zwei Mechanismen ermöglichen den Datenaustausch an dieser Schnittstelle:
An dieser Schnittstelle endet auch das Versprechen „keine Laufzeitfehler“. Daten, die über Ports in Elm gelangen, werden beim Eintritt validiert, während auf der JavaScript-Seite die üblichen Risiken bestehen bleiben. In der Praxis erweitern Teams den Elm-Anteil ausgehend von diesem ersten Modul, sobald sie Vertrauen gefasst haben. Genau so hat beispielsweise Pivotal Tracker Elm in eine bestehende Rails- und Backbone-Codebasis integriert.
Da der Ansatz inkrementell ist, gleicht die Entscheidung eher einer normalen Technologieauswahl als einem riskanten Glücksspiel für das gesamte Unternehmen. Unser Leitfaden zur Wahl eines Tech-Stacks für die Webentwicklung beleuchtet das Gesamtbild.
Die Anzahl der Elm-Entwickler ist geringer als die der React-Entwickler. Das ist ein echter Nachteil, wenn auch einer, der besser zu bewältigen ist, als die reine Kopfzahl vermuten lässt. Die Sprache ist bewusst schlank gehalten und der Compiler unterstützt Einsteiger außergewöhnlich gut, weshalb Teams immer wieder von kurzen Einarbeitungszeiten für alle berichten, die bereits JavaScript beherrschen. Pivotal Tracker maß diese Zeit in Tagen.
Meistens schulen Unternehmen, die auf Elm umsteigen, ihre vorhandenen Frontend-Entwickler um, anstatt nach Elm-Spezialisten zu suchen. Sie setzen dabei auf Tools wie elm-review, einen nativen Elm-Linter, um die Konsistenz in wachsenden Teams zu wahren. Die eigentliche Frage lautet weniger „Finden wir dafür Personal?“, sondern vielmehr „Sind wir bereit, uns eine Nischenkompetenz intern oder mit einem Partner anzueignen?“
Eine ehrliche Betrachtung muss sich mit der am häufigsten diskutierten Schwäche von Elm auseinandersetzen: wie selten neue Versionen erscheinen. Die Sprache verharrte von Oktober 2019 an auf Version 0.19.1, gefolgt von einer langen Phase ohne jegliche Releases. Ungewöhnlich für aktive Software. Eine berechtigte Sorge für jeden, der ein Produkt darauf aufbaut.
Das Gesamtbild ist jedoch weniger alarmierend. Der Kern von Elm ist seit Jahren stabil und gilt als funktionsvollständig. Es gibt keine kritischen Hindernisse, weshalb die Entwicklung stillstehen konnte, ohne dass die Software veraltet. Und das Schweigen wurde gebrochen: Elm 0.19.2 erschien am 6. Juli 2026, das erste einer geplanten Reihe kleiner, abwärtskompatibler Releases auf dem Weg zur Version 1.0. Währenddessen entwickelte sich das Ökosystem durch Community-Projekte wie elm-review, elm-pages und die Full-Stack-Plattform Lamdera stetig weiter.
Ist Elm also tot? Nein. „Langsame Release-Zyklen“ und „nicht gewartet“ sind nicht dasselbe. Elms Beständigkeit ist im Grunde genau das Ziel: Ein Projekt, das nicht unter ständigem Abhängigkeits-Chaos leidet, ist kostengünstiger im Unterhalt.
Drei Risiken sollten auf Vorstandsebene offen angesprochen werden. Erstens das Richtungsrisiko: Die Weiterentwicklung von Elm liegt weitgehend in den Händen des Erfinders, weshalb die Roadmap weniger vorhersehbar ist als bei Frameworks, die von einer Stiftung getragen werden. Zweitens das Ökosystemrisiko: Da es weniger fertige Pakete gibt, müssen Sie hin und wieder Lösungen selbst entwickeln, die Sie andernfalls einfach installieren könnten – ein Kostenfaktor, den man einplanen sollte. Drittens das Konzentrationsrisiko: Wenn eine Nischenkompetenz nur bei wenigen Entwicklern liegt, stellt dies eine Abhängigkeit dar, die durch Dokumentation, Linting-Standards oder einen Implementierungspartner gemanagt werden muss.
Dem gegenüber steht ein Argument für die Eigenentwicklung, das in die andere Richtung weist. Vieles von dem, was Sie in einem JavaScript-Stack mühsam zusammenfügen und betreuen müssten – State-Container, Unveränderlichkeit, Typenprüfung, Debugger – ist bereits integriert und stabil, was den langfristigen Aufwand für Upgrades und Integrationen deutlich reduziert. Keines dieser Risiken ist ein Ausschlusskriterium. Sie sind lediglich Gründe dafür, die Einführung gezielt zu planen, anstatt sie unreflektiert in vollem Umfang umzusetzen.
Wenn man es auf den Punkt bringt, ist Elm ein klarer Tauschhandel. Man entscheidet sich für eine weniger verbreitete Sprache, einen kleineren Talentpool und einen bewusst langsamen Release-Zyklus. Im Gegenzug erhält man ein Frontend ohne Laufzeitfehler, ohne Null-Pointer-Exceptions und mit einer vollständigen Abdeckung aller Grenzfälle, da der Compiler dies erzwingt. Das Ergebnis ist ein geringerer QA-Aufwand und Code, der über Jahre hinweg wartbar bleibt, anstatt schleichend zu verfallen. Genau das berichten Unternehmen wie NoRedInk und Pivotal Tracker.
Für die meisten Teams ist ein komplettes Rewrite nicht der klügste Weg. Besser ist ein begrenztes Pilotprojekt: Elm dort einsetzen, wo Zuverlässigkeit am wichtigsten ist, und die Auswirkungen auf Vorfälle sowie den QA-Aufwand vor einer weiteren Entscheidung mit dem Ist-Zustand vergleichen. Treffen Sie diese Entscheidung mit einem klaren Blick auf Ihre Systeme, Ihr Team und Ihre Risikobereitschaft. Lassen Sie dann die Zahlen entscheiden.
Für die Entwicklung zuverlässiger Front-End-Webanwendungen. Elm wird zu JavaScript kompiliert und läuft im Browser. Es glänzt besonders bei Benutzeroberflächen, bei denen Stabilität entscheidend ist – etwa bei Dashboards, datenintensiven Tools oder Single-Page-Anwendungen –, da es Laufzeitfehler durch sein Design konsequent ausschließt.
Ja. Sowohl NoRedInk als auch Pivotal Tracker betreiben umfangreiche Elm-Codebasen in der Produktion. NoRedInk berichtet von einem System mit 100.000 Zeilen, das seit 2015 keine einzige Laufzeitausnahme aufweist; Pivotal Tracker hat sein Dashboard in Elm entwickelt, nachdem es Elm gegen Redux getestet hatte.
Für den Code, den Sie in Elm schreiben, trifft das in der Praxis zu. Das Typsystem verhindert Null-Referenz- und Typfehler in der Produktion, und die Sprache kennt keine Exception-Primitive. Fehler können lediglich an der Schnittstelle auftreten, an der Elm über Ports mit JavaScript kommuniziert, aber der Kern der Sprache ist darauf ausgelegt, ohne Abstürze zu laufen.
Das hängt davon ab, worauf Sie optimieren. React ist die sicherere Wahl hinsichtlich der Personalsuche und verfügbarer Komponenten, da es eine deutlich weitere Verbreitung und ein tiefgreifendes Ökosystem bietet. Elm punktet bei integrierter Sicherheit und langfristiger Wartbarkeit, sofern diese Faktoren im Vordergrund stehen. Viele Unternehmen entscheiden sich nicht für ein Entweder-oder, sondern betten Elm-Module in eine größere React- oder JavaScript-Anwendung ein und beginnen dabei mit den kritischsten Bereichen.
Schrittweise. Ein Elm-Programm wird zu einem JavaScript-Modul kompiliert, das Sie in eine Seite oder Komponente einbinden. Daten werden über Flags übergeben, und die Kommunikation erfolgt bidirektional über Ports. Teams beginnen meist mit einer einzelnen, besonders kritischen Ansicht und erweitern den Elm-Anteil mit wachsendem Vertrauen, anstatt das gesamte System neu zu schreiben.
Für das richtige Projekt: ja, wenn man die Rahmenbedingungen kennt. Der Kern ist stabil, die Erfolgsbilanz in der Produktion ist stark, und die Version 0.19.2 vom Juli 2026 signalisiert neue Release-Aktivitäten in Richtung 1.0. Die abzuwägenden Risiken sind ein schlankeres Ökosystem, ein kleinerer Talentpool und eine vom Erfinder gesteuerte Roadmap. Deshalb ist ein begrenztes Pilotprojekt einem vollständigen Umstieg vorzuziehen.
Stabil, nicht tot. Nach der langen Pause seit 0.19.1 im Jahr 2019 wurde Elm 0.19.2 im Juli 2026 veröffentlicht. Dies markierte den Beginn einer Reihe kleiner, abwärtskompatibler Releases mit Blick auf eine zukünftige 1.0, begleitet von einer durchgehend aktiven Community.
Weniger als die meisten funktionalen Sprachen. Elm wurde speziell für JavaScript-Entwickler konzipiert, verzichtet auf komplexe Funktionen wie Typklassen und bietet ungewöhnlich klare, hilfreiche Fehlermeldungen. Bei Pivotal Tracker waren die meisten Entwickler in weniger als zwei Tagen produktiv.
Das ist möglich. Community-Tools wie elm-pages unterstützen die Generierung statischer Websites sowie serverseitiges Rendering. Damit lassen sich die SEO-Bedenken ausräumen, die oft mit rein clientseitig gerenderten Single-Page-Anwendungen einhergehen.
Wenn Sie Elm – oder einen funktionalen Front-End-Ansatz im Allgemeinen – für ein neues Produkt oder einen besonders kritischen Bereich einer bestehenden Anwendung in Betracht ziehen, lohnt es sich, dies mit Experten zu besprechen, die diese Entscheidung bereits getroffen haben. Sprechen Sie mit unserem Engineering-Team darüber, wie dieser Schritt in der Praxis aussieht: Wo Elm sinnvoll eingesetzt werden kann, welcher Aufwand mit der Einführung verbunden ist und wie es sich in Ihre bestehenden Systeme integrieren lässt. Wenn Sie lieber erst einmal herausfinden möchten, wo die tatsächlichen Risiken Ihres Front-Ends liegen, ist ein technisches und UX-Audit ein sinnvoller erster Schritt.
Rails-Entwickler mit mehr als 10 Jahren Erfahrung mit verschiedenen Technologien. Ich interessiere mich für funktionale Programmierung.
People who read this post, also found these interesting:
.webp)
