Web Component Standard als nachhaltige Entwicklungstechnologie
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Praxisprojektarbeit
Web Component Standard als nachhaltige
Entwicklungstechnologie
Wie ist die Verwendung von Web Standards im Hinblick auf Langlebigkeit in
einem komponenten-basierten Frontend zu bewerten?
vorgelegt von
Finn Nils Gedrath
im Studiengang
Medieninformatik (Ba.)
Betreuung
Prof. Dipl.-Des. Christian Noss
TH Köln, Advanced Media Institute
Gummersbach, im August 2021
Praxisprojektarbeit
Web Component Standard als nachhaltige Ent-
wicklungstechnologie
Wie ist die Verwendung von Web Standards im Hinblick auf Langlebigkeit in
einem komponenten-basierten Frontend zu bewerten?
Field Project Thesis
Web Component Standard as a sustainable development technology
How should the use of web standards be evaluated in terms of long-term durability in a
component-based frontend?
Wissenschaftliche Arbeit im Modul Praxisprojekt
im Studiengang Medieninformatik Bachelor am Advanced Media Institute
an der Fakultät für Informatik und Ingenieurwissenschaften
der Technischen Hochschule Köln
vorgelegt von: Finn Nils Gedrath (finn_nils.gedrath@smail.th-koeln.de)
Matrikel-Nr.:
Betreuer: Prof. Dipl.-Des. Christian Noss (christian.noss@th-koeln.de)
Finn Nils Gedrath Prof. Dipl.-Des. Christian Noss
Finkelsteinstraße 19, TH Köln, Campus Gummersbach
51375 Leverkusen. Steinmüllerallee 1,
51643 GummersbachKurzfassung
Bevor mit der Entwicklung eines interaktiven Systems begonnen werden kann, müssen mehrere Tech-
nologieentscheidungen getroffen werden. In der Web-Frontend-Entwicklung wird durch die steigen-
de Diversität von standardisierten Technologien und Drittanbieter-Frameworks bzw. Libraries diese
Entscheidung erschwert. Für den Kooperationspartner Junges Musical Leverkusen e. V. ist es besonders
wichtig, langlebige Software zu entwickeln. Der ehrenamtlich-arbeitende Verein hat eine geringe Res-
sourcenverfügbarkeit, um Entwicklungsprojekte kontinuierlich zu pflegen. Für ein Ticketverkaufssys-
tem soll nun eine langlebige Technologieentscheidung getroffen werden.
In dieser Arbeit wird der Web Components Standard vorgestellt und auf seine Langlebigkeit untersucht.
Dazu werden Standards im Web im Allgemeinen vorgestellt. Unterschiedliche Entscheidungsorgane
und Standardisierungsprozesse werden erläutert. Um eine Aussage über die Lebenszeit von Standards
in Web Browsern zu treffen, wird ein Paper des Google-Chrome-Teams vorgestellt, aus dem geschlossen
werden kann, dass keine allgemeingültige Vorhersage über den Zeitpunkt des Verfalls von Standards
getroffen werden kann. Dennoch werden Web Standards in Abhängigkeit von ihrer Verwendung im
Web, Sicherheitsproblemen und anderen Faktoren als veraltet markiert.
Der komponenten-getriebene Ansatz von Software-Entwicklung wird vorgestellt, um Web Components
im Kontext der Softwareentwicklung zu verstehen. Die Spezifikationen der Webtechnologien für den
Web Components Standard werden im Detail vorgestellt, um im weiteren Verlauf der Arbeit Grenzen
des Standards zu erörtern. Des Weiteren wird eine Auswahl von Drittanbieter-Frameworks nach einer
gekürzten Liste von Metriken verglichen. Konzepte und Prinzipien dieser Frameworks werden erläu-
tert.
Es werden allgemeingültige Konzepte und Prinzipien vorgestellt, die das Thema der Langlebigkeit von
Software adressieren. Hierzu zählen Test-Driven Development und Coding Style. Der Diskurs um die-
se Konzepte wird angerissen. Als Konzept für die Langlebigkeit von Web-Frontendprojekten wird die
Bewegung Lean Web vorgestellt.
Es wird damit abgeschlossen, dass die Verwendung des Web Component Standard diskutiert wird. Die
Konzepte aus den untersuchten Frameworks und die Prinzipien zur Erreichung einer Langlebigkeit
von Software werden in die Diskussion eingebracht. Es wird überprüft, inwieweit eine Bewertung des
Standards möglich ist und ob dem Kooperationspartner die Verwendung der Technologie zu empfehlen
ist.
Stichworte Frontend-Development, Componend-Based Development, Langlebigkeit, Lean Web, Tech-
nologieauswahl, JavaScript-Frameworks, Standards, Web Components
iAbstract
Before the development of an interactive system can begin, several technology decisions must be ma-
de. In web front-end development, this decision is made more difficult by the increasing diversity of
standardised technologies and third-party frameworks and libraries. For the cooperation partner Jun-
ges Musical Leverkusen e. V. it is especially important to develop long-lasting software. The non-profit
organisation has few resources available for the continuous maintenance of development projects. Now
a long-lasting technology decision is to be made for a ticket sales system.
In this paper, the Web Components Standard is presented and examined for its longevity. For this pur-
pose, standards for the web in general are introduced. Different decision-making bodies and standar-
disation processes are explained. In order to make a statement about the lifespan of standards in web
browsers, a paper of the Google Chrome team is presented, from which it can be concluded that no ge-
nerally valid prediction can be made about the time of decay of standards. Nevertheless, web standards
become obsolete depending on their use on the web, security issues and other factors.
The component-driven approach of software development is presented to understand Web Components
in the context of software development. The specifications of web technologies for the Web Com-
ponents Standard are presented in detail to discuss limitations of the standard later in the paper. Fur-
thermore, a selection of third-party frameworks is compared according to an abbreviated list of metrics.
Concepts and principles of these frameworks are explained.
General concepts and principles that address the issue of software longevity are presented. These inclu-
de Test-Driven Development and Coding Style. The discourse around these concepts is touched upon.
As a concept for the longevity of front-end web projects, the Lean Web movement is presented.
It concludes by discussing the use of the Web Component Standard. The concepts from the frameworks
that have been explored and the principles for attaining longevity in software are brought into the
discussion. The extent to which an evaluation of the standard is possible and whether the use of the
technology can be recommended to the cooperation partner is examined.
Keywords Frontend Development, Component-Based Development, Longevity, Lean Web, Choice
of Technologies, JavaScript Frameworks, Standards, Web Components
iiGender Erklärung
In dieser Arbeit wird die Methode des Gender Gaps mittels „:“ verwendet, um alle Geschlechterausprä-
gungen ansprechen zu können. Dort wo möglich wurde auf eine geschlechtsneutrale Formulierung
geachtet. Es wird an dieser Stelle darauf hingewiesen, dass eine Vollständigkeit nicht garantiert wer-
den kann und jede Formulierung geschlechtsunabhängig verstanden werden soll.
Danksagung
Ich bedanke mich bei Prof. Christian Noss für die spannenden Diskussionen und die hilfreichen Hin-
weise bei der Erstellung dieser Arbeit. Außerdem bedanke ich mich bei Leonard Pelzer für wichtigen
Austausch während dieser Zeit. Für die Korrektur der Arbeit bedanke ich mich bei Karl Jochen Micheel.
Zu guter Letzt bedanke ich mich vielmals bei Alina Maybauer an die Erinnerungen, dass es neben dem
Schreibtisch auch noch ein wunderbares Leben gibt.
iiiAbkürzungsverzeichnis
API Application Programming Interface. 2, 5, 7, MVC Model-View-Controler. 23
12, 17–19, 21, 22, 24, 29, 30, 32, 34, 41 MVVM Model-View-ViewModel. 23, 40
CBSE Component-based Software Engineering. NPM Node Package Manager. 19, 20, 27, 40
10
CLI Command Line Interface. 27 PR Proposed Recommendation. 6, 7, 40
CPU Central Processing Unit. 20
REC Recommendation. 6, 7, 40
CR Canditate Recommendation. 6, 7, 40
CRD Canditate Recommendation Draft. 6, 40 SPA Single Page Application. 21, 24, 29
CSS Cascading Style Sheets. iv, 5, 13, 16, 27, 29, 30,
38, 39 TDD Test-Driven-Development. 26, 34
CSSWG CSS Working Group. 5 TFD Test-First-Development. 26
DOM Document Object Model. iv, 5, 7, 11–16, 23, UI User Interface. 11, 17, 19, 23, 24
32, 37, 39, 40, 42, 44 UKM User Keyed Metrics. 9
UMA User Metrics Analysis. 8, 9
ES ECMAScript. 16, 19, 27, 35, 42, 44 URL Uniform Resource Locator. 24, 40, 45
HTML Hypertext Markup Language. 2, 5–7, 11–
VDOM Virtual DOM. 23
17, 19, 27, 29, 30, 39, 44
HTTP Hypertext Transfer Protocol. 9, 29 W3C World Wide Web Consortium. 5–8, 14, 38–40
WD Working Draft. 6, 40
IDL Interface Definition Language. 12, 14, 15, 32
WHATWG Web Hypertext Application Techno-
IE Internet Explorer. 16, 44
logy Working Group. 2, 5–9, 11–15, 29, 32,
JS JavaScript. 2, 5, 12, 13, 17, 19, 21, 23, 27, 29, 30 34, 39, 40
WWW World Wide Web. 6
MDN Mozilla Developer Network. 13, 14, 16, 37,
40 XP eXtream Programming. 26, 28
ivInhaltsverzeichnis
Kurzfassung i
Abstract ii
Abkürzungsverzeichnis iv
Inhaltsverzeichnis vi
1. Einleitung 1
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Problemraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Fachlicher Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Forschungsfragen und Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Standards im Web 5
2.1. Arbeitsprozess der Standardisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Arbeitsgruppen der W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. WHATWG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Lebenszeit von Web Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Komponenten-basierte Entwicklung 10
3.1. Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Der Web Components Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Browser-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Zukünftige Proposals in der WHATWG . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3. Browser-Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4. Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Dritt-Anbieter Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Vergleichsmetriken für Drittanbieter Software . . . . . . . . . . . . . . . . . . . 17
3.3.2. React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Svelte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.4. Konzepte und Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Nachhaltige Web Entwicklung 25
4.1. Legacy Code und Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Coding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Der Lean-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
v5. Diskussion 31
6. Abschließende Bewertung und Ausblick 34
Literaturverzeichnis 35
Abbildungsverzeichnis 40
Tabellenverzeichnis 41
Codeverzeichnis 42
Anhang 44
A. Tabelle über den Browser-Support von ausgewählten Web Standards . . . . . . . . . . 44
B. The Cost of JavaScript-Frameworks nach Kadlec . . . . . . . . . . . . . . . . . . . . . . 45
Eidesstattliche Erklärung 46
vi1. Einleitung
1.1. Motivation
Das Praxisprojekt ist eingegliedert in den ehrenamtlich-arbeitenden Verein Junges Musical Leverku-
sen e. V.1 . Dieser führt seit 2008 regelmäßig semi-professionell Musicalshows auf. Im Mittelpunkt seiner
Arbeit steht die Förderung junger Menschen im Musiktheater und die Bereicherung des kulturellen An-
gebots in der Region. Der Verein ist als eingetragener Verein dazu verpflichtet kein eigenes finanzielles
Vermögen aufzubauen. Die jährlichen Kosten werden hauptsächlich von Mitgliedsbeiträgen, externen
Förderungen und den Einnahmen von Ticketverkäufen getragen. Die Arbeit der Mitglieder erfolgt in
der Freizeit und ist somit nicht entgeltlich. Eine kontinuierliche Arbeit an technischen Systemen auf
professioneller Ebene ist aufgrund der fehlenden Zeit nicht möglich.
In dem Verein sind zwei bis vier Mitglieder für Software-Projekte verantwortlich. Diese pflegen zur-
zeit drei verschiedene Software-Projekte: Die Homepage des Vereins; Ein Mitgliederverwaltungssytem;
Ein Ticketverkaufsystem. Für den Verkauf von Eintrittskarten nutzt der Verein ein von ehemaligen Mit-
gliedern geschriebenes System, welches aus rechtlichen Gründen nicht mehr verwendet werden kann.
Dieser Zeitpunkt soll dazu genutzt werden, eben dieses Software-Projekt so zu gestalten, dass es mit so
wenig zeitlichem Aufwand wie möglich funktionsfähig gehalten werden kann. Außerdem kann dieses
Wissen, welches in dieser Arbeit gewonnen wird, auf andere Softwareprojekte des Vereins und Soft-
wareprojekte mit ähnlichen organisatorischen Anforderungen übertragen werden.
Diese Arbeit soll dazu genutzt werden, um aus fachlicher Seite tiefer in den Kontext von Frontend-
Development und langlebiger Softwareentwicklung einzutauchen.
1.2. Problemraum
Es soll in den gegebenen Problemraum eingeführt werden, um den sozio-technischen Kontext des Soft-
wareprojektes verstehen zu können. Es handelt sich hierbei um Anforderungen, welche aus Gesprä-
chen mit verschiedensten Stakeholder:innen synthetisiert wurden. Da in dieser wissenschaftliche Ar-
beit Technologien diskutiert werden sollen, werden diese Anforderungen als gegeben angesehen. Das
zu entwickelnde System soll drei übergeordnete Anwendungsfälle unterstützen:
1. Kauf von Tickets für eigene Shows und weitere Events durch potenzielle Besucher:innen
2. Nachverfolgung und Buchführung von verkauften Tickets durch Administration
3. Kontrolle der Gültigkeit von Tickets bei Einlass durch Helfer:innen
1
Online-Präsenz: https://www.jungesmusical.de/; Letzter Zugriff: 10. August 2021
1Der Verkauf von Tickets findet über drei verschiedene Arten statt: (i) selbstständiger Online-Kauf, (ii)
Verkauf an Vorverkaufs-Stellen in ausgewählten Geschäften und (iii) Verkauf an der Abendkasse. Mög-
liche Interaktionen müssen die situationsbedingten Erfordernisse abdecken können oder alternative
Interaktionsansichten anbieten.
Das Ticket-Verkaufssystem soll als Web-Anwendung über das Internet aufrufbar sein. Daten, die in
der Interkation benötigt werden, werden über einen Application Programming Interface (API)-Service
angeboten. Dieses System verwaltet alle Anwendungsobjekte und ist auch für sicherheits-technische
Anforderungen wie beispielsweise einer der Session-Verwaltung verantwortlich. Der genaue Aufbau
und die Arbeitsweise dieser API liegt außerhalb des Scopes dieser wissenschaftlichen Arbeit.
Das Frontend ist für die Anforderung und die Darstellung benötigter Daten verantwortlich. Die tech-
nischen Möglichkeiten, das Frontend zu gestalten, sollen in Einbezug der genannten organisatorischen
Gegebenheiten das grobe Themengebiet der Arbeit sein.
1.3. Fachlicher Kontext
Diese wissenschaftliche Arbeit ist fachlich in mehrere Forschungszweigen der Medieninformatik einzu-
ordnen: Vorrangig steht die Web Entwicklung im Frontend-Bereich im fachlichen Fokus dieser Arbeit.
Die Arbeit steht zudem im Kontext mit der Software-Entwicklung unter Einbezug der komponenten-
basierten Entwicklung. Das Konzept wurde bereits von Parnas im Jahr 1972 diskutiert und findet sich
auch im Design bspw. in dem Atomic Design-Ansatz nach Frost (2016) wieder. Auch in der Frontend-
Entwicklung ist durch die steigende Anzahl an komponenten-basierten Frameworks und anderen Tech-
nologien das Thema der Modularität von Interaktionsobjekten prominent. Nach einer Studie von Greif
und Benitte (2020a) ist die Anzahl von JavaScript-Frameworks, die es ermöglichen diesen Code in Kom-
ponenten zu unterteilen und die unter Entwickler:innen bekannt sind, von vier (Jahr 2016) auf neun
(Jahr 2020) Frameworks gestiegen. Beispielsweise hat das Framework Svelte2 , welches erst seit 2019 in
der Studie auftaucht, eine Zufriedenheits-Bewertung von 88 % (Jahr 2019) und 89 % (Jahr 2020) und zeigt
nach Greif und Benitte (ebd.) die höchste Zufriedenheit aller Frameworks nach der Verwendung. Auf
der anderen Seite bietet der Hypertext Markup Language (HTML) Standard, publiziert durch die Web
Hypertext Application Technology Working Group (WHATWG), eine Möglichkeit Komponenten (sog.
Custom Elements) mithilfe von nativen Browser-Technologien unabhängig von Drittanbieter-Software
zu erstellen (WHATWG 2021b).
Konzepte wie beispielsweise Micro frontends versuchen Modularität, auf einer höheren Abstraktions-
stufe zu erreichen. Parsons et al. (2020) empfehlen diesen Ansatz in ihrem Technology Radar als ein
sinnvolles Konzept, um ein Frontend in kleine wiederverwendbare Bausteine zu überführen und die-
sen Code vor allem in Teams zu strukturieren (vgl. Jackson 2019; Parsons et al. 2020).
Es ist somit klar, dass eine Vielzahl an Konzepten und Technologien existieren, mit denen im Frontend
agiert werden kann. Es ist nun Ziel, eine Entscheidung für eine Technologie zu treffen und sich mit der
Verwendbarkeit von Standard-Technologien zu beschäftigen. Diese Arbeit ist zwar in Zusammenarbeit
2
Svelte Team o.D.(b)
22016
2017
2018
2019
2020
React 93%
93%
91%
89%
89%
Svelte
Vue.js
87%
91%
91%
88%
88%
React
Angular
68%
66%
84%
87%
85%
Vue.js
Ember
47%
41%
45%
78%
82%
Alpine.js
41%
38%
78%
Preact
30%
78%
LitElement
67%
Stimulus
42%
Angular
27%
Ember
Abbildung 1.1.: Grad der Zufriedenheit von ausgewählten Frontend-Frameworks in den Jahren 2016 bis 2020 nach dem State
of JavaScript Trend Report. Technologien mit einer Bekanntheit von unter 10 % sind nicht inkludiert. (Ange-
passte Darstellung nach Greif und Benitte 2020a)
mit den Kooperationspartner und dem vorgestellten Softwareprojekt entstanden, jedoch wird versucht
die Fragestellungen in einem allgemeingültigen Kontext zu erschließen.
1.4. Forschungsfragen und Vorgehensweise
Die Arbeit soll dazu verwendet werden, den Web Component Standard für eine komponenten-basierte
Entwicklung im Frontend zu untersuchen. Dazu wird folgende Forschungsfrage formuliert (vgl. For-
schungsfrage 1).
Forschungsfrage 1 Wie ist die Verwendung von Web Standards im Hinblick auf Langlebigkeit in einem
komponent-basierten Frontend zu bewerten?
Die Forschungsfrage unterteilt sich in mehrere Teilaspekte, welche im Einzelnen untersucht werden
müssen. Da in der Forschungsarbeit ein Web Standard untersucht werden soll, müssen diese vorerst
beleuchtet werden (vgl. Leitfrage 1.1).
Leitfrage 1.1 Wie sieht der Prozess der Entwicklung von Web Standards aus und wie langlebig sind die
spezifischen Technologien?
Im speziellen soll der Web Components Standard untersucht werden, welcher eine komponenten-
basierte Entwicklung ermöglichen kann. Diese komponenten-basierte Entwicklung muss vorgestellt
werden, um Web Components einordnen zu können. Es müssen alternative Technologien beleuchtet
werden. Diese Anforderungen sind in Leitfrage 1.2 formuliert.
3Leitfrage 1.2 Welche Anforderungen und Prinzipien stehen im Zusammenhang der Komponenten-basierten
Entwicklung und mit welchen Technologien neben dem Web Components-Standards kann diese umgesetzt
werden?
Um eine Aussage über die Langlebigkeit treffen zu können, muss diese im Allgemeinen erörtertet wer-
den. Die Forschungsarbeit soll dazu genutzt werden, einen breiten Überblick über Konzepte der Lang-
lebigkeit zu geben (siehe Leitfrage 1.3).
Leitfrage 1.3 Welche Konzepte gibt es, um Software und Web Projekte langlebig zu gestalten?
Dies bietet die Möglichkeit, eine Bewertung im Kontext bestehender Konzepte aus nah und weit ver-
wandten Forschungsgebieten durchzuführen. Auch können und die Ergebnisse auf andere Anwen-
dungsfälle übertragen werden, um weitere Forschungsarbeiten zu motivieren.
42. Standards im Web
Das Web ist in seiner Kommunikation zwischen verschiedenen Clients und Servern von einer standar-
disierten Sprache abhängig. Im Bereich des Frontend-Development müssen die vom Server gesendeten
Daten durch die Render Engine des Browser geparsed (also „verstanden“) werden und dann in einer
bestimmten Art dargestellt werden (vgl. Mirian et al. 2019, S. 303; vgl. Grosskurth und Godfrey 2005).
Hierbei handelt es sich um Markup (Hypertext Markup Language, HTML), Styling (Cascading Style
Sheets, CSS), Scripte (JavaScript, JS) und/oder multimedia Dateien. Die Interpretation der Dateien ist
Aufgabengebiet der Browser-Entwickler:innen. Um ein gleiches bis ähnliches zu erwartendes Verhal-
ten auf allen Browsern zu erzielen, wurden verschiedene Web Features standardisiert (vgl. Mirian et al.
2019, S. 303). — Nach Mirian et al. (ebd.) seien Web Features als jegliches Browserverhalten zu verste-
hen, welches dem:der Entwickler:in einer Webseite zur Verfügung stünden. „We consider Javascript
functions, CSS properties and HTML elements as examples of web features“ (ebd., S. 303).
Diese Features werden von verschiedenen Arbeitsgruppen gepflegt. Spezifikationen der HTML-Elemente
der DOM-API werden von der Web Hypertext Application Technology Working Group (WHATWG)
durchgeführt. CSS wird weiterhin durch das World Wide Web Consortium (W3C) spezifiert. Die Spe-
zifikation der JS-Sprache liegt hingegen im Aufgabengebiet der Ecma International (vgl. Ecma Interna-
tional 2021).
2.1. Arbeitsprozess der Standardisierung
Für die beschriebenen Web Technologien und Sprachen sind unterschiedliche Arbeitsgruppen verant-
wortlich. Hierbei muss zwischen den Arbeitsgruppen, die dem World Wide Web Consortium (W3C)
unterstellt sind, und anderen Arbeitsgruppen unterschieden werden. Das W3C war lange Zeit für die
Standardisierung aller Web Technologien zuständig. Die Arbeitsgruppen, die die Spezifikation von CSS
verantwortet, ist die CSS Working Group (CSSWG)3 und Teil des W3C. Um den Arbeitsprozess dyna-
misch auf die Anforderungen der Browser-Hersteller und die allgemeine Web Community auszurich-
ten, wurde diese Verantwortung erst parallel-laufend und seit 2019 vollständig auf die Web Hypertext
Application Technology Working Group (WHATWG) übertragen (Jaffe 2019). Diese Arbeitsgruppe be-
steht aus den Browser-Entwickler:innen von Apple, Google, Mozilla und Microsoft und spezifiziert
mehrere Standards in kontinuierlicher Weise (WHATWG 2020).
3
Homepage der Arbeitsgruppe: https://www.w3.org/Style/CSS/; Letzter Zugriff: 10. August 2021
52.1.1. Arbeitsgruppen der W3C
Das World Wide Web Consortium (W3C) wurde von Tim-Berners Lee, dem Erfinder des World Wide
Web, gegründet. Es publiziert „protocols and guidelines that ensure the long-term growth of the Web.“
(vgl. W3C 2021a). Das W3C ist in Working Groups und Interest Groups unterteilt. In den Arbeitsgruppen
werden diese Protokolle und Guidelines als Artefakte diskutiert, welche dann für die Web Gemeinschaft
veröffentlicht werden. In Abbildung 2.1 ist dieser Prozess dargestellt. Die Interessensgruppen bieten
Foren für den Austausch von Ideen innerhalb einer Web Gemeinschaft, produzieren keine Artefakte
(vgl. W3C 2020c, Kap. 5).
In Abbildung 2.1 werden fünf Status beschrieben, in denen sich eine Spezifkation befinden kann. Als
Recommendation (REC) wird für Browser-Entwickler:innen und Entwickler:innen und anderen User
Agents empfohlen diese Spezifikation umzusetzen. Damit eine Spezifikation einen Status wechseln
kann, wird die Zustimmung eines W3C-Direktors benötigt. (vgl. ebd., Kap. 6.2)
Das W3C patentiert ihre Spezifikation als Patent Review Drafts unter der W3C Royalty-Free License.
Das W3C wolle dadurch garantieren, dass Artefakte unter dieser Lizenz für jede:n frei zugänglich und
verwendbar ist. (vgl. W3C 2020b)
WG Decision
WG Decision: review needed, or
CRD
No Change for 6 months
WG Decision +
WG Decision
Director's approval
Advisory Committee Review
Director's approval Director's approval Director's Decision
First Public WD
WD CR PR REC
WG decision
Director's approval WG or Director decision AC Review,
e.g. for further review Director Decision
e.g. for editorial changes
Advisory Committe review and Director's Decision, e.g. for further work and review
Abbildung 2.1.: „Recommendation Track“ des World Wide Web Consortium (W3C) (Eigene Darstellung nach W3C 2020c,
§ 6.2). — Working Draft (WD), Canditate Recommendation (CR), Canditate Recommendation Draft (CRD),
Proposed Recommendation (PR), Recommendation (REC)
2.1.2. WHATWG
Die Web Hypertext Application Technology Working Group (WHATWG) wurde 2004 von den führen-
den Browser-Herstellern Mozilla, Apple und Opera gegründet, um eine die HTML-Technologie entge-
gen den Entscheidungen des W3C weiter und schneller zu entwickeln. Das W3C hatte Pläne, die Weiter-
entwicklung der HTML-Spezifikation einzustellen. Die WHATWG wurde außerhalb des W3C gegrün-
det und verfolgt auch nicht die Arbeitsweise des W3C. Die Arbeitsgruppe wurde von den Browser-
Herstellern Mozilla, Apple und Opera gegründet, um eine die HTML-Technologie entgegen den Ent-
scheidungen des W3C weiter und schneller zu entwickeln. Seit 2017 sind Apple, Google, Microsoft und
6Mozilla Teil der Arbeitsgruppe. Sie bilden eine sogenannte Steering-Group. (vgl. WHATWG 2021b, Kap.
1.6)
Das W3C hat bis 2019 (vgl. Jaffe 2019) parallel Spezifikationen zur HTML-API und DOM-API veröf-
fentlicht. Ab 2019 wurde diese Verantwortlichkeit vollständig auf die WHATWG übertragen. Seitdem
existieren für die HTML-API und DOM-API reine Living Standards, die Funktionalitäten über Browser-
Entwickler:innnen hinaus vereinheitlicht (vgl. ebd.).
Die Besonderheit des Living Standard sind fehlende strikte Versionierungsnummern und Veröffentli-
chungszeitpunkte. Zu spezifizierende Funktionalitäten werden als empfohlen (Englisch: Recommenda-
tion (REC), siehe Abbildung 2.2) deklariert, wenn sie ausreichende Zustimmung der Steering Group
erhalten und mögliche Auswirkungen der Spezifikation-Veränderung diskutiert wurden. Im Vergleich
zu dem W3C-Prozess (vgl. Abbildung 2.1) sind in dem in Abbildung 2.2 beschriebenen Prozess weniger
Status vorgesehen. Die Status CR, PR und REC seien mit dem Status des Review Drafts gleichzustel-
len. Um die in Unterabschnitt 2.1.1 vorgestellte Patentierung weiterhin zu garantieren, werden diese in
Form von Review Drafts regelmäßig veröffentlicht (vgl. Abbildung 2.2). Nach Vorstellungen der WHAT-
WG sind Spezifikation, die in dem Living Standard veröffentlicht sind, empfohlen, und benötigen keine
Veröffentlichung durch das W3C.
Web Feature Proposal
Discussion and Review by
Community and Implementors
Support from implementors;
Automatic Tests included;
Review by community member Implementaion
Active Living Standard Browser
Submitter's Decision;
Submitter's Decision Implementor's
Recommendation
periodical publishing
due to patent rights
Passive
independent development of proposed feature
unregualar feedback by community W3C Review Drafts
Abbildung 2.2.: Schematische Darstellung des Arbeitsprozess für die WHATWG. Ein Proposal ist nach Review und Unterstü-
zung der Community und Browser-Entwickler:innen Teil des Living Standards. (Zusammenfassende eigene
Darstellung nach WHATWG 2020)
Die WHATWG stellt in ihrem Arbeitsprozess die unterschiedlichen Arten, sich an dem Living Standards
zu beteiligen, vor. Neben der Erweiterung des Living Standards kann sich jeder an der Diskussion und
dem Review von Web Features beteiligen oder mit Hinweisen auf ein möglicherweise fehlerhaftes und
standard-unkonformes Verhalten in Browsern helfen. Der Arbeitsprozess ist öffentlich einsehbar und
wird über GitHub in mehreren Repositories4 geregelt. Eine Änderung bedarf der Zustimmung durch
4
Siehe bspw. das Repository für die DOM-API (https://github.com/whatwg/dom) mit 146 offenen Issues und 15 offenen
Pull Requests (Letzter Zugriff: 8. Juli 2021)
7Browser-Entwickler:innen, da diese das Verhalten umsetzen müssen (WHATWG 2020). Es kann disku-
tiert werden, ob dieses Veto-Recht der Steering-Group die Machttypologie in der Entscheidungsfindung
stark beeinflusst.
2.2. Lebenszeit von Web Standards
Um eine Aussage über die Lebenszeit eines Standards, also die Dauer der Browser-Unterstützung, tref-
fen zu können, muss das Verhalten bei bereits veralteten Web Features untersucht werden. Es gibt wenig
Literatur, dass dieses Verhalten untersucht. Vor allem konnten für Arbeitsprozesse nach dem W3C (vgl.
Unterabschnitt 2.1.1) keine Ergebnisse gefunden werden. Aus der Sicht der Browser-Entwickler:innen
untersuchten Mirian et al. (2019) für den Arbeitsprozess der WHATWG den Veraltungsprozess. Sie ver-
suchten den Prozess des Chrome-Entwickler:innen-Teams, bestimmte Web Features als veraltet (Eng-
lisch: deprecated) zu markieren, zu vereinheitlichen. Hierzu haben Mirian et al. Gründe der Browser-
Entwickler:innen ermittelt, bestimmte Web Features nicht mehr zu unterstützen. Sie untersuchten 123
Anfragen, die Unterstützung von Web Features einzustellen. Dabei konnten folgende Gründe mit je-
weiligem Anteil ermittelt werden (vgl. ebd., Tabelle III, S. 205):
• Sicherheit („Security“): „Feature was deprecated because of security flaw or concern“ (21,36 %)
• Niemals Standardisiert („Never Standardized“): „Experimental web feature was never stan-
dardized“ (16,23 %)
• Neuerer Standard („Updated Standard“): „Feature or attribute was deprecated because the
standard was updated“ (10,25 %)
• Aus dem Standard entfernt („Removed from Standard“): „Feature was removed from the
standard“ (19,65 %)
• Uneinheitliche Implementierung („Inconsistent Implementation“): „Buggy or inconsis-
tent implementation of the feature spec“ (10,25 %)
• Sauberes Erlebnis („Clean Experience“): „Removing the feature provides a less confusing ex-
perience for web developers“ (22,22 %)
Es fällt auf, dass die meisten Änderungen aufgrund von Sicherheitsproblemen oder einer besseren
Entwickler:innen-Experience verändert wurden.
Mirian et al. erörterten die Risiken, die bei Entfernen von Web Features auftreten können. Werden
Funktionen von zu vielen Entwickler:innen in ihren Projekten verwendet oder verwenden zu viele
Webseiten mit den meisten Nutzer:innnen diese Technologien, kann ein nicht erwartetes Verhalten
auftreten. Sie beschreiben dies allgemein als den Ripple effect. „An unsuccessful deprecation can turn
users away from the browser.“ (vgl. ebd., S. 303 f.)
Um diese Risken zu minimieren, haben Mirian et al. Metriken für Browser-Entwickler:innen bereit-
gestellt, die bei Entscheidungen, einen Web Feature als veraltet zu markieren, unterstützend wirken
sollen. Dabei sollen die durch den Chrome Browser aggregierten Daten, wie der User Metrics Analysis
8(UMA)5 und User Keyed Metrics (UKM)6 , und öffentlich-zugänglichen Daten, wie dem HTTP Archive7
und CanIUse8 , über die geringe Nutzung der Web Features garantieren (vgl. Abbildung 2.3).
If Below
Pick appropriate Check that UMA + Thresholds Sanity check
category for your HTTP Archive counts
with UKM
feature are below threshold
Some time If Below
If Above Threshold
after outreach Threshold
is completed
Verify Cross Browser
Outreach with
Implementation with
Analysis via UKM
CanIUse?
Deprecate
Feature
Abbildung 2.3.: Entscheidungsflussdiagram für Browser-Entwickler:innen Web Features zu veralten (Erweiterte eigene Dar-
stellung nach Mirian et al. 2019, S. 308)
Erst wenn die Werte durch die genannten Metriken unter definierte Schwellenwerte fallen, kann ein
Web Feature als veraltet markiert werden. Dieser Schwellenwert ist abhängig von der Kategorie des
Verwurfsgrundes und der Datenquelle. Er liegt nach Mirian et al. für alle Kategorien bei einer Nutzung
zwischen 0,08 % und 0,002 %. Die Kategorie der Clean Experience liegt mit dem Schwellenwert von
0,22 % bis 0,13 % höher als bei den anderen Kategorien. (vgl. Mirian et al. 2019, S. 306 – 307)
Eine genaue und allgemeingültige Aussage über die Lebenszeit von bestimmten Web Features kann
nicht getroffen werden. Der Arbeitsprozess der WHATWG (vgl. Unterabschnitt 2.1.2) und des Google
Chrome Teams lassen darauf schließen, dass Standards nur mit besonderer Vorsicht verworfen und
aus Browsern entfernt werden. Sie hängt mit großen Teil von der Resonanz der Web-Entwickler:innen
weiltweit ab. Diese Resonanz wird in Anzahl von Web Projekten gemessen, die einen spezifischen Web
Feature verwenden.
5
Prozentualer Anteil an Seitenaufrufen und Clients pro Funktion für den Chrome Browser. Daten sind öffentlich unter
chromestatus.com einsehbar (vgl. Mirian et al. 2019, Tabelle IV, S. 305).
6
Prozentualer Anteil an eindeutigen Domains und Clients pro Funktion. Daten sind nur intern einsehbar (vgl. ebd., Tabelle
IV, S. 305).
7
Anzahl der 500.000 beliebtesten Domains, die Feature verwenden (vgl. ebd., Tabelle IV, S. 305).
8
Aktuelle und historische Liste von Browser-Versionen, ob bestimmte Browser Features unterstützt werden. (vgl. ebd., Ta-
belle IV, S. 305).
93. Komponenten-basierte Entwicklung
In Kapitel 2 wurden Web Standards im Übergeordneten diskutiert. Nun sollen die ausgewählten Stan-
dards um Web Components untersucht werden. Um diesen Standard einordnen zu können, wird dieser
im Kontext der komponenten-basierten Entwicklung im Allgemeinen und in Kontrast zu Dritt-Anbieter-
Projekten untersucht.
3.1. Allgemein
Die komponenten-basierte oder komponenten-getriebene Entwicklung geht davon aus, ein System in
mehrere wohldefinierte, kleine, wiederverwendbare Fragmente zu unterteilen. Das Prinzip der Modu-
larität für die Software-Entwicklung wurde bereits 1972 von Parnas als Mechanismus zur Flexibilität
und Verständlichkeit eines Systems diskutiert9 .
Nach Fowler (2015) sind Komponenten „things that are independently replaceable and upgradeable“
(ebd.). Er hebt hierbei die Eigenschaften der Unabhängigkeit und Autonomie jeder Komponente hervor.
Jede Komponente definiert seine eigene Schnittstelle und kann ohne Absprache von anderen Kompo-
nenten versioniert werden, da sich nach Fowler der Kommunikationsvertrag zwischen den einzelnen
Komponenten nicht ändern darf (vgl. ebd.).
Crnkovic et al. (2005) heben hervor, dass die Komponenten-basierte Entwicklung (Englisch: Component-
based Software Engineering, CBSE) einen besondere Arbeitsweise erfordert. Im Lebenszyklus der Software-
Entwicklung wird das technische System aus bereits bestehenden Komponenten generiert. Somit sei der
Prozess der Komponenten-Entwicklung von der System-Entwicklung systematisch zu trennen. Werden
neue Komponenten für das technische System benötigt, muss ein parallel-verlaufender Prozess initiiert
werden. (vgl. ebd., Kap. 3.1.)
Es gibt mehrere Ansätze, welche die komponenten-getriebene Entwicklung umsetzen und im anderen
Fall auf weitere Fachdisziplinen übertragen. Ein Teil dieser werden nun erläutert:
• Atomic Design
Frost (2016) entwickelte eine Sprache Design-Systeme zu strukturieren. Ziel war es Interaktions-
Komponenten wiederverwendbar zu machen und sie einheitlicher zu gestalten. — „Consistency
and Standards“ ist eine Heuristik nach Nielsen (1994) in der Interaktionsgestaltung. — Frost (2016)
erweiterte die Buch-Metapher von Web-Seiten und unterteilte diese in mehreren Abstraktions-
stufen und nutzte hierbei die Metaphern aus der Chemie: Atome, Moleküle und Organismen (vgl.
ebd.). Frost betont hierbei, dass einzelne Komponenten aus anderen Komponenten bestehen kön-
9
Parnas (1972): „On the Criteria to Be Used in Decomposing Systems into Modules“
10nen und miteinander kombiniert werden können. Dabei sind grundlegenden Gestaltungselemen-
te wie Farbe, Schrift und Form außerhalb dieser Metapher. Atome sind die Bausteine, die nicht
mehr unterteilt werden können und aus denen Moleküle, also größere Gestaltungs- und Inter-
aktionsblöcke entstehen. Von Organismen wird gesprochen, wenn ein Gestaltungsobjekt erneut
in Zusammenspiel mit weiteren Molekülen eine Einheit bilden kann und an anderen Stellen des
Gestaltungs- und Interaktionskonzeptes verwendet werden können. (vgl. Frost 2016)
• Micro Services
Auf Server-Architekturebene wurde der komponenten-getriebene Ansatz in Form von Micro-
Services aufgezeigt. Hierbei werden einzelne voneinander unabhängige Services als Komponen-
ten entwickelt, über die die gesamte Anwendungslogik verteilt wird. Für besonders große oder
schnell wachsende Systeme ist es sinnvoll, den Server in mehrere Komponenten zu unterteilen,
da Anfrage-Lasten besser verteilt werden können, aber auch einzelne Teams autonom über die
Funktionsweise der Komponente entscheiden können. Durch die Vielzahl an Komponenten und
die zu pflegende Kommunikation zwischen den Komponenten steigt die Komplexität im Vergleich
zu einem monolithischen System. (vgl. Lewis und Fowler 2014)
• Micro Frontends
Jackson (2019) stellte Micro Frontends als eine Erweiterung des Micro Services Konzept vor. Er de-
finiert diese als einen „architectural style where independently deliverable frontend applications
are composed into a greater whole“ (ebd.). Die Komponten, die hier zusammengetragen wer-
den, sind ganze Organismen oder Seiten, die von autonom arbeitenen Teams gepflegt werden.
Klimm (2021) untersuchte in seiner Bachelorarbeit einen framework-agnostischen Ansatz diese
Microfrontends mit einander zu verbinden.
Es wurden die komponenten-getriebene Entwicklung im Bereich der allgemeinen Software-Entwicklung,
des UI-Design, Server-Architektur und auf einer hohen Abstraktion im Frontend vorgestellt. Im Folgen-
den soll sich der Begriff der Komponente auf eine technische Implementierung einer UI-Komponente
beschränken. Dabei können sich diese auf allen Abstraktionsstufen nach Frost (2016) befinden.
3.2. Der Web Components Standard
Der Web Components Standard ist ein Zusammenschluss von Web Standards, mit denen es möglich ist,
wiederverwendbare Komponenten zu definieren. Diese sind „voll funktionsfähige DOM-Elemente“, die
entweder bestehende standardisierte Elemente erweitern oder eigenständig fungieren. (vgl. WHATWG
2021b, § 4.13.3)
Der Standard wurde in einem ersten Proposel mit Version 0 im Jahr 2014 hauptsächlich durch das Goo-
gle Chrome Team entwickelt und veröffentlicht. Seit 2016/2017 ist die aktuelle Version 1 veröffentlicht.
Seit 2020 ist beispielsweise Version 0 endgültig aus dem Chrome Browser entfernt worden. Teil der Ver-
sion 0 war unter anderem ein Proposal für HTML-Importierung, welches nicht in Version 1 übertragen
wurde. (vgl. Google Chrome o.D.)
113.2.1. Browser-API
Die API, wie standardisiert durch die WHATWG, bietet mehrere Interfaces und Schnittstellen an, die
in diesem Abschnitt diese vorgestellt werden.
Web Components werden über das CustomElementRegistry-Interface10 definiert (vgl. WHATWG 2021b,
§ 14.3.4). Hierzu wird eine JS-Klasse, welche das standardisierte HTMLElement-Interface11 erweitert, er-
stellt. Diese definiert die Funktionsweise der Komponente. Der müssen diese mindestens ein „–“ im Tag-
Namen haben, um zukünftige Erweiterungen der standardisierten HTML-Tags zu ermöglichen (siehe
Codebeispiel 3.1 in Zeile 24 und Codebeispiel 3.2).
1 class ShowlistComponent extends HTMLElement {
2 static template() {
3 return `
4
5 Shows
6
7
8 `;
9 }
10
11 constructor() {
12 super();
13 this.root = this.attachShadow({ mode: 'open' });
14 this.root.innerHTML = this.constructor.template();
15
16 const template = this.root.querySelector('template');
17 const clone = template.content.cloneNode(true);
18 this.root.appendChild(clone);
19 }
20
21 static get observedAttributes() { return []; }
22 }
23
24 window.customElements.define('tickets-showlist', ShowlistComponent);
Codebeispiel 3.1: Ein Web Component definiert über das CustomElementRegistry-Interface und kann über
in die DOM Struktur eingepflegt werden.
Es ist bekannt, dass HTML-Dokumente nach dem Empfangen und Parsen im Browser in eine Baum-
struktur überführt werden (vgl. Grosskurth und Godfrey 2005). Diese Baumstruktur wird Document
Object Model (DOM) genannt. In dieser Baumstruktur wird das -Tag als Wurzel-Knoten reprä-
sentiert. Alle weiteren Elemente sind Kinder dieses Knoten. Über die DOM-API (spezifiert durch die
WHATWG) können diese Knoten erweitert, verändert und gelöscht werden.
10
für Interface Definition Language (IDL) siehe WHATWG 2021b, § 4.13.4.
11
für IDL siehe WHATWG 2021a, § 3.2.2.
12Da Custom Elements die Liste der durch den Browser erkennenden HTML-Tags erweitert, können
diese als Kinder von bestehenden DOM-Knoten dynamisch oder deklarativ (d.h. in dem versendeten
HTML-Dokument) eingefügt werden. Verändert sich ein Element, kann mit Hilfe spezifierter Lifecycle-
Callbacks auf diese reagiert werden. Es werden mehrere Funktionen zur Verfügung gestellt (vgl. WHAT-
WG 2021b, § 14.13.6; vgl. MDN 2021b):
• constructor
Die Konstruktor-Funktion der JS-Klasse wird aufgerufen, wenn eine neue Instanz des Elements
im Client-Speicher angelegt wird.
• connectedCallback
Wird aufgerufen, wenn das Element in die DOM-Struktur eingepflegt. Es wird sichergestellt sein,
dass das Element seine relative Position im DOM-Baum kennt. Der Inhalt des Elements muss
nicht zwingend geparsed sein.
• disconnectedCallback
Wird aufgerufen, wenn das Element aus der DOM-Struktur entfernt wird. Bei einem Entfernen
kann es sich um eine Verschiebung im Baum handeln.
• adoptedCallback
Wird aufgerufen, wenn das Element sich in einer neuen document-Umgebung befindet. Dies kann
durch den Document.adoptNode() Befehl geschehen, indem ein Element beispielsweise in ein
iframe verschoben wird (vgl. WHATWG 2021a, § 4.5).
• attributeChangedCallback
Bei Änderung der Attribute eines Elements wird die Funktion mit dem vorherigen Wert und
neuem Wert aufgerufen. Das Element muss hierfür nicht in die DOM-Struktur eingepflegt sein.
Shadow-DOM
Um die Komposition von weiteren Nodes zu erzielen, haben Custom Components einen Shadow-DOM.
Dies ist ein versteckter und parallel verlaufender DOM-Baum (siehe Abbildung 3.1). Um beide Bäu-
me unterscheiden zu können, wird der bekannte Baum Document-DOM und der neue Baum Shadow-
DOM genannt. Elemente, die sich in diesem Shadow-DOM befinden, sind außerhalb nicht sichtbar und
können nicht direkt über beispielsweise Query-Selektoren angesprochen werden. Hierzu müssen von
der shadowRoot-Property DOM-Selektionen und -Manipulationen ausgeführt werden. Über die mode-
Eigenschaft mit der Ausprägung closed ist es möglich, dass Styles und andere DOM-Operationen,
die außerhalb des Schadow-Baums definiert werden, keinen Einfluss auf die Elemente innerhalb des
Shadow-Baums haben. Somit ist es möglich, vollständig gekapselte Komponenten in einer DOM-Struktur
zu erstellen.
Styles können mithilfe von Inline-Style-Blöcken, die sich innerhalb des Shadow-DOM befinden, gesetzt
werden. Diese CSS Regeln beeinflussen nur diesen Teil des DOM-Baums. Auch können die Regeln mit
Hilfe des -Elements aus einer externen CSS-Datei geladen werden (vgl. MDN 2021c).
Wird von einem offenen Shadow-DOM ausgegangen, ist es möglich, über entsprechende CSS-Selektoren
von außen Elemente im Shadow-DOM zu stylen. In der CSS Shadow Parts und CSS Scoping Module Le-
13Flattened Tree (for rendering)
document
Document Tree
document
shadow
Shadow Tree host
shadow shadow
host root
Shadow
Tree
Shadow Boundary
Abbildung 3.1.: Schematische Darstellung eines Shadow-DOMs in dem Document-DOM. Jede Kreis in der Darstellung ent-
spricht einem Node/Element in der DOM-Struktur. Der Ursprung des Schadow-Trees ist sowohl Shadow-Host
und Shadow-Root. (MDN 2021c)
vel 1 werden diese Pseudo-Selektoren durch die W3C (2020a, 2021b) spezifiert. Zur Verfügung gestellt
wird der :part()-Pseudo-Selektor, um bestimmte Teile des Shadow-DOMs zu selektieren. Diese müs-
sen mit einem part Attribut besetzt sein. Zu dem wird der :host()-Pseudo-Selektor spezifiziert, um
das Root-Element außerhalb des Shadow-DOM zu selektieren. Dadurch können Styles aufgrund von
Attributen und Klassen des Root-Elements im Document-DOM gesetzt werden. (W3C 2020a, 2021b)
HTML-Template
Die DOM-Struktur im Schatten-Baum kann dynamisch die Funktionen document.createElement12 er-
stellt werden, um jeden Node einzeln zu erstellen und in die Baumstruktur einzupflegen. Das -
Element ist dafür da, eine solche Struktur zu definieren. Diese kann in die HTML-Struktur eingefügt
werden, ohne dass sie durch die Render-Engine des Browsers angezeigt wird. Um die Validität des
HTML-Struktur zu sichern, wird das -Element geparsed. (vgl. MDN 2021a)
Slot
Custom Elements können nicht nur Kinder im Schatten-Baum, sondern auch in der Baum-Struktur des
Shadow-Host (gegebenenfalls ist das der Document-DOM) haben. Damit diese durch die Render Engi-
ne angezeigt werden, müssen diese eine Verbindung in den Schatten-Baum haben. Diese Verbindung
wird durch das -Element erzeugt, welches im HTML-Template definiert wird. Werden mehre-
re -Elemente in einem Template definiert, kann eine Differenzierung über eine Benennung des
Slots erzielt werden, die dann bei Slotables, also Elemente und Texte, als Attribut festgelegt wird. (vgl.
WHATWG 2021a, § 4.2.2; vgl. WHATWG 2021b, § 4.12.4)
Wird eine Referenz für das -Element im Document-DOM nicht gesetzt und hat das -
Element Kind-Elemente im Template, werden diese standardmäßig angezeigt. Dadurch kann ein Fallback-
Verhalten erzielt werden. (vgl. WHATWG 2021a, § 4.2.2.1)
12
für IDL siehe WHATWG 2021a, § 4.5.
14Erweitern von nativen Elementen
Wie bereits erwähnt ist es möglich, nicht nur eigene HTML Elemente zu definieren, sondern auf Grund-
lage standardisierter Elemente eigene Elemente zu erstellen. Hierbei muss bei Definition der Element-
Klasse nicht von der HTMLElement-Klasse sondern von der jeweiligen Elementen Klasse vererbt werden.
Wird beispielsweise die Funktionalität des -Elements erweitert, muss die Web Components
Klasse das HTMLButtonElement13 -Interface erweitern. In der HTML-Struktur wird der Web Component
über das is-Attribut referenziert (siehe Codebeispiel 3.2).
1 1
2 Children in the Document DOM. 2 Children in the Document DOM.
3 3
(a) Ein Custom Element mit eigenem Namen und Kin- (b) Ein Natives Element, welches um eine Web Com-
dern im Doucment DOM. ponents Funktionalität erweitert wurde.
Codebeispiel 3.2: Web Components Elemente in einer DOM-Struktur
3.2.2. Zukünftige Proposals in der WHATWG
Die Entwicklung der Spezifikation für Web Components ist durch die WHATWG und die Community
nicht abgeschlossen. Zum Zeitpunkt der Erstellung dieser Arbeit unteranderem diese zwei Vorschläge
zur Erweiterung des Standards diskutiert:
• Declarative Shadow-DOM:14
Die Inhalte des Schatten-DOMs sollen in die HTML-Struktur als Kind des Web Components de-
finiert werden. Diese werden, dann automatisch beim Parsen übersetzt.
• Standardize variables and event handlers:15
Variablen in Templates sollen automatisch erkannt und mit bestimmten Werten belegt werden.
Diese Vorschläge führen weitere Möglichkeiten in der Arbeit mit Web Components ein und sind aber
noch kein Standard. Somit wird die Auswirkung und genauen Umsetzungen dieser Vorschläge nicht
weiter diskutiert.
3.2.3. Browser-Support
Wie in Abschnitt 2.2 beschrieben sind für einen Standard zwei Metriken entscheidend: Zum einen die
Unterstützung der Browser, zum anderen die verbreitete Verwendung unter Web-Entwickler:innnen.
Der Standard um die Web Components ist in der aktuellen Version v1 seit 2016/2017 publiziert, sodass
Browser-Entwickler:innen diese umsetzen konnten. Deveria stellte eine Liste mit dem Technologie-
Support vieler Browser zur Verfügung. Im Anhang A ist eine Tabelle mit dem Browser-Support für die
13
für Interface Definition Language (IDL) siehe WHATWG 2021b, § 4.10.6.
14
Proposal auf GitHub: https://github.com/whatwg/dom/issues/831; Letzter Zugriff: 10. August 2021
15
Proposal auf GitHub: https://github.com/whatwg/dom/issues/2254; Letzter Zugriff: 10. August 2021
15Web Technologien, die für Web Components gebraucht werden. Dazu gehören Custom Elements, Shadow
DOM, HTML Template und ES Modules. Es fällt auf, dass eine breite Anzahl an Browsern unter vielen
Betriebssystemen die Technologien um Web Components unterstützen. Der Internet Explorer (IE) hat
mit einer weltweiten Nutzung von 1,10 % keine Unterstützung für die benötigten Web Technologien.
Die Firma Microsoft wird ab Juni 2022 seine Unterstützung für den IE endgültig einstellen (vgl. War-
ren 2021). So kann dieser Browser von der Liste der zu unterstützenden Browser genommen werden.
Apples Safari-Browser (macOS 14.1 & iOS 14.5, vgl. Anhang A) ist nach Deveria (o.D.[a]) der einzige
Browser, der die Erweiterung von nativen Elementen über das is Attribut nicht unterstützt. Um eine
genaue Aussage zu treffen, ob Benutzer:innen des zukünftigen Systems Browserarten und -versionen
verwenden, die diese Standards nicht verwenden, müssten empirische Untersuchungen in Form von
Umfragen, Interviews oder Untersuchungen im Nutzerverhalten durch Analytic-Tools durchgeführt
werden.
Alternativ gibt es Konzepte, wie mit Technologien umgegangen werden kann, die in bestimmten Brow-
sern nicht unterstützt werden. Zu unterscheiden sind hierbei die beiden Gestaltungsphilosophien Gra-
cefull degregation und Progressive Enhancement. Sie unterscheiden sich in ihrer Grundannahme, welche
Features verwendet werden können. Bei der Gracefull degregation wird der Fokus auf die neusten Brow-
ser gesetzt und deren Web Features genutzt. Für ältere Browser werden Fallbacks zur Verfügung gestellt,
die die Browser-Funktionalität imitieren (vgl. MDN 2020a). Bei dem Konzept des Progressive Enhance-
ment werden Funktionalitäten verwendet, die von der Breite der von den Benutzer:innen verwende-
ten Browser unterstützt werden. Bietet ein Browser die Unterstützung für bestimmte Funktionalitäten,
kann die geladene Webseite um diese erweitert werden (vgl. MDN 2020b). Eine beispielhafte Anwen-
dung der Progressive Enhancement ist die Verwendung von erweiterten HTML-Elementen. Sollte der
Browser Web Components nicht unterstützen, greift das standardisierte Verhalten des jeweiligen Ele-
ments. Bei Browsern mit Unterstützung von Web Components wird das eigene Verhalten ausgeführt.
Für den Web Components Standard gibt es die Möglichkeit über einen Polyfill einen Teil der Funktionen
zu imitieren. Der Begriff des Polyfills wurde von Sharp (2010) geprägt und ermöglicht Gracefull degre-
gation von Web Features (MDN 2020a). Ein Polyfill16 , der von webcomponents.org angeboten wird,
unterstützt dabei nicht alle Funktionalitäten des Web Component Standard. So is beispielsweise die
Kapselung von CSS-Styles nicht möglich.
3.2.4. Libraries
Um die Web Components sind mehrere Libraries entstanden, die eine höhere Abstraktionsstufe des
Web Standards haben. Sie bieten die Möglichkeit, häufig wiederholenden Code sogenannter Boilerplate-
Code zu vermeiden. Dies wird dadurch ermöglicht, dass die Registrierung und Validierung von Attri-
butänderungen und auch das Templating automatisiert und vereinfacht wird.
Neben dem in der Einleitung erwähnten Projekt Polymer haben die Entwickler:innen von Google das
Projekt Lit 17 veröffentlicht (vgl. Polymer Project Authors 2018). In dem Library-Paket ist unteranderem
16
GitHub-Repository: https://github.com/webcomponents/polyfills/tree/master/packages/webcomponentsjs/;
Letzter Zugriff: 10. August 2021
17
GitHub-Repository: https://github.com/lit/lit/; Letzter Zugriff: 10. August 2021
16auch das LitElement Projekt enthalten. Es stellt unteranderem das Parsing von HTML in der JS-Klasse
zur Verfügung. Außerdem werden bei Attributänderungen automatisch die Werte in den entsprechen-
den Typ überführt und in anderen Fällen für ein bestimmtes Format validiert. (vgl. Google, Inc. o.D.)
Viele Frameworks, die im folgenden Abschnitt 3.3 vorgestellt werden sollen, bieten die Möglichkeit Web
Components automatisch aus ihren Definitionen zu generieren. Somit ist der Code zur Laufzeit unab-
hängig von der verwendeten Technologie, oder es kann im weiteren Entwicklungsprozess vollständig
mit Web Components gearbeitet werden. (vgl. bspw. React Team o.D.[b])
3.3. Dritt-Anbieter Frameworks
A framework is a semi-complete application. A framework provides a reusable, common struc-
ture to share among applications. Developers incorporate the framework into their own appli-
cation and extend it to meet their specific needs. Frameworks differ from toolkits by providing
a coherent structure, rather than a simple set of utility classes. — Tahchiev et al. 2011, S. 4
Frameworks im Bereich des Web-Frontends bieten Webseiten-Entwickler:innen die Möglichkeit, Kom-
ponenten auf einer höheren Abstraktionsstufe zu erstellen. Dabei bieten sie ein einheitliches Rahmen-
werk, um Funktionalitäten für verschiedene Browser und anderen Entwickler:innen zu vereinheitli-
chen. In diesem Kapitel werden mehrere Frameworks vorgestellt, wobei die gemeinsamen Konzepte
und verschiedenen Umsetzungen für ähnliche Probleme näher erläutert werden. Hierbei handelt es
sich rein um JS-Frameworks für die Frontend-Entwicklung, mit denen UI-Komponenten erstellt wer-
den können. Ausgewählt wurden hierbei die nach Greif und Benitte (2020a) das am meisten verwendete
Frontend-Framework React. Auch wurde Svelte ausgewählt, da es das jüngste und zugleich das belieb-
teste Framework aus der Liste nach Greif und Benitte (ebd.) ist (vgl. Abbildung 1.1 auf Seite 3).
Semantische Versionierung Die folgenden Abschnitte werden auch die Releases der zu untersu-
chenden Frameworks behandeln. Um Versions-Namen unterscheidbar zu machen, hat Preston-Werner
(2013) das System des Semantic Versioning entwickelt. Er schlägt vor Versions-Nummern in drei Teile zu
unterteilen: (i) Major, (ii) Minor und (iii) Patch (bspw. 1.4.2). Dabei führen Major-Releases Änderungen
ein, die nicht mit vorherigen Versionen kompatibel sind (auch Breaking Changes genannt). Minor- und
Patch-Version sind hingegen rückwärtskompatibel. Preston-Werner führte des Weiteren Möglichkeiten
ein, um Releases als unfertigen Release — also alpha oder beta — zu markieren. (vgl. ebd.)
3.3.1. Vergleichsmetriken für Drittanbieter Software
Um die ausgewählten Frameworks mit vorstellen zu können und in Teilen auch vergleichen zu kön-
nen, müssen Metriken ermittelt werden. Larios Vargas et al. (2020) untersuchten in einer Erhebung
Gründe, die bei einer Auswahl von Frameworks, Libraries und APIs in der Industrie verwendet wer-
den. Sie ermittelten 26 Faktoren, die in die Kategorien Technical factors, Human factors und Economical
factors unterteilt werden. Larios Vargas et al. unterscheiden in ihren Ausführungen, ob die Metriken
zum Anfang der Konzeption („up-front phase“) oder im späteren Verlauf („prototyping phase“) verwen-
17Sie können auch lesen
