Wir sind eine zertifizierte B Corporation.

Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

entwickler magazin

Softwarearchitektur

Frontend

Was ist der JAMstack?

Eine Einführung für performante und sicherere Frontends

<p>Seitdem das Angular-Team verkündet hat, dass der <a href="https://www.codecentric.de/wissen/schulungen/detail/?schulung=angularjs">AngularJS</a> -Nachfolger Angular2 in TypeScript entwickelt wird, ist TypeScript mehr in den Fokus gerückt. Dabei kann TypeScript auch ohne Angular2 überzeugen und findet mehr und mehr Nutzer. Grund genug, hier im Blog eine kleine Einführung in die Arbeit mit TypeScript zu geben. In den kommenden Wochen zeige ich, wie man ein Projekt mit TypeScript aufsetzt, welche Features TypeScript uns bietet und auch, wie man TypeScript in seine bestehende AngularJS-Anwendung integrieren kann.</p><p>Heute stelle ich ein minimales Setup vor und gebe einen Einblick in das Typsystem von TypeScript.</p><h2>TypeScript</h2><p>Die Verwendung von TypeScript ist keine Entscheidung gegen JavaScript. Sie folgt eher dem aktuellen Trend, JavaScript mithilfe von Transpilern zu generieren, um mit moderneren Sprachfeatures arbeiten zu können. TypeScript selbst ist ein Superset von JavaScript und bietet primär Funktionalität an, die entweder in einer zukünftigen Version von ECMAScript Standard wird (z.B. Arrow-Funktionen) oder aber syntaktischen Zucker für bestehende Funktionalitäten bietet. Im Projektalltag erleichtert das <strong>statische Typsystem</strong> die Arbeit an komplexen Anwendungen enorm. Selbiges ermöglicht auch einen sehr guten IDE-Support. Ich gehe hier nicht so weit wie <a href="http://staltz.com/all-js-libraries-should-be-authored-in-typescript.html">André Staltz in seinem Blog</a> , der fordert, dass alle Bibliotheken in TypeScript geschrieben werden sollten, möchte jedem Entwickler aber einen Blick auf TypeScript ans Herz legen.</p><p>Im Folgenden möchte ich einige der Eigenschaften von TypeScript vorstellen. Eine wesentlich gründlichere Einführung gibt es <a href="http://www.typescriptlang.org/Handbook">auf der Projektseite</a>  oder auch im <a href="http://basarat.gitbooks.io/typescript/">Guide von Basarat Ali Syed</a> .</p><p>Zunächst ist wichtig, dass TypeScript ein Superset von JavaScript ist, und auch, wenn es Fehler anzeigt, immer in JavaScript umgewandelt wird. In der Theorie ist also eine einfache Umbenennung der <em>.js</em>-Dateien in <em>.ts</em>-Dateien schon die halbe Miete. Die Erfahrung zeigt aber, dass es einfacher ist, diese Migration Schritt für Schritt durchzuführen und zunächst neue Funktionalität in TypeScript zu entwickeln und alten Code, wo notwendig, zu überarbeiten.</p><h2>Minimales Setup</h2><p>Wir werden uns in einem späteren Teil ansehen, wie man TypeScript in seinen Build integrieren kann. Bis dahin reicht für die ersten Schritte ein einfacheres Setup. Damit alles funktioniert, sollten aktuelle Versionen von Node.js und npm installiert sein. TypeScript kann dann mit dem folgenden Befehl global installiert werden:</p>

```
npm install -g typescript

```

<p>Warum global? Wenn wir TypeScript global installieren, können wir den TypeScript Compiler einfach via <code>tsc</code> ausführen. Man kann diesen natürlich auch nur lokal installieren, dann ist das aber etwas umständlicher.</p><p>Ein <code>tsc -v</code> sollte nun eine Version >= 1.8.9 ausgeben.</p><p>Jetzt fehlt nur noch ein Ordner, in dem entwickelt wird (z.B. <code>hello-typescript</code>). In diesem legen wir zunächst einen Ordner <code>src</code> für den Quellcode an und eine Datei <code>tsconfig.json</code>, die die Konfiguration für den TypeScript Compiler enthält. Im Ordner <code>src</code> legen wir eine Datei <code>app.ts</code> für unseren Code an.</p><p>Die Ordnerstruktur sieht danach so aus:</p>

```
- hello-typescript/
   |
   |- src/
   |   |
   |   |- app.ts
   |
   |- tsconfig.json

```

<p>In die <code>tsconfig.json</code> schreiben wir die folgende Konfiguration:</p>

```
{
  "compilerOptions": {
    "target": "es5"
  }
}

```

<p>Diese Konfiguration stellt sicher, dass der TypeScript Code in ES5 kompiliert wird. In vielen IDEs reicht die tsconfig.json auch schon aus, damit der Code automatisch kompiliert wird.</p><h2>Ein einfaches Beispiel</h2><p>Zunächst schreiben wir folgenden Code in <code>app.ts</code>:</p>

```
function add(x, y) {
  return x + y;
}

var result = add(1, 2);
console.log(result);

```

<p>Im Ordner <code>hello-typescript</code> führen wir dann <code>tsc -p .</code> aus, um den TypeScript-Code in JavaScript zu kompilieren (<code>-p .</code> stellt sicher, dass die lokale tsconfig.json verwendet wird). Mit <code>node src/app.js</code> führen wir den generierten Code aus (natürlich könnte man die JavaScript-Datei auch einfach über den Browser in ein HTML-Dokument integrieren). Im Terminal erscheint nun die Zahl <em>3</em>.</p><p>Im Ordner <code>src</code> findet man nun die Datei <code>app.js</code>, die den kompilierten Code anzeigt. Was direkt auffällt: Es gibt so gut wie keinen Unterschied zu unserer TypeScript-Datei (nur ein paar Leerzeilen fehlen). Da wir hier aber eigentlich nur JavaScript geschrieben haben, wäre alles andere überraschend.</p><h3>Typsystem</h3><p>Wie der Name schon ahnen lässt, bietet TypeScript im Gegensatz zu JavaScript ein statisches Typsystem. Die Vorteile liegen auf der Hand:</p><ul><li>viele Fehler fallen schon auf, wenn der Code kompiliert wird</li><li>Refactoring des Codes ist wesentlich einfacher</li><li>Typen sind eine gute Form der Dokumentation</li></ul><p>Warum funktioniert unser Beispiel nun ohne die Angaben von Typen? Der Grund hierfür ist, dass TypeScript <em>implizite Typen</em> unterstützt. Natürlich können wir hier auch etwas konkreter werden und die Signatur unserer Funktion anpassen:</p>

```
function add(x: number, y: number): number {
  return x + y;
}

var result = add(1, 2);

console.log(result);

```

<p>Die Funktion <code>add</code> erwartet nun also zwei Parameter vom Typ <code>number</code> und gibt ebenfalls einen Wert vom Typ <code>number</code> zurück. Wenn wir nun diesen Code wieder kompilieren und ausführen, ist das Ergebnis identisch. Das besonders hier: Die JavaScript-Datei hat sich nicht verändert: <strong>TypeScript entfernt alle Typinformationen</strong>.</p><p>Gut, provozieren wir einen Fehler:</p>

```
var result = add(1, 'foo');

```

<p>Je nach IDE wird dieser Code nicht automatisch kompiliert. Wenn wir dies aber nun manuell mit <code>tsc</code> tun, passieren zwei Dinge:</p><ul><li>wir bekommen eine Fehlermeldung <code>error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.</code></li><li>es wird trotzdem eine JavaScript-Datei erzeugt (wenn wir diese kompilieren und ausführen, bekommen wir als Ausgabe <em>1foo</em>).</li></ul><p>Wenn wir verhindern wollen, dass bei einem Fehler JavaScript erzeugt wird, können wir in der tsconfig.json einfach das Property <code>noEmitOnError</code> auf <code>true</code> setzen.</p><p>Gerade, wenn man bestehenden Code migiriert, kommt es schnell vor, dass man einer Variable keinen Typ zuweisen kann (beispielsweise weil es noch keine Typdefinition für einen Typ gibt). In diesem Fall kann man einer Variable auch den Typ <code>any</code> geben.</p><h3>Interfaces</h3><p>Bauen wir unser Beispiel ein wenig aus und addieren komplexe Zahlen:</p>

```
interface IComplexNumber {
    real: number;
    imaginary: number;
}

function add(x: IComplexNumber, y: IComplexNumber): IComplexNumber {
    return {
        real: x.real + y.real,
        imaginary: x.imaginary + y.imaginary
    }
}

var a = {
    real: 1,
    imaginary: 2
};

var b = {
    real: 3,
    imaginary: 4
};

var result = add(a, b);

console.log(result);

```

<p>Wir definieren komplexe Zahlen zunächst über ein Interface <code>IComplexNumber</code>. Die Funktion <code>add</code> akzeptiert nun zwei komplexe Zahlen, addiert diese und gibt eine neue komplexe Zahl zurück. So weit, so gut.</p><p>Wenn wir diesen Code kompilieren und ausführen, lautet das Ergebnis <code>{ real: 4, imaginary: 6 }</code>. Wie auch bei den anderen Beispielen entfernt der Compiler alle Typinformationen.</p><p> Interessant ist die Initialisierung der Werte: Wir müssen hier keinen Konstruktor verwenden, sondern können einfach ein Objekt erzeugen, das dem Interface entspricht. Wir können hier auch zusätzliche Felder definieren, was in diesem Use Case aber keinen Sinn ergibt. TypeScript berücksichtigt also die Struktur der Objekte (<em>structural typing</em>).</p>

```
var b = {
    real: 3,
    imaginary: 4,
    foo: 5
};

```

<p>Das war es auch schon für heute. In diesem Teil haben wir TypeScript installiert, ein Projekt aufgesetzt und uns das Typsystem von TypeScript angesehen. Im nächsten Teil werfen wir einen Blick auf Klassen und Interfaces in TypeScript.</p><p>Wie sehen Eure Erfahrungen mit TypeScript aus? Habt ihr es bereits im Projekt eingesetzt oder denkt darüber nach?</p>

Einführung in TypeScript: Setup und Typsystem

<p>Im vergangenen Jahr hat sich Webpack quasi als Standard-Build-Tool für Webanwendungen etabliert. Trotzdem haben viele Entwickler Probleme mit der Konfiguration von <a href="https://webpack.js.org" target="_blank">Webpack</a> , was ich mit dieser Serie ändern möchte.</p><p>Webpack existiert momentan in Version 3 und erfreut sich einer aktiven Community und zahlreicher Entwickler. Tools wie <a href="https://github.com/facebookincubator/create-react-app" target="_blank">create-react-app</a>  oder die <a href="https://github.com/vuejs/vue-cli" target="_blank">vue-cli</a>  setzen auf Webpack und dementsprechend viele Tutorials lassen sich im Netz finden. Aber warum haben viele Entwickler Probleme mit Webpack? Die erste Version von Webpack hatte eine eher komplizierte Doku und im Netz ließen sich vor allem komplexe Beispiele finden. Version 2 wurde komplett überarbeitet. Vor allem die <a href="https://webpack.js.org/concepts/" target="_blank">Dokumentation</a>  ist erheblich besser geworden.</p><h2>Was ist Webpack?</h2><p>Bei Webpack handelt es sich um einen “static module bundler” für JavaScript-Anwendungen. Die Idee dahinter ist, einen Dependency-Graphen aufzubauen, der alle JavaScript-Module der Anwendung enthält und diese in ein (oder mehrere) Bundle packt. Bevor wir uns nun mit Webpack beschäftigen, sollten wir uns hier zwei Dinge genauer ansehen: JavaScript-Module und Bundles.</p><h2>Was sind JavaScript-Module?</h2><p>JavaScript-Module ermöglichen es, Code zu gruppieren, so wie wir es auch aus anderen Programmiersprachen kennen. Wer sich hier für Details interessiert, der kann sich <a href="https://eloquentjavascript.net/10_modules.html" target="_blank">diesen Artikel</a>  ansehen. Da wir uns in diesem Beitrag auf Webpack konzentrieren, nehmen wir ein einfaches Beispiel:</p>

```

// add.js
export const add = (a, b) => a+b;

```

<p>In der Datei <code>add.js</code> definieren wir eine Funktion <code>add</code>, die zwei Zahlen addiert. Diese Funktionen exportieren wir. Somit ist <code>add.js</code> unser Modul.</p>

```

// index.js
import {add} from ‘./add.js’;

console.log(add(1,2));

```

<p>Unser Modul verwenden wir dann in der Datei <code>index.js</code>, welche die Funktion <code>add</code> aus dem Modul importiert und verwendet.</p><p>Nun können wir mit diesen Dateien in unserem Browser noch nicht viel anfangen. Wir brauchen hier einen Module Bundler wie Webpack, um aus dem Code ein Bundle zu machen.</p><h2>Was ist ein Bundle?</h2><p>Ein Bundle ist quasi der zusammengefasste JavaScript-Code. Wir geben Webpack als Eingabe unsere Datei <code>index.js</code>, Webpack lädt unsere vollständige Anwendung und erstellt dann – im einfachen Fall – eine JavaScript-Datei, die unseren vollständigen Code enthält und so auch im Browser verwendet werden kann.</p><p>Mit einem aktuellen node.js und npm können wir unser Bundle nun auch schon erstellen:</p>

```
npx webpack index.js dist/bundle.js
```

<p><a href="https://www.npmjs.com/package/npx" target="_blank">npx</a>  gehört zu npm und erspart uns hier, Webpack manuell zu installieren, was ganz nützlich ist, wenn man mal eben etwas ausprobieren möchte. In späteren Beispielen installieren wir Webpack dann normal über npm.</p><p>Das Kommando <code>webpack</code> benötigt zwei Eingabeparameter: den Einstiegspunkt (hier <code>index.js</code>) und den Pfad, an dem Webpack das Bundle dann erstellen soll (hier <code>dist/bundle.js</code>). Nach ein paar Sekunden erstellt Webpack dann auch schon unser Bundle.</p><p>Diese Datei können wir nun in eine HTML-Datei einbinden und uns das Ergebnis ansehen. Das Ganze funktioniert hier so einfach, da Webpack auf “convention over configuration” setzt und von Hause aus schon sehr gut mit JavaScript umgehen kann. Wir benötigen normalerweise erst eine eigene Konfiguration, wenn wir moderne JavaScript-Features nutzen möchten oder spezielle Anforderungen an den Input oder Output haben (z.B. Umgang mit .jsx-Dateien, Laden von Stylesheets).</p><p>Im nächsten Teil sehen wir uns dann die Konzepte hinter Webpack etwas genauer an, installieren Bibliotheken und erstellen eine Webpack-Konfiguration.</p>

Webpack Basics – Teil 1: Einstieg

<p>Im <a href="https://blog.codecentric.de/2018/01/webpack-basics-teil-1-konzepte/">ersten Teil der Serie</a>  haben wir uns Module und Bundles angesehen und mit Webpack unser erstes Bundle erstellt. Bevor wir uns nun näher mit der Konfiguration beschäftigen, sehen wir uns ein paar Konzepte an, die zu Webpack gehören: <em>Entry</em>, <em>Output</em>, <em>Loaders</em> und <em>Plugins</em>.</p><h2>Entry</h2><p>Über den Entry legt man den Einstiegspunkt für die Bundle fest, die man erstellen möchte. Hier reicht sehr häufig schon ein einziger Einstiegspunkt. Diese Datei importiert dann alle anderen Dateien, so wie im ersten Beitrag beschrieben.</p><h2>Output</h2><p>Der Output definiert, was mit den erzeugten Bundles passieren soll. Also wie die JavaScript-Datei heißen soll, in der das Bundle gespeichert wird, und wo diese liegt.</p><h2>Loaders</h2><p>Hier passiert quasi die Magie von Webpack, denn in den Loaders können wir definieren, ob und wie Webpack mit Dateien umgeht. So kann man mit dem <a href="https://github.com/babel/babel-loader" target="_blank">babel-loader</a>  modernes JavaScript (ES6+) in ES5 umwandeln oder mit dem <a href="https://github.com/TypeStrong/ts-loader" target="_blank">ts-loader</a>  den verwendeten TypeScript Code in JavaScript umwandeln.</p><p>Bei komplexeren Anwendungen kann man diese aber auch nutzen, um Sass oder Less Stylesheets zu verarbeiten und Bilder zu optimieren.</p><h2>Plugins</h2><p>Während Loader sich auf die Bundles und den Code in den Modulen beschränken, sind Plugins dazu in der Lage, alles rund um den Build zu steuern. Vom Aufräumtask vor dem Build über die Erstellung der HTML-Dateien für unsere Anwendung bis zur Minifizierung unseres Codes gibt es unfassbar viele Möglichkeiten.</p><h2>Installation und erste Konfiguration</h2><p>Wie bei jedem Tool können wir auch mit Webpack sehr ungewöhnliche Dinge anstellen. In dieser Serie bleiben wir aber zunächst bei den Grundlagen.</p><h3>Projekt anlegen</h3><p>Um nun unser Beispiel aus dem letzen Beitrag mit Hilfe einer Webpack-Konfiguration zu bauen, müssen wir als erstes ein Projekt anlegen und dort Webpack installieren: Hierfür initialisieren wir npm zunächst in einem leeren Ordner <code>webpack-sample</code> (mehr zu npm habe ich <a href="https://blog.codecentric.de/2017/09/ein-blick-auf-npm-und-package-json/">in diesem Beitrag geschrieben</a> ).</p>

```

mkdir webpack-sample
cd webpack-sample
npm init -y

```

<p>Als nächstes benötigen wir einen Ordner für unseren Code. Hierfür legen wir einen Ordner <code>lib</code> an in den wir unseren Code aus dem ersten Beispiel kopiere. Damit wir auch etwas sehen können, änderen wir die <code>index.js</code> im Ordner <code>lib</code> etwas ab:</p>

```

import { add } from "./add";
const result = add(1, 2);
// ändert den Text im Element mit der id #app in "1 + 2 = 3"
document.getElementById("app").textContent = "1 + 2 = " + result;

```

<p>Als letztes erstellen wir eine Datei <code>index.html</code>, die ein Element mit einer Id <code>app</code> hat und die JavaScript-Datei, die wir erzeugen werden, einbindet. Ein Beispiel für diese habe ich <a href="https://github.com/dmies/webpack-blog-series/blob/master/02-konzepte/index.html" target="_blank">auf GitHub</a>  online gestellt.</p><h3>Webpack-Konfiguration</h3><p>Wenn wir nun Webpack manuell ausführen (<code>npx webpack lib/index.js dist/bundle.js</code>) und die <code>index.html</code> im Browser öffnen, sehen wir den erwarteten Text. Natürlich möchten wir Webpack nicht immer manuell ausführen. Damit wir es bequem über npm starten können, installieren wir es als dev-Dependency:</p>

```

npm install --dev webpack

```

<p>Nun ergänzen wir in unserer <code>package.json</code> im scripts-Block ein neues Skript:</p>

```

"scripts": {
 "build": "webpack"
},

```

<p>Wenn wir nun <code>npm run build</code> ausführen, wird Webpack im aktuellen Ordner ausgeführt und gibt uns erstmal einen Fehler zurück, der auf die fehlende Webpack-Konfiguration hinweist. Diese findet man normalerweise in der Datei <code>webpack.config.js</code>, die wir auch direkt anlegen und dort entry und output definieren:</p>

```

module.exports = {
 entry: "./lib/index.js",
 output: {
   filename: "./dist/bundle.js"
 }
};

```

<p>Unsere Webpack-Konfiguration exportiert also ein Objekt mit den Keys <em>entry</em> und <em>output</em>. Die minimalste Konfiguration in <code>entry</code> ist ein String mit dem Pfad zur <code>index.js</code>. Unser <code>output</code> muss hier schon ein Objekt mit dem Key Filename sein, dem wir ebenfalls einen Pfad, diesmal zum Bundle, zuweisen.</p><p>Wenn wir nun erneut <code>npm run build</code> ausführen, erstellt Webpack für uns das Bundle. Und schon steht unsere erste Webpack-Konfiguration. Noch ist sie recht überschaubar, aber wir werden schon im nächsten Teil etwas mehr Funktionalität hinzufügen und uns mehr mit den Möglichkeiten, die Webpack uns bietet, beschäftigen.</p>

Webpack Basics – Teil 2: Konzepte und Installation

<p><img width="640" height="427" src="https://media.graphassets.com/7ko5SmoTGPxFi4516HRQ" alt="JH04" /></p><p>Für uns, Daniel und Anna, war Jugend hackt 2016 die erste Veranstaltung dieser Art, und dementsprechend neugierig und offen sind wir das Wochenende angegangen. Was Jugend hackt eigentlich ist, hat unser Kollege Andreas <a href="/wissens-hub/blog/jugend-hackt-west-2016/">bereits erklärt</a> .</p><p>Wir hatten nicht die Erwartung, dass wir den Jugendlichen Programmieren beibringen oder ihre algorithmischen Probleme lösen. Vielmehr war unsere Idee, agile Techniken und Organisationsstrukturen aus unserem Berufsalltag, insbesondere Scrum, einzubringen und die Jugendlichen so bei der Umsetzung ihrer Idee zu unterstützen und ihnen zu helfen. Ebenso wollten wir die Jugendlichen dazu anhalten, im Pair zu arbeiten, um das Wissen über die einzelnen Projektbestandteile im Team gut zu verteilen.</p><p>Das Feedback der anderen Mentoren, die schon Erfahrung mit Jugend hackt hatten, war eindeutig: Niemand erwartete, dass sich ein Team den ganzen Hackathon an einer Methodik wie Scrum festhalten und durchgängig nach den Richtlinien dort arbeiten würde. Vielmehr rechneten alle damit, uns eingeschlossen, dass Scrum und Co. nach kurzer Zeit über Bord geworfen und das Hacken in den Vordergrund gestellt würde.</p><p><img loading="lazy" width="640" height="427" src="https://media.graphassets.com/LTdMcZLSeyfR0HChzmq9" alt="JH01" /></p><h2>Mentoren als Scrum Master</h2><p>Gleich vorweg: Es kam anders als erwartet. Unser Team gab Scrum nicht nur eine Chance, sondern forderte Standups und Retrospektiven zu den vereinbarten Zeiten ein. Zu keinem Zeitpunkt wurde Scrum durch unser Team in Frage gestellt. Begünstigt wurde dies dadurch, dass alle Gruppenmitglieder schon mindestens eine Programmiersprache kannten und auch schon Erfahrungen auf Hackathons gesammelt hatten. Ein Team, das hier mehr technische Hürden oder weniger Vorerfahrung zu bieten gehabt hätte, hätte sich vielleicht anders verhalten.</p><p>Ein Sprint dauerte bei uns in der Regel zwei Stunden, und wir als Mentoren übernahmen die Rolle der Scrum Master. Zu Beginn wurde jeweils ein Planning durchgeführt, bei dem die anstehenden Aufgaben im Team verteilt wurden. Nach einer Stunde gab es ein Standup, bevor der Sprint dann mit einer Retrospektive beendet wurde.</p><p>Schon nach dem ersten Sprint zahlte sich Scrum auch schon für uns aus: Innerhalb der Retrospektive stellten wir fest, dass es noch Klärungbedarf bezüglich der Architektur gab. Während derartige Probleme sonst gerne erst spät im Projekt auffallen und dann nur noch schwer zu beheben sind, konnten wir direkt einen Spike einplanen und das Thema im Team diskutieren.</p><p>Gerade am Anfang haben wir in jeder Retrospektive deutlich gemacht, dass wir natürlich auch ohne Scrum weiterarbeiten könnten. Das Team hat sich jedoch konsequent für Scrum ausgesprochen.</p><p><img loading="lazy" width="640" height="427" src="https://media.graphassets.com/cHxIvbwQuyXlFcsCum6A" alt="JH02" /></p><h2>Ohne Scrum: Chaos</h2><p>Nachdem am Samstag hart und sehr konzentriert an dem Projekt gearbeitet wurde und die meisten Teilnehmer in der Nacht von Samstag auf Sonntag wenig bis keinen Schlaf hatten, wollten wir es zunächst lockerer angehen und verzichteten am Sonntagmorgen zunächst auf ein weiteres Planning. Direkt fiel den Teammitgliedern auf, wie unstrukturiert die Arbeit weiterging: Aufgaben waren im Team nicht klar zugewiesen, jeder hatte mehrere Themen im Kopf, und so langsam lief die Zeit bis zur Präsention davon. Es kam das Gefühl auf, das Projekt nicht mehr reichtzeitig abschließen zu können. Nach einer Stunde machten wir also wieder ein Planning, um diesem Chaos zu entgehen und der Aufgaben und des Projektes wieder Herr zu werden. So konnten wir die abschließenden Tätigkeiten an der Anwendung und die Vorbereitung der Präsentation gut im Team verteilen. Als wir gegen Ende erfuhren, dass ein anderes Team noch Tests eingebaut hatten, konnten wir spontan reagieren und hier ebenfalls nachlegen.</p><h2>Prädikat „Bester Code“</h2><p>Nach drei Tagen konnten wir dann das Projekt erfolgreich beenden. Für die Teammitglieder, die schon bei Jugend hackt waren, war es das erste Projekt, das komplett abgeschlossen werden konnte. Dies zahlte sich auch bei der abschließenden Preisverleihung aus: Unser Team erhielt den Preis in der Kategorie „Bester Code“, wobei unsere Organisation besonders lobend erwähnt wurde. Für unser Team also ein voller Erfolg: Alle haben sich über den Preis gefreut, aber auch besonders, dass sie das Projekt fertig gestellt und dabei Neues gelernt haben. Scrum live auszuprobieren und so kennenlernen zu können empfanden die Jugendlichen auch als eine positive Bereicherung dieser Veranstaltung.</p><p><img loading="lazy" width="640" height="427" src="https://media.graphassets.com/ph45TOjTPyIOaqGLtCzo" alt="JH03" /></p><p>Für uns zwei Mentoren war es ein kleiner Erfolg, dass wir zeigen konnten, wie mithilfe von Scrum und Co. auch während eines Hackathons sehr gute Ergebnisse erzielt werden können. Auch wenn Planning und Retrospektive auf den ersten Blick Zeit kosten, zahlte sich dies innerhalb kürzester Zeit aus.<br /> Wir beide mussten an diesem Wochenende fast nie bei technischen Problemen im Team helfen. Rückblickend waren wir hier öfter in anderen Teams zur Stelle. Dadurch, dass immer zwei Gruppenmitglieder im Pair arbeiteten und grundsätzlich die Hilfsbereitschaft innerhalb des Teams sehr hoch war, kam das Team sehr gut ohne uns zurecht.</p><p>Unser Fazit: Jugend hackt war eine tolle Erfahrung für uns. Wir hatten viel Spaß dabei, mit wissbegierigen Jugendlichen in einer produktiven, aber auch entspannten Atmosphäre zu arbeiten. Nächstes Jahr sind wir definitiv wieder dabei. Vielen Dank auch an die anderen Jugendlichen und Mentoren und die Veranstalter für die hervorragende Organisation.</p>

Agilität & Hackathon: Passt das? – Jugend hackt West 2016

<p>Teil der Webentwicklung in 2020 sind nicht nur komponentenbasierte Ansätze, sondern ebenso die Nutzung von State-Management-Lösungen. Diese orientieren sich in der Regel an der Flux-Architektur und ihrem prominentesten Vertreter, <a href="https://redux.js.org/" target="_blank">Redux</a> . Und so ist es nicht verwunderlich, dass auch Svelte hier eine passende Lösung mitbringt, welche ich im folgenden Artikel vorstelle. Der hier gezeigte Code stammt aus dem <a href="https://svelte.dev/tutorial" target="_blank">offiziellen Tutorial</a> .</p><p>Interessierst du dich zunächst für die Grundlagen von Svelte? Dann schau dir meine <a href="https://blog.codecentric.de/2020/02/gleich-und-doch-anders-einfuehrung-in-svelte/">Einführung zu Svelte an</a> .</p><h2>Erste Schritte</h2><p>Svelte bringt, wie erwähnt, seine Store-Implementierung gleich mit. Um beispielsweise einen Store zu implementieren, der den State eines Counters verwaltet, brauchen wir lediglich zwei Zeilen Code:</p><div>

```html
import { writable } from 'svelte/store';
 
export const count = writable(0);
```

</div><p>Wir implementieren den Store als <em>writeable</em> (wir kommen später noch zum read-only pendant) und erstellen einen Store mit dem initialen State (hier 0). Die hier exportierte Variable <code>count</code> bietet drei Methoden:</p><ul><li><code>subscribe(callback)</code>: Wird ausgeführt, wenn der Store aktualisiert wird. Die callback-Funktion bekommt als Parameter den initialen Wert im Store übergeben.</li><li><code>update(callback)</code>: Führt den callback aus. Die callback-Funktion bekommt als Parameter den initialen Wert im Store übergeben.</li><li><code>set(value)</code>: Setzt den Wert im Store auf den übergebenen Wert <em>value.</em></li></ul><p>In einer Svelte-Komponente könnte ein Counter folgendermaßen aussehen:</p><div>

```html
<script>
 import { count } from "./store";
 
 let count_value;
 function increment() {
   count.update(n => n + 1);
 }
 function decrement() {
   count.update(n => n - 1);
 }
 function reset() {
   count.set(0);
 }
count.subscribe(value => {
   count_value = value;
 });
</script>
<h1>The count is {count_value}</h1>
<button> + </button> <button> - </button> <button> Reset </button>
```

</div><p>Man kann sich die Nutzung der <code>subscribe-</code>Funktion hier noch sparen, indem man die Kurzform <code>$count</code> nutzt:</p><div>

```html
<script>
 import { count } from "./store";
 
 function increment() {
   count.update(n => n + 1);
 }
 function decrement() {
   count.update(n => n - 1);
 }
 function reset() {
   count.set(0);
 }
</script>
<h1>The count is {$count}</h1>
<button> + </button> <button> - </button> <button> Reset </button>
```

</div><p>Das <code>$-</code>Zeichen ist in Svelte ein reserviertes Zeichen, welches sich immer auf einen Store beziehen muss. Es ist also nicht erlaubt, dieses für eigene Variablen zu nutzen.</p><h2>Custom Stores</h2><p>Nun möchte man nicht immer innerhalb einer Komponente direkt mit dem Store interagieren. In Redux gibt es hierfür Reducer und Actions, mit denen man Änderungen am State auslösen kann. In Svelte können wir einen custom store anlegen, für den wir eigene Operationen definieren können. Der Vorteil hier ist, dass man weniger Boilerplate Code benötigt, um die State zu manipulieren.</p><div>

```html
import { writable } from "svelte/store";
 
function createCount() {
 const { subscribe, set, update } = writable(0);
 
 return {
   subscribe,
   increment: () => update(n => n + 1),
   decrement: () => update(n => n - 1),
   reset: () => set(0)
 };
}
 
export const count = createCount();
```

</div><p>In der Komponente sparen wir uns so einiges an Code und machen alles etwas übersichtlicher:</p><div>

```html
<script>
 import { count } from "./store";
</script>
<h1>The count is {$count}</h1>
<button> + </button> <button> - </button> <button> Reset </button>
```

</div><h2>Readable und Derived Store</h2><p>Neben dem writeable store bietet Svelte zwei weitere spannende Möglichkeiten: den readable store und den derived store.</p><p>Der <a href="https://svelte.dev/docs#readable" target="_blank">readable store</a>  ist, wie der Name schon sagt, ein read-only Store. Dieser kann genutzt werden, wenn die im Store verwalteten Daten nicht vom Nutzer manipuliert werden sollen.</p><p>Der <a href="https://svelte.dev/docs#derived" target="_blank">derived store</a>  erlaubt es, Daten abhängig von anderen Stores zu verwalten. So lässt sich Komplexität in einzelnen Stores vermeiden, indem man diese in derived stores auslagert.</p><h2>Fazit</h2><p>Auch beim Thema State Management erfindet Svelte das Rad nicht neu: Die Idee, State Management über Stores zu realisieren kennen wir schon von React, Angular und Vue. Dennoch ist die von Svelte etablierte Lösung interessant: read-only und derived stores lösen bekannte Probleme in Frontend-Anwendungen. Die Möglichkeit Custom Stores zu erstellen spart einerseits sehr viel Boilerplate Code (der ja auch bei anderen <a href="https://blog.codecentric.de/2020/02/einfacheres-redux-mit-dem-redux-toolkit/">durch Bibliotheken ersetzt wird</a> ) und erlaubt es zudem, die einzelnen Stores mit domänenspezifischer Logik zu implementieren.</p><p>Foto von <a href="https://unsplash.com/@mikepetrucci" target="_blank">Mike Petrucci</a> </p>

State Management in Svelte

<p>Node, <a href="https://www.npmjs.com/" target="_blank">npm</a>  und das JavaScript-Ökosystem werden, gerade in der Enterprise-Entwicklung, gerne belächelt. So wurde das Thema z.B. <a href="http://autoweird.fm/folge26-backend-vs-frontend/" target="_blank">bei @autoweird.fm intensiv diskutiert</a> . Trotzdem führt momentan kein Weg an modernen Web-Anwendungen vorbei. Das Problem: <em>npm</em> und <em>package.json</em> sind für viele eine Blackbox, die ich in diesem Artikel ein wenig demystifizieren möchte.<span></span></p><h2>Projekt-Setup</h2><p>Fangen wir ganz vorne an: Wenn ein neues Projekt angelegt wird, kann man natürlich eine alte <em>package.json</em> kopieren, selbige von Hand schreiben oder aber es etwas einfacher angehen: Mit <code>npm init</code> (<a href="https://docs.npmjs.com/cli/init" target="_blank">docs.npmjs.com/cli/init</a> ) wird ein Dialog gestartet, in dem man folgende Dinge über das eigene Projekt angeben kann:</p><ul><li>Name des Packages</li><li>Version</li><li>Beschreibung</li><li>Einstiegspunkt</li><li>Test-Befehl</li><li>Git Repository</li><li>Keywords (für die npm-Suche)</li><li>Autor</li><li>Lizenz</li></ul><p>Hier schlägt <em>npm</em> immer einen sinnvollen Standard vor, und man kann viele dieser Standards einfach akzeptieren. Noch einfacher ist es <code>npm init -y</code> (oder <code>--yes</code>) zu nutzen, damit <em>npm</em> einfach eine <em>package.json</em> mit diesen Standards anlegt. Um zu vermeiden, dass ein Modul versehentlich veröffentlicht wird, kann man dieses in der <em>package.json</em> mit <code>“private”: true</code> entsprechend auszeichnen.</p><h2>Dependencies</h2><p>Libraries und Frameworks lassen sich mit <code>npm install <dependency></code> (<a href="https://docs.npmjs.com/cli/install" target="_blank">docs.npmjs.com/cli/install</a> ) installieren. Auch hier gibt es einen kürzeren Befehl: <code>npm i <dependency></code>.</p><p>Neben den normalen Abhängigkeiten erlaubt es <em>npm</em> auch, Dev-Dependencies zu installieren (<code>npm install --save-dev <dependency></code> oder kurz: <code>npm i -D <dependency></code>) . Dev-Dependencies sind alle Abhängigkeiten, die nur während der Entwicklung, nicht aber zur Laufzeit benötigt werden.</p><p>Beispiele für solche Libraries sind der Testrunner, Buildtools und Linter. Was hier oft vergessen wird: In vielen Frontend-Projekten werden die im Einsatz befindlichen Libraries und Frameworks oft im Rahmen des builds in eine oder mehrere JavaScript-Dateien gepackt. In diesem Fall sind dann auch, streng genommen, React, Angular und Co. Dev-Dependencies. Die richtige Verwendung von Dependencies kann die Größe von <em>npm</em>-Modulen erheblich beeinflussen.</p><h3>In Produktion</h3><p>Wenn ihr <em>npm</em> mit dem Flag <code>--production</code> nutzt oder die <code>NODE_ENV</code>-Umgebungsvariable den Wert “production” hat, wird <em>npm</em> keine Dev-Depenencies installieren.</p><h2>Versionen</h2><p>Auch wenn einige Libraries sich nicht daran halten: <em>npm</em> setzt stark auf Semantic Versioning und bietet euch zahlreiche Optionen, dies zu nutzen. Trotzdem muss hier klar darauf hingewiesen werden, dass man je nach verwendeter Library vorsichtig mit den Möglichkeiten von <em>npm</em> umgehen muss.</p><p>Wer ganz sicher gehen will, trägt immer eine feste Version in die <em>package.json</em> ein. Der Standard bei <em>npm</em> ist ein Zirkumflex vor der Version (<code>^</code>).</p><h3>Versionen in npm definieren</h3><ul><li>fixe Version, wie z.B. “1.0.1”: In diesem Fall installiert <em>npm</em> auch nur die dort angegebene Version.</li><li>Versionsbereich, wie z.B. “>1.0.0”: Es ist möglich, hier einen größeren Bereich abzudecken. Die möglichen Vergleichsoperatoren sind “<”, “<="”," “="">”, “>=” und “=”.</li><li>Tags: Es ist möglich, einer Version einen Tag wie “-beta” oder “-alpha.3” zu geben, um Versionen, die nicht stabil sind, zu veröffentlichen.</li><li>Patchversion, mit z.B “~1.0.0”: In diesem Fall wird die aktuellste minor-Version genutzt. Dies ist in vielen Fällen ein sinnvoller Standard, wenn die im Einsatz befindliche Library semantic versioning korrekt umsetzt.</li><li>Die erste Zahl (ungleich 0) bleibt stabil mit Zirkumflex: “^1.0.0”: Hier sind also i.d.R. auch Minor Upgrades Teil der unterstützten Version. Bei “^0.0.1” würde sich die Version allerdings nicht verändern, da die erste Zahl, die nicht 0 ist, in diesem Fall die Minor-Version ist.</li></ul><h2>Dependencies aktualisieren</h2><p>Gerade während der Entwicklung macht es häufig Sinn, die verwendeten Dependencies auf dem aktuellen Stand zu halten. Mit Hilfe von <code>npm outdated</code> kann man sich eine Liste der Dependencies anzeigen lassen und diese dann mit <code>npm update</code> auch auf die aktuelle Version aktualisieren.</p><h2>package-lock.json und npm-shrinkwrap.json</h2><p>Immer wenn über <em>npm</em> der Inhalt des <em>node_modules</em>-Ordner oder die <em>package.json</em> geändert wird, wird die <em>package-lock.json</em> verändert (bzw. erzeugt). In dieser wird der komplette Dependency-Tree aufgeführt, um<br /> die Installation unabhängig von inzwischen aktuelleren Versionen zu reproduzieren. Diese Datei sollte unter Versionskontrolle gehalten werden, damit im Team die gleichen Dependencies verwendet werden. Wichtig hier: Es geht dabei nicht darum, Versionen festzuzurren (dies könnt ihr mit shrinkwrap), sondern vielmehr darum die Arbeit im Team zu vereinfachen.</p><p>Wenn zwei Entwickler neue Abhängigkeiten einbringen, kann dies Konflikte in der <em>package-lock.json</em> verursachen. Daher muss hier besonders darauf geachtet werden, dass die <em>package-lock.json</em> nicht einfach blind gemerged oder überschrieben wird, sondern die Updates kontrolliert sequenziell eingepflegt werden. Hier empfiehlt es sich, diese Situationen dazu zu nutzen, generell mit Hilfe von <code>npm outdated</code> die Anwendung auf veraltete Abhängigkeiten zu überprüfen und Patches bzw. Minor Updates einzupflegen. Im Zuge dieser Aktualisierung kann dann auch eine neue, frische, <em>package-lock.json</em> erstellt werden.</p><p>Mit <code>npm shrinkwrap</code> wird neben der <em>package-lock.json</em> eine <em>npm-shrinkwrap.json</em> angelegt. Diese entspricht inhaltlich der <em>package-lock.json</em>, wird aber immer der <em>package-lock.json</em> vorgezogen. Wenn diese Datei mit dem Modul veröffentlicht wird, stellt dies sicher, dass die dort aufgeführten Dependencies unverändert bleiben. Nützlich ist dies vor allem bei globalen Libraries wie Kommandozeilen-Tools. Bei Libraries und Frameworks, bei denen Nutzer die transitiven Abhängigkeiten noch selber pflegen können sollen, sollte auf die Datei verzichtet werden.</p><h2>Skripte</h2><p>Das <em>npm</em> CLI kann auch als Taskrunner verwendet werden. Dazu können in der <em>package.json</em> Skripte (<a href="https://docs.npmjs.com/misc/scripts" target="_blank">docs.npmjs.com/misc/scripts</a> ) definiert werden, die über <em>npm</em> ausführbar sind. Über diese ist es auch möglich, Hooks für Lifecycle Events zu definieren, die <em>npm</em> von sich aus mitbringt (z.B. mit Skripten für <code>preinstall</code> oder <code>postinstall</code>).</p><h3>Lifecycle events</h3><ul><li>publish</li><li>install</li><li>uninstall</li><li>version</li><li>test</li><li>stop</li><li>start</li><li>restart</li></ul><p>Bei all diesen Lifecycle Events können noch “pre” oder “post” vorangestellt werden. Ebenso ist es möglich, npm-Skripte in anderen Skripten wiederzuverwenden. Ein Beispiel zu <code>npm version</code> sieht dann so aus:</p><div>

```javascript
"scripts": {
  "preversion": "npm test",
  "version": "npm run build && git add -A dist",
  "postversion": "git push && git push --tags && rm -rf build/temp"
}
```

</div><p>Ausgeführt werden die Skripte dann mit <code>npm <lifescycleEvent></code> oder auch mit <code>npm run <myOwnScript></code>. Es ist nämlich durchaus möglich, hier eigene Skripte zu definieren:</p><div>

```javascript
"scripts": {
  "build": "webpack"
}
```

</div><p>Dieses Skript könnte man dann mit <code>npm run build</code> starten.</p><p>Zusätzlich erweitert <em>npm</em> die <code>PATH</code>-Umgebungsvariable für die in der <em>package.json</em> definierten Skripte um <em>node_modules/.bin</em>, hier werden alle ausführbaren Skripte gelinkt. Dadurch können in der <em>package.json</em> auch Skripte wie <code>“lint”: “eslint”</code> definiert werden.</p><p>Durch dieses Feature muss so gut wie nie eine Library global installiert werden, was früher durchaus bei Lintern oder anderen Tools notwendig war.</p><h2>Semantic Versioning</h2><p>Sehr oft beobachtet man, dass Versionen in der <em>package.json</em> manuell geändert werden. Wenn das eigene Modul allerdings Semantic Versioning richtig folgen möchte, lohnt sich ein Blick auf <code>npm version</code> (<a href="https://docs.npmjs.com/cli/version" target="_blank">docs.npmjs.com/cli/version</a> ). Dieser Befehl überlässt <em>npm</em> die Aktualisierung der Version. Dabei ist es möglich, sowohl eine feste Version anzugeben, z.B. <code>npm version 1.0.0</code> aber auch, <em>npm</em> die Erhöhung der Version zu überlassen (z.B. <code>npm version patch</code>). Valide Parameter hier sind: <code>patch</code>, <code>minor</code>, <code>major</code>, <code>prepatch</code>, <code>preminor</code>, <code>premajor</code>, <code>prerelease</code> oder <code>from-git</code>. Hierbei nutzt <code>from-git</code> den aktuellen Tag, während die anderen Parameter die Version entsprechend erhöhen.</p><p>Die Option <code>-m</code> erlaubt es, eine Commit-Message hinzuzufügen (<code>npm version patch -m “Updated module to version %s”</code> – %s wird durch die neue Version ersetzt).</p><p>Die folgenden Schritte werden von <code>npm version</code> ausgeführt:</p><ul><li>Überprüfung, ob alle Dateien im Verzeichnis hinzugefügt/committet sind</li><li>Führe das preversion-Skript, wenn vorhanden, durch</li><li>Erhöhe die Version in der package.json</li><li>Führe das version-Skript, wenn vorhanden, durch</li><li>commit und tag</li><li>Führe das postversion-Skript, wenn vorhanden, durch</li></ul><h2>Und viel mehr</h2><p>Und natürlich bietet npm hier wesentlich mehr. Die Dokumentation von npm ist sehr umfangreich und bietet auch zahlreiche Beispiele. Es lohnt sich hier definitiv, einen genaueren Blick auf diese zu werfen, um npm im eigenen Projekt optimal zu nutzen.</p>

Ein Blick auf npm und package.json

<p>Wenn es um moderne Web-Anwendungen geht, dann führt momentan (fast) kein Weg an Angular und React vorbei. Natürlich gibt es hier sehr interessante Alternativen wie Vue.js, Ember und Co, in größeren Projekten spielten diese aber 2017 eine wesentlich kleinere Rolle. Natürlich stellt sich die Frage, wie es in einem schnelllebigen Ökosystem rund um JavaScript & Co in den nächsten Jahren weitergeht. Sicherlich werden auch 2018 komponentenbasierte Frameworks den Markt dominieren – am Horizont zeichnet sich aber seit einer Weile eine Alternative ab: Web Components.</p><p>Bei Web Components handelt es sich um eine Reihe von Features, die momentan vom W3C den HTML- und DOM-Spezifikationen hinzugefügt werden. Web Components erlauben es, wiederverwendbare Komponenten für Web-Anwendungen zu erstellen. Ein Konzept, das wir von Angular und React schon kennen.</p><p>In diesem Beitrag werfen wir einen Blick auf diese Features und welche Möglichkeiten sie bieten.</p><h2>Beispiel mit React</h2><p>Nehmen wir als Beispiel eine Liste von Strings, die wir darstellen möchten. In React sieht das dann so aus:</p><p></p><p>Das fühlt sich schon sehr nach “eigenem” HTML an. Während React aber nur erlaubt, die eigenen Komponenten zu verwenden, ermöglichen es Web Components, eigene HTML-Elemente zu definieren, die dann auch wie normales HTML in eine Seite integriert werden können. Sie lassen sich also auch serverseitig einfach einsetzen. Ein weiterer Vorteil: Sie verhalten sich wie HTML und können daher auch mit jeder JavaScript-Bibliothek und jedem Framework verwendet werden, das mit HTML umgehen kann (z.B. für Events).</p><p>Außerdem basieren Web Components auf Web-Standards und haben daher eine höhere Zukunftssicherheit. Bei der Bewertung müssen wir aber auch einen Nachteil berücksichtigen, den Web Components momentan leider mitbringen: Noch sind Web Components nicht in jedem Browser ohne Weiteres verfügbar. Man kann diese Funktionalität aber über Polyfills nachrüsten.</p><h3>Polyfills</h3><p>Polyfills erlauben es, Funktionen, die im Browser momentan nicht unterstützt werden, nachzurüsten. Dies kann bedeuten, dass die Performance nicht der nativen Implementierung entspricht und ist zusätzlicher Ballast für den Nutzer, da das jeweilige Skript geladen und ausgeführt werden muss.</p><h2>Überblick</h2><p>Wenn wir von Web Components sprechen, meinen wir vier Features, die wir uns im Folgenden genauer ansehen werden:</p><ul><li><strong>HTML Templates</strong>: Eine Möglichkeit mit Hilfe des <code><template></code> Elements HTML Vorlagen im Dokument zu hinterlegen. Diese können dann mit Hilfe von JavaScript manipuliert werden</li><li><strong>HTML Imports</strong>: Möglichkeit HTML in andere Dokumente zu laden</li><li><strong>Shadow DOM</strong>: innerhalb von HTML-Elementen ein eigenes, unabhängiges, DOM erzeugen und innerhalb von diesem neue Komponenten hinzufügen und stylen</li><li><strong>Custom Elements</strong>: API um eigene HTML Elemente zu schreiben</li></ul><ul><p>In diesem Beitrag sehen wir uns diese Features an. Der zugehörige Code liegt ebenfalls auf GitHub oder kann in einer HTML-Datei eingefügt werden, um das Ergebnis dann im Browser zu sehen.</p><h2>HTML Template Tag</h2><p>Mit dem <code>template</code>-Element können wir in HTML Vorlagen erstellen, die wir dann über JavaScript manipulieren und nutzen können. Das <code>template</code>-Element wird von HTML-Browsern geparst und in dem DOM-Tree aufgenommen, aber nicht auf der Seite gerendert.</p><p>Zunächst brauchen wir ein <code>template</code>, das wir in unserer HTML-Datei an beliebiger Stelle einfügen können.</p><p></p><p>In diesem Fall ist es nur ein <code>li</code>-Element, das wir gleich in eine Liste einbauen möchten. Hierzu brauchen wir in derselben HTML-Datei noch eine leere Liste:</p><p></p><p>Nun zum JavaScript: Da Web Components noch in Entwicklung sind, prüfen wir zunächst, ob HTML Templates im aktuellen Browser überhaupt unterstützt werden (1). Hier wird geprüft, ob man ein <code>template</code>-Element anlegen könnte und dieses das Property <em>content</em> hat. Ansonsten fügen wir einen Text ein, der uns über den fehlenden Support informiert (2). Diese Technik nennt sich Progressive Enhancement und soll sicherstellen, dass möglichst jeder Nutzer eine Seite auch benutzen kann.</p><p></p><p>Wenn wir HTML Templates nutzen können, definieren wir eine Liste von Strings, die wir als <code>li</code>-Element in der Liste sehen möchten. Danach  greifen wir über die DOM API auf das Template zu (1) und suchen uns innerhalb des Templates das <code>li</code>-Element (2). Die Liste benötigen wir, um die generierten <code>li</code>-Elemente einzufügen (3).</p><p>Anschließend iterieren wir über die zuvor definierten Features und schreiben das jeweilige Feature in unser li-Element (4), klonen das Ganze (5) und fügen den Klon in die Liste ein (6)</p><p></p><h3>Zwischenfazit: Template Tags</h3><p>Wenn wir uns HTML Template Tags alleine ansehen, sind diese nicht sonderlich spektakulär: Nichts, was man nicht mit ein paar Zeilen JavaScript auch vorher schon in ähnlicher Form machen konnte. Wahrscheinlich blähen sie den HTML-Code auf und bieten wenig Mehrwert. Neu ist das Element <code>template</code>, das wir im HTML verwenden und dann über JavaScript manipulieren können. Trotzdem sollten wir sie nicht direkt abschreiben: Wir werden später noch sehen, dass wir sie in Kombination mit den anderen Features gut gebrauchen können.</p><p>Momentan unterstützen Chrome, Edge, Firefox und Safari HTML Templates. Im Internet Explorer fehlt der Support. <a href="https://caniuse.com/#feat=template">Insgesamt werden bei ca 89 % der Nutzer HTML Templates unterstützt</a> .</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>ja</td><td>ja</td><td>ja</td><td>ja</td></tr></tbody></table><h2>HTML Imports</h2><p>Die Idee bei HTML Imports ist es, HTML-Code auszulagern und über das <code>link</code>-Element in die Anwendung zu laden. Wir integrieren mit etwas JavaScript die importieren Daten in unsere Anwendung.</p><p>Zunächst brauchen wir hier eine HTML-Datei, die den zu importierenden Code enthält.</p><p></p><p>In unserer eigentlichen Seite müssen wir nun nur noch die zu importierende Datei über ein <code>link</code>-Element referenzieren.</p><p></p><p>Im JavaScript-Code können wir nun erneut prüfen, ob der aktuelle Browser HTML Imports unterstützt:</p><p></p><p>Jetzt können wir den Inhalt des Imports über JavaScript laden (1), das Element aus dem Import suchen, das wir gerne nutzen möchten (2) und in unsere HTML-Datei (hier direkt im <code>body</code>-Element) einfügen (3).</p><p></p><h3>Zwischenfazit: HTML Imports</h3><p>Natürlich können wir hier, ähnlich dem vorherigen Beispiel, das HTML manipulieren (das wäre allerdings nichts neues). HTML Imports entfernen so die zusätzlichen <code>template</code>-Tags in unserem Dokument und sorgen so für eine kleinere HTML-Datei. Zusätzlich wird durch das Auslagern die Wiederverwendung in anderen Dateien möglich. Leider kommt dieses Feature nicht kostenlos, da wir nun für jeden Import einen zusätzlichen Server Request haben. Dies bedeutet dann, dass wir Dinge wie Caching und CORS berücksichtigen müssen.</p><p>HTML Imports sind momentan nur in Chrome implementiert und somit <a href="https://caniuse.com/#feat=imports">bei ca. 69 % der Nutzer</a>  verfügbar. Mozilla plant momentan nicht, HTML Imports zu implementieren.</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>ja</td><td>nicht geplant</td><td>nicht geplant</td><td>in Diskussion</td></tr></tbody></table><h2>Shadow DOM</h2><p>Das Shadow DOM erlaubt uns, innerhalb von HTML-Elementen ein eigenes DOM zu implementieren und dort zum Beispiel zusätzliche HTML Komponenten samt Styling zu hinterlegen. Dieses Shadow DOM ist unabhängig vom DOM, was die Entwicklung von Komponenten natürlich enorm vereinfacht. Gerade das Styling wird so vereinfacht, da sich CSS-Regeln nicht gegenseitig beeinflussen.</p><p>Unser HTML ist hier etwas einfacher: Wir brauchen nur ein Element, in das wir unser Shadow DOM einfügen. Dies erinnert an die etablierten Frameworks, die ebenfalls nur einen Einstiegspunkt brauchen. Das <code>p</code>-Element unter dem <code>div</code> dient als Beispiel für das Styling innerhalb des Shadow DOM</p><p></p><p>Wie bei den anderen Beispielen müssen wir überprüfen, ob wir das Shadow DOM im aktuellen Browser nutzen können.</p><p></p><p>Jetzt können wir das Element, in dem wir das Shadow DOM anlegen möchten, auswählen und mit <code>attachShadow()</code> unser Shadow DOM erzeugen (1). Mit <code>mode:"open"</code> (2) wird die Manipulation des Shadow DOM durch andere JavaScript-Funktionen erlaubt. Wenn hier <code>mode:"closed"</code> genutzt wird, ist dies nicht möglich. Ein einfacher Anwendungsfall ist z. B., mithilfe von <code>innerHTML</code> zusätzliches HTML in unser Shadow DOM zu schreiben (3). Dies funktioniert nicht bei allen Elementen, weshalb wir hier statt einer Liste ein paar Absätze in das Shadow DOM einfügen. Das CSS, das ebenfalls hinzugefügt wird (4), wirkt sich nur auf die Element im Shadow DOM aus.</p><p></p><h3>Zwischenfazit: Shadow DOM</h3><p>Dies ist ein sehr grundlegendes Beispiel für das Shadow DOM. Schön ist, dass man mit relativ wenig Code ein eigenes DOM erstellen und HTML-Code dynamisch ergänzen kann, das unabhängig gestylt werden kann. Der ursprüngliche HTML-Code spiegelt diese Änderungen jedoch nicht wider und so ist auf den ersten Blick nicht ersichtlich, woher die Inhalte der Seite kommen.</p><p>Das Shadow DOM ist momentan in Chrome und Firefox vollständig und in Safari teilweise implementiert, so dass hier <a href="https://caniuse.com/#feat=shadowdomv1"> ca 79 % der Nutzer das Feature nutzen können</a> .</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>ja</td><td>in Entwicklung (nä. Version)</td><td>teilweise</td><td>in Diskussion</td></tr></tbody></table><h2>Custom Elements</h2><p>Custom Elements erlauben es, eigene HTML-Tags zu schreiben und diese direkt im HTML-Dokument zu verwenden.</p><p>Im einfachsten Fall könnte es so aussehen, dass wir im HTML-Code zunächst unser Custom Element einbinden:</p><p></p><p>Um zu überprüfen, ob wir Custom Elements nutzen können, gibt es die folgende Prüfung:</p><p></p><p>Nun können wir uns eine JavaScript-Klasse erzeugen (diese erbt von HTMLElement) (1) und definieren über <code>innerHTML</code> (2), wie das Markup der Komponente aussieht. Wichtig: der <em>super</em>-Konstruktor muss aufgerufen werden, damit alles funktioniert.</p><p>Am Ende registrieren wir unsere Komponente als <code><web-components></code> (3). Custom Elements müssen übrigens unbedingt einen Dash (-) im Namen haben um zu funktionieren.</p><p></p><p>Spannend sind die Methoden, die wir in einem Custom-Element nutzen können (Tabelle 1).</p><table><thead><tr><th>API</th><th>Beschreibung</th><tbody><tr><td><code>static get observedAttributes()</code></td><td>Funktion, die einen Array der Attribute zurückgibt, die überwacht werden sollen.</td></tr><tr><td><code>connectedCallback()</code></td><td>Diese Funktion wird immer aufgerufen, wenn dieses Element in das DOM eingefügt wird.</td></tr><tr><td><code>disconnectedCallback()</code></td><td>Diese Funktion wird immer aufgerufen, wenn dieses Element aus dem DOM entfernt wird.</td></tr><tr><td><code>attributeChangedCallback(attrName, oldVal, newVal)</code></td><td>Wird aufgerufen, wenn eines der überwachten Attribute verändert wird (bspw. durch ein Event).</td></tr></tbody></tr><tr><td><code>adoptedCallback()</code></td><td>Wird aufgerufen, wenn das Element in ein anderes DOM verschoben wird.</td></tr></thead></table><h3>Zwischenfazit: Custom Elements</h3><p>Da wir Custom Elements in unserer Anwendung direkt im HTML-Code verwenden, können wir diese einfacher als React und Co integrieren. Die Browserkompatibilität ist allerdings, ohne Polyfill, ein Problem.</p><p>Custom Elements sind in Chrome vollständig und in Safari teilweise implementiert. Im Firefox wird das Feature in der nächsten Version implementiert sein. Wir kommen damit <a href="https://caniuse.com/#feat=custom-elementsv1">auf eine Verbreitung von ca 79 %</a> .</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>ja</td><td>in Entwicklung (nä. Version)</td><td>ja</td><td>in Diskussion</td></tr></tbody></table><h2>Shadow DOM, HTML Templates und Custom Elements</h2><p>Die vorherigen Beispiele zeigen, wie die einzelnen Features jeweils funktionieren. Erst die Kombination der einzelnen Features macht Web Components möglich: Wir erstellen ein Template (1) und verwenden dieses über ein Shadow DOM (2) in unserem Custom Element(3).</p><p></p><h2>Fazit</h2><p>Zusammenfassend lässt sich sagen, dass die hier vorgestellten Technologien noch nicht ohne den Einsatz von Polyfills im Projekt eingesetzt werden können. Mit fast 70 % Verbreitung ist allerdings auch schon ein guter Teil des Marktes abgedeckt. Sobald die Browserhersteller hier nachziehen, sollte einem Einsatz nichts mehr im Wege stehen.</p><p>Bei den hier vorgestellten Features handelt es sich um Low-level-APIs, die nur als Fundament für andere Frameworks und Libraries dienen können. Denkbar ist, dass React irgendwann auf Web Components wechselt, oder, wie beispielsweise Vue.js und Angular schon heute, Bibliotheken anbietet, mit denen Web Components erzeugt werden können (<a href="https://github.com/vuejs/vue-web-component-wrapper">vue-web-component-wrapper</a> , <a href="https://angular.io/guide/elements">angular elements</a> ). Vielversprechend sind hier auch Frameworks wie <a href="https://stenciljs.com/">stencil.js</a>  oder <a href="https://www.polymer-project.org/">Polymer</a> , die die Nutzung von Web Components vereinfachen.</p><p>Die Codebeispiele sind auch <a href="https://github.com/dmies/web-components-demo">auf GitHub</a>  einsehbar.</p><p>Eine erste Fassung des Artikels ist im Softwerker Vol. 11 erschienen. <a href="https://www.codecentric.de/wissen/softwerker/registrierung/">Jetzt kostenlos herunterladen</a> .</p></ul>

Ein Blick auf Web Components

<p>Verglichen mit den letzten Jahren ist es im JavaScript-Umfeld in letzter Zeit verhältnismäßig ruhig geworden. Gerade im Frontend sind React, Angular und, mit etwas Abstand, Vue etabliert und erfreuen sich einer wachsenden Nutzerbasis. Komponentenbasierte Ansätze haben sich hier durchgesetzt und <a href="https://blog.codecentric.de/2018/10/ein-blick-auf-web-components/" target="_blank">WebComponents</a>  sind weiterhin ein möglicher nächster Entwicklungsschritt, welcher aber vielmehr Fundament für die etablierten Frameworks als wirkliche Alternative sein könnte.</p><p><a href="https://svelte.dev" target="_blank">Svelte</a>  erfindet das Rad nicht neu, gewinnt aber immer mehr Aufmerksamkeit in der Community. Was Svelte mit den etablierten Ansätzen gemeinsam hat und wo es dann doch neue Wege geht, möchte ich in diesem Artikel beleuchten.</p><h2>Was ist Svelte?</h2><p>Svelte ist ein komponentenbasiertes Framework, so wie wir es von React, Angular und Vue bereits kennen, unterscheidet sich allerdings in einem wichtigen Punkt von den etablierten Platzhirschen: Diese erfordern deklarativen, State-getriebenen Code, welchen der Browser mit Techniken wie einem Virtual DOM in DOM-Operationen konvertieren muss.</p><p>Svelte versteht sich hier weniger als klassisches Framework, sondern vielmehr als Compiler, welcher den Code in hocheffizienten imperativen Code umwandelt und direkt das DOM manipuliert. Da Svelte keinen Framework-Code benötigt, produziert es kleinere Bundles, und ohne Virtual DOM im Speicher verspricht es eine bessere Performance.</p><p>Dies klingt ziemlich vielversprechend und fühlt sich in der Praxis auch schon sehr gut an. Der IDE Support ist leider noch nicht vergleichbar mit dem etablierter Frameworks, die offizielle Seite hilft hier aber gut weiter.</p><h2>Ein Blick auf Svelte</h2><p>Sobald die eigene IDE eingerichtet ist, kann eines der vorgefertigten Templates genutzt werden, um ein Svelte-Projekt aufzusetzen. Hierzu wird auf svelte.dev der Einsatz von <a href="https://github.com/Rich-Harris/degit" target="_blank">degit</a>  empfohlen und einfache Projekttemplates für Rollup und webpack stehen zur Verfügung.</p><p>Mit webpack sieht das ganze so aus:</p><div>

```bash
npx degit sveltejs/template-webpack svelte-app
cd svelete-app
npm install
npm run dev
```

</div><h3>Hello-World-Beispiel</h3><p>Jetzt, wo wir ein laufendes Projekt haben, können wir einen Blick auf die Komponenten werfen: Diese werden in .svelte-Dateien gespeichert und sehen auf den ersten Blick den Komponenten, wie man sie aus Vue kennt, relativ ähnlich. Innerhalb eines <script>-Elements kann JavaScript-Code geschrieben werden und innerhalb eines <style>-Elements steht der zugehörige CSS Code.</p><p>Wir öffnen im Ordner src die Datei <em>App.svelte</em> und ändern den Inhalt folgendermaßen ab:</p><div>

```html
<script>
  const name = "world!"
</script>
 
 
<style>
  h1{
    color:blue;
  }
</style>
 
<h1>Hello {name}</h1>
```

</div><p>Svelte wandelt diesen Code im Build-Prozess nun in JavaScript-Code um. In der <a href="https://svelte.dev/repl/hello-world?version=3.18.2" target="_blank">Svelte REPL</a>  kann man sich diesen übrigens auch direkt ansehen und ein wenig mit Svelte rumspielen.</p><p>Um unsere Anwendung etwas spannender zu gestalten, erstellen wir eine neue Headline-Komponente, die wir über Properties steuern können:</p><div>

```html
<script>
  export let text = "A sample headline";
</script>
 
 
<style>
  h1 {
    color: purple;
  }
</style>
 
<h1>{text}</h1>
```

</div><p>Properties werden im script-Element einfach exportiert und können dort auch mit einem Standard-Wert versehen werden.<br /> In unserer App.svelte importieren wir nun die Headline und ergänzen sie im Code:</p><div>

```html
<script>
  import Headline from "./Headline.svelte";
  const name = "world!"
</script>
 
 
<style>
  h1{
    color:blue;
  }
</style>
 
<h1>Hello {name}</h1>
```

</div><p>Wenn wir uns die Anwendung nun im Browser ansehen, fällt auf, dass beide Überschriften unterschiedliche Farben haben.</p><p><img loading="lazy" width="250" height="108" src="https://media.graphassets.com/cQlhMFQkRAaNRiZS7Iiq" alt="Svelte Appliation in the browser" /></p><p>Grund hierfür ist, dass jede Svelte-Komponente ihr eigenes Styling (scoped styles) hat, was es enorm einfach macht, Komponenten mit CSS zu gestalten.</p><h3>Kontrollstrukturen</h3><p>Kontrollstrukturen lassen sich in Svelte über die Templates realisieren. Eine if-Bedingung sieht hier beispielsweise folgendermaßen aus:</p><div>

```html
<script>
  export let level = 2;
  export let text = "Some headline"
</script>
 
{#if level===1}
<h1>{text}</h1>
{:else}
<h2>{text}</h2>
{/if}
```

</div><p>Besonders nützlich ist bei Schleifen die Möglichkeit, einen Fallback zu definieren, falls keine Elemente ausgegeben werden können:</p><div>

```html
<script>
  export let items = ["Hello", "World"];
</script>
 
{#each items as item}
{item}
 
{:else}
 
no item provided
 
{/each}
```

</div><p>Last but not least: Svelte erlaubt es hier auch auf asynchrone Requests zu reagieren und sowohl den Ladezustand, das Ergebnis als auch den Fehlerfall mit Hilfe der Template Syntax abzubilden:</p><div>

```html
<script>
  async function timeout(ms) {
    return new Promise(resolve => setTimeout(resolve, ms));
  }
</script>
 
{#await timeout(2000)}
sleeping
 
{:then}
 
awake!
 
{:catch}
 
error :(
 
{/await}
```

</div><p>Auch wenn die Template-Syntax anfangs etwas ungewohnt ist, hat sie einige sehr nützliche Features, die die Lesbarkeit des Codes verbessern.</p><h3>Und mehr…</h3><p>Svelte weiß auch an anderer Stelle mit nützlichen Features zu überzeugen. Es ist relativ einfach 2-way binding umzusetzen, und auch die Freunde von Animationen finden einige Möglichkeiten, hier mit Svelte schnell ein vorzeigbares Ergebnis zu erstellen. Schön ist auch die Integration von slots, wie man sie aus Vue kennt. Hier gibt es einige Möglichkeiten sehr flexible Komponenten zu erstellen. Auch anspruchsvolles State Management ist mit einer eigenen Store-Implementierung möglich. Diese ist aber sicher einen eigenen Beitrag im Blog wert.</p><p>Wer hier einen genaueren Blick auf all die Möglichkeiten werfen möchte, die Svelte mitbringt, sollte das <a href="https://svelte.dev/tutorial/basics" target="_blank">offizielle Tutorial</a>  ausprobieren.</p><p>Neben Svelte lohnt sich auch der Blick auf <a href="https://sapper.svelte.dev/" target="_blank">Sapper</a>  (App-Framework vergleichbar mit next.js) und <a href="https://svelte-native.technology/" target="_blank">Svelte Native</a>  (vergleichbar mit React Native).</p><p>TypeScript-Nutzer müssen sich bei Svelte noch etwas gedulden. Die Integration ist allerdings in Arbeit und hat auch <a href="https://svelte.dev/blog/svelte-3-rethinking-reactivity" target="_blank">hohe Priorität</a> .</p><h2>Fazit</h2><p>Svelte ist ein interessanter Ansatz, der es erlaubt Anwendungen ohne viel Boilerplate zu erstellen. Leider ist der IDE Support noch nicht vergleichbar mit den anderen Lösungen am Markt, und auch bei den verfügbaren Komponenten muss man noch Abstriche machen. Ein guter Einstiegspunkt hier ist die <a href="https://svelte-community.netlify.com/" target="_blank">offizielle Svelte-Community-Seite</a> . Svelte sieht wirklich vielversprechend aus und bekommt in letzter Zeit auch mehr und mehr Aufmerksamkeit.</p><p>Foto: <a href="https://unsplash.com/@flowforfrank">Ferenc Almasi</a> </p>

Gleich und doch anders: Einführung in Svelte

<p>Es gibt Libraries und Frameworks, die gehören zum täglichen Handwerkszeug eines Java-Entwicklers. Sei es das bevorzugte Test-Framework oder nützliche Libraries wie Guava. Für mich gehört seit langer Zeit <a href="http://projectlombok.org">Project Lombok</a>  dazu. Es erfüllt drei Kriterien, die mir im Entwickleralltag sehr wichtig sind: Lombok erlaubt mir überflüssigen Boilerplate Code zu vermeiden, reduziert Fehlerquellen und spielt sehr gut mit anderen Frameworks zusammen.<br /> <span><br /> Warum ich von Lombok so begeistert bin, lässt sich mit einem Blick auf etwas Code, der sich so oder so ähnlich in vielen Java-Projekten finden lässt, demonstrieren:</span></p><div>

```java
public class Person {
    private String firstName;
    private String familyName;
 
    public Person(String firstName, String lastName){
        this.firstName = firstName;
        this.lastName = lastName;
    }
 
    public String getFirstName() {
        return firstName;
    }
 
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
 
    public String getFamilyName() {
        return familyName;
    }
 
    public void setFamilyName(String familyName) {
        this.familyName = familyName;
    }
 
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
 
        Person person = (Person) o;
 
        if (firstName != null ? !firstName.equals(person.firstName) : person.firstName != null) return false;
        return !(familyName != null ? !familyName.equals(person.familyName) : person.familyName != null);
    }
 
    @Override
    public int hashCode() {
        int result = firstName != null ? firstName.hashCode() : 0;
        result = 31 * result + (familyName != null ? familyName.hashCode() : 0);
        return result;
    }
 
    @Override
    public String toString() {
        return "Person{" +
               "firstName='" + firstName + '\'' +
               ", familyName='" + familyName + '\'' +
               "}";
    }
}
```

</div><p>Was direkt auffällt: In Java ist relativ viel Code notwendig um sehr wenig auszudrücken. In der Tat überlassen es viele Entwickler der IDE, den Code zu generieren und hier fängt das Problem an: Sobald eine Klasse verändert wird, müssen auch <code>equals</code>, <code>hashCode</code> und <code>toString</code> berücksichtigt und neue Getter und Setter geschrieben werden. Natürlich ist dies beonders fehleranfällig, wenn unter Zeitdruck noch schnell eine Klasse angepasst werden muss. Sprachen wie Scala und Groovy können dies definitiv besser.</p><p>Hier kommt Lombok ins Spiel, denn mit einer einzigen Annotation sieht die selbe Klasse schon viel übersichtlicher aus:</p><div>

```java
@Data
public class Person {
    private String firstName;
    private String familyName;
 
    public Person(String firstName, String lastName){
        this.firstName = firstName;
        this.lastName = lastName;
    }
}
```

</div><p>Lombok generiert für uns alle Getter, Setter sowie <code>hashCode</code>, <code>equals</code> und <code>toString</code>. Da das Ganze zur compile time passiert, spielt Lombok auch sehr gut mit anderen Frameworks wie JPA zusammen.</p><p>Auch für die Generierung von Konstruktoren gibt es Annotationen (<code>@Data</code>) von Lombok:</p><div>

```java
@Data
@AllArgsConstructor
public class Person {
    private String firstName;
    private String familyName;
}
```

</div><p>Ein weiterer Vorteil: Lombok ergänzt nur die fehlenden Methoden. Wenn es also einen Getter oder Setter gibt, der vom Standard abweicht, kann er problemlos ergänzt werden. Dieser fällt dann in der Klasse auch gleich viel stärker auf.</p><div>

```java
@Data
@AllArgsConstructor
public class Person {
    private String firstName;
    private String familyName;
 
    public void setFamilyName(String familyName){
        if(familyName == null || familyName.isEmpty()){
            throw new IllegalArgumentException("Family name must be set.");
        }
        this.familyName = familyName;
    }
}
```

</div><p>Aber Lombok kann noch mehr: Sobald Vererbung ins Spiel kommt, lässt sich einfach festlegen ob <code>hashCode</code>, <code>equals</code> und <code>toString</code> auch die Felder der Elternklasse berücksichtigen sollen:</p><div>

```java
@Data
@EqualsAndHashCode(callSuper = true)
@ToString(callSuper = true)
public class Developer extends Person{
    private String favoriteFramework;
}
```

</div><p>Das Einsatzgebiet von Lombok beschränkt sich nicht nur darauf Java POJOs mit weniger Code zu schreiben. Auch für andere Dinge kann Lombok verwendet werden:</p><ul><li>Lombok bietet Annotationen für alle gängigen Logger-Frameworks um in einer Klasse einen Logger zu generieren.</li><li>Mit <a href="https://projectlombok.org/features/Builder.html"><code>@Builder</code></a>  kann ein POJO einfach um eine Builder-API erweitert werden.</li><li>weitere Einsatzgebietet sind in der <a href="https://projectlombok.org/features/index.html">Dokumentation</a>  zu finden.</li></ul><h2>Lombok im Projekt verwenden</h2><p>Alle notwendigen Informationen zu den Maven-Koordinaten (bzw. Ivy und Gradle) findet man auf der <a href="https://projectlombok.org/download.html">Download-Seite</a> . Auf dieser Seite sind auch die IDE Plugins aufgelistet, die Lombok-Support anbieten. Dies ist gerade für Funktionen wie Autovervollständigung notwendig.</p><p>Für Eclipse reicht es die aktuelle Version von Lombok zu laden und das jar auszuführen. Es öffnet sich eine grafische Oberfläche die den Anwender durch die Installation führt. In IntelliJ kann das Plugin über die Plugin-Verwaltung installiert werden.</p><p>Alle, die gerne weniger Code schreiben möchten, sollten Lombok eine Chance geben. Was sind Eure bevorzugten Libraries und warum? Schreibt doch einen Kommentar und erzählt mehr über Eure Werkzeuge.</p>

Weniger aber ausdrucksstarker Code mit Project Lombok

<p>Initial steps with Webpack can be confusing: Syntax and philosohy are pretty unique, and the documentation is not really beginner-friendly. Another problem I faced when starting to use it: There are many “starter packs” available which provide a build configuration, e.g. for ReactJS, that are very powerful and hard to understand for beginners. So, after working with it in my current project, I decided to help you get started with Webpack, too.</p><p><span></span></p><h2>What is Webpack?</h2><p>Webpack is a module bundler. It allows us to define modules in JavaScript and import them. With webpack you can split your application in multiple, smaller files and import them where needed.</p><p>But how do modules work? Let’s first have a look at a small example to gather an understanding of the underlying concepts, before creating a project and implementing the example (you can find the code at <a href="https://github.com/dmies/hello-webpack">GitHub</a> ).</p><h2>First steps on the command line</h2><p>First we need two JavaScript files where one loads the other to display some content on a webpage.</p><p>We create a file <code>add.js</code> which just exports a function that adds two numbers:</p>

```
module.exports = function(a,b){
  return a+b;
}

```

<p>Now we need a file which imports this module and writes the content to a webpage. We call this file <code>index.js</code> and save it in the same folder as <code>add.js</code></p>

```
var add = require('./add');

document.write("1 + 2 = " + add(1, 2));


```

<p>We use <code>require</code> to load the file (like we would do in a nodeJS file) and then write the content to the document using <code>document.write</code>.</p><p>So how to get this code working in the browser? Create a new file, <code>index.html</code> which just includes the <code>index.js</code>:</p>

```
<html>
    <head>
        <meta charset="utf-8">
    </head>
    <body>
        <script type="text/javascript" src="index.js"></script>
    </body>
</html>

```

<p>If you open this file in your browser, you get an error: “Uncaught ReferenceError: require is not defined”. We haven’t used Webpack yet, so this is okay. To get our sample working, we need to bundle our JavaScript files into one file.</p><p>If you haven’t installed webpack yet, use <code>npm</code> to install it globally:</p>

```
npm install -g webpack

```

<p>Afterwards use the command line tool to bundle the JavaScript code:</p>

```
webpack index.js bundle.js

```

<p>This command uses <code>index.js</code> as <strong>entry point</strong> and creates a new file <code>bundle.js</code> as <strong>output</strong>. The newly generated file combines our two files. Important: It doesn’t concatenate them like you would do it with tools like Gulp or Grunt. If you are curious, have a look at the generated file.</p><p>Finally, add <code>bundles.js</code> to our HTML file by replacing <code>index.js</code> with <code>bundle.js</code>. After reloading the HTML file in the browser, the string “1 + 2 = 3” should appear.</p><p>This was a first step with Webpack. Let’s have a look at a sample project.</p><h2>Project setup</h2><p>First we need a new folder for our project, let’s call it <code>hello-webpack</code> and initialize a new npm project in it (<code>npm init -y creates a project with default values</code>). Then we install Webpack locally:</p>

```
mkdir hello-webpack
cd hello-webpack
npm init -y
npm install --save webpack

```

<p>Create a folder <code>src</code> for our JavaScript files and copy <code>index.js</code> and <code>add.js</code> into it. The <code>index.html</code> must be copied into the root folder.</p><p>Project structure:</p>

```
├── index.html
├── node_modules
├── package.json
└── src
    ├── add.js
    └── index.js

```

<p>To simplify the usage of Webpack here, we can add a configuration file <code>webpack.conf.js</code> which stores all required information:</p>

```
module.exports = {
    entry: "./src/index.js",
    output: {
        filename: "bundle.js"
    }
};

```

<p>For our basic sample we only need the entry point: <code>src/index.js</code> and the path to the output: <code>bundle.js</code>. If you execute <code>webpack</code> now, it creates the bundles.js file and everything should work like before.</p><h2>Adding more modules to Webpack configuration</h2><p>To be honest, this is a nice example but it doesn’t show why Webpack is so great. Webpack becomes really powerful when you add loaders to it. Let’s start with two pretty useful ones:</p><ul><li><code>eslint-loader</code> for linting</li><li><code>babel-loader</code> to use modern JavaScript features with the help of Babel</li></ul><h3>Linting</h3><p>We use ESLint for linting here. A simple way to add it is by installing <code>eslint</code>, <code>babel-eslint</code> (because we use babel later) and <code>eslint-loader</code> (the loader for Webpack)</p>

```
npm i eslint babel-eslint eslint-loader --save-dev

```

<p>Now add a file <code>.eslintrc</code> with our linting configuration to the root of our project:</p>

```
{
   "parser": "babel-eslint"
}

```

<p>And finally, tell Webpack that it should use eslint for all JavaScript files:</p>

```
module.exports = {
    entry: "./src/index.js",
    output: {
        filename: "bundle.js"
    },
    module: {
        preLoaders: [{
            test: /\.js$/,
            loaders: ['eslint'],
        }]
    }
};

```

<p>The <code>preLoader</code> gets executed on every file which passes the <em>test</em>. In this case, every *.js file. The eslint-loader is executed for those files.</p><p>With linting enabled, it is easy to find problematic patterns in our code. Now we can update our modules and use modern JavaScript.</p><h3>Adding Babel</h3><p>Again we install a loader via npm. This time <code>babel-loader</code>:</p>

```
npm i -D babel-loader

```

<p>Now we can add it to our Webpack configuration:</p>

```
module.exports = {
    entry: "./src/index.js",
    output: {
        filename: "bundle.js"
    },
    module: {
        preLoaders: [{
            test: /\.js$/,
            loaders: ['eslint'],
        }],
        loader: {
            test: /\.js$/,
            loaders: ['babel']
        }
    }
};

```

<p>The <code>loader</code> is executed after the <em>preLoader</em>. Like the <em>preLoader</em> it has a test to control which files are handled by the loader.</p><p>With Babel in our Webpack configuration, we can use modern JavaScript in our project. Webpack handles bundling and (with help of babel) transpiling of our code.</p><p>For example, we can rewrite the file <code>add.js</code>:</p>

```
module.exports = (a,b) => a+b;

```

<p>After running Webpack again, the result should be the same as above.</p><h2>And much more</h2><p>This was just an introduction to Webpack that showed how to use it to bundle modules and add loaders for linting and transpiling our code. But there is so much more: Webpack is not limited to JavaScript, so you can add other resources like SASS or LESS files or even images to your modules, too. With the help of loaders you can process those files. I’m sure there are many projects where Webpack can replace build tools like Grunt and Gulp.</p>

Getting started with Webpack

<p>In 2020, web development is not only based on component-driven approaches but also on the use of state management solutions. These solutions are usually oriented towards the Flux architecture and its most prominent representative, <a href="https://redux.js.org/" target="_blank">Redux</a> . That’s why it is not surprising that Svelte also brings a suitable solution here, which I present in the following article. The code shown here is taken from the <a href="https://svelte.dev/tutorial" target="_blank">official tutorial</a> .</p><p>Interested in Svelte basics first? Have a look at my <a href="https://blog.codecentric.de/en/2020/02/same-but-different-introduction-to-svelte/">introduction to Svelte</a> .</p><h2>First steps</h2><p>Svelte comes with its own store implementation, as already mentioned. If we want to implement a store that manages the state of a counter, for example, we only need two lines of code:</p><div>

```html
import { writable } from 'svelte/store';
 
export const count = writable(0);
```

</div><p>The store is implemented as writeable (we will get to the read-only counterpart later) and we create a store with the initial state (here 0). The count variable exported here offers three methods:</p><ul><li><code>subscribe(callback)</code>: executed when the store is updated. The callback function gets the initial value in the store as parameter</li><li><code>update(callback)</code>: executes the callback. The callback function gets the initial value in the store as parameter</li><li><code>set(value)</code>: sets the value in the store to the transferred value value</li></ul><p>In a Svelte component a counter could look like this:</p><div>

```html
<script>
 import { count } from "./store";
 
 let count_value;
 function increment() {
   count.update(n => n + 1);
 }
 function decrement() {
   count.update(n => n - 1);
 }
 function reset() {
   count.set(0);
 }
count.subscribe(value => {
   count_value = value;
 });
</script>
 
<h1>The count is {count_value}</h1>
<button on:click="{increment}">
 +
</button>
<button on:click="{decrement}">
 -
</button>
<button on:click="{reset}">
 Reset
</button>
```

</div><p>You can save the usage of the <code>subscribe</code> function by using the short form <code>$count</code>:</p><div>

```html
<script>
 import { count } from "./store";
 
 function increment() {
   count.update(n => n + 1);
 }
 function decrement() {
   count.update(n => n - 1);
 }
 function reset() {
   count.set(0);
 }
</script>
 
<h1>The count is {$count}</h1>
<button on:click="{increment}">
 +
</button>
<button on:click="{decrement}">
 -
</button>
<button on:click="{reset}">
 Reset
</button>
```

</div><p>The <code>$</code> character is a reserved character in Svelte, which must always refer to a store. So it is not allowed to use it for your own variables.</p><h2>Custom stores</h2><p>Now you do not always want to interact directly with the store within a component. In Redux there are Reducers and Actions, with which you can trigger changes to the state. In Svelte we can create a custom store, for which we can define our own operations. The advantage here is that you need less boilerplate code to manipulate the state.</p><div>

```html
import { writable } from "svelte/store";
 
function createCount() {
 const { subscribe, set, update } = writable(0);
 
 return {
   subscribe,
   increment: () => update(n => n + 1),
   decrement: () => update(n => n - 1),
   reset: () => set(0)
 };
}
 
export const count = createCount();
```

</div><p>In the component we save a lot of code and make everything a bit clearer:</p><div>

```html
<script>
 import { count } from "./store";
</script>
 
<h1>The count is {$count}</h1>
<button on:click="{count.increment}">
 +
</button>
<button on:click="{count.decrement}">
 -
</button>
<button on:click="{count.reset}">
 Reset
</button>
```

</div><h2>Readable and derived store</h2><p>In addition to the writeable store, Svelte offers two more appealing options: the readable store and the derived store.</p><p>The <a href="https://svelte.dev/docs#readable" target="_blank">readable store</a>  is, as the name suggests, a read-only store. It can be used if the data managed in the store should not be manipulated by the user.</p><p>The <a href="https://svelte.dev/docs#derived" target="_blank">derived store</a>  allows you to manage data dependent on other stores. This way, complexity in individual stores can be avoided by outsourcing them to derived stores.</p><h2>Conclusion</h2><p>Svelte is not reinventing the wheel when it comes to state management: We are already familiar with the idea of implementing state management via stores from React, Angular and Vue. Nevertheless, the solution established by Svelte is interesting: read-only and derived stores solve known problems in front-end applications. The possibility to create custom stores saves a lot of boilerplate code (which <a href="https://blog.codecentric.de/en/2020/02/simplifying-redux-with-the-redux-toolkit/">can be replaced by libraries</a> ) and allows you to implement the stores with domain-specific logic.</p><p>Picture by <a href="https://unsplash.com/@mikepetrucci" target="_blank">Mike Petrucci</a> </p>

State management in Svelte

<p>When it comes to modern web applications, there is currently (almost) no way around Angular and React. Of course there are very interesting alternatives such as Vue.js, Ember etc., but in larger projects, they played a considerably smaller role in 2017.<br /> Obviously, the question arises as to how things will develop in the fast-moving ecosystem around JavaScript etc. in the upcoming years. Certainly, component-based frameworks will continue dominate the market in 2018 and beyond. However, an alternative has been emerging on the horizon for some time now: Web Components.</p><p>Web Components are a series of features that the W3C is currently adding to the HTML and DOM specifications. Web Components allow you to create reusable components for Web applications, a concept already familiar from Angular and React.</p><p>In this post we will take a look at these features and the possibilities they offer.</p><h2>Example with React</h2><p>Let’s take as an example a list of strings we want to display. In React it looks like this:</p><p></p><p>This feels a lot like “native” HTML. While React only allows you to use your own components, Web Components allow you to define your own HTML elements, which you can integrate into a page like normal HTML. Therefore, they can also be easily used on the server side. Another advantage: they behave like HTML and can therefore be used with any JavaScript library and any framework that can handle HTML (e.g. for events).</p><p>Web Components are also based on Web standards and are therefore more future-proof. However, we must also take into account one disadvantage that Web Components unfortunately currently have: they are not yet available in every browser without difficulty. However, this functionality can be added using Polyfills.</p><h3>Polyfills</h3><p>Polyfills allow you to retrofit functions that are not currently supported in the browser. This in turn can mean that the performance does not correspond to the native implementation and is an additional burden for the user, since the respective script must be loaded and executed.</p><h2>Overview</h2><p>When we talk about Web Components, we refer to four features that we will explore in more detail below:</p><ul><li><strong>HTML Templates</strong>: a way to store HTML templates in the document using the <code><template></code> element. These can then be manipulated with the help of JavaScript.</li><li><strong>HTML Imports</strong>: possibility to load HTML into other documents</li><li><strong>Shadow DOM</strong>: create your own, independent DOM within HTML elements</li><li><strong>Custom Elements</strong>: API to write your own HTML elements</li></ul><ul><p>In the following we will look at these features. The corresponding code is also on GitHub or can be inserted into an HTML file to see the result in the browser.</p><h2>HTML Template tag</h2><p>With the <code>template</code> element, we can create templates in HTML, which we can manipulate and use via JavaScript. The <code>template</code> element is parsed by the HTML browser and included in the DOM tree, but not rendered on the page.</p><p>First we need a <code>template</code> which we can insert into our HTML file at any place.</p><p></p><p>In this case it is only a <code>li</code>-element, which we want to include in a list. For this we need an empty list in the same HTML file:</p><p></p><p>As to JavaScript: since Web Components are still under development, we first check whether HTML templates are supported in the current browser (1). Here we check if you could create a template element which has the property content, otherwise we insert a text informing us about the missing support (2). This technique is called progressive enhancement and is intended to ensure that as many users as possible can use a page.</p><p></p><p>If we can use HTML templates, we define a list of strings we want to see as li elements in the list. Then we access the template (1) via the DOM API and look for the li element (2) within the template. We need the list to insert the generated li elements (3).</p><p>Then we iterate over the previously defined features and write the respective feature into our li element (4), clone the whole thing (5) and insert the clone into the list (6).</p><p></p><h3>Interim Conclusion: Template tags</h3><p>If we look at HTML template tags themselves, they are not very spectacular: nothing you weren’t able to do before with a few lines of JavaScript in a similar form. They probably inflate the HTML code and offer little added value. What’s new is the element template, which we can use in HTML and then manipulate via JavaScript. Nevertheless, we should not write them off directly: we’ll see later that we can use them in combination with the other features.</p><p>Currently, Chrome, Edge, Firefox and Safari support HTML Templates. Internet Explorer lacks support. <a href="https://caniuse.com/#feat=template">Altogether 89% of users support HTML templates</a> .</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>yes</td><td>yes</td><td>yes</td><td>yes</td></tr></tbody></table><h2>HTML imports</h2><p>The idea behind HTML Imports is to outsource HTML code and load it into the application using the <code>link</code> element.</p><p>First we need an HTML file containing the code to import.</p><p></p><p>In our actual page we only have to reference the file to be imported via a <code>link</code> element.</p><p></p><p>In the JavaScript code we can now check again whether the current browser supports HTML imports:</p><p></p><p>Now we can load the content of the import via JavaScript (1), search for the element from the import we would like to use (2) and insert it into our HTML file (here directly in the body element) (3).</p><p></p><h3>Interim conclusion: HTML imports</h3><p>Of course, similar to the previous example, we can manipulate the HTML (but that would be nothing new). HTML imports remove the additional template tags in our document and create a smaller HTML file. In addition, outsourcing allows for reuse in other files. Unfortunately, this feature is not free, as we now have an additional server request for each import. This means that we have to consider things like caching and CORS.</p><p>HTML imports are currently only implemented in Chrome and therefore available to <a href="https://caniuse.com/#feat=imports">about 68% of users</a> . Mozilla is currently not planning to implement HTML imports.</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>yes</td><td>not planned</td><td>not planned</td><td>in discussion</td></tr></tbody></table><h2>Shadow DOM</h2><p>The shadow DOM lets us implement our own DOM within HTML elements and store additional HTML components including styling, for example. The Shadow DOM is independent of the DOM, which simplifies the development of components enormously. Especially the styling is simplified, because CSS rules do not influence each other.</p><p>Our HTML is a bit simpler here: we only need one element into which we insert our shadow DOM. This is reminiscent of the established frameworks, which also only need one entry point. The p element below the div serves as an example of styling within the shadow DOM.</p><p></p><p>As with the other examples, we need to check if we can use the Shadow DOM in the current browser.</p><p></p><p>Now we can select the element in which we want to create the shadow DOM and create our shadow DOM with attachShadow() (1). With mode: “open” (2) the Shadow DOM can be manipulated by other JavaScript functions. If mode: “closed” is used here, this is not possible. A simple use case is e.g. to write additional HTML into our shadow DOM with the help of innerHTML (3). This does not work for all elements, so instead of a list here we insert a few paragraphs into the shadow DOM. The CSS, which is also added (4), only affects the elements in the shadow DOM.</p><p></p><h3>Interim conclusion: Shadow DOM</h3><p>This is a very basic example for the Shadow DOM. It is great that you can create your own DOM with relatively little code and dynamically add HTML code, which can be styled independently. However, the original HTML code does not reflect these changes and thus at first glance it is not obvious where the contents of the page come from.</p><p>The Shadow DOM is currently fully implemented in Chrome and (the next) Firefox. It is partially implemented in Safari, so that <a href="https://caniuse.com/#feat=shadowdomv1">about 79% of users can use the feature</a> .</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>yes</td><td>in development (next version)</td><td>partial</td><td>in discussion</td></tr></tbody></table><h2>Custom elements</h2><p>Custom elements allow you to write your own HTML tags and use them directly in the HTML document.</p><p>In the most basic case it could look like this, where we first include our custom element in the HTML code:</p><p></p><p>To check whether we can use custom elements, the following check is available:</p><p></p><p>Now we can create a JavaScript class (this inherits from <code>HTMLElement</code>) (1) and use <code>innerHTML</code> (2) to define what the markup of the component looks like. Important: the super constructor must be called for everything to work.</p><p>At the end we register our component as <code><web-components></code> (3). Custom elements must have a dash (-) in their name to work.</p><p></p><p>The methods that we can use in a custom element are noteworthy.</p><table><thead><tr><th>API</th><th>Beschreibung</th><tbody><tr><td><code>static get observedAttributes()</code></td><td>function that returns an array of attributes to be monitored.</td></tr><tr><td><code>connectedCallback()</code></td><td>this function is always called when this element is inserted into the DOM.</td></tr><tr><td><code>disconnectedCallback()</code></td><td>this function is always called when this element is removed from the DOM.</td></tr><tr><td><code>attributeChangedCallback(attrName, oldVal, newVal)</code></td><td>Called when one of the monitored attributes is changed (for example, by an event).</td></tr></tbody></tr><tr><td><code>adoptedCallback()</code></td><td>is called when the element is moved to another DOM.</td></tr></thead></table><h3>Interim conclusion: Custom elements</h3><p>Since we use custom elements in our application directly in HTML code, we can integrate them more easily than React and Co. Browser compatibility, however, is a problem without Polyfill.</p><p>Custom elements are partially implemented in Chrome and Safari, resulting in <a href="https://caniuse.com/#feat=custom-elementsv1">a distribution of about 79%</a> .</p><table><thead><tr><th>Chrome</th><th>Firefox</th><th>Safari</th><th>Edge</th></tr></thead><tbody><tr><td>yes</td><td>in development (next version)</td><td>yes</td><td>in discussion</td></tr></tbody></table><h2>Shadow DOM, HTML Templates und Custom Elements</h2><p>The previous examples show how each feature works. Only the combination of the individual features makes Web Components possible: We create a template (1) and use this via a shadow DOM (2) in our custom element (3).</p><p></p><h2>Conclusion<p>In summary it can be said that the technologies presented here cannot yet be used in the project without using Polyfills. With almost 70% distribution, however, a good part of the market is already covered. As soon as the browser manufacturers follow suit, nothing should stand in the way of using them.</p><p>The features presented here are low-level APIs, which can only serve as a foundation for other frameworks and libraries. It is conceivable that React will eventually switch to Web Components, or, as Vue.js and Angular already do today, offer libraries with which Web Components can be created (<a href="https://github.com/vuejs/vue-web-component-wrapper">vue-web-component-wrapper</a> , <a href="https://angular.io/guide/elements">angular elements</a> ). Promising frameworks such as <a href="https://stenciljs.com/">stencil.js</a>  or <a href="https://www.polymer-project.org/">Polymer</a> , which simplify the use of Web Components, are also available.</p><p>The code examples are also available on <a href="https://github.com/dmies/web-components-demo">auf GitHub</a> .</p></h2></ul>

A look at Web Components

<p>Compared to the past few years, the JavaScript world has become relatively quiet lately. Especially in the frontend React, Angular, and with some distance Vue are established and delight a growing user base. Component-based approaches have gained acceptance here and <a href="https://blog.codecentric.de/en/2018/10/a-look-at-web-components/" target="_blank">WebComponents</a>  are still a possible next development step, which could rather be the foundation for the established frameworks as a real alternative.</p><p><a href="https://svelte.dev" target="_blank">Svelte</a>  is not reinventing the wheel, but is gaining more and more attention in the community. In this article, I would like to highlight what Svelte has in common with the established approaches and where it comes to breaking new ground.</p><h2>About Svelte</h2><p>Svelte is a component-based framework just as we already know it from React, Angular and Vue, but differs from the established top performers in one important aspect: they require declarative, State-driven code, which the browser has to convert into DOM operations using techniques like a Virtual DOM.</p><p>Svelte is not a classical framework but rather a compiler, which converts the code into highly efficient imperative code and manipulates the DOM directly. Since Svelte does not require any framework code, it produces smaller bundles, and without a Virtual DOM in memory it promises better performance.</p><p>This sounds quite promising and already feels very good in practice. Unfortunately, the IDE support is not comparable to the established frameworks but the official site helps a lot.</p><h2>A glance at Svelte</h2><p>Once your IDE is set up, you can use one of the predefined templates to set up a Svelte project. On svelte.dev the use of <a href="https://github.com/Rich-Harris/degit" target="_blank">degit</a>  is recommended, and simple project templates for rollup and webpack are available.</p><p>Using webpack, the whole thing looks like this:</p><div>

```bash
npx degit sveltejs/template-webpack svelte-app
cd svelete-app
npm install
npm run dev
```

</div><h3>Hello world example</h3><p>Now that we have a project up and running, we can take a brief look at the components: these are stored in <em>.svelte</em> files and at first glance look quite similar to the components we know from Vue. Inside a <script> element JavaScript code can be written and inside a <style> element the corresponding CSS code can be found.</p><p>We open the file <em>App.svelte</em> in the folder src and change the content as follows:</p><div>

```html
<script>
  const name = "world!"
</script>
 
 
<style>
  h1{
    color:blue;
  }
</style>
 
<h1>Hello {name}</h1>
```

</div><p>Svelte now converts this code into JavaScript code in the build process. In the <a href="https://svelte.dev/repl/hello-world?version=3.18.2" target="_blank">Svelte REPL</a>  you can have a look at it and play around with Svelte.</p><p>To make our application a bit more exciting we create a new Headline component which we can control via properties:</p><div>

```html
<script>
  export let text = "A sample headline";
</script>
 
 
<style>
  h1 {
    color: purple;
  }
</style>
 
<h1>{text}</h1>
```

</div><p>Properties are exported inside the script element and can also be assigned a default value.<br /> In our App.svelte we now import the headline and add it to the code:</p><div>

```html
<script>
  import Headline from "./Headline.svelte";
  const name = "world!"
</script>
 
 
<style>
  h1{
    color:blue;
  }
</style>
 
<h1>Hello {name}</h1>
```

</div><p>Looking at the application in the browser, we notice that both headings have different colors.</p><p><img loading="lazy" width="250" height="108" src="https://media.graphassets.com/cQlhMFQkRAaNRiZS7Iiq" alt="Svelte Appliation in the browser" /></p><p>This is because each Svelte component has its own styling (scoped styles), which makes it very easy to create components with CSS.</p><h3>Control structures</h3><p>Control structures can be realized in Svelte via the templates. For example, an if condition looks like this:</p><div>

```html
<script>
  export let level = 2;
  export let text = "Some headline"
</script>
 
{#if level===1}
<h1>{text}</h1>
{:else}
<h2>{text}</h2>
{/if}
```

</div><p>The option to define a fallback if no elements can be output is particularly useful for loops:</p><div>

```html
<script>
  export let items = ["Hello", "World"];
</script>
 
{#each items as item}
{item}
 
{:else}
 
no item provided
 
{/each}
```

</div><p>Last but not least: Svelte also allows us to handle asynchronous requests and represents the load state, the result, and the error case using the template syntax:</p><div>

```html
<script>
  async function timeout(ms) {
    return new Promise(resolve => setTimeout(resolve, ms));
  }
</script>
 
{#await timeout(2000)}
sleeping
 
{:then}
 
awake!
 
{:catch}
 
error :(
 
{/await}
```

</div><p>Although the template syntax is a bit unusual in the beginning, it has some very useful features that improve the readability of your code.</p><h3>And much more</h3><p>Svelte also has a few other useful features to convince you. It is pretty easy to implement 2-way binding, and also friends of animation will find some possibilities to create a presentable result in no time using Svelte. The integration of slots is also pretty nice, as you already know it from Vue. There are several possibilities to create very flexible components. Even sophisticated state management is possible with an own store-implementation. But this is certainly worth a seperate post on the blog.</p><p>If you want to take a closer look at all the possibilities Svelte offers, you should try the official <a href="https://svelte.dev/tutorial/basics" target="_blank">tutorial</a> .</p><p>Besides Svelte it is also worthwhile to have a look at <a href="https://sapper.svelte.dev/" target="_blank">Sapper</a>  (App Framework comparable to next.js) and <a href="https://svelte-native.technology/" target="_blank">Svelte Native</a>  (comparable to React Native).</p><p>TypeScript users still have to wait out for Svelte. However, the integration is in progress and <a href="https://svelte.dev/blog/svelte-3-rethinking-reactivity" target="_blank">has a high priority</a> .</p><h2>Conclusion</h2><p>Svelte is an inspiring approach that allows you to build applications without using much boilerplate. Unfortunately, the IDE support is not yet comparable to the other solutions on the market, and also the available components have to be cut back. A good entry point is the <a href="https://svelte-community.netlify.com/" target="_blank">official Svelte community website</a> . Svelte looks very promising and is getting more and more attention lately.</p><p>Picture: <a href="https://unsplash.com/@flowforfrank" target="_blank">Ferenc Almasi</a> </p>

Same but different: Introduction to Svelte

<p>There are libraries and frameworks that belong to the daily tools of a Java developer, e.g. your preferred testing framework or useful libraries like Guava. For some time now, I have used a library that meets three criteria that are essential to my daily work: <a href="http://projectlombok.org">Project Lombok</a> . It allows me to avoid boilerplate code, it reduces errors, and it plays very well together with other frameworks.</p><p>But first, to show you why I’m so thrilled about Lombok, let us have a look at some code that can be found in many Java projects:</p><div>

```java
public class Person {
    private String firstName;
    private String familyName;
 
    public Person(String firstName, String lastName){
        this.firstName = firstName;
        this.lastName = lastName;
    }
 
    public String getFirstName() {
        return firstName;
    }
 
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
 
    public String getFamilyName() {
        return familyName;
    }
 
    public void setFamilyName(String familyName) {
        this.familyName = familyName;
    }
 
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
 
        Person person = (Person) o;
 
        if (firstName != null ? !firstName.equals(person.firstName) : person.firstName != null) return false;
        return !(familyName != null ? !familyName.equals(person.familyName) : person.familyName != null);
    }
 
    @Override
    public int hashCode() {
        int result = firstName != null ? firstName.hashCode() : 0;
        result = 31 * result + (familyName != null ? familyName.hashCode() : 0);
        return result;
    }
 
    @Override
    public String toString() {
        return "Person{" +
                "firstName='" + firstName + '\'' +
                ", familyName='" + familyName + '\'' +
                '}';
    }
}
```

</div><p>One thing which stands out immediately: In Java, you sometimes need quite a lot of code to express very little. In fact, many developers let their IDE generate most of this code, and this is the main problem: Once a class must be changed, you have to write new getters and setters, <code>equals</code>, <code>hashCode</code>, and <code>toString</code>. Of course, this is error-prone, especially if you have to adjust a class under time constraints and pressure.</p><p>This is where Lombok comes into play: Only a single annotation (<code>@Data</code>) is needed to make the class look clearer:</p><div>

```java
@Data
public class Person {
    private String firstName;
    private String familyName;
 
    public Person(String firstName, String lastName){
        this.firstName = firstName;
        this.lastName = lastName;
    }
}
```

</div><p>Lombok generates all getters, setters as well as <code>hashCode</code>, <code>equals</code> and <code>toString</code>. This happens at compile time. Thus, Lombok plays well with other frameworks such as JPA.</p><p>There is an annotation to generate constructors, too:</p><div>

```java
@Data
@AllArgsConstructor
public class Person {
    private String firstName;
    private String familyName;
}
```

</div><p>Another benefit: Lombok only generates missing methods. If there is a getter or setter in your code that is more specific, you can add it to your normal code. It will then be more noticeable than before.</p><p>But Lombok can do even more: Once inheritance comes into play, it is easy to specify whether <code>equals</code>, <code>hashCode,</code> and <code>toString</code> should also take account of fields of the parent class:</p><div>

```java
@Data
@EqualsAndHashCode(callSuper = true)
@ToString(callSuper = true)
public class Developer extends Person{
  private String favoriteFramework;
}
```

</div><p>Lombok is not limited to writing Java POJOs with less code, though. There are other use cases, too:</p><ul><li><p>Lombok provides annotations for all common logger frameworks to create a logger in a class.</p></li><li><p><a href="https://projectlombok.org/features/Builder.html"><code>@Builder</code></a>  generates a builder-api for your POJO.</p></li><li><p>more usecases can be found in the <a href="https://projectlombok.org/features/index.html">documentation</a> .</p></li></ul><h2>Use Lombok in your project</h2><p>The Maven coordinates (or Ivy and Gradle) can be found on the <a href="https://projectlombok.org/download.html">download page</a> . On this page the IDE plugins, offering Lombok support, are listed, too. These are especially necessary for features like autocompletion.</p><p>For Eclipse, it is sufficient to download the latest version of Lombok and execute the JAR. This will open a graphical interface that guides you through the installation process. In IntelliJ the plugin can be installed via plugin management.</p><p>So if you like to write less code, give Lombok a try. What are your favorite Java frameworks and everyday helpers and why? Leave a comment and tell more about your tools.</p>

Less but more expressive code with Project Lombok

Contact Us | Fragen an Mitarbeiter

Sprich mich an

Möchtest du dich mit mir zum JAMStack austauschen?

Auf unserem Blog findest du viele Artikel zu Tech-Themen von unseren Mitarbeitenden. Vielleicht ist auch hier ein Thema für dich dabei. Schau gerne mal rein!

BLOG

codecentric Blog

WISSENS-HUB

Events – codecentric mittendrin

Community

Softwareentwicklung

Kultur

Der Softwerker

Hier gibt's noch mehr spannende Infos von uns für euch

Was ist der JAMstack? | codecentric AG

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Absenden

Was ist der JAMstack?

Aus dem Inhalt:

Sprich mich an

Hier gibt's noch mehr spannende Infos von uns für euch

codecentric Blog

Events – codecentric mittendrin

Der Softwerker

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten