Dieser Artikel ist für Einsteiger und fortgeschrittene Webworker gleichermaßen relevant. Für die IT-Talents mit etwas Vorwissen hilft dieser Artikel, vollgepackt mit Erklärungen zu den Basics des Web-Developments, gut gegen gefährliche Halbwisseritis. Ihr Einsteiger ins spannende Thema Web-Development: Lasst Euch von den vielen Begriffen und Zusammenhängen nicht abschrecken. Es wäre auch unfair das ganze Thema beim ersten Lesen zu verstehen – ich selbst habe Jahre gebraucht um die ‘Logik des Internets’ zu begreifen.

Wie funkioniert die Entwicklung einer markttauglichen Web Application eines Startups?

Nach vielen entwickelten Web-Apps, Websites und Designs hat sich im Laufe der Jahre eine bestimmte Vorgehensweise bei meiner Webentwicklung eingestellt, die ich im Folgenden vorstellen möchte. Das beschriebene Vorgehen kann als Orientierung im Web Development Prozess verstanden werden. So sinnvoll es oft ist, sich daran zu halten, kann es je nach Projekt auch richtig sein, hier und da ein wenig vom Masterplan abzuweichen. Das Fundament jeder Web-Entwicklung ist das Webdesign.

Webdesign – Begriffsdifferenzierung

UX steht für User Experience. Ziel des UX-Designs ist ein funktionales Konzept, das dem User ein bestmögliches Nutzererlebnis der App bietet. UI steht für User Interface. Ziel des UI-Designs ist es, das UX Konzept in ein schönes Äußeres zu verpacken. UX ist also die Basis des UI Designs. Es ist somit unbedingt vorher auszuarbeiten.

Zu oft werden UX und UI in einen Topf geworfen, worunter das Endprodukt leidet. Es ist wichtig, diese beiden Arbeitsschritte voneinander zu trennen. UX steht in engem Zusammenhang mit dem Produktkonzept. Es werden Features erdacht und ein Userflow erarbeitet, der das Verhalten der User steuert und das Nutzererlebnis in großem Maße beeinflusst – deutlich stärker als das UI-Design.

Es ist wie beim Dating: Ein schönes Äußeres (UI) kann viel Aufmerksamkeit auf sich ziehen, stehen aber keine inneren Werte dahinter (UX), sind die meisten Interessenten so schnell wieder weg, wie sie gekommen sind. Das ist auch oft bei Websites oder Web Apps zu beobachten, die den Fehler gemacht haben, sich stärker aufs UI-Design zu konzentrieren als auf das UX-Design.

UX-Design

Ziel: Nutzererlebnis maximieren.

Vorgehen:

1. Erarbeitung eines Features-Book mithilfe von Personas und User Stories
2. Erstellung von Wireframes auf Grundlage des Features-Books

Personas und User Stories

Ziel: Userflow der App abbilden und optimieren.

Vorgehen: Erfinde Personen der Zielgruppe, die die App nutzen sollen. Gib diesen Personen einen Namen und einen Hintergrund: Woher kommt die Person, welche Absicht hat diese Person die App zu nutzen und mit welchem Ziel usw. Dies sind die sogenannten Personas. Lasse diese Personas nun gedanklich die App nutzen. Versuche jeden Schritt von Login bis Logout durchzuspielen. In einer umfangreichen App gibt es dafür nicht nur einen Weg. Ziel ist es, möglichst alle Pfade und Abzweigungen im Userflow abzubilden. Gehe also mit verschiedenen Personas verschiedene Wege. Solange, bis möglichst jeder Schritt der App durchdacht ist. Dadurch entsteht ein guter Überblick über die Features, die zu implementieren sind.

Features List

Schreibe alle gefundenen Features in eine Liste. Ordne nun die Features nach Wichtigkeit. Wichtig sind solche Features, die sehr oft benutzt werden und der App ihr Gesicht geben. Unwichtig sind Features, die selten benutzt werden oder nur für eine kleine Nutzergruppe interessant sind. Hier sollte aus Sicht der größten Nutzergruppe sortiert werden.

Das erste Drittel der Features-Liste sollte nun alle Features eines “Minimum Viable Product” (MVP) umfassen. Ein MVP ist eine Version des Produktes, die die Mindestanforderung der User erfüllt und auch schon die Schlüsselfeatures enthält – mehr jedoch nicht. Behalte das zweite Drittel der Liste im Hinterkopf und vergiss das letzte Drittel.

Ein Startup zeichnet sich durch knappe Ressourcen aus. Deshalb ist unter Berücksichtigung dieser Engpässe zu optimieren. Sprich: Von der Idee bis hin zum Launch sollten wenige Monate liegen, damit das investierte Kapital möglichst schnell Umsatz erwirtschaftet, der die anfallenden Kosten (Personal-, Server- und Softwarekosten, aber auch eigene Opportunitätskosten) deckt.

Aus diesem Grund ist ein MVP zu empfehlen, das wegen seiner schlanken Architektur schon wenige Monate nach der Idee gelauncht werden kann. So können schnell erste Umsätze erwirtschaftet und zugleich früh Feedback der Zielgruppe eingeholt werden.

Features Book

Schreibe zu jedem Feature des MVP – also des ersten Drittels der Features-Liste – eine Kurzbeschreibung als Text oder, wo es angebracht ist, in Stichworten. Versuche so knapp wie möglich aber so ausführlich wie nötig zu formulieren, um es theoretisch einem externen Entwickler in die Hand geben zu können und dieser genau weiß, was welches Feature können soll und wie es zu implementieren ist. Das hört sich einfacher an, als es ist, aber die Arbeit macht sich später bezahlt.

So wird aus der Features-List nach und nach ein Features Book. Dieses Features Book ist das Fundament der App.

Wireframes

Wireframes sind Skizzen einer Ansicht der App. Beginne mit dem wichtigsten Feature. Mache Dir seine Hauptfunktionen klar und zeichne diese auf ein Blatt Papier. Solange, bis es Dir gefällt. Trial & Error. Bis der Papierkorb voll ist. Und dann nochmal.

Das wiederholst Du mit allen Deinen Features so lange, bis Du zu jedem Dropdown, zu jedem Button und zu jedem Eingabefeld ein konsistentes Konzept erarbeitet hast. Das bedeutet, dass sich ein Header, ein Button oder eine Sidebar in jeder Ansicht möglichst gleich oder ähnlich verhält und auch aussieht. Das erhöht das Nutzererlebnis und verringert Design- und Programmieraufwand.

Auch wenn die einzelnen Features in sich konsistent sind, kann es sein, dass sie nicht gut mit anderen Features des Designs zusammenspielen. In diesem Fall muss solange nachgebessert werden, bis es passt. Füge am Ende die fertigen Wireframes als Fotos oder Skizzen dem Features-Book hinzu. An dieser Stelle ist Perfektion angebracht. Sollten sich auf dieser abstrakten Ebene schon Probleme im UX herausstellen, werden sich diese durch UI-Design und Progammierung nicht auflösen – sie werden sich durch die gesamte App ziehen.

Eine besondere Herausforderung hierbei ist, dass zwar für ein MVP entwickelt wird, später jedoch das Produkt auf vielen Ebenen ausgebaut werden soll. Hier zeigt sich das Talent des UX-Designers, der das gesamte Konzept der App im Kopf hat und auch in Hinblick auf weitere Erweiterungen designt.

Es gibt viele Tools, die dem UX Designer Arbeit abnehmen sollen. Bisher konnten mich keine dieser Konzepte überzeugen. Ich bleibe bei Stift und Papier.

UI Design

Für ein erfolgreiches UI-Design sollte ein UI-Styleguide angelegt werden. Ein UI-Styleguide enthält Regeln für das Design von Features und Elementen. Er beschreibt z.B. wie ein Button aussieht (Farbe, Größe, Abstand, Icon) und sich verhält (Hoverstate, Error) oder wie Headlines gestylt sind (Schriftart, Größe, Zeilenabstand, Fontweight).

Das Erstellen eines umfangreichen UI-Styleguides für alle Features und Elemente ist sehr aufwändig. Je nach verfügbarer Zeit würde ich zu einer vereinfachten Version raten, die jedoch mindestens Informationen zum benutzten Farbschema und Regeln für die Schlüsselfeatures und -elemente beinhalten, die während des UX-Designs herausgearbeitet wurden.

Nachdem der Mini-UI-Styleguide angelegt ist, kann er mit den Wireframes des UX-Designs verheiratet werden. So entstehen die Ansichten der App, wie sie später im Browser oder auf dem Mobile Device zu sehen sein sollen.

Wenn man keine Erfahrung mit UI-Design hat, ist vom Selbsterstellen abzuraten. Es würde zu lange dauern und das Ergebnis würde weit unter den Erwartungen liegen. Auch wenn Kapital eine knappe Ressource ist, lohnt sich hier die Investition in einen professionellen UI-Designer mit Erfahrung. Gute UI-Designer haben auch Übung im UX-Design. Sie können so auf Probleme in der UX aufmerksam machen und diese lösen.

Ich erstelle meine UI-Designs hauptsächlich mit Adobe Illustrator ®. Viele UI-Designer arbeiten auch mit Adobe Photoshop ®. Es gibt viele Pros und Cons für beide Programme. Im Endeffekt ist es Geschmackssache.

Das UI-Design ist der letzte Schritt des Webdesigns. Jetzt sollte das Konzept soweit ausgereift sein, dass es guten Gewissens zur technischen Umsetzung übergeben werden kann. Damit beschäftigen wir uns zweiten Teil des Blogartikels.

---

Web-Development

Im Folgenden verwende ich oft den Begriff der “App” als Abkürzung des Wortes “Application”, dem englische Begriff für “Programm”. Diese Bezeichnung hat sich auch im Web-Development stark etabliert. Damit ist aber nicht (nur) die Entwicklung einer Mobilanwendung gemeint, sondern auch jegliche Anwendung im Browser (z.B. Facebook, YouTube, Soundcloud).

Die technische Umsetzung im Web-Development lässt sich allgemein in 3 Teile gliedern:

1. Client-Side Development
2. Server-Side Development
3. Deployment

Es gibt keinen festgelegten ersten Schritt im Web-Development-Prozess. Für das eine Projekt mag es sinnvoll sein mit dem Server-Side Development und dem Datenbankmodell zu starten, für ein anderes Projekt ist es besser mit dem Client-Side Development zu beginnen. Die Gliederung des Artikels spiegelt also nicht unbedingt das Vorgehen jeder Webentwicklung wieder.

Entwickelt wird nahezu jede Website und App zunächst lokal. Das bedeutet, dass die App nicht über das Internet erreichbar ist, sondern nur über den bzw. die Computer, mit denen entwickelt wird.

Client-Side Development

Der sog. Client im Web-Development ist der Browser (Chrome, Safari, Firefox, etc.).

So versteht man unter Client-Side Development alle Codes und Programmierungen, die direkt im Browser dargestellt und ausgeführt werden.

Hierbei kommen typischerweise drei Computersprachen zum Einsatz: HTML, CSS und JavaScript (auch JS). HTML (HyperText Markup Language) wird für die Entwicklung der Seitenstruktur (DOM) eingesetzt. CSS (Cascading Style Sheet) ist für die Darstellung und das Styling des HTML zuständig und JavaScript für die dynamischen Inhalte.

Eine ausführliche Einführung in alle Sprachen würde hier weit über das Ziel hinausschießen, deshalb hier nur eine Einführung. Am Ende des Artikels sind einige Empfehlungen aufgelistet, um mehr über das Thema Coding zu lernen.

HTML

Basis jeder Web-Application ist das HTML. Ein HTML Dokument besteht aus einem Head und einem Body. Der Head enthält hauptsächlich Informationen zum Dokument, die selbst nicht im Browser dargestellt werden. Der Body umfasst alle darstellbaren Elemente.

Ein HTML Element, dargestellt als

 Inhalt

, wobei “html” hier für eine Elementbezeichnung steht, besteht aus einem Opening Tag () und einem Closing Tag (

). Es gibt eine Vielzahl definierter Elemente, wie z.B.

 
, 
, 
, , , 
, 

, um nur einige relevante zu nennen.

Ein HTML Dokument besteht aus vielen ineinander verschachtelten Elementen. Dieser Aufbau wird DOM (Document Object Model) genannt. Ein Beispiel: So wird unsere Website http://3alsterkinder.de ohne CSS und JavaScript dargestellt. Zugegeben – nicht sehr schick: http://jsfiddle.net/djaax/fhn5kr9a/2/.

Hier wird nur der Body des Dokuments betrachtet. Im Eingabefeld oben links steht der Quellcode als HTML, unten rechts das sichtbare Ergebnis. Was wir auch tun, HTML alleine reicht nicht aus, um eine Website ansprechend zu gestalten. Dafür brauchen wir CSS.

CSS

Den einzelnen HTML Elementen des DOM können wir mithilfe von CSS einen Style zuordnen, indem wir diese Elemente mit einer Class oder ID identifizieren. Hier betrachten wir beispielsweise eine Class-Zuordnung. Aus dem einfachen

Inhalt

wird

Inhalt

Den Namen der Class können wir selbst definieren. Im CSS Dokument erstellen wir nun ein Code-Snippet das unserer HTML Element stylt:

.erster-container {     color: white;     background: #333333;     width: 200px;     height: 200px; }

So bekommt das Element mit der Class “erster-container” eine weiße Schriftfarbe, einen dunklen Hintergrund (#333333 steht für eine HEX-Codierung einer Farbe), und eine Breite und Höhe von jeweils 200 Pixeln.

Die Syntax von CSS ist simpel. Zunächst wird mithilfe von “.” (für Class) oder “#” (für ID) deutlich gemacht, ob es sich bei dem folgenden Ausdruck (“erster-container”), um eine Class

oder eine ID

handelt. In unserem Fall betrachten wir eine Class, also verwenden wir im CSS “.”.

Nach dem . oder # folgt der Name der Class (oder ID) und geschweifte Klammern { }. Innerhalb dieser geschweiften Klammern definieren wir dann den Style des Elements. Auch hier gibt es eine sehr große Anzahl an Attributen, wie background, color, width und height.

Unsere Website http://3alsterkinder.de sieht mit CSS schon sehr viel ansprechender aus: http://jsfiddle.net/djaax/fhn5kr9a/3/

FYI: HTML und CSS sind keine echten Programmiersprachen. Bei HTML handelt es sich um eine sog. “markup language”, bei CSS um eine “stylesheet language”. Als solche werden sie auch nicht “programmiert”, sondern lediglich geschrieben. Allgemein kann man bei der Anwendung von Computersprachen von Coding sprechen.

Etwas fehlt aber noch. Das große Thema JavaScript.

JavaScript

Nun, wo unsere Website mit CSS so aussieht, wie wir es haben wollen, wozu dann noch JavaScript? Tatsächlich benötigt man nicht für jedes Projekt JavaScript. Wie wir gesehen haben, http://3alsterkinder.de sieht auch ohne JS schon ansprechend aus.

Gehen wir aber nun weiter, von der einfachen Homepage, hin zur großen Web-App. Dort sollen Inhalte dynamisch dargestellt werden: Es gibt Formulare die ausgefüllt und validiert werden sollen, Eingaben müssen bestätigt und Fehlermeldung korrekt angezeigt werden. Und vor allem: Wir wollen mit dem Server kommunizieren.

Angenommen wir entwickeln ein neues fancy Social Network. Betrachten wir zunächst eine Profilseite: Unser DOM und auch das CSS, haben wir schon fertig gecodet. Es ist allerdings noch nicht sehr aufregend. Alle Inhalte haben wir direkt in unser HTML geschrieben (“hard coding” genannt) – es ist völlig statisch. Nun bringen wir ein wenig Dynamik hinein.

Ich möchte eine Statusmeldung auf meinem Profil veröffentlichen, ohne dafür den Quelltext des Dokuments bearbeiten zu müssen. Ich schreibe also den Status in ein definiertes Formular-Feld. Ein sogenanntes Input-Field. Mit Tastendruck auf “Enter” oder Klick auf “Senden” soll der Status meinem Profil hinzugefügt und angezeigt werden. Um das zu erreichen, behelfen wir uns mit JavaScript:

Dafür definieren wir eine Funktion, die den Input findet, liest, den Inhalt anschließend in ein neues HTML Element verpackt und es der Liste anfügt. Klingt doch ganz einfach! Und so sieht das Ergebnis aus: http://jsfiddle.net/djaax/zq7t1e13/3/.

Die mit “//” angeführten Zeilen im JS unten links sind Kommentare und werden nicht ausgeführt. Die Profilseite funktioniert ohne jegliche Einbindung von Libraries – ja, das geht auch! VanillaJS, also JavaScript ohne zusätzliche Libraries ist schneller als jede Library Implementation. Aber zugegeben, es fühlt sich ein bisschen an wie das Rad neu zu erfinden. Dieser Ansatz ist für große Apps auch nicht zeitgemäß. Heutzutage ist der Einsatz von durchdachten JS-Libraries wie Google’s “Angular.js” zu empfehlen, die uns sehr viel Arbeit abnehmen.

FYI: Das Input-Field ist neben einigen wenigen anderen HTML-Elementen ein sog. Standalone-Tag. Als solches hat es die Besonderheit, dass es kein Closing-Tag

besitzt. Das Input Element wird einfach am Ende mit einem “/>” wieder geschlossen:

Client-Server Kommunikation

Nun soll diese Profilseite aber nicht nur von einer Person genutzt werden – es wäre wohl das unsozialste Social Network der Welt. Also können wir auch viele

anderen Inhalte nicht direkt in unser HTML schreiben. Für Marie, Erik und Anni, würde

Marie

immer als “Marie” angezeigt werden. Lösung des Rätsels ist eine Anfrage (ein Request) an den Server, der uns auf wundersame Weise die richtige Darstellung des Profils liefert. Schauen wir uns die Magie dahinter genauer an.

Server-Side Development

Zunächst teilen wir dem Server mit, wer wir sind. Das geschieht üblicherweise über ein Login. Auf Client-Seite schicken wir den Request mit E-Mail Adresse und Passwort zum Server. Der Server stellt daraufhin eine Verbindung zur Datenbank her, wo geprüft wird, zu wem die E-Mail Adresse passt und ob das Passwort aus der Datenbank mit dem aus dem Request übereinstimmt. Sollte das der Fall sein, senden wir eine Antwort (Response) mit einem “OK”-Status und dem neuen Inhalt.

Nun gibt es grundsätzlich zwei unterschiedliche Varianten unsere individuelle Profilseite darzustellen.

Variante 1) Wir “rendern” die gesamte HTML-Seite auf dem Server. Die personenbezogenen Informationen aus der Datenbank, übergeben als Parameter, werden so in das HTML eingesetzt. Das gerenderte HTML Dokument wird als Ganzes dem Client als Antwort zurückgegeben, der die Seite dargestellt. Wichtige Aspekte dieser Variante sind, dass die Leistungsbeanspruchung des Renderings komplett auf Seiten des Servers liegt und die Website komplett neu geladen werden muss.

Variante 2) Der Server übermittelt nicht das gesamte HTML Dokument als Response, sondern nur das Ergebnis der Datenbankanfrage. Der Client empfängt die Daten und baut sie an der entsprechenden Stelle ins DOM ein. Hier liegt die Leistungsbeanspruchung stärker auf Seiten des Clients. Zudem ist mehr Programmieraufwand auf Client-Seite notwendig, um den Inhalt korrekt darzustellen.

Ein Mix beider Varianten wäre es, dass nur der relevante Teil schon auf dem Server als HTML gerendert und als Response zurückgeschickt wird. Dort müsste das fertige HTML-Snippet dann wiederum an die richtige Stelle im DOM eingesetzt werden. Welche Variante zu bevorzugen ist, hängt von vielen Faktoren ab und ist pauschal leider nicht zu beantworten.

Wie wir gesehen haben, ist es Aufgabe des Servers, Requests vom Client zu beantworten. Dabei ist das Vorgehen immer sehr ähnlich:

Der Client schickt ein Request an den Server. Auf dem Server werden die gesendete Informationen interpretiert und ggf. eine Anfrage an die Datenbank gestellt. Die Antwort der Datenbank wird wiederum interpretiert und dann dem Client als Response zurückgesendet.

Anders als beim Client-Side Development, gibt es keine fest definierten Sprachen die üblicherweise zum Einsatz kommen. Hier ist die Auswahl deutlich größer. Neben den alt eingesessenen Sprachen wie Java oder PHP, sind die Sprachen Ruby und JavaScript als Server-Side Programmiersprachen stark im Kommen.

Die Idee, JavaScript auch auf dem Server zu benutzen, ist vergleichsweise jung, aber sehr interessant. Dank “Node.js“ ist es seit einigen Jahren möglich, die gleiche Sprache Client-seitig als auch Server-seitig zu verwenden.

Deployment

Nachdem die Web-Application lokal entwickelt wurde – also ohne oder nur mit wenig Anschluss ans Internet, wollen wir unsere App nun der ganzen Welt zugänglich machen. Wir müssen die App von unserer Entwicklungsumgebung, unserem Computer, auf den Webserver “portieren”. Dieses Vorhaben wird “Deployment” genannt: Die Installation von Software auf Anwendungssystemen.

Eine elegante Möglichkeit Programmcode auf den Webserver zu portieren bietet git.

“Git” ist ein open source Versionsverwaltung von Dateien. Grundlage der Versionsverwaltung ist das sog. Versioning. Idee des Versioning ist es, dass bei jedem Update unserer Web-Application nur ein Teil aktualisiert wird – gerade der, den wir verändert haben. Dabei wird jeder einzelne Stand gespeichert. So kann man jederzeit zurück zu einer vorherigen oder benachbarten Version. Mit Hilfe vom Versioning ist es auch möglich, dass viele Entwickler gleichzeitig an einem Code schreiben.

FYI: Versioning ist Grundlage vieler Backup-Systeme, wie Mac’s Time Machine.

Mittels Kommandos in der Konsole lässt sich so der Quellcode auf den Webserver bringen und ggf. von dort aus starten.

Das Deployment ist der letzte Schritt der Entwicklung der App. Nun läuft unsere Web-Application auf dem Server und ist via URL ansprechbar. Puh, geschafft.

Einen guten Einstieg in das gesamte Thema der Web-Development bietet www.codecademy.com. Es werden verschiedene Tracks angeboten, unter anderem HTML & CSS und JavaScript.

Für die Client-seitige JavaScript Entwicklung gibt es verschiedene Hilfsmittel, die die Entwicklung vereinfachen und beschleunigen. Hier seien neben vielen anderen Projekten die “jQuery” Library von John Reisig und das erwähnte “Angular.js” Framework von Google genannt.

Nachdem ich für die Client-seitige Entwicklung mit JavaScript lange Zeit die jQuery Library genutzt habe, arbeite ich nun hauptsächlich mit dem Angular.js Framework. Mithilfe dieses Frameworks ist es möglich, Programmabläufe direkt in die HTML Struktur zu integrieren, wodurch der Programmieraufwand deutlich reduziert werden kann.

Für die Server-seitige Entwicklung kommt bei mir hauptsächlich das erwähnte Node.js zum Einsatz.

Node.js basiert auf der “V8”, einer JS-Laufzeitumgebung, die ursprünglich für den Chrome Browser entwickelt wurde. Deshalb besitzt Node.js eine ressourcensparende Architektur und ermöglicht eine große Anzahl von gleichzeitig bestehenden Netzwerkverbindungen. Neben weiteren Vorteilen ist die Modulsammlung des Paketmanagers www.npmjs.com mit derzeit über 110.000 Modulen eine große Bereicherung. Zudem gibt es um Node.js eine junge und engagierte Community, in der man Lösungen für viele Probleme, auf die man während der Entwicklung stößt, schnell finden kann.

Wer sich genauer mit Node.js und Angular.js beschäftigen möchte, findet unter http://scotch.io tolle Basic-Tutorials.

Außerdem sehr zu empfehlen für den Entstieg in das Thema Angular.js sind die Videos von https://egghead.io.

Gute Tutorials im Bereich System Administration (und Deployment) bietet der Hostinganbieter DigitalOcean hier: www.digitalocean.com/community

Eine interessante Trendanalyse zum Thema Programmiersprachen hat http://githut.info basierend auf GitHub Repositories zusammengestellt. Go JavaScript!

Viel Erfolg bei eurer nächsten Webentwicklung! Für Fragen und Beratung stehe ich gerne zur Verfügung.

Mein Name ist Dustin Jaacks. Ich bin Mitgründer der “3 Alsterkinder” in Hamburg. Wir begleiten Startups von der Ideenfindung über Produktdesign und Programmierung bis hin zum Marketing. Alles, was das Startup-Herz begehrt. Für Fragen oder Anregungen, stehe ich gerne per Mail an dustin [dot] jaacks [at] 3alsterkinder.de oder via XING zur Verfügung.

Nachtrag zum Client-side JavaScript Development:

Die Benutzung von JavaScript beim Client-Side Development wurde in den letzten Jahren immer wichtiger. Heutzutage liegt der durchschnittliche Anteil von Usern die JavaScript deaktiviert haben, um die 2%. Dieser Wert schwankt allerdings von Branche zu Branche. Mobil liegt der Wert sogar unter 1%. Infolgedessen hat sich Mozilla dazu entschlossen im August 2013 für den Firefox 23, die Option “JavaScript deaktivieren” zu entfernen, mit der Begründung “es würde das Internet kaputt machen”.

Seit Jahren gibt es Debatten darum, ob man “Fallbacks” für Nicht-JavaScript-User implementieren sollte, damit die Seiten auch ohne JS voll funktionsfähig sind. Je nach Zielsetzung kann es sinnvoll sein, für die letzten 2% zu optimieren.

Festzuhalten ist jedoch, dass sich ein Startup bei knappen Budget und wenig Zeit auf die 98% der User konzentrieren sollte. Versucht lieber, vielen ein großartiges Produkt anbieten als allen ein mittelmäßiges.