Auf der Website bekommst du auch einen guten Eindruck, was sich geändert hat. Unter anderem neue Formen und neue Animationen.

Was ich am spannendsten finde: dynamische Farben.

Google hat in Android 12 ein Algorithmus integriert, der Farbtöne aus dem Wallpaper der Nutzer:innen extrahiert, die vom UI verwendet werden können. So bekommen die Apps eine persönlichere Note.

Ich habe kein Android-Gerät, deswegen konnte ich das Feature noch nicht selbst ausprobieren.

Umsetzung für Webseiten?

Bisher ist Material You hauptsächlich für Android vorgesehen, es wird aber eine Frage der Zeit sein, dass auch an Web gedacht wird. Webseiten haben keine direkte Möglichkeit, den Wallpaper vom Betriebssystem abzugreifen.

Möglicherweise wird Google für Chrome die Theme-Farben als CSS-Variablen liefern, sodass Webentwickler:innen diese einfach nutzen können. Andere Chromium-Browser (wie Edge) könnten diese API dann ebenfalls erhalten.

Übergangslösung

Ich habe ein wenig experimentiert und Farben aus dem Standard-Wallpaper aus macOS Monterey mit Hilfe von Adobe Color extrahiert.

Den Dark Mode habe ich ebenfalls berücksichtigt:

In nächsten Schritten könnte man mit JavaScript herausfinden, welches Betriebssystem verwendet wird und jeweils Farben der Standard-Wallpaper anwenden.

Oder man erlaubt, Benutzer:innen ein Bild zum Analysieren hochzuladen/auszuwählen. Das halte ich allerdings für einen nicht sehr eleganten Ansatz.

Innerhalb eines Projekts ist es auf jeden Fall angenehm, überall die gleiche Formatierung zu haben. Das sorgt für eine bessere Übersicht und befriedigt nebenbei den inneren Monk.
Arbeitet man mit mehreren Personen an einem Projekt, kannst du entweder regelmäßig von Hand den Code der anderen formatieren oder du lässt es machen, automatisch!

Installiere Prettier

Das geht mit dem Tool Prettier! Du legst zuvor in einer Config-Datei (.prettierrc.json) die Regeln fest (Semikolons ja/nein, maximale Zeilenlänge etc.) und führst dann Prettier aus. In einer separaten Datei (.prettierignore) kannst du noch definieren, welche Ordner und Dateien dabei unangetastet bleiben sollen.

Folge einfach dem offiziellen Guide, um Prettier bei dir einzurichten: Install · Prettier

Prettier bei jedem Git Commit ausführen

Du kannst Prettier jedes Mal manuell ausführen oder dafür eine Extension in deinem Code-Editor installieren. Ich finde es allerdings angenehmer, dass Prettier automatisch vor jedem Git Commit ausgeführt wird. So wird sichergestellt, dass kein unschöner Code nach GitHub gelangt (oder wo auch immer du Git hostest). Auch funktioniert das ganze dann unabhängig davon, welchen Code-Editor du oder Team-Kolleg:innen verwenden.

Ich bin einfach den Abschnitt “Git hooks” gefolgt: Install · Prettier

Das Tool “Husky” sorgt also dafür, dass Prettier vor jedem Git Commit-Befehl ausgeführt wird und der Code formatiert wird.

Meine bevorzugten Einstellungen

Meine .prettierrc.json-Datei sieht so aus:

{
    "tabWidth": 4,
    "useTabs": false,
    "semi": false,
    "singleQuote": false,
    "trailingComma": "none",
    "bracketSpacing": true,
    "bracketSameLine": false,
    "fluid": false
}

• Zur Einrückung werden 4 Leerzeichen verwendet.
• Ich nutze keine Semikolons (bei JavaScript und TypeScript).
• Ich nutze doppelte Anführungszeichen bei Strings (").
• Keine Kommata, wo es nicht notwendig ist (z.B. in TypeScript Interfaces).
• Leerzeichen um geschweifte Klammern ({ foo: bar }).
• Für bracketSameLine siehe: https://prettier.io/docs/en/options.html#bracket-line

Was du in .prettierignore reinschreibst, ist stark von deinem jeweiligem Projekt abhängig. Grundsätzlich sollte da alles rein, was kompiliert wird (vielleicht build-Ordner).

Aber auch für Microsoft bietet das meiner Ansicht nach die Chance, Windows ARM endlich attraktiver zu machen. Tatsächlich war Microsoft in dem Bereich schon viel weiter, Windows RT wurde bereits 2012 veröffentlicht. Möglicherweise seiner Zeit voraus, konnte es sich aber nicht gut behaupten. Es gab nur wenig gute Apps, die dafür entwickelt wurden und es war auch nicht möglich, x86-Apps zu emulieren, so wie es mit Apple M1 und macOS Big Sur möglich ist (Stichwort Rosetta 2).

Microsoft war leider noch nie erfolgreich darin, Entwickler zu überzeugen, Software für ihre Plattform anzupassen. Windows Phone und Windows Mobile hatten ein ähnliches Problem. Das ist leider auch ein Teufelskreis. Entwickler werden Apps eher für Betriebssysteme schreiben, die auch von der Mehrheit genutzt wird (iOS/Android). Apple ist darin deutlich besser. Bereits in der kurzen Zeit, seitdem macOS mit Apple Silicon angekündigt hat, haben bereits viele Entwickler begonnen, ihre Software anzupassen und auf ARM-Architektur zu optimieren. Und deswegen glaube ich, dass bald auch Windows-ARM-Geräte wieder interessanter werden können. Denn wenn Software wie Photoshop einmal für Apple M1 umgeschrieben wurde, könnte es auch einfacher sein, diesen Code auch für andere ARM-CPUs zu kompilieren.

Glaubt ihr, dass wir schon bald mehr ARM-PCs mit Windows sehen werden?