© Excellent backgrounds/Shutterstock.com
Java Magazin
Design Patterns für HTML

Web Components - Softwaredesign fürs Frontend

„Ist doch nur das Frontend“ - das ist ein Satz, der bei Enterprise-Anwendungen mit komplexer Geschäftslogik im Backend durchaus auf „die paar“ benötigten Webformulare zutreffen mag. Doch wie ist dieser Satz in Zeiten zu bewerten, in denen „Joy of Use“ immer mehr in den Vordergrund tritt? Immer anspruchsvollere Single Page Applications erhöhen die für das Frontend benötigten Budgets. Der erfahrene Backend-Entwickler ist geneigt, Paradigmen wie Wiederverwendung und Ersetzbarkeit auch für das Frontend anwenden zu wollen. Web Components könnten diesen Wunsch technologieübergreifend erfüllen.

Dirk Dorsch


Der Anspruch an ein modernes Web-Frontend wächst zusehends. Während vor einigen Jahren noch einfache, serverseitig gerenderte Formulare für viele Webapplikationen genügten, gehören heute Single-Page-Applikationen mit gefühlt keiner Ladezeit zum Standard. Webseiten werden heute häufig nach dem „Mobile First“-Paradigma in responsivem Design entworfen. Um es dem Webentwickler möglichst einfach zu machen, haben sich zahlreiche UI-Frameworks etabliert, die jedem Projekt einen schnellen Start für ein responsives Layout geben (mit der Nebenwirkung, dass viele Webseiten gleich aussehen).

Mit wachsendem Anspruch an die Usability steigen auch die Investitionskosten für das Frontend. Die Entscheidung für ein UI-Framework führt zu einer nahezu vollständigen Abhängigkeit des UI-Codes zur gewählten Technologie. Somit hat ein nicht trivialer Teil der Software starre Abhängigkeiten zu technologischen Belangen. Ein Austausch dieser Basistechnologie kommt dann ebenso selten in Frage wie in der Backend-Entwicklung der Austausch des zugrunde liegenden Webframeworks. In beiden Fällen ist der Wechsel des Basisframeworks mit erheblichen Kosten verbunden. Im Backend ermöglichen Frameworks wie Spring die weitgehende Abstraktion der Geschäftslogik von den technischen Belangen und ermöglichen so den Erhalt der Geschäftslogik über den Frameworkwechsel hinaus. Eine Indirektionsschicht hier, ein bisschen Dependency Injection da, und die Architekturentscheidung hat zumindest nicht mehr den Charakter einer gefühlt unumkehrbaren Endgültigkeit.

Neben der Unabhängigkeit der Geschäftslogik hat sich ebenso der Gedanke der Wiederverwendung einzelner Softwarekomponenten, unabhängig ob technischer / querschnittlicher Belang oder Geschäftslogik, etabliert. Nach ein paar Jahren Java-Entwicklung ist die Trennung der unterschiedlichen Belange in Packages und deren anschließende Kapselung in zu Wiederverwendung isolierten .jar-Files zum Automatismus geworden. Die sich hieraus zwangsläufig ergebenden Probleme transitiver Abhängigkeiten und komplexer werdender Builds sind durch Maven, Ivy, Gradle und Co. einfach in den Griff zu bekommen.

Wiederverwendung im Web

Nahezu alle Webframeworks, gleich ob serverseitiges Templating oder clientseitige Single Page Application (SPA), bringen Mechanismen zur Modularisierung und Wiederverwendung von Markup und Style Sheets mit. So verfügen beispielsweise JavaServer Pages (JSP) und (Grails-)Groovy Server Pages (GSP) über Taglibs und Templates. Das Google Web Toolkit...

Java Magazin
Design Patterns für HTML

Web Components - Softwaredesign fürs Frontend

„Ist doch nur das Frontend“ - das ist ein Satz, der bei Enterprise-Anwendungen mit komplexer Geschäftslogik im Backend durchaus auf „die paar“ benötigten Webformulare zutreffen mag. Doch wie ist dieser Satz in Zeiten zu bewerten, in denen „Joy of Use“ immer mehr in den Vordergrund tritt? Immer anspruchsvollere Single Page Applications erhöhen die für das Frontend benötigten Budgets. Der erfahrene Backend-Entwickler ist geneigt, Paradigmen wie Wiederverwendung und Ersetzbarkeit auch für das Frontend anwenden zu wollen. Web Components könnten diesen Wunsch technologieübergreifend erfüllen.

Dirk Dorsch


Der Anspruch an ein modernes Web-Frontend wächst zusehends. Während vor einigen Jahren noch einfache, serverseitig gerenderte Formulare für viele Webapplikationen genügten, gehören heute Single-Page-Applikationen mit gefühlt keiner Ladezeit zum Standard. Webseiten werden heute häufig nach dem „Mobile First“-Paradigma in responsivem Design entworfen. Um es dem Webentwickler möglichst einfach zu machen, haben sich zahlreiche UI-Frameworks etabliert, die jedem Projekt einen schnellen Start für ein responsives Layout geben (mit der Nebenwirkung, dass viele Webseiten gleich aussehen).

Mit wachsendem Anspruch an die Usability steigen auch die Investitionskosten für das Frontend. Die Entscheidung für ein UI-Framework führt zu einer nahezu vollständigen Abhängigkeit des UI-Codes zur gewählten Technologie. Somit hat ein nicht trivialer Teil der Software starre Abhängigkeiten zu technologischen Belangen. Ein Austausch dieser Basistechnologie kommt dann ebenso selten in Frage wie in der Backend-Entwicklung der Austausch des zugrunde liegenden Webframeworks. In beiden Fällen ist der Wechsel des Basisframeworks mit erheblichen Kosten verbunden. Im Backend ermöglichen Frameworks wie Spring die weitgehende Abstraktion der Geschäftslogik von den technischen Belangen und ermöglichen so den Erhalt der Geschäftslogik über den Frameworkwechsel hinaus. Eine Indirektionsschicht hier, ein bisschen Dependency Injection da, und die Architekturentscheidung hat zumindest nicht mehr den Charakter einer gefühlt unumkehrbaren Endgültigkeit.

Neben der Unabhängigkeit der Geschäftslogik hat sich ebenso der Gedanke der Wiederverwendung einzelner Softwarekomponenten, unabhängig ob technischer / querschnittlicher Belang oder Geschäftslogik, etabliert. Nach ein paar Jahren Java-Entwicklung ist die Trennung der unterschiedlichen Belange in Packages und deren anschließende Kapselung in zu Wiederverwendung isolierten .jar-Files zum Automatismus geworden. Die sich hieraus zwangsläufig ergebenden Probleme transitiver Abhängigkeiten und komplexer werdender Builds sind durch Maven, Ivy, Gradle und Co. einfach in den Griff zu bekommen.

Wiederverwendung im Web

Nahezu alle Webframeworks, gleich ob serverseitiges Templating oder clientseitige Single Page Application (SPA), bringen Mechanismen zur Modularisierung und Wiederverwendung von Markup und Style Sheets mit. So verfügen beispielsweise JavaServer Pages (JSP) und (Grails-)Groovy Server Pages (GSP) über Taglibs und Templates. Das Google Web Toolkit...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang