Anmelden
[unable to retrieve full-text content]
Dank KI können Entwickler viele neue Anwendungsfälle umsetzen. Die Built-in-AI-APIs bringen KI-Modelle auf das eigene Gerät.
(Bild: Fabio Principe/ Shutterstock.com)
Chatbots und andere Use Cases rund um natürliche Sprache laufen dank der Built-in-AI-APIs direkt im Browser. Erste APIs können Developer in Chrome testen.
Generative KI legt den Grundstein für zahlreiche Anwendungsfälle, die vorher schwierig oder gar nicht umzusetzen waren. Sie legt den Fokus auf das Verarbeiten und Erzeugen von Inhalten wie Text, Bildern, Audio und Video mithilfe von Machine-Learning-Modellen: In der Trainingsphase werden sie mit erheblichen Datenmengen trainiert und können dann aus ihnen völlig unbekannten Situationen sinnvolle Zusammenhänge schließen, in denen regelbasierte Algorithmen an ihre Grenzen stoßen.
Large Language Models (LLMs) beschränken sich auf das Verarbeiten und Erzeugen von Text in natürlicher Sprache. Sie sind bereits zu einem wichtigen Baustein in der Softwarearchitektur geworden: LLMs können Inhalte übersetzen, Daten aus unstrukturiertem Text extrahieren, längere Textabschnitte präzise zusammenfassen, Code schreiben oder interaktive Dialoge mit dem Anwender führen.
Bislang führte der Weg zur Nutzung von LLMs praktisch immer in die Cloud. Gerätehersteller sind jedoch dazu übergegangen, LLMs mit ihren Geräten und Betriebssystemen auszuliefern: Die Funktionen von Apple Intelligence wie das Zusammenfassen mehrerer Benachrichtigungen werden durch ein lokales LLM ausgeführt [1]. Google liefert High-End-Smartphones mit seinem LLM Gemini Nano aus [2] und Microsoft bringt mit der Windows Copilot Runtime sein LLM Phi Silica auf Windows-Geräte [3].
Lokal ausgeführte LLMs sind auch offline verfügbar, haben ein verlässliches Antwortverhalten unabhängig von der Netzwerkqualität und die Userdaten verlassen das Gerät nicht, was die Privatsphäre des Anwenders schützt. Da LLMs aber einen großen Speicherplatzbedarf haben, werden oftmals eher kleinere LLMs eingesetzt, die eine geringere Antwortqualität haben. Die Performance hängt zudem vom Endgerät ab.
Im Rahmen seiner Built-in-AI-Initiative [4] liefert Google KI-Modelle zu Testzwecken mit seinem Browser Google Chrome aus. Für die Installation werden Windows 10 oder 11, macOS ab Version 13 (Ventura), 6 GByte Video-RAM und mindestens 22 GByte freier Festplattenplatz auf dem Volume des Chrome-Profils vorausgesetzt, die heruntergeladenen KI-Modelle sind allerdings deutlich kleiner.
Nach dem initialen Download teilen sich sämtliche Webseiten den Zugriff auf diese Modelle über sechs Built-in-AI-APIs [5], die innerhalb der Web Machine Learning (WebML) Community Group [6] des W3C spezifiziert sind. Eine der APIs ist allgemein verwendbar, während der Rest aufgabenspezifisch ist:
Während die Prompt API und Writing Assistance APIs derzeit auf das LLM Gemini Nano 2 mit 3,25 Milliarden Parametern zurückgreifen, werden für die Translation und Language Detection API intern andere Modelle genutzt.
Das Chrome-Team stellt die APIs derzeit im Rahmen eines Origin Trial zur Verfügung. Dabei handelt es sich um eine Testphase für neue Webplattform-APIs. Entwickler müssen von Google ein Origin-Trial-Token beziehen [10] und mit ihrer Website ausliefern. Dann wird die Schnittstelle auf dieser Website aktiviert, auch wenn sie noch nicht allgemein verfügbar ist.
Auf diese Art können Interessierte die Translator API, Language Detector und Summarizer APIs bereits testen. Auch für die Prompt API gibt es eine Origin Trial, allerdings nur für Chrome-Erweiterungen.
Da sich die APIs noch alle im Spezifikationsprozess befinden und sich das KI-Feld stetig weiterbewegt, sind Änderungen an den Schnittstellen sehr wahrscheinlich. So soll etwa die Prompt API künftig multimodale Eingaben (neben Text auch Bilder oder Audiomitschnitte) verarbeiten können.
Mit dem Paket @types/dom-chromium-ai [11] stehen bereits TypeScript-Definitionen zur Verfügung, um die APIs bequem aus eigenem TypeScript-Code aufrufen zu können. Das Paket entspricht derzeit der in Chrome 128.0.6545.0 implementierten API. Änderungen werden mit neuen Chrome-Versionen nachgeliefert.
Das folgende Beispiel zeigt die Verwendung der Language Detector API in einer Webanwendung:
FreshRSS const languageDetector = await self.ai.languageDetector.create();
const review = "こんにちは！Hier esse ich einfach am liebsten Sushi."
+ "Immer super 美味しい！";
const result = await languageDetector.detect(review);
// result[0]: {confidence: 0.800081193447113,
detectedLanguage: 'de'}
// result[1]: {confidence: 0.0267348475754261,
detectedLanguage: 'ja'}Die Built-in-AI-APIs sind ein spannendes Experiment, das die Fähigkeiten generativer KI direkt auf das eigene Gerät bringt. Entwickler und Entwicklerinnen können im Rahmen des Early-Preview-Programms für Built-in AI [12] Feedback an das zuständige Chrome-Team richten.
Danke an Thomas Steiner für das Review dieses Blogposts.
URL dieses Artikels:
https://www.heise.de/-10256818
Links in diesem Artikel:
[1] https://www.heise.de/news/Statt-Cloud-Apples-LLM-angeblich-vollstaendig-on-device-9692827.html
[2] https://www.heise.de/news/Google-Gemini-zieht-in-Android-und-iOS-Geraete-ein-samt-Live-Funktion-9834081.html
[3] https://www.heise.de/news/Windows-Copilot-Runtime-Fundament-fuer-offene-KI-Entwicklung-mit-APIs-und-SLMs-9731468.html
[4] https://developer.chrome.com/docs/ai/built-in?hl=de
[5] https://developer.chrome.com/docs/ai/built-in-apis?hl=de
[6] https://webmachinelearning.github.io/incubations/
[7] https://github.com/webmachinelearning/prompt-api
[8] https://github.com/webmachinelearning/writing-assistance-apis
[9] https://github.com/webmachinelearning/translation-api
[10] https://developer.chrome.com/origintrials/
[11] https://www.npmjs.com/package/@types/dom-chromium-ai
[12] https://developer.chrome.com/docs/ai/built-in-apis?hl=de#participate_in_early_testing
[13] mailto:rme@ix.de
Copyright © 2025 Heise Medien
Der 2024 Web Almanac ist seit wenigen Tagen verfügbar
(Bild: HTTP Archive, Apache 2.0)
98 Prozent aller Requests nutzen HTTPS, 25 Prozent der Websites setzen keinerlei Caching ein: Nach einer Pause in 2023 meldet sich der Web Almanac zurück.
Der Web Almanac 2024 [1] ist da! Das kostenlose Jahrbuch bietet tiefgehende Einblicke in die aktuellen Entwicklungen des World Wide Web. Das in diverse Sprachen übersetzte Nachschlagewerk identifiziert Trends, aber auch Herausforderungen und richtet sich an alle, die das moderne Web verstehen und mitgestalten möchten.
78 führende Webexperten aus der ganzen Welt haben ehrenamtlich 21 Kapitel verfasst, die unterschiedliche Aspekte des Web beleuchten: Dazu gehören Markup [2], Performance [3], E-Commerce [4] oder Cookies [5]. Alle Kapitel haben ein Peer-Review durchlaufen und die Rohdaten sind jeweils am Ende eines Artikels verlinkt. Die Analysen basieren auf den umfangreichen Daten des HTTP Archive [6].
Das Jahrbuch erschien vergangenes Jahr nicht, da sich der Projektleiter in Elternzeit befand und keine halbherzige Durchführung wollte. Verglichen zur Ausgabe von 2022 [7] hat sich das Rohdatenmaterial verdoppelt: Über 17 Millionen Websites wurden analysiert und über 83 TByte Daten verarbeitet. Das Jahrbuch wurde auf Basis der Daten des Juli-Crawls geschrieben.
Auch die diesjährige Ausgabe fördert wieder viele interessante, aber auch einige kuriose Erkenntnisse zutage:
h1-Element (bei 6 Prozent davon ist es leer, Quelle [11])divs (Quelle [14])Um die Veröffentlichung des Web Almanac 2024 zu feiern, laden die Autoren zu einem Online-Event ein, das am 10. Dezember 2024 um 19 Uhr stattfindet. Interessierte können sich unter folgendem Link zuschalten: The Web Almanac Live Stream (YouTube) [17].
URL dieses Artikels:
https://www.heise.de/-10186758
Links in diesem Artikel:
[1] https://almanac.httparchive.org/en/2024/
[2] https://almanac.httparchive.org/en/2024/markup
[3] https://almanac.httparchive.org/en/2024/performance
[4] https://almanac.httparchive.org/en/2024/ecommerce
[5] https://almanac.httparchive.org/en/2024/cookies
[6] https://httparchive.org/
[7] https://www.heise.de/blog/HTTP-Archive-legt-Web-Jahrbuch-2022-vor-mit-einigen-kuriosen-Erkenntnissen-7286733.html
[8] https://almanac.httparchive.org/en/2024/security#fig-1
[9] https://almanac.httparchive.org/en/2024/third-parties#prevalence
[10] https://almanac.httparchive.org/en/2024/third-parties#fig-6
[11] https://almanac.httparchive.org/en/2024/seo#header-elements
[12] https://almanac.httparchive.org/en/2024/cdn#fig-3
[13] https://almanac.httparchive.org/en/2024/cookies#fig-2
[14] https://almanac.httparchive.org/en/2024/markup#fig-13
[15] https://almanac.httparchive.org/en/2024/sustainability#fig-28
[16] https://almanac.httparchive.org/en/2024/sustainability#how-many-of-the-sites-listed-in-the-http-archive-run-on-green-hosting
[17] https://www.youtube.com/live/cdYR0ZmplIM
[18] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Andrey Suslov/Shutterstock.com)
Das Web ist zur Heimat vieler Anwendungen geworden, doch es bleibt eine Lücke zwischen Web-Apps und nativen Anwendungen. Können IWAs diese Lücke schließen?
Das Web ist in den vergangenen Jahren deutlich leistungsfähiger geworden: Nicht zuletzt hat das Anwendungsmodell der Progressive Web Apps [1] (PWA) sowie die Chromium-Initiative Project Fugu [2] dazu beigetragen, dass zunehmend viele Anwendungen direkt für das Web verfasst und im Browser lauffähig gemacht werden können, wie etwa Photoshop oder Visual Studio Code.
Aufgrund der Sicherheitsarchitektur des Web wird die Web-App-Gap, also die Lücke zwischen den Möglichkeiten plattformspezifischer Anwendungen und Web-Apps aber nie ganz geschlossen werden können.
Eine Schnittstelle, die direkt im Web nicht verfügbar gemacht werden kann, ist die Direct Sockets API [3], die Entwicklern die Möglichkeit eröffnen sollte, beliebige Server-Ports anzusprechen – über HTTPS, WebSockets und WebRTC hinaus.
Da diese die Same-Origin-Policy (SOP) des Web umgehen würde, und damit eine zentrale Sicherheitsbarriere im Web, meldete die Technical Architecture Group (TAG) des W3C deutliche Bedenken [4] an. Dieses gewählte Gremium innerhalb des W3C soll sicherstellen, dass sich neue Schnittstellen sinnvoll in das World Wide Web einfügen.
Gleichzeitig wünschen sich Softwareentwickler jedoch, diese Fähigkeiten nutzen zu können. Manche komplett grundlegenden Schnittstellen sind im Web oder zumindest nicht in allen Browsern verfügbar.
Die TAG kündigte im September 2023 auf der diesjährigen W3C-Jahreskonferenz TPAC in Sevilla daher die Gründung einer Taskforce an [5], um auch solche Schnittstellen ins Web bringen zu können.
Untersucht werden soll dabei ein möglicher "powerful context", bei dem der Anwender in die Installation einer Anwendung etwa explizit einwilligen könnte, um weitere Fähigkeiten wie den Zugriff auf Sockets freizuschalten.
Einen möglichen Vorschlag für einen solchen leistungsfähigen Kontext lieferte Google in der Vergangenheit bereits: die sogenannten Isolated Web Apps [6] (IWA). Auch bei diesem Anwendungsmodell handelt es sich um Webanwendungen, die dieses Mal aber in Form eines signierten Bündels vertrieben werden, über die klassischen Vertriebswege wie App-Stores, Installationspakete oder Enterprise-Deployments. Auch ein Sideloading durch die direkte Installation des Bundles wäre möglich.
Durch diesen zusätzlichen Vertrauensanker erhalten die Webanwendungen im Gegenzug dann Zugriff auf einen größeren Umfang von Schnittstellen. Ausgeführt würden diese trotzdem durch einen Browser.
Durch die Signatur werden Man-in-the-Middle-Angriffe oder die Manipulation des Quellcodes auf dem Anwendungsserver deutlich erschwert. Aufgrund solcher Bedenken [7] wird etwa der Messenger Signal nur als Electron-App, nicht aber als Progressive Web App herausgegeben.
Alle Folgeversionen müssen mit demselben Schlüssel signiert werden. Um Downgrading-Angriffe zu vermeiden, dürfen Updates ausschließlich auf eine höhere Versionsnummer vorgenommen werden. Das Laden von Quellcode außerhalb des Anwendungskontextes wird unterbunden, daher rührt auch der Name Isolated Web App. Hierfür würde ein eigenes URI-Schema [8] eingeführt: isolated-app://signed-web-bundle-id/path/foo.js?query#fragment
Die signed-web-bundle-id entspricht dabei dem Base32-kodierten öffentlichen Schlüssel.
Im Falle der IWAs werden Anwendungen über die klassischen, dem Anwender vertrauten Vertriebswege ausgeliefert. Anwendungsentwickler können ihr bestehendes Webwissen mitnehmen, aber dank des zusätzlichen Vertrauensankers auf noch leistungsfähigere Schnittstellen zugreifen. Diese würden auch weiterhin durch das W3C offen standardisiert.
Die Anwendungen basieren weiterhin auf Webtechnologien und könnten auch Code etwa mit einer PWA teilen. Und das alles ohne die Zusatzlast klassischer Wrapper-Ansätze wie Electron, Tauri, Cordova oder Capacitor.
Die Web Smart Card API Demo [9] des Chrome-Teams soll das IWA-Anwendungsmodell demonstrieren, indem die verpackte Webanwendung Zugriff auf Smartcards bekommt, um Personen zu identifizieren. Allerdings setzt dies ein ChromeOS-Gerät und die Aktivierung mehrerer Feature-Flags voraus. Unterstützung für die Web Smart Card API soll im Laufe des Jahres 2024 in Chromium für Windows, macOS und Linux hinzugefügt werden.
Zusammengefasst könnten Isolated Web Apps die Web-App-Gap tatsächlich erneut deutlich reduzieren und das Cross-Plattform-Feld aufmischen. Allerdings steht die gesamte Anstrengung noch komplett am Anfang. Die im September ausgerufene Taskforce wurde bislang noch nicht eingerichtet. Und auch ein Commitment von Mozilla oder Apple gibt es derzeit noch nicht.
URL dieses Artikels:
https://www.heise.de/-9540145
Links in diesem Artikel:
[1] https://www.heise.de/ratgeber/Progressive-Web-Apps-Write-once-run-anywhere-4839505.html
[2] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html
[3] https://www.heise.de/blog/Direct-Sockets-API-Laufen-FTP-und-SSH-Clients-bald-direkt-im-Browser-7156224.html
[4] https://github.com/w3ctag/design-reviews/issues/548
[5] https://www.w3.org/events/meetings/6d209c82-549d-4506-bc36-764ac4326b14/
[6] https://chromestatus.com/feature/5146307550248960
[7] https://community.signalusers.org/t/google-to-retire-chrome-apps-what-will-be-with-signal-desktop/469/6
[8] https://github.com/WICG/isolated-web-apps/blob/main/Scheme.md
[9] https://github.com/GoogleChromeLabs/web-smartcard-demo
[10] mailto:rme@ix.de
Copyright © 2024 Heise Medien
Progressive Web Apps bleiben in der EU-Ausgabe von iOS nun doch erhalten.
(Bild: Apple)
Apple wird PWAs in der EU-Version von iOS doch nicht abschalten. Zuvor unterzeichneten fast 5.000 Personen und Organisationen einen offenen Brief an Tim Cook.
Mit iOS 17.4 sollte für Anwender innerhalb der Europäischen Union die Möglichkeit entfallen, Webanwendungen auf dem Home-Bildschirm des Gerätes zu installieren [1]. Damit hätten Entwickler von Webanwendungen Zugriff auf kritische Funktionen verloren, darunter die Möglichkeit, Web-Apps vollflächig anzuzeigen, Pushbenachrichtigungen an die Anwender zu senden oder Badges auf dem Homebildschirm-Icon darzustellen [2]. Eine ausführliche Übersicht bietet Thomas Steiners Artikel: So, what exactly did Apple break in the EU? [3]
Nun hat Apple eingelenkt und angekündigt, dass Homescreen-Web-Apps in der EU doch erhalten bleiben [4]. Entwickler können davon ausgehen, dass mit der finalen Ausgabe von iOS 17.4 die Möglichkeit, Webanwendungen auf dem Home-Bildschirm hinzuzufügen, wieder vorhanden sein wird. In den Beta-Versionen von iOS 17.4 wurde die Funktion für EU-Nutzer entfernt.
Begründet wurde die ursprüngliche Entscheidung durch die Änderungen im Rahmen des Digital Markets Act (DMA) der EU. Das Gesetz über digitale Märkte verpflichtet Apple zur Öffnung seines Betriebssystems iOS für alternative App-Stores und Browser-Engines. Bei iPadOS ändert sich zunächst nichts [5].
Apple argumentierte, dass es das Sicherheitsmodell von iOS derzeit nicht zulasse, die Installation von Webanwendungen durch fremde Browser-Engines zu ermöglichen und wollte die Funktion daher grundsätzlich abschalten.
Als Kompromiss bleiben installierbare Webanwendungen in iOS nun erhalten, setzen dann aber wie gehabt auf WebKit als Browser-Engine auf. Somit kann das bestehende Sicherheitsmodell von iOS weiterverwendet werden und Anwender können Web-Apps auch weiterhin installieren.
Der Umentscheidung vorausgegangen war die Veröffentlichung eines offenen Briefs der Open Web Advocacy [6] (OWA) an Apple-CEO Tim Cook, der Apple aufforderte, die Installation von Webanwendungen in iOS zu erhalten. Innerhalb weniger Tage haben fast 5.000 Webentwickler und Organisationen den offenen Brief unterzeichnet, darunter viele Community-Mitglieder, Mitarbeiter von Branchengrößen wie Google, Microsoft, Adobe oder des W3C sowie Mitglieder des Europäischen Parlaments.
URL dieses Artikels:
https://www.heise.de/-9641325
Links in diesem Artikel:
[1] https://www.heise.de/news/Apple-bestaetigt-Keine-Progressive-Web-Apps-mehr-fuer-iOS-in-der-EU-9630089.html
[2] https://www.heise.de/news/Web-Push-und-Badging-in-iOS-16-4-Beta-1-Mega-Update-fuer-Progressive-Web-Apps-7521127.html
[3] https://blog.tomayac.com/2024/02/so-what-exactly-did-apple-break-in-the-eu.md/
[4] https://developer.apple.com/support/dma-and-apps-in-the-eu/#:~:text=Why%20don%E2%80%99t%20users%20in%20the%20EU%20have%20access%20to%20Home%20Screen%20web%20apps
[5] https://www.heise.de/hintergrund/Digital-Markets-Act-Neue-Freiheiten-und-Herausforderungen-fuer-iOS-Entwickler-9637241.html
[6] https://letter.open-web-advocacy.org/
[7] mailto:rme@ix.de
Copyright © 2024 Heise Medien
Künstliche Intelligenz hat auch das World Wide Web erreicht.
(Bild: metamorworks/Shutterstock.com)
Braucht es für KI-Funktionen immer die Cloud? Nicht zwingend, denn KI-Modelle laufen auch direkt im Browser – gute Performance und viel Speicher vorausgesetzt.
Künstliche Intelligenz (KI) ist in aller Munde: Keine Woche vergeht ohne die Ankündigung eines neuen Produkts, Chatbots oder eines verbesserten KI-Modells. Zeitgleich hält generative KI in die großen Produktivitätsanwendungen Einzug: Adobe Photoshop erlaubt das Ersetzen von Objekten in einem Bild per einfacher Texteingabe [1] und in Office und Windows steht der Microsoft Copilot [2] dem Anwender zur Seite. Kein Wunder, dass auch viele Anwendungsentwickler derzeit beabsichtigen, generative KI in die eigene Anwendung zu bringen.
Bislang führt dieser Weg fast ausschließlich in die Cloud. Alle großen Cloudanbieter halten einfach verwendbare Schnittstellen bereit, um KI-Funktionen in die eigenen Anwendungen zu integrieren.
Doch das muss nicht zwingend so sein: Der KI-Trend hat auch das World Wide Web erreicht. Fast zeitgleich zum Hype wurde mit Chromium 113 (April 2023) die Schnittstelle WebGPU unter Windows und macOS verfügbar gemacht. Diese API gibt Webanwendungen einen Low-Level-Zugriff auf die Graphics Processing Unit (GPU) des Systems, die sich nicht nur für Grafikanwendungen, sondern auch für die erforderlichen Berechnungen im Bereich Machine Learning (ML) gut eignet. Darüber lassen sich ML-Modelle effizient im Browser ausführen.
Zwei Showcases von Machine Learning Compilation [3] machen von dieser Schnittstelle bereits Gebrauch:
Beide Showcases sind quelloffen, im Falle von WebLLM gibt es sogar das npm-Paket @mlc-ai/web-llm [6], das Entwickler in die eigene App integrieren können.
In beiden Fällen müssen die KI-Modelle zuerst auf das Endanwendergerät übertragen werden. Diese Modelle sind allerdings mehrere Gigabyte groß, sodass eine schnelle Internetverbindung ebemso erforderlich ist wie ausreichend viel Speicherplatz. Auch die Ausführung des Modells ist anspruchsvoll, setzt viel Arbeitsspeicher und Rechenleistung voraus.
Im Gegenzug sind die Modelle nach dem initialen Download auch offline oder bei unzuverlässiger Internetverbindung verfügbar. Die Daten verlassen das Gerät des Anwenders zudem nicht, sodass sich dieser Ansatz auch für kritische Daten eignet. Ferner fallen keine Kosten an, da die Modelle quelloffen sind. Allerdings sind kommerzielle Modelle wie OpenAI GPT-4 noch deutlich leistungsfähiger. Doch auch in diesem Bereich tut sich viel, und Open-Source-Modelle werden kontinuierlich besser – und kleiner.
Mit WebGPU ist das Ende der Fahnenstange zudem noch nicht erreicht: Die Web Neural Network API [7] (WebNN) befindet sich derzeit beim World Wide Web Consortium (W3C) in Spezifikation. Diese Schnittstelle wird die Ausführung von Machine-Learning-Modellen im Webbrowser noch einmal beschleunigen, indem sie Webanwendungen zusätzlich Zugriff auf die plattformspezifischen ML-Schnittstellen und somit auf die Neural Processing Unit (NPU) gewähren, sofern diese auf der Zielplattform verfügbar sind.
Schon heute lassen sich anspruchsvolle KI-Modelle direkt im Webbrowser verwenden. In Kombination mit den übrigen Schnittstellen aus dem Umfeld der Progressive Web Apps [8] lassen sich damit komplett offlinefähige KI-Webanwendungen bauen. Zweifelsohne steht diese Entwicklung aber noch ziemlich am Anfang: So befindet sich WebGPU in WebKit (Safari) und Gecko (Firefox) noch in Implementierung; auch in Chromium-basierten Browsern ist die Schnittstelle unter Android und Linux noch nicht verfügbar. WebNN ist noch in keinem Browser nutzbar.
KI in Webanwendungen dürfte aber zunehmend an Relevanz gewinnen: Zu viele Anwendungsfälle lassen sich mit klassischer regelbasierter Entwicklung nicht sinnvoll abdecken. Das Web geht dieser Entwicklung jedenfalls vorbereitet entgegen.
URL dieses Artikels:
https://www.heise.de/-7520733
Links in diesem Artikel:
[1] https://www.adobe.com/de/products/photoshop/generative-fill.html
[2] https://adoption.microsoft.com/de-de/copilot/
[3] https://mlc.ai/
[4] https://webllm.mlc.ai/
[5] https://websd.mlc.ai/
[6] https://www.npmjs.com/package/@mlc-ai/web-llm
[7] https://webmachinelearning.github.io/webnn-intro/
[8] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html
[9] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Andrey Suslov/Shutterstock.com)
Electron ist nicht nur sprichwörtlich das Schwergewicht in der Cross-Plattform-Entwicklung. Kleiner und sicherer will Tauri sein, das im Backend auf Rust setzt.
Viele Anwendungen wie Signal, Slack, WhatsApp, Discord oder Visual Studio Code nutzen unter der Haube Electron [1], ein Framework zur plattformübergreifenden Ausführung von Anwendungen. Die App selbst wird dabei mithilfe von Webtechnologien wie HTML, CSS, JavaScript und WebAssembly [2] implementiert. Electron verpackt die Anwendungen gemeinsam mit dem Webbrowser Chromium und der Runtime Node.js in ein plattformspezifisches Bündel. Über das sogenannte Backend in Node.js kann die Webanwendung sämtliche Schnittstellen des Betriebssystems aufrufen.
Entwickler sparen bei diesem Ansatz viel Zeit, Geld und Aufwand, da sie ihre Anwendung nur einmal mit Webtechnologien entwickeln müssen und auf einer Vielzahl von Plattformen vertreiben können, Webbrowser eingeschlossen.
Allerdings sind Electron-Anwendungen aufgrund der Bündelung gleich zweier Laufzeitumgebungen leider auch sehr groß: Schon eine einfache Hello-World-Anwendung wird in Electron verpackt rund 100 MByte groß.
Jede ausgeführte Instanz führt zu einem Mehrverbrauch an Arbeitsspeicher, und veraltete Node.js- und Chromium-Versionen innerhalb eines Anwendungsbündels können zu Sicherheitsproblemen führen. Entwickler müssen Updates nicht nur bei Aktualisierungen ihrer App vertreiben, sondern auch, wenn sich Electron aktualisiert hat.
(Bild: Tauri.app)
Hier kommt Tauri [4] ins Spiel: Der Electron-Herausforderer erlaubt ebenfalls das Verpacken von Webanwendungen in Form eines plattformspezifischen Bündels. Allerdings fügt Tauri keinen eigenen Webbrowser hinzu, sondern nutzt die Web-View des Betriebssystems, auf dem die Anwendung ausgeführt wird: WebView2 auf Windows, WebKit unter macOS und WebKitGTK auf Linux.
In Tauri 2.0, das sich derzeit noch in der Alpha-Phase befindet, sollen sich iOS und Android zur Liste der unterstützten Plattformen hinzugesellen. Diese Plattformen können mit Electron nicht adressiert werden. Tauri würde damit auch Wrapper für mobile Betriebssysteme wie Cordova oder Capacitor [5] ersetzen.
Im Backend greift Tauri nicht auf JavaScript zurück, sondern auf Rust. Insofern muss auch Node.js nicht mit der Anwendung verpackt werden. Eine Hello-World-Anwendung ist mit Tauri gerade einmal 600 KByte groß. Mithilfe von Sidecars können Anwendungen mit externen Binärdateien ausgeliefert werden, die nochmal in anderen Sprachen verfasst sind.
Und auch das Thema Security nimmt bei Tauri einen hohen Stellenwert [6] ein: So können die benötigten Programmierschnittstellen gezielt aktiviert werden. Nur dann wird der dafür erforderliche Code überhaupt in das Bündel aufgenommen. Tauri bringt auch viele erweiterte Funktionen wie einen Auto-Updater oder die Integration in das Benachrichtigungssystem der Plattform mit.
Der Nachteil von Tauri besteht allerdings gerade darin, dass die Webanwendung nun in verschiedenen Ausführungsumgebungen ausgeführt wird: Die Unterstützung bestimmter Webschnittstellen oder CSS-Features variiert zwischen unterschiedlichen Web-Engines, sodass die Anwendung auf allen Zielumgebungen getestet werden muss.
Während Electron von GitHub herausgegeben wird, ist Tauri ein Community-getriebenes Projekt. Finanziell unterstützt wird Tauri etwa von 1Password, deren Passwortmanager zumindest derzeit noch auf Electron basiert.
Auch wenn die erste Version von Tauri schon länger erschienen ist, bleibt es noch das "New Kid on the Block". Große Namen finden sich unter den Tauri-Verwendern [7] derzeit noch nicht. Nicht nur aufgrund der deutlich geringeren Bundle-Größe sollte das Framework jedoch in Betracht gezogen werden, vielleicht sogar noch vor dem Platzhirsch Electron. Eine neue Tauri-App lässt sich über den npm-Befehl npm create tauri-app , auf der Bash mit sh <(curl https://create.tauri.app/sh oder auf der Powershell mit irm https://create.tauri.app/ps | iex erstellen.
URL dieses Artikels:
https://www.heise.de/-9538237
Links in diesem Artikel:
[1] https://www.electronjs.org/
[2] https://www.heise.de/blog/WebAssembly-Das-Web-wird-nativ-er-4023451.html
[3] http://paint.js.org/
[4] https://tauri.app/%E2%80%8B
[5] https://www.heise.de/blog/Capacitor-oder-Cordova-Welche-Plattform-sollten-Entwickler-webbasierter-Mobilapps-waehlen-4690975.html
[6] https://tauri.app/v1/references/architecture/security%E2%80%8B
[7] https://github.com/tauri-apps/awesome-tauri#applications%E2%80%8B
[8] mailto:rme@ix.de
Copyright © 2023 Heise Medien
(Bild: Pixelvario/Shutterstock.com)
Um eine Webanwendung in Chromium-basierten Browsern installieren zu können, musste diese ursprünglich offlinefähig sein. Diese Bedingung ist entfallen.
Progressive Web Apps [1] sind Webanwendungen, die auf dem Gerät des Anwenders installiert werden können. Voraussetzung dafür war in Google Chrome und Microsoft Edge lange Zeit, dass die Anwendung offlinefähig sein muss. Für die User Experience ist eine Bedienbarkeit auch dann wünschenswert, wenn der Anwender offline ist – zumindest im Rahmen der Möglichkeiten. Wer also den zusätzlichen Aufwand auf sich nahm, dies umzusetzen, wurde mit der Installierbarkeit der Anwendung belohnt.
Zur Implementierung der Offlinefähigkeit bei Webanwendungen kommen Service Worker [3] zum Einsatz. Dabei handelt es sich um ein durch die Website registriertes Stück JavaScript, das als Proxy zwischen Webanwendung und Netzwerk agiert und Zugriff auf einen clientseitigen, programmierbaren Cache besitzt. Speichert man die erforderlichen Quelldateien der Anwendung im Cache zwischen und liefert sie im Offline-Fall von dort aus, lässt sich die Anwendung auch ohne Internetverbindung betreiben.
Findige Webentwickler haben um diese Anforderung jedoch herummanövriert: Manche setzten einen leeren Service Worker ein, um die Bedingung zu erfüllen. Google zog daraufhin nach und erforderte einen fetch-Ereignishandler, sodass der Service Worker zumindest theoretisch in der Lage war, die Website offline verfügbar zu machen. Also setzten Seiten einfach diesen Ereignis-Handler ein und leiteten sämtliche Anfragen gegen das Netzwerk um. Folglich war das Ziel wieder nicht erreicht, und aufseiten des Browsers führte die zusätzliche Prüfung zu einem erheblichen Mehraufwand.
Mit Chromium 109 (mobil) und 110 (Desktop) wurden daher im Januar 2023 neue Offline-Fallbackansichten für installierte Webanwendungen [4] implementiert: Die Offlineerfahrung wird automatisch generiert, indem das Icon der Anwendung und der Hinweis "You're offline" angezeigt wird.
Die Notwendigkeit eines Service Worker und damit der Offlinefähigkeit ist seitdem komplett entfallen. Damit nähern sich Chrome und Edge auch an Safari an: Denn die Installation von Websites ist auf dem iPhone seit den frühen Tagen möglich, ganz ohne Bedingungen. Im Fall von Chrome und Edge wird zunächst jedoch auch weiterhin ein Web Application Manifest gefordert sowie die Übertragung der Website über HTTPS (siehe Installationskriterien [5]).
Service Worker haben den Nachteil, dass sie in JavaScript geschrieben und erst hochgefahren werden müssen, um Websites auszuliefern oder Pushbenachrichtigungen entgegenzunehmen. Um dem entgegenzuwirken, wurde für die Beschleunigung von Netzwerkabfragen beim Service-Worker-Start Navigation Preloads [6] entwickelt, während es für Pushbenachrichtigungen einen alternativen Vorschlag gibt, Declarative Web Push [7]. Für Webentwickler ist das Verfassen von solchem Infrastrukturcode zudem recht ungewohnt.
Die Implementierung einer sinnvoll bedienbaren Offlinevariante bleibt jedoch ein zentraler Baustein einer guten User Experience. PWA-Entwickler sollten diese daher auch in Zukunft anbieten, um ihre Anwender glücklich zu machen.
URL dieses Artikels:
https://www.heise.de/-9356942
Links in diesem Artikel:
[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
[2] http://pwapraxis.liebel.io/
[3] https://www.heise.de/blog/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Workers-3740464.html
[4] https://developer.chrome.com/blog/default-offline/
[5] https://web.dev/articles/install-criteria
[6] https://web.dev/blog/navigation-preload
[7] https://github.com/w3c/push-api/issues/360
[8] mailto:rme@ix.de
Copyright © 2023 Heise Medien
Für Apple so wichtig, dass es sogar in den Top-Neuerungen von macOS Sonoma erscheint: Die Installation von Webanwendungen aus Safari heraus.
(Bild: Apple)
Was auf dem iPhone seit der ersten Version funktioniert, geht nun endlich auch mit Safari unter macOS: Webanwendungen lassen sich auf dem Gerät installieren.
Mit der Veröffentlichung von Safari 17 [1] und macOS Sonoma sind Progressive Web Apps [2] nun auch unter Verwendung des Apple-Browsers unter macOS installierbar. Dies war unter macOS mit Chromium-basierten Browsern wie Google Chrome und Microsoft Edge schon seit einigen Jahren [3] möglich, mit Safari auf dem iPhone bereits seit Januar 2008, als iPhone OS 1.1.3 veröffentlicht wurde.
Bei der Installation wird eine Verknüpfung zur Website auf dem Dock (auf Mobilgeräten auf dem Home-Bildschirm) hinterlegt. Webentwickler können das Icon und den Namen der Verknüpfung vordefinieren und dabei auch festlegen, dass die von der Verknüpfung geöffnete Website im Standalone-Modus ausgeführt wird, also in einem eigenständigen Fenster (auf Mobilgeräten vollflächig, also ohne Browser-Steuerelemente). Dies wird über das Web Application Manifest [4] definiert. Ist kein Manifest vorhanden, werden Titel und Icon aus anderen Quellen bezogen.
Die Installation erfolgt analog zu iOS und iPadOS aus dem Teilen-Menü heraus, das sich neben der Adresszeile befindet. Darin muss der Eintrag "Add to Dock" ausgewählt werden. Als Beispiel soll hier die Produktivitäts-PWA [5] paint.js.org [6] dienen.
Die Installation müssen Anwender in einem separaten Dialog bestätigen. Safari erlaubt dabei das Ändern der Bezeichnung. Wer davon Gebrauch macht, kann mehr als eine Instanz der Anwendung auf dem Gerät installieren – etwa, um eine Anwendung mit unterschiedlichen Benutzerprofilen zu verwenden, denn Cookies werden zwischen den Instanzen nicht geteilt. Dies ist bei Chrome oder Edge in dieser Form so nicht möglich.
Beim Zustimmen zur Aufforderung wird die Verknüpfung dem Dock hinzugefügt und dort zugleich angeheftet. Außerdem erscheint die Anwendung auch im Launchpad und ist im Applications-Ordner des Benutzerverzeichnisses zu finden. Von dort kann die Webanwendung auch wieder gelöscht werden [7]. Von der Verknüpfung aus gestartet, erscheint die Webanwendung dann wie plattformspezifische Apps in einem eigenen Fenster.
Damit sind Webanwendungen nun unter Safari auf sämtlichen Plattformen offline-fähig, installierbar und können Pushbenachrichtigungen entgegennehmen: Installierte Anwendungen können wie auch unter iOS und iPadOS Pushbenachrichtigungen empfangen und Badges auf dem Anwendungs-Icon anzeigen [8]. Als einziger der großen Browser unterstützt Firefox keine Installation von Webanwendungen auf dem Desktop.
Der nächste logische Schritt wäre nun die Bereitstellung der File System Access API [9] in Safari. Diese Webschnittstelle, die bereits seit 2019 mit Chromium-basierten Browsern ausgeliefert wird, erlaubt die Bearbeitung von Dateien aus dem lokalen Dateisystem. Über die Erweiterung File Handling API können sich installierte Webanwendungen sogar als Bearbeitungsprogramm für bestimmte Dateitypen hinterlegen. Dass das interessant sein könnte, merkten Apple-Vertreter auf der vergangenen Jahreskonferenz des W3C [10] bereits an.
URL dieses Artikels:
https://www.heise.de/-9356873
Links in diesem Artikel:
[1] https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=and%20error%20handling.-,Web%20apps%20on%20Mac,-Safari%2017.0%20for
[2] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html
[3] https://www.heise.de/blog/Chrome-76-PWA-Installation-wird-einfacher-4481046.html
[4] https://www.heise.de/blog/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html
[5] https://www.heise.de/blog/paint-js-org-MS-Paint-Remake-als-PWA-mit-Web-Components-und-modernen-Web-Capabilities-6058723.html
[6] http://paint.js.org/
[7] https://support.apple.com/en-us/104996
[8] https://www.heise.de/blog/Web-Push-und-Badging-in-iOS-16-4-Beta-1-Mega-Update-fuer-Progressive-Web-Apps-7518359.html
[9] https://www.heise.de/blog/Produktivitaets-PWAs-auf-Desktop-Niveau-dank-File-System-Access-und-File-Handling-API-4963752.html
[10] https://blog.tomayac.com/2023/09/25/w3c-tpac-2023-trip-report/#:~:text=Apple%20noted%20that%20a%20launch%20handling%20feature%20is%20something%20that%20they%20would%20probably%20need.
[11] mailto:rme@ix.de
Copyright © 2023 Heise Medien
(Bild: SWstock / Shutterstock.com)
Web-Platform-APIs erlauben Zugriff auf das lokale Dateisystem oder die Zwischenablage. Zur bequemen Nutzung der Schnittstellen in C# stehen NuGet-Pakete bereit.
Progressive Web Apps [1] (PWA) sind ein webbasiertes Anwendungsmodell. Einmal implementiert lassen sie sich überall dort ausführen, wo ein halbwegs moderner Webbrowser zur Verfügung steht – Offlinebetrieb sowie Icon auf dem Homescreen oder in der Taskleiste inklusive.
Dazu passend brachten Initiativen wie Project Fugu [2] in der Vergangenheit weitere Web-Plattform-Schnittstellen ins Web. Dazu zählen etwa die File System Access API zum Zugriff auf das lokale Dateisystem, die Async Clipboard API zum Verwenden der Zwischenablage oder die Web Share API zur Integration in die Funktionalität des Betriebssystems zum Teilen von Inhalten. Diese Schnittstellen stehen allen Webanwendungen zur Verfügung.
Andere APIs setzen voraus, dass die Webanwendung auf dem System des Users installiert ist. Das gilt beispielsweise für die Badging API, die eine kleine Plakette auf dem Symbol der PWA darstellt, oder die File Handling API, die eine PWA bei Installation als Bearbeitungsprogramm für bestimmte Dateierweiterungen registriert.
Auch Microsofts Single-Page-App-Framework Blazor WebAssembly [3] eignet sich zum Implementieren von PWAs. In der Projektvorlage für Blazor-WebAssembly-Projekte können Entwickler und Entwicklerinnen einfach ein Kontrollkästchen setzen, um die PWA-Unterstützung zu aktivieren.
Blazor WebAssembly wird gerne von .NET-Entwicklern gewählt, die ihre Webanwendung in C# schreiben möchten. Natürlich kommen die Web-Plattform-Schnittstellen sämtlichen Webentwicklerinnen zugute, auch Nutzern von Blazor WebAssembly. Da die APIs in der Regel aber JavaScript-basiert sind, braucht es zur einfachen Nutzung in der C#-Welt geeignete Wrapper.
Glücklicherweise stehen für viele interessante APIs bereits quelloffene Wrapper zur Verfügung, die sich via NuGet in das Blazor-WebAssembly-Projekt installieren lassen. Hinweise zum Verwenden der NuGet-Pakete und zum Browser-Support der Schnittstellen finden sich jeweils in Klammern verlinkt:
Nachstehend wird das NuGet-Paket Thinktecture.Blazor.Badging vorgestellt. Die Badging API eignet sich etwa für Todo-Listen-Apps oder E-Mail-Clients, die darüber die Liste zu erledigender Todos oder ungelesener E-Mails darstellen. Ein prominenter Verwender der API ist die Twitter-PWA.
Die API wird von Chromium-basierten Browsern seit Version 81 auf macOS und Windows unterstützt. In der aktuellen Beta-Version 1 von iOS und iPadOS 16.4 liefert auch Apple die Unterstützung für die Schnittstelle mit [16].
Zunächst muss das NuGet-Paket ins Blazor-WebAssembly-Projekt aufgenommen werden:
dotnet add package Thinktecture.Blazor.BadgingAls Nächstes muss der BadgingService bei der IServiceCollection registriert werden. Dies geschieht üblicherweise in der Datei Program.cs:
builder.Services.AddBadgingService();Nicht alle APIs werden auf jedem Browser und jedem Betriebssystem unterstützt. So zeigen App-Badges unter Android etwa die Anzahl der Notifications dieser App an, weswegen die Schnittstelle hier nicht anwendbar ist. Auch steht die Schnittstelle nur dann zur Verfügung, wenn die App installiert wurde.
Daher sollten Entwickler innen und Entwickler immer das Prinzip des Progressive Enhancement [17] nutzen: Nur wenn eine Schnittstelle verfügbar ist, sollte man sie auch nutzen. Andernfalls könnte es zur Laufzeit zu einem Fehler kommen.
Ist eine Schnittstelle nicht verfügbar, sollte die Funktion in der App versteckt oder ausgegraut werden. Manchmal stehen auch Fallback-Ansätze zur Verfügung, auf die Entwicklerinnen zurückgreifen können. Im Falle der Badging API könnte etwa der Fenstertitel angepasst werden, indem die Anzahl der Mitteilungen dem Anwendungstitel in Klammern vorangestellt wird: "(3) My Cool App".
Um eine Unterscheidung zu ermöglichen, bieten die Pakete in der Regel die Methode IsSupportedAsync() an, mit der Entwickler das Vorhandensein der API prüfen können:
var isSupported = await badgingService.IsSupportedAsync();
if (isSupported)
{
// enable badging feature
}
else
{
// use alternative implementation
}Steht die API zur Verfügung, lässt sich das Badge über die Methode SetAppBadgeAsync() setzen. Diese Methode nimmt eine Zahl entgegen, die auf dem Badge dargestellt werden sollen. Alternativ kann auch "null" übergeben werden, in diesem Fall wird eine generische Plakette dargestellt.
await badgingService.SetAppBadgeAsync(3);Und so erscheint dann das gewünschte Badge auf dem App-Icon:
Über die vergangenen Jahre ist das Web immer leistungsfähiger geworden: Microsoft hat dank der File System Access API seinen Codeeditor Visual Studio Code in den Browser bringen können [18] (vscode.dev [19]). Adobe nutzt die File System API in seiner Webversion von Photoshop [20]. Gleich mehrere APIs vereinigt der webbasierte Microsoft-Paint-Klon paint.js.org [21] (paint.js.org [22]) in sich.
Dank der Wrapper-Pakete können auch Blazor-WebAssembly-Anwendungen bequem auf die neuen, leistungsfähigen Web-Plattform-APIs zugreifen. Die Schnittstellen integrieren sich meistens nahtlos in die C#-Welt. Und damit können auch .NET-Entwickler komplexe Produktivitätsanwendungen direkt für den Browser schreiben.
URL dieses Artikels:
https://www.heise.de/-7520799
Links in diesem Artikel:
[1] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html
[2] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html
[3] https://www.heise.de/blog/Angular-oder-Blazor-Eine-Entscheidungshilfe-fuer-Webentwickler-6197138.html
[4] https://www.w3.org/TR/clipboard-apis/#async-clipboard-api
[5] https://www.nuget.org/packages/Thinktecture.Blazor.AsyncClipboard
[6] https://w3c.github.io/badging/
[7] https://www.nuget.org/packages/Thinktecture.Blazor.Badging
[8] https://fs.spec.whatwg.org/
[9] https://www.nuget.org/packages/KristofferStrube.Blazor.FileSystem
[10] https://wicg.github.io/file-system-access/
[11] https://www.nuget.org/packages/KristofferStrube.Blazor.FileSystemAccess
[12] https://github.com/WICG/file-handling/blob/main/explainer.md
[13] https://nuget.org/packages/Thinktecture.Blazor.FileHandling
[14] https://www.w3.org/TR/web-share/
[15] https://www.nuget.org/packages/Thinktecture.Blazor.WebShare
[16] https://www.heise.de/blog/Web-Push-und-Badging-in-iOS-16-4-Beta-1-Mega-Update-fuer-Progressive-Web-Apps-7518359.html
[17] https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement
[18] https://www.heise.de/news/Visual-Studio-Code-laeuft-ab-sofort-im-Browser-6224465.html
[19] https://vscode.dev
[20] https://www.heise.de/blog/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html
[21] https://www.heise.de/blog/paint-js-org-MS-Paint-Remake-als-PWA-mit-Web-Components-und-modernen-Web-Capabilities-6058723.html
[22] https://paint.js.org
[23] mailto:map@ix.de
Copyright © 2023 Heise Medien
(Bild: Apple)
Apple liefert in Safari für iOS und iPadOS 16.4 Beta 1 gleich mehrere Programmierschnittstellen aus, die Webanwendungen deutlich leistungsfähiger machen.
In einem Blogbeitrag hat das WebKit-Team bekannt gegeben, dass Webanwendungen mit der frisch veröffentlichten Beta 1 von iOS und iPadOS 16.4 endlich Push-Benachrichtigungen über das Web-Push-Verfahren empfangen können [1]. Damit folgt Apple seiner Ankündigung aus dem Sommer 2022 [2]. Das ist jedoch nicht die einzige interessante Programmierschnittstelle, auf die Webentwickler in der neuen Vorabversion von Safari Zugriff haben.
Voraussetzung für die folgenden Schnittstellen und Funktionen ist unter iOS und iPadOS, dass die Webanwendung zum Home-Bildschirm des Gerätes hinzugefügt wurde. Anwender können die Installation über das Teilen-Menü und die Auswahl des Menüeintrags Zum Home-Bildschirm hinzufügen veranlassen. Das Hinterlegen von Web-Clips auf dem Home-Bildschirm ist seit dem im Januar 2008 veröffentlichten iPhone OS 1.1.3 möglich. Apple nennt auf diese Art hinterlegte Webanwendungen Homescreen Web Apps, was synonym zu Progressive Web Apps [3] (PWA) zu verstehen ist. Vom Home-Bildschirm aus gestartet erscheinen sie wie plattformspezifische Apps ohne Browserwerkzeugleisten und inklusive Auftritt im App Switcher. Einmal implementiert laufen sie überall von Mobile bis Desktop dank der zugrundeliegenden W3C-Spezifikationen Service Worker [4] und Web Application Manifest [5].
Das Web-Push-Verfahren ist eine Kombination verschiedener Spezifikationen von W3C und IETF (Push API, Notifications API und HTTP Web Push), die es Entwicklern ermöglichen, Benachrichtigungen proaktiv an ihre Benutzer zu schicken [6]. Die Information, etwa eine Instant Message oder ein Preisalarm, wird auf dem Endgerät in Form eines Notification-Banners dargestellt. Das API-Tandem wird seit vielen Jahren von Microsoft Edge, Google Chrome und Mozilla Firefox unterstützt. Unter Safari für macOS ist die Web Push API seit Version 16 verfügbar, die im September 2022 veröffentlicht wurde. Mit iOS und iPadOS erhalten nun die letzten größeren Betriebssysteme die Unterstützung dafür. Der große Vorteil des Web-Push-Verfahrens ist, dass es nur einmal implementiert werden muss und danach plattformübergreifend verwendet werden kann. Unter iOS und iPadOS erscheinen die Benachrichtigungsbanner genau so, wie sie auch von anderen Apps bekannt sind, inklusive Übertragung auf die Apple Watch und Integration in die Fokus-App.
Weniger aufdringlich als Benachrichtigungsbanner sind Badges, kleine rote Plaketten, die auf dem Symbol einer Anwendung dargestellt werden. Die Badging API [7] erlaubt es Webanwendungen, ein Badge auf dem Symbol der Anwendung auf dem Home-Bildschirm, im Dock beziehungsweise der Taskleiste darzustellen. E-Mail-Programme oder To-do-Listen-Apps nutzen diese Möglichkeit, um die Anzahl ungelesener Nachrichten oder zu erledigender Aufgaben darzustellen. Die Schnittstelle wird seit vielen Jahren von Google Chrome und Microsoft Edge unter macOS und Windows unterstützt. Auch die Twitter-PWA greift auf diese Schnittstelle zurück, um die ungelesenen Mitteilungen und Direktnachrichten zu kommunizieren. Voraussetzung dafür ist unter iOS und iPadOS, dass der Benutzer zuvor dem Empfang von Pushbenachrichtigungen zugestimmt hat.
Ebenso unterstützt die neue Safari-Version die "id"-Eigenschaft des Web Application Manifest [8]. Diese erlaubt eine eindeutige Identifizierung einer auf dem Gerät installierten Webanwendung, um mehrere Installationen zu vermeiden und die Benachrichtigungseinstellungen über mehrere Geräte hinweg zu synchronisieren. Allerdings gibt Safari Usern die Möglichkeit in die Hand, den Anzeigenamen der Anwendung anzupassen. Wählt der Benutzer einen anderen Namen, werden doch wieder mehrfache Installationen einer App möglich, etwa um sie mit unterschiedlichen Profilen nutzen zu können.
Erstmals erhalten Browser von Drittanbietern die Möglichkeit, selbst Verknüpfungen für Webanwendungen auf dem Home-Bildschirm zu hinterlegen. Dies war zuvor ausschließlich Safari vorbehalten. Unter Android, macOS und Windows war es schon früher üblich, dass Fremdbrowser Webanwendungen installieren konnten. Allerdings müssen auch die Browser von Drittanbietern unter iOS und iPadOS zwingend die WebKit-Engine nutzen. An dieser Vorgabe ändert sich nichts.
Neben den oben genannten APIs sind in iOS und iPadOS 16.4 Beta 1 auch weitere Programmierschnittstellen zu finden: Etwa die Screen Wake Lock API [9], die den Bildschirm aktiviert lässt (etwa für Präsentationsprogramme) sowie die Screen Orientation API [10], die Informationen zur Ausrichtung des Bildschirms zugänglich macht. Für diese Schnittstellen ist allerdings keine vorherige Installation der App erforderlich.
Einmal mehr schließt sich die Lücke zwischen plattformspezifischen Apps und Webanwendungen. Mit der Verfügbarkeit von Push-Benachrichtigungen wird wohl eine der häufigsten Anfragen von Webentwicklern über die letzten Jahre nun auf allen relevanten Plattformen abgehakt. Die Integration von Web Push und Badging API ist in der Betaversion von iOS und iPadOS richtig gut umgesetzt, von plattformspezifischen Apps sind die Benachrichtigungsmethoden nicht zu unterscheiden. Auch die Verfügbarkeit weiterer Programmierschnittstellen zeigt, dass es Apple ernst meint und das Web als Anwendungsplattform stetig besser wird.
URL dieses Artikels:
https://www.heise.de/-7518359
Links in diesem Artikel:
[1] https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/
[2] https://www.heise.de/blog/Web-Push-kommt-auf-iOS-und-iPadOS-Pushbenachrichtigungen-fuer-PWAs-jetzt-ueberall-7134230.html
[3] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html
[4] https://www.heise.de/blog/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Workers-3740464.html
[5] https://www.heise.de/blog/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html
[6] https://www.thinktecture.com/pwa/push-notifications-api/
[7] https://developer.chrome.com/articles/badging-api/
[8] https://www.w3.org/TR/appmanifest/#id-member
[9] https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API
[10] https://developer.mozilla.org/en-US/docs/Web/API/Screen_Orientation_API
[11] mailto:rme@ix.de
Copyright © 2023 Heise Medien
Über 8 Millionen Websites und 43 TByte Daten durchsuchte das HTTP Archive für den 2022 Web Almanac
(Bild: HTTP Archive, Apache 2.0)
Die größte Website ist 678 MByte "schwer" und ein Prozent nutzt noch immer das Marquee-Tag: Diese und weitere Einblicke fördert der 2022 Web Almanac zutage.
Der 2022 Web Almanac [1] ist seit wenigen Tagen verfügbar, das kostenfreie Jahrbuch des HTTP Archive [2]. Das HTTP Archive ist Teil des Internet Archive [3], das vor allem durch die Wayback Machine bekannt ist. Es erfasst, wie Webinhalte verbreitet werden: Verwendete Technologien, Leistungs- und Nutzungsdaten. Dazu durchsucht das HTTP Archive monatlich knapp 8,4 Millionen Websites mithilfe der Tools WebPageTest und Lighthouse.
Für die diesjährige Ausgabe des Jahrbuchs haben sich 108 Beitragende aus der Web-Community zusammengeschlossen. In über 20 Kapiteln beleuchten sie den Zustand des Web aus unterschiedlichsten Blickwinkeln. Der Almanach stützt sich dabei auf die Daten des Crawls aus dem Juli 2022, insgesamt wurden 43,88 TByte an Daten verarbeitet.
Das Web-Jahrbuch zeigt Trends auf, fördert aber auch kuriose Erkenntnisse zutage:
div-Element, das mit Abstand meistverwendete Element ist. Rund ein Prozent aller mobilen Websites verwenden sogar noch das veraltete marquee-Element aus den Zeiten des Internet Explorer 2.active heißt, die beliebteste ID ist content.Alle Kapitel haben ein Peer Review durchlaufen, die Rohdaten sind jeweils am Seitenende verlinkt. Den 2022 Web Almanac gibts kostenlos beim HTTP Archive [11]. Seit 2019 wird er jährlich herausgegeben.
URL dieses Artikels:
https://www.heise.de/-7286733
Links in diesem Artikel:
[1] https://almanac.httparchive.org/en/2022/
[2] https://httparchive.org/
[3] https://archive.org/
[4] https://almanac.httparchive.org/en/2022/markup
[5] https://almanac.httparchive.org/en/2022/page-weight
[6] https://almanac.httparchive.org/en/2022/cms
[7] https://almanac.httparchive.org/en/2022/css
[8] https://almanac.httparchive.org/en/2022/capabilities
[9] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html
[10] https://www.heise.de/blog/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Workers-3740464.html
[11] https://almanac.httparchive.org/en/2022/
[12] mailto:map@ix.de
Copyright © 2022 Heise Medien
(Bild: Andrey Suslov/Shutterstock.com)
Über die Direct Sockets API könnten Web-Apps in Zukunft UDP- und TCP-Ports öffnen und sich direkt mit Geräten oder Diensten verbinden, die kein HTTP sprechen.
Project Fugu, eine Initiative mehrerer Browserhersteller innerhalb des Chromium-Projekts, hat über die vergangenen Jahre viele Schnittstellen ins Web gebracht, die Webanwendungen Zugriff auf plattformspezifische Fähigkeiten gegeben haben und im Web ursprünglich nicht vorhanden waren. Der Fokus des Projektes, das auf diesem Blog schon mehrfach diskutiert wurde [1], lag zuletzt auf Produktivitätsanwendungen wie Bildbearbeitungsprogrammen oder Office-Apps.
Dank der Fugu-Schnittstellen konnten Ende 2021 etwa gleich zwei hochkarätige Anwendungen in einer Webfassung herausgegeben werden: Adobe stellte eine webbasierte Variante von Photoshop [2] zur Bearbeitung von Clouddokumenten bereit (Creative-Cloud-Abonnement erforderlich) und Microsoft packte seinen Codeeditor Visual Studio Code direkt ins Web [3].
Doch dabei soll es nicht bleiben. Im Rahmen der Isolated Web Apps [4], das sind Apps, die exklusiv über den Play Store oder per Enterprise Configuration im Unternehmenskontext zur Verfügung gestellt werden und mit Web-Technologien gebaut werden, kommt nun die nächste Kategorie von Anwendungen ins Visier: Apps, die über HTTP, WebSockets und WebRTC hinaus mit Netzwerkdiensten kommunizieren wollen, also etwa FTP-, SSH-, Remote-Desktop- oder E-Mail-Clients, die direkt via POP3 oder SMTP mit dem Server sprechen möchten. Ebenso denkbar sind Netzwerkspiele oder Steuersoftware für (Intranet-)Geräte, die über andere als die üblichen Ports und Protokolle kommunizieren.
Hierzu befindet sich gerade die Direct Sockets API in der frühen Phase der Spezifikation. Das ganze geschieht entsprechend der üblichen Prozesse innerhalb der Web Incubator Community Group [5] (WICG) des W3C. Dort können neue Schnittstellen erprobt und mit Entwicklern und anderen Browser-Herstellern diskutiert werden.
Die von dieser Gruppe herausgegebenen Dokumente sind keine offiziellen Webstandards, können aber später zur passenden Arbeitsgruppe übertragen und dort dann zur W3C-Recommendation werden – Voraussetzung dafür ist die Unterstützung der Schnittstelle durch eine zweite, unabhängige Browser-Engine. Es handelt sich dabei um den zweiten Anlauf zur Implementierung einer solchen Schnittstelle, nachdem die TCP and UDP Socket API [6] im Jahr 2015 nicht zu Ende geführt wurde.
Die Direct Sockets API wird im Explainer-Dokument bei der WICG [7] grob vorgestellt, ein inoffizieller Spezifikationsentwurf [8] wird aktuell erarbeitet. Die Schnittstelle soll es ermöglichen, Client-Ports zu anderen Servern zu öffnen; Server-Ports sind dabei aktuell kein Teil der Spezifikation, der Browser wird also (noch) nicht selbst zum Server. Die Direct Sockets API würde dem globalen Navigator-Objekt zwei Methoden hinzufügen: openTCPSocket(), um ein neues TCP-Clientsocket zu öffnen, und openUDPSocket() zum Öffnen eines UDP-Clientsockets. Zum Aufbau einer SMTP-Verbindung mit einem Mailserver könnte eine Webanwendung etwa folgenden Code nutzen:
if ('openTCPSocket' in navigator) {
const tcpSocket = await navigator.openTCPSocket({
remoteAddress: 'mail.gmx.net',
remotePort: 587,
});
// read/write on socket
}Die jeweiligen Methoden geben dann ein Promise zurück, das mit einem TCP- oder UDP-Socket-Objekt resolved. Kann das Socket nicht geöffnet werden, wird das Promise rejected. Auf dem Socket-Objekt befinden sich die Eigenschaften readable und writable, zwei Streams zum Lesen bzw. Schreiben von Daten. Die Methode close() auf dem Socketobjekt schließt das geöffnete Socket wieder.
Die Schnittstelle befindet sich aktuell in einer frühen Phase der Entwicklung. In Chromium-basierten Browsern muss unter about://flags die Origin der Web-App eingetragen werden, um die Direct Sockets API für diese zu aktivieren. Das funktioniert schon jetzt mindestens unter Linux. Aktuell wird in diesem Fall ein dauerhafter Warnhinweis angezeigt.
Mozilla lehnt die Implementierung der Schnittstelle ab [9], von Apple gibt es kein offizielles Statement. Die Direct Sockets API würde einer weiteren Klasse von Anwendungen den Weg ins Web ebnen und wäre für alle interessant, die eine plattformübergreifende, direkt im Browser lauffähige Software schreiben wollen, um mit Diensten oder Geräten zu sprechen, die kein HTTP, WebSockets oder WebRTC implementieren. Der weitere Verlauf der Entwicklung bleibt also spannend, bei neuen Ereignissen informieren wir wieder hier auf dem ÜberKreuz-Blog.
[Update 7.7. 14:00]: Die Direct Sockets API wird nicht, wie zuvor berichtet, generell verfügbar gemacht, sondern nur für Isolated Web Apps. Die Schnittstelle lässt sich mindestens unter Linux schon ausprobieren
URL dieses Artikels:https://www.heise.de/-7156224
Links in diesem Artikel:[1] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html[2] https://www.heise.de/blog/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html[3] https://www.vscode.dev[4] https://github.com/reillyeon/isolated-web-apps/blob/main/README.md[5] https://wicg.io/[6] https://www.w3.org/TR/tcp-udp-sockets/[7] https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md[8] https://wicg.github.io/direct-sockets/[9] https://github.com/mozilla/standards-positions/issues/431[10] mailto:rme@ix.de
Copyright © 2022 Heise Medien
(Bild: akedesign/Shutterstock.com)
Das W3C, bislang von mehreren Universitäten betrieben, wird eine eigenständige Organisation. W3C-CEO Dr. Jeff Jaffe spricht über Gründe und Auswirkungen.
Das World Wide Web Consortium [1] (W3C) wird zum 1. Januar 2023 eine eigenständige, gemeinnützige Non-Profit-Organisation [2]. Zuvor wurde das Konsortium, dem sich derzeit 463 Mitgliedsorganisationen aus aller Welt angeschlossen haben, von unterschiedlichen Universitäten und Forschungseinrichtungen als Gastgeber getragen ("Hosted Model"). Christian Liebel sprach mit Dr. Jeff Jaffe, CEO des W3C, über Gründe und Auswirkungen dieses Umbaus.
Christian Liebel: Das W3C setzte traditionell auf das Hosted Model, die Organisation wurde von mehreren Universitäten und Forschungseinrichtungen gemeinsam betrieben. Wie kam es dazu?
Dr. Jeff Jaffe: Nachdem das Web 1991 für die Öffentlichkeit freigegeben wurde, verbreitete sich die Webtechnologie sehr schnell. 1994 traten Vertreter des Massachusetts Institute of Technology (MIT) an Tim Berners-Lee heran, um das World Wide Web Consortium zu gründen, da sie Erfahrung mit Technologiekonsortien hatten (siehe die Pressemitteilung des MIT vom Oktober 1994 [3]). Tim erkannte jedoch von Anfang an, dass das W3C global aufgestellt sein müsse.
Innerhalb weniger Jahre schlossen das MIT, Keio in Japan und Inria (später übertragen auf das ERCIM, ein europäisches Technologiekonsortium) Vereinbarungen, um das W3C gemeinsam und auf Augenhöhe zu betreiben. Diese Hosting-Vereinbarungen bilden das Fundament, auf dem das W3C heute aufsetzt. Im Jahr 2013 kam die Beihang-Universität in China als weiterer Host hinzu. Diese Verwaltungspartnerschaft, das sogenannte Hosted Model, ermöglicht die Verwaltung der W3C-Mitglieder und die Beschäftigung von W3C-Mitarbeitern weltweit, die unter der Leitung der W3C-Geschäftsführung arbeiten.
Nach 28 Jahren soll das W3C nun zum 1. Januar 2023 eine eigenständige Legal Entity, also eine unabhängige juristische Person werden. Warum ist dieser Schritt notwendig?
Jaffe: Neben verschiedenen weiteren Gesichtspunkten gibt es zwei Hauptgründe, die die Einführung einer unabhängigen Legal Entity erforderlich machen:
Zum einen die Notwendigkeit, unsere Mitglieder in die formale Leitung einzubinden. Das soll über ein Board of Directors geschehen, um eine klarere Berichterstattung, Verantwortlichkeit, größere Diversität, bessere strategische Ausrichtung und globale Koordination zu erreichen. Von Beginn an war das W3C eine mitgliedergetriebene Organisation, bei der die teilnehmenden Mitglieder ihre Patente gebührenfrei zur Verfügung stellen und sich gemeinsam um den Erhalt und die Weiterentwicklung des Web kümmern. Mit den Vertretern unserer Hosts und unseren internen Führungsgruppen, von denen einige von W3C-Mitgliedern in beratender Funktion gewählt wurden, verfügen wir über erstaunliche Talente in der Leitung von technischen und Standardisierungsprozessen. Wir wollen und müssen noch weiter gehen, mit einem Gremium, das aus CEOs und CTOs von Unternehmen besteht – und aus Führern der Zivilgesellschaft.
Weiterhin ist der Bedarf nach neuen Webfunktionen über die Jahre gestiegen und die drängenden Probleme des Web sind stärker hervorgetreten. Dies hat sich in den letzten Jahren unter dem Druck, der von der Corona-Pandemie ausgeht, noch verschärft. Um diese Herausforderungen zu bewältigen und den Anforderungen im richtigen Tempo gerecht zu werden, muss das Web-Konsortium auf eine rasche Entwicklung und Kompetenzerwerb in neuen Bereichen setzen, seien es Medien, Web-Barrierefreiheit, Datenschutz, Sicherheit, Nachhaltigkeit, Fehlinformationen und so weiter. Die Fachkenntnisse, die wir von unseren Mitarbeitern benötigen, ändern sich ständig, und die Einstellungsprozesse in den akademischen Host-Einrichtungen bieten hierfür zu wenig Flexibilität.
Welche Auswirkungen wird die Umstrukturierung auf das Konsortium, die Entwickler und das World Wide Web haben?
Jaffe: Wir erwarten keine Veränderungen hinsichtlich unserer Vorgehensweisen im Umgang mit Entwicklern und der breiteren Web-Community. In der üblichen Interaktion wird es keine unmittelbaren Änderungen geben. Wie eben schon gesagt, gehen wir davon aus, dass uns die Umstrukturierung ermöglicht, das Tempo zur Bewältigung der wachsenden Anforderungen im Web zu erhöhen – sowohl für funktionale Verbesserungen, aber auch um gesellschaftliche Anliegen zu adressieren.
Innerhalb des W3C wird schon seit einiger Zeit über eine Zukunft des W3C ohne Direktor ("Director-Free") diskutiert, wenn der derzeitige Direktor Tim Berners-Lee zurücktritt. Adressiert die Umwandlung in eine Legal Entity diese Thematik?
Jaffe: Die Umwandlung in eine Legal Entity geht Hand in Hand mit den Director-Free-Diskussionen. Ein großer Teil des Erfolgs des W3C und des Web ist der Verdienst von Tim Berners-Lee. Das geht so weit, dass wir nie einen Aufsichtsrat hatten, sondern Tim es war, seine Vision und seine Kontakte, die uns mit den richtigen Stellen in Verbindung gebracht haben. Im Zuge der Director-Free-Diskussionen sollen die vielen Rollen des W3C-Direktors aufgeteilt werden, und manche dieser Rollen werden durch das Board of Directors unterstützt.
Zu guter Letzt: Welche Entwicklungen im World Wide Web finden Sie derzeit spannend?
Jaffe: Es freut mich, dass Sie das fragen, da es viele Möglichkeiten gibt, die Herausforderungen des bestehenden Web zu bewältigen und eine bessere Zukunft dafür zu schaffen. Wir nehmen das Web nicht als gegeben hin. Es kann mehr leisten. Es kann noch mehr sein. Wir haben das während der Pandemie gesehen, als die Welt plötzlich "virtuell" wurde und es die Webtechnologien waren, die die Durchführung vieler Aktivitäten weltweit ermöglichten.
Um den gesellschaftlichen Ansprüchen gerecht zu werden, wird es eine gemeinsame Anstrengung brauchen, um sicherzustellen, dass das Internet für Menschen auf der ganzen Welt zugänglicher und sicherer wird und als Motor für das Wachstum in wichtigen Bereichen von Wirtschaft und Gesellschaft dienen kann.
Wir müssen nicht nur die unzähligen Kerntechnologien des Web auf dem aktuellsten Stand halten, sondern auch unsere Bemühungen um die Technologien verstärken, die den Übergang zu mehr Virtualität ermöglichen, zum Beispiel Web Real Time Communications (WebRTC). Unsere 350 Community-Gruppen entwickeln unentwegt neue Technologien in verschienenen Bereichen wie Virtual Reality, dem Metaverse, der Interoperabilität von hybriden (nativen/webbasierten) Anwendungen sowie für ein dezentraleres Web. Wir arbeiten an Technologien, die auf die Bedürfnisse einer sich wandelnden Gesellschaft eingehen, einschließlich Fragen des Datenschutzes, der Werbung im Web, Smart Cities, sicherer Zahlungen und der Automatisierung.
In einer immer stärker global vernetzten Welt sorgen wir dafür, dass das Web für Zeichensätze und Verleger in der ganzen Welt funktioniert. Wir erwägen, am Thema "finanzielle Inklusion" zu arbeiten, um das Web für Menschen ohne Bankkonto besser nutzbar zu machen. Wir gehen auf branchenspezifische Bedürfnisse ein – wie die Tatsache zeigt, dass wir in diesem Jahr unseren dritten Emmy-Award in sieben Jahren gewonnen haben.
Schließlich unterstreichen die kulturellen, wirtschaftlichen und gesellschaftlichen Verschiebungen der letzten zwei Jahre die Wichtigkeit webbasierter Technologie und Dienste. Sie haben die Notwendigkeit allgemein akzeptierter technischer Spezifikationen, Leitlinien und Webstandards deutlich gemacht. Wir müssen anerkennen, dass das Web sowohl die schnelle Verbreitung wichtiger Informationen ermöglicht, aber leider zugleich auch Kanäle zur Verbreitung von Fehlinformationen schafft. Wir müssen verstehen, dass das Web einerseits der ultimative Beschleuniger von Wirtschaft und Handel ist, durch seine Allgegenwart aber zugleich auch missbräuchlich verwendet werden kann. All das zwingt uns zu anhaltender und erhöhter Wachsamkeit, um sicherzustellen, dass eine der größten Errungenschaften der Menschheit nicht denjenigen zum Opfer fällt, die seine enorme Macht für falsche Zwecke missbrauchen wollen.
Das Interview wurde schriftlich geführt und aus dem Englischen übersetzt.
URL dieses Artikels:https://www.heise.de/-7157916
Links in diesem Artikel:[1] https://www.w3.org/[2] https://www.heise.de/news/Webstandards-Das-W3C-baut-sich-um-7156498.html[3] https://news.mit.edu/1994/lcs-1019[4] mailto:rme@ix.de
Copyright © 2022 Heise Medien
(Bild: MichaelJayBerlin/Shutterstock.com)
Apple bringt Web Push auf Safari für macOS, iPadOS und iOS. Damit können Websites und PWAs jetzt auf allen relevanten Plattformen Pushnachrichten empfangen.
Progressive Web Apps [1] sind Anwendungen, die plattformübergreifend ausgeführt werden können: Einmal geschrieben laufen PWAs überall dort, wo ein halbwegs moderner Webbrowser zur Verfügung steht – unter anderem auf Android, iOS, Linux, macOS und Windows. Schon seit vielen Jahren können Webanwendungen auf dem Gerät des Anwenders installiert und offline ausgeführt werden. Mit den Apple-Mobilplattformen iOS und iPadOS können Websites und PWAs nun auf sämtlichen relevanten Mobil- und Desktoplattformen Pushnachrichten empfangen und anzeigen. Diese Funktion brauchen unter anderem Messenger, Nachrichten- oder Banking-Apps sowie soziale Netze.
Apple implementiert Web Push für Safari 16 auf macOS Ventura, das im Herbst 2022 erscheinen soll. Auf iOS und iPadOS folgt die Implementierung im Jahr 2023 [2]. Unter macOS können Anwender bereits seit langer Zeit mit Firefox, Edge oder Chrome Pushbenachrichtigungen erhalten. Aufgrund der fehlenden Browserenginewahl unter iOS und iPadOS war dies dort aber bislang nicht möglich. Apple wird in Safari dieselben Spezifikationen implementieren, die alle übrigen relevanten Browserhersteller schon seit einigen Jahren unterstützen:
Aufseiten des Frontends bedeutet dies, dass Websites und Webanwendungen einen Service Worker [9] implementieren müssen, um Pushbenachrichtigungen empfangen zu können. Für den Empfang von Pushnachrichten muss der Anwender erst einwilligen. Dazu wird eine Berechtigungsabfrage angezeigt, die nur im Rahmen einer Benutzerinteraktion wie einem Klick oder Tastendruck geöffnet werden darf. Wie bei allen anderen Apps auch können Anwender die Berechtigung in den Systemeinstellungen auch wieder zurückziehen. Das genaue Vorgehen ist im Video Meet Web Push for Safari [10] von der Entwicklerkonferenz WWDC 2022 zu sehen.
Der Apple Push Notification Service (APNs) wird wie die anderen Pushdienste Windows Push Notification Service, Firebase Cloud Messaging und Mozilla Push Service die Voluntary Application Server Identification [11] (VAPID, RFC 8292) unterstützen, mit der sich das Backend beim Pushdienst ausweisen kann. Auch das Backend muss lediglich ein Protokoll sprechen, um mit den verschiedenen Pushdiensten zu kommunizieren. Eine Registrierung beim Apple Developer Program ist nicht erforderlich. Wer Web Push bereits implementiert und sich an die Standards gehalten hat, muss vermutlich gar nichts ändern: Sobald Safari die Schnittstellen generell verfügbar macht, sollte es auch dort einfach funktionieren.
Weitere Details sind in der Apple Developer Documentation [12] nachzulesen. Mit der Verfügbarkeit von Pushbenachrichtigungen schließt sich für PWAs unter iOS und iPadOS nun endlich der Kreis: Schon 2018 [13] implementierte Apple den Service Worker sowie das Web Application Manifest in WebKit. Diese Spezifikationen bilden die Grundlage für Offlinefähigkeit und Installierbarkeit von Webanwendungen. Die Push API wird seit Chrome 42 (2015), Firefox 44 (2016) und Edge 17 (2018) unterstützt. Safari unterstützt unter macOS seit Version 7 ein proprietäres Pushprotokoll (Safari Push Notifications), das auch weiterhin funktionieren wird, aber eine Registrierung beim Apple Developer Program voraussetzt, sowie die Notifications API seit Version 6.
Mit Web Push und weiteren WebKit-Ankündigungen von der WWDC 2022 holt Apple im Web-Bereich zunehmend auf. Das PWA-Anwendungsmodell ist nun auch auf iOS und iPadOS abgerundet. Die Herausgeber Chromium-basierter Browser, die seit vielen Jahren Web Push unterstützen, sind jedoch längst in neue Gefilde aufgebrochen: Die im Rahmen von Project Fugu [14] entstandenen Webschnittstellen haben es etwa Adobe erlaubt, Photoshop in einer Webfassung herauszugeben [15]. Für Webentwickler bleibt zu hoffen, dass Apple auch hier nachlegen wird, um Webanwendungen auf dem Desktop mit weiteren spannenden Fähigkeiten auszustatten.
URL dieses Artikels:https://www.heise.de/-7134230
Links in diesem Artikel:[1] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[2] https://webkit.org/blog/12945/meet-web-push/[3] https://www.thinktecture.com/pwa/push-api/[4] https://www.w3.org/TR/push-api/[5] https://www.thinktecture.com/pwa/push-notifications-api/[6] https://notifications.spec.whatwg.org/[7] https://www.thinktecture.com/pwa/push-api/[8] https://datatracker.ietf.org/doc/html/rfc8030[9] https://www.heise.de/blog/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Workers-3740464.html[10] https://developer.apple.com/videos/play/wwdc2022/10098/[11] https://datatracker.ietf.org/doc/html/rfc8292[12] https://developer.apple.com/documentation/usernotifications/sending_web_push_notifications_in_safari_and_other_browsers[13] https://www.heise.de/blog/iOS-11-3-Willkommen-Progressive-Web-Apps-3960706.html[14] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html[15] https://www.heise.de/blog/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html[16] mailto:map@ix.de
Copyright © 2022 Heise Medien
Micro-Frontends sind Benutzeroberflächen, die sich aus kleinen isolierten Anwendungen zusammensetzen. Implementieren kann man sie zum Beispiel mit Web Components.
Es handelt sich um die Übertragung des Microservice-Konzepts aus dem Backendbereich auf das Frontend: Größere Anwendungen werden in kleinere, besser zu implementierende und zu wartende Unteranwendungen zerlegt. Entwickler können dabei die Sprachen und Frameworks wählen, die zu ihnen und dem konkreten Anwendungsfall passen. Web Components sind ein möglicher Ansatz zur Implementierung solcher Micro-Frontends.
Es gibt viele Möglichkeiten, Micro-Frontends zu bauen: Unter anderem können Inline Frames (IFrames) eingesetzt werden, in denen unterschiedliche Single-Page-Apps ausgeführt werden. Über jeweils zu implementierende Kommunikationsschichten können diese miteinander Daten austauschen. Die Module Federation in Webpack 5 erlaubt das Nachladen von fremdem Programmcode zur Laufzeit, um dasselbe Ziel zu erreichen – hier nicht in unterschiedlichen Frames, sondern in ein und demselben Browsingkontext. Ganz ähnlich verhält es sich mit Web Components, mit denen sich dieser Artikel beschäftigt.
Web Components [1] sind das eingebaute Komponentenmodell des Web. Entwickler können dabei eigene HTML-Elemente definieren und deren Aussehen sowie Verhalten selbst steuern. Die Technologie ist noch verhältnismäßig neu, funktioniert aber in den vier Evergreen-Browsern Chrome, Edge, Firefox und Safari seit längerem.
Der Datenaustausch erfolgt über benutzerdefinierte DOM-Attribute bzw. -Eigenschaften sowie -Ereignisse, auf der Komponente können auch eigene JavaScript-Methoden definiert werden, das Theming der Komponenten ist dabei über CSS Custom Properties möglich.
Web Components lassen sich mit Plain JavaScript schreiben, es gibt jedoch auch Bibliotheken wie Lit, die das Verfassen solcher Elemente noch einmal deutlich vereinfachen. Weiterhin erlauben auch Frameworks wie Angular (Angular Elements) oder Stencil das Verfassen eigener Web Components. Entwickler können hier einfach einen passenden Unterbau aussuchen, die Komponenten lassen sich anschließend problemlos miteinander kombinieren.
Web Components werden zur Laufzeit durch den Verwender registriert, damit ist auch ein Nachladen beliebiger Komponenten während der Ausführung möglich. Es gilt jedoch zu bedenken , dass der hierfür erforderliche JavaScript-Code innerhalb des eigenen JS-Kontextes ausgeführt wird. Einmal geladen kann der fremde Code etwa den Local Storage oder auch Cookies auslesen, wenn sie für JavaScript sichtbar sind. Wenn dies vermieden werden soll, bieten sich die oben genannten IFrame-Ansätze an.
Vor wenigen Monaten habe ich hier auf dem ÜberKreuz-Blog meinen webbasierten Remake von Microsoft Paint [2] vorgestellt. Es handelt sich dabei um eine Progressive Web App, die komplett alleinstehend betrieben werden kann. Die Anwendung ist zugleich jedoch eine Web Component und kann somit auch in beliebige andere Anwendungen eingebettet werden. Die Paint-Web-Component steht unter dem Paket @christianliebel/paint [3] auf npmjs.org zur Verfügung.
Viele Softwarehersteller setzen Design Systems ein, die Steuerelemente in der eigenen Corporate Identity enthalten. Adobe hat sein Design System namens Spectrum mit Web Components realisiert und quelloffen zur Verfügung gestellt. Unter anderem kommen diese Komponenten beim jüngst eingeführten Photoshop Web [4] zum Einsatz. Zur einfachen Demonstration des Ansatzes wird der Titel des aktuell bearbeiteten Dokuments der Paint-App auf einen Spectrum-Button geschrieben:
<html>
<body>
<paint-app style="width: 600px; height: 480px;"></paint-app>
<sp-theme scale="large" color="dark"><sp-button></sp-button></sp-theme>
<script
src="https://unpkg.com/@christianliebel/paint/dist/elements/index.js"
type="module"></script>
<script
src="https://jspm.dev/@spectrum-web-components/bundle/elements.js"
type="module"></script>
<script>
const paintApp = document.querySelector('paint-app');
const button = document.querySelector('sp-button');
paintApp.addEventListener('titlechange',
evt => button.innerText = evt.detail.title);
</script>
Um zu wissen, welche benutzerdefinierten HTML-Elemente von Drittanbieterpaketen zur Verfügung gestellt werden, gibt es das sogenannte Custom Element Manifest. Es zählt alle Web Components mit den verfügbaren Attributen, Eigenschaften, Ereignissen und CSS-Variablen auf. Für manche Umgebungen gibt es auch Generatoren, um die Manifest-Datei automatisiert erstellen zu lassen.
{
"version": 2,
"tags": [
{
"name": "paint-app",
"description": "An open-source, Web Components-based remake" +
"of MS Paint using modern web capabilities.",
"properties": [],
"events": [
{
"name": "titlechange",
"description": "The titlechange event fires whenever" +
"the document's title changes, for example, " +
"when a document is saved with a new name," +
"or a document was opened from the file system.",
"type": "{ title: string }"
}
],
"slots": [],
"cssProperties": []
}
]
}
Bei Micro-Frontends ergibt sich das Problem, dass eigentlich unabhängige Anwendungen integriert werden müssen. Eventuell gibt es Versionsabhängigkeiten zwischen den Einzelanwendungen, die erfüllt werden müssen. Ist das nicht möglich, funktioniert auch die Gesamtanwendung nicht. Komponentenmarktplätze wie npmjs.org haben sich dieser Problematik durch das Konzept der semantischen Versionierung genähert. Hier ergibt sich durch die Versionsnummer, ob bei einem Update Breaking Changes zu erwarten sind. Ein weiterer Ansatz besteht darin, Schnittstellen dauerhaft abwärtskompatibel zu gestalten. Die Win32-API oder die Web-Plattform sind gute Beispiele hierfür, allerdings bedarf es hierfür passender organisatorischen Strukturen, um dieses Ziel einzuhalten.
Speziell auf Web Components bezogen lassen sich Custom Elements derzeit nur genau einmal registrieren. Mehrere Komponentenversionen nebeneinander ließen sich also nur durch versionierte Komponentennamen (z.B. <my-button-2>) realisieren – ein Antipattern. Die spätere Neuregistrierung einer Web Component, etwa um zur Laufzeit geänderte Versionsabhängigkeiten zu erfüllen, ist nicht möglich. Abhilfe soll hier die Scoped Custom Element Registry [5] schaffen, die bei der Web Platform Incubator Community Group (WICG) vorgeschlagen wurde. Damit ist eine Komponentenregistrierung in untergeordneten Anwendungsscopes möglich. Ein Polyfill ist verfügbar, implementiert ist das Konzept bislang aber in keinem Browser.
Aufgrund der vielen Schnittgrenzen kann der Micro-Frontend-Ansatz schließlich selbst zum Problem werden: Typische Anforderungen, die den Einsatz von Micro-Frontends bedingen, sind hochmodulare Umgebungen mit mehreren Zielanwendungen oder Apps, die von mehreren organisatorisch getrennten Teams mit unterschiedlichen Vorerfahrungen zeitgleich entwickelt werden sollen. Liegt das nicht vor, sind Entwickler mit einem durch passende Architekturmittel gut strukturierten Monolithen eventuell besser aufgehoben.
Wenn wirklich ein Micro-Frontend-Ansatz gebraucht wird, stellen Web Components eine gute Option zur Umsetzung dar. Da sie im selben JavaScript-Kontext ausgeführt werden, sollten nur eigene Komponenten verwendet werden oder nur solche, deren Hersteller vertraut wird. Dann können unterschiedliche Entwicklerteams gleichzeitig unter Zuhilfenahme unterschiedlichster Frameworks eine oder mehrere Anwendungen entwickeln.
URL dieses Artikels:https://www.heise.de/-6328145
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Single-Page-Applications-ohne-Framework-Web-Components-als-Ersatz-fuer-React-Co-4850959.html[2] https://www.heise.de/developer/artikel/paint-js-org-MS-Paint-Remake-als-PWA-mit-Web-Components-und-modernen-Web-Capabilities-6058723.html[3] https://www.npmjs.com/package/@christianliebel/paint[4] https://www.heise.de/developer/artikel/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html[5] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
Copyright © 2022 Heise Medien
Auch in diesem Jahr gibt das HTTP Archive sein kostenloses Jahrbuch, den Web Almanac heraus. 112 Autoren, Analysten und Reviewer aus der Community haben sich zusammengetan, um den Zustand des Web im Jahr 2021 zu analysieren. Entstanden ist ein Werk mit 24 Kapiteln, die das Web aus unterschiedlichsten Blickwinkeln beleuchten.
Das HTTP Archive ist eine Unterorganisation des Internet Archive, das unter anderem für seine Wayback Machine bekannt ist. Das HTTP Archive crawlt monatlich 8,2 Millionen Websites und führt dabei unterschiedliche Analysen durch. Dazu zählt etwa die Größe der übertragenen Dateien, eingesetzte Caching-Techniken oder verwendete Webschnittstellen. Insgesamt fallen 39,5 TByte Datenmaterial an.
Der Web Almanac, der dieses Jahr zum dritten Mal herausgegeben wird, basiert auf den Daten des Crawls im Juli 2021. Insgesamt 24 Kapitel widmen sich unterschiedlichsten Themenbereichen im Web, darunter CSS, Kompression oder Barrierefreiheit. In diesem Jahr feiert das Kapitel zu WebAssembly sein Debüt. Nur ein Ausschnitt einiger interessanter Erkenntnisse: 94,4 Prozent aller Websites laden mindestens eine Third-Party-Ressource. 43,02 Prozent aller Desktop-Websites verweisen auf eine Datenschutzerklärung. Die beliebteste HTML-Element-ID lautet "content".
Der Autor dieses Blogs hat das Kapitel über Capabilities verfasst: In diesem werden Websites auf die Verwendung moderner Webschnittstellen [1] geprüft. Die meistgenutzten APIs sind die Async Clipboard API und die Web Share API; rund 9 Prozent aller Websites setzen Code ein, der auf diese Schnittstellen zurückgreift. Im vergangenen Jahr hat sich die Nutzung der Async Clipboard API um Faktor 10 erhöht.
Das Jahrbuch ist kostenlos unter https://almanac.httparchive.org/en/2021/ [2] abrufbar. Viel Spaß beim Lesen!
URL dieses Artikels:https://www.heise.de/-6280705
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[2] https://almanac.httparchive.org/en/2021/
Copyright © 2021 Heise Medien
Wer webbasierte Anwendungen für Android und iOS schreibt, hat die Qual der Wahl: Mit Capacitor und Cordova gibt es zwei Ansätze, die zum selben Ziel führen. Zeit für einen Vergleich der beiden Cross-Plattform-Frameworks.
Das Framework Apache Cordova, auch unter dem Namen PhoneGap bekannt, bringt seit über einer Dekade zuverlässig Web-Apps auf Mobilgeräte. Mit Capacitor gibt es einen Herausforderer, hinter dem mit Ionic ein Unternehmenssponsor steht. ÜberKreuz stellt die beiden Plattformen vor und gibt eine Empfehlung ab, welcher Ansatz nach Meinung des Autors gegenwärtig zu bevorzugen wäre.
Cordova [1] ist ein Community-Projekt der Apache Software Foundation (ASF). Es handelt sich dabei um den technischen Kern des Frameworks PhoneGap, das Adobe im Jahr 2011 gekauft hatte. Während Adobe PhoneGap als kommerziellen Dienst mit einigen Mehrwertangeboten wie einem Cloud-basierten Build-System betrieb, wurde der Unterbau quelloffen verfügbar gemacht und an die ASF übergeben. Im August 2020 kündigte Adobe an, PhoneGap einzustellen und sich nicht mehr an der Weiterentwicklung von Cordova zu beteiligen. Damit liegt die Wartung der Software nun bei der Community.
Bei Cordova gibt es zwei wichtige Konzepte: Plattformen und Plug-ins. Die Plattform stellt den portablen, webbasierten Quelltext auf einem bestimmten nativen Betriebssystem zur Verfügung, zum Beispiel Android oder iOS. Es werden auch weitere Plattformen wie macOS, Windows oder Electron unterstützt. Die Plattform greift auf die vom Betriebssystem bereitgestellte Web-View zurück und bettet die Anwendung darin ein. Daneben gibt es Plug-ins, die der Webanwendung den Zugriff auf beliebige native Schnittstellen erlauben. Das Plug-in enthält dabei (je Zielplattform) nativen Quelltext und macht diesen in JavaScript verfügbar.
Die grundlegende Philosophie bei Cordova ist, dass das komplette native Plattformprojekt als Artefakt eines Build-Vorgangs entsteht; für Entwickler verhält es sich als Black Box. Sämtliche Modifikationen werden in einer XML-Konfigurationsdatei vorgenommen und die Plattformprojekte daraus generiert. Die nativen Quelltexte sollen weder im Repository eingecheckt noch in irgendeiner Form verändert werden, da die Anpassungen beim nächsten Build wieder hinfällig wären.
Daten der App-Analyse-Plattform appfigures zeigen [2], dass im November 2021 rund 18 Prozent der App-Store-Anwendungen und Google-Play-Anwendungen auf Cordova setzen (über alle Anwendungskategorien hinweg, einschließlich Spielen). Das macht die Plattform im App Store zum zweithäufigsten und im Play-Store zum dritthäufigsten eingesetzten Entwicklungs-SDK. Auf Cordova setzt etwa die Selbstachtungs-App Sanvello (4,8 Sterne bei 17.300 Bewertungen im App Store).
Capacitor [3] ist im Jahr 2019 erstmals erschienen. Hinter Capacitor steckt das Unternehmen Ionic, das auch ein gleichnamiges Cross-Plattform-Framework herausgibt und weitere Dienste rund um die plattformübergreifende Entwicklung anbietet. Bei Capacitor handelt es sich vergleichbar zu Cordova um die technische Basis, um Webanwendungen auf nativen Plattformen zur Verfügung stellen zu können. Das Framework Ionic stellt darüber hinaus Steuerelemente in den nativen Plattformstilen von Android und iOS bereit, damit diese Anwendungen so aussehen und sich so verhalten wie ihre nativen Gegenstücke. Weitere Dienste wie Cloud-Builds oder Single Sign-on lassen sich kostenpflichtig bei Ionic abonnieren.
Der zentrale Unterschied zwischen Cordova und Capacitor besteht in der Philosophie, wie die nativen Plattformprojekte betrachtet werden: Bei Capacitor werden diese nicht als Build-Artefakt angesehen, sondern einmal generiert, in die Codebasis eingecheckt und dann direkt modifiziert [4]. Damit haben Entwickler die volle Freiheit im Umgang mit dem nativen Projekt, müssen sich umgekehrt aber auch um dessen Wartung kümmern.
Plattformen und Plug-ins gibt es auch bei Capacitor: Als Ausgabeplattformen werden iOS, Android sowie Progressive Web-Apps unterstützt. Das Framework stellt für häufig verwendete native Schnittstellen eigene Plug-ins zur Verfügung und kümmert sich um deren Wartung. Außerdem ist Capacitor mit den meisten Cordova-Plug-ins kompatibel und kann somit auch auf diese zurückgreifen. Installierte Plug-ins findet Capacitor übrigens automatisch, wohingegen diese bei Cordova in der Konfiguration bekannt gemacht werden müssen.
Capacitor rangiert laut den Daten von appfigures aktuell auf Platz 20 (unter einem Prozent der Anwendungen) im App Store beziehungsweise Platz 12 (etwa 1 Prozent der Anwendungen) in Google Play unter den meistverwendeten Development-SDKs. Auf Capacitor setzt etwa die Fitness-App Sworkit (4,7 Sterne bei 27.000 Bewertungen im App Store).
Für welchen Ansatz sollten sich Entwickler entscheiden?
Cordova und Capacitor lösen zunächst einmal dasselbe Problem, nämlich die Ausführung einer Webanwendung auf einer nativen Plattform. Capacitor entstand dabei auf Basis der Erfahrungen des Ionic-Teams mit Cordova. Zugleich steht mit Ionic ein Unternehmenssponsor hinter Capacitor, der sein Geschäftsmodell darauf aufbaut. Weiterhin reagiert Capacitor durch die Bereitstellung einer PWA-Ausgabeplattform auf aktuelle Trends.
Das Cordova-Ökosystem scheint überdies in die Jahre gekommen. Einige von der Community bereitgestellte Plug-ins sind veraltet und werden nicht mehr gewartet. Auch JavaScript hat sich in der Zwischenzeit weiterentwickelt: Manche der Cordova-Plug-ins stellen globale Methoden bereit, die von Capacitor veröffentlichten Schnittstellen setzen hingegen auf ECMAScript-Module. Das bedeutet jedoch nicht, dass die Entwicklung von Cordova eingestellt ist, außerdem vereint Cordova derzeit noch den größeren Marktanteil auf sich.
Im täglichen Gebrauch fühlt sich der von Capacitor gewählte Ansatz, die nativen Plattformprojekte in das Repository einzuchecken, deutlich besser an. Manchmal braucht es bei Cordova-Projekten separate Build-Skripte, um String-Replacements an den Quelldateien der nativen Projekte durchzuführen. Umgekehrt bedeutet der Capacitor-Ansatz jedoch auch einen erhöhten Wartungsaufwand bei Plattformupdates.
Zusammengefasst dürfte Capacitor aktuell die naheliegendere Wahl für die meisten Entwicklerteams sein. Das Framework ist deutlich moderner und der Unternehmenssponsor dürfte die kontinuierliche Weiterentwicklung auf absehbare Zeit sichern.
URL dieses Artikels:https://www.heise.de/-4690975
Links in diesem Artikel:[1] https://cordova.apache.org/[2] https://appfigures.com/top-sdks/development/all%E2%80%8B[3] https://capacitorjs.com/[4] https://ionicframework.com/blog/announcing-capacitor-1-0/
Copyright © 2021 Heise Medien
Adobe stellt Photoshop und Illustrator als Webanwendungen zur Verfügung. Die plattformübergreifend ausführbaren Web-Apps haben aktuell noch den Status einer Betasoftware. Dabei soll es aber nicht bleiben.
Photoshop und Illustrator kommen ins Web. Das kündigte der Branchenführer Adobe am Dienstagabend auf seiner hauseigenen Konferenz Adobe MAX an [1]. Es ist das Ergebnis einer jahrelangen Kooperation mit Google [2]. Das Bildbearbeitungsprogramm Photoshop ist für Creative-Cloud-Abonnenten ab sofort verfügbar, die Vektorgrafiksoftware Illustrator durchläuft zunächst noch ein geschlossenes Beta-Programm. Interessierte können eine Einladung hierfür anfordern [3].
In Photoshop geht es im ersten Schritt darum, Photoshop-Cloud-Dokumente (*.psdc) aus der Creative Cloud anzuzeigen, zu kommentieren und geringfügige Bearbeitungen vornehmen zu können. Dazu müssen Anwender die Creative Cloud [4] öffnen, ein Cloud-Dokument auswählen und dann die Schaltfläche "Open in Photoshop on the web beta" auswählen. Unterstützt werden unter anderem das Schnellauswahltool, das Pinselwerkzeug, der Radierer oder das Füllen-Tool. Bei diesem Funktionsumfang soll es jedoch nicht bleiben, weitere Features seien geplant.
Im Gegensatz zum nativen Photoshop müssen nicht erst mehrere hundert Megabyte heruntergeladen werden, sondern nur rund 20 MByte. Die Quelldateien werden mithilfe eines Service Workers [5] offline zwischengespeichert, sodass beim erneuten Aufrufen nur noch rund 150 Kilobyte übertragen werden müssen.
Die Anwendungen setzen mit Lit entwickelte Web Components [6] für ihre Benutzeroberfläche ein: Adobe gibt mit Spectrum [7] ein eigenes, auf Web Components basierendes Design System heraus. Darüber hinaus setzt Adobe auf WebAssembly, einen Bytecode für das Web [8]. Im Gegensatz zu JavaScript muss WebAssembly nicht erst geparst und interpretiert werden, sondern lässt sich direkt auf der virtuellen Maschine des Browsers ausführen. Adobe nutzt diesen Ansatz, um in C++ geschriebenen Code ins Web zu bringen. Auch Project Fugu [9] ist an Bord: Mit der File System Access API [10] können Anwender weiterhin Bilder vom eigenen Computer öffnen und und direkt bearbeiten.
Mit Adobe Photoshop und Illustrator gesellen sich weitere Produktivitätsanwendungen zum ständig wachsenden Kreis der plattformübergreifend einsetzbaren Browser-Apps. Erst vor wenigen Tagen gab Microsoft seinen Code-Editor Visual Studio Code als Webanwendung [11] heraus.
URL dieses Artikels:https://www.heise.de/-6229321
Links in diesem Artikel:[1] https://blog.adobe.com/en/publish/2021/10/26/creative-cloud-canvas-spaces-ps-ai-in-browser[2] https://web.dev/ps-on-the-web/[3] https://pages.adobe.com/creativecloud/en/collaboration/private-beta[4] https://assets.adobe.com/[5] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[6] https://blog.adobe.com/en/publish/2021/10/26/creative-cloud-canvas-spaces-ps-ai-in-browser[7] https://spectrum.adobe.com/[8] https://www.heise.de/developer/artikel/WebAssembly-Das-Web-wird-nativ-er-4023451.html[9] https://www.heise.de/hintergrund/Project-Fugu-Brueckenschlag-zwischen-progressive-Web-und-nativen-Apps-4684369.html[10] https://www.heise.de/developer/artikel/Produktivitaets-PWAs-auf-Desktop-Niveau-dank-File-System-Access-und-File-Handling-API-4963752.html[11] https://www.heise.de/news/Visual-Studio-Code-laeuft-ab-sofort-im-Browser-6224465.html
Copyright © 2021 Heise Medien
Nullreferenzen sind die vermutlich häufigste Ursache für Laufzeitfehler in vielen Programmiersprachen. Neue JavaScript-Sprachfeatures sowie Compilerparameter in TypeScript helfen, den "Billion-Dollar Mistake" zu vermeiden.
JavaScript dürften diese Fehler aufgrund der fehlenden statischen Typisierung noch einmal deutlich häufiger auftreten. Zwei mit ECMAScript 2020 eingeführte Operatoren erleichtern den Umgang mit nullishen Werten. TypeScript bietet einen Compilerparameter an, um Nullreferenzausnahmen nach Möglichkeit zu vermeiden.
In vielen Programmiersprachen ist es möglich, einer Variable, die mit einem Objekttyp deklariert wurde, den Wert "null" zuzuweisen, etwa in C#:
Person person = null;
Dieses Vorgehen führt jedoch zu einem Problem, wenn Entwickler davon ausgehen, dass sich ein passendes Objekt in der Variable befindet und versuchen, Eigenschaften davon zu dereferenzieren. Dann kommt es während der Laufzeit zu einer Nullreferenzausnahme:
person.Name
// NullReferenceException!
Fehler im Zusammenhang mit Nullreferenzen dürften zu den häufigsten Programmierfehlern zur Laufzeit gehören. Tony Hoare, der Erfinder der Nullreferenz, entschuldigte sich 2009 öffentlich für seinen "Billion-Dollar Mistake", die Einführung der Null-Referenz in ALGOL W. In modernen Sprachen wie Swift oder Kotlin ist die oben gezeigte Zuweisung von "nil" bzw. "null" standardmäßig nicht erlaubt, sondern nur für optionale beziehungsweise nullable Typen:
let person: Person? = nil
Viele Sprachen haben seitdem nachgezogen: In C# und TypeScript können Entwickler per Opt-in ebenfalls auf eine striktere Null-Prüfung setzen und die Gefahr von Nullreferenzausnahmen zur Laufzeit deutlich reduzieren. Mit dem Sprachlevel ECMAScript 2020 wurden einige neue Operatoren in JavaScript eingeführt, um den Umgang mit nullishen Werten zu vereinfachen. Diese kommen auch TypeScript-Entwicklern zugute.
Zunächst ist festzuhalten, dass JavaScript zwei "nullishe" Werte besitzt, "null" selbst und "undefined". Während "null" laut Sprachstandard das absichtliche Fehlen eines Wertes repräsentiert, also tendenziell explizit gesetzt wird, handelt es sich "undefined" um den Wert, wenn einer Variable bisher kein Wert zugewiesen wurde, also auch implizit entstehen kann. In JavaScript ist das Abrufen nicht existierender Eigenschaften eines Objektes möglich, nicht jedoch das Abrufen von Eigenschaften auf "null" oder "undefined":
const foo = { bar: null };
foo.bar // null
foo.baz // undefined
foo.baz.qux // TypeError: Cannot read properties of
// undefined ≈ NullReferenceException
Der erste, schon immer mögliche Weg, in JavaScript und TypeScript mit solchen Werten umzugehen, ist der aus vielen Sprachen bekannte Ternärausdruck:
const name = person ? person.name : 'Keine Person gewählt';
Dabei ist jedoch Vorsicht geboten, denn die Bedingung vor dem Auswahloperator ? wird im Gegensatz zu den im Folgenden vorgestellten Operatoren als boolscher Wert interpretiert: In JavaScript werden nicht nur false, null oder undefined bei der Konvertierung nach Boolean zu false abgeleitet, sondern auch die Werte 0, NaN, oder der leere String. Daher kann die Bedingung auch in Fällen greifen, die vielleicht nicht beabsichtigt waren.
Mit dem Sprachlevel ECMAScript 2020 wurde das sogenannte Optional Chaining (Operator ?.) in JavaScript eingeführt. Dieses Konzept hat viele Namen: Es ist auch als Safe Navigation bekannt; der Operator wird gerne auch als ELVIS-Operator bezeichnet, das als Akronym für Evaluate Left Value If Set stehen soll, oder, um 90 Grad nach rechts gedreht, an Elvis Presleys Schmalztolle erinnert.
Ausdrücke werden von links nach rechts ausgewertet. Eine Dereferenzierung findet beim Optional Chaining jeweils nur dann statt, wenn die ausgewertete Eigenschaft nicht die Werte null oder undefined enthält. Andernfalls wird für den kompletten Ausdruck der Wert undefined zurückgegeben.
const foo = { bar: 3, baz: null };
foo?.bar // 3
foo?.baz // null
foo?.baz?.qux // undefined
Eine Nullreferenzausnahme tritt hier zur Laufzeit nun also nicht mehr auf, selbst wenn nicht existierende Eigenschaften (wie etwa "qux" von der Eigenschaft "baz") abgerufen werden. Weniger bekannt ist, dass das Optional Chaining auch bei Indexzugriffen und Methodenaufrufen funktioniert. Dabei muss den Klammern für die Parameterauflistung beziehungsweise dem Indexausdruck ein Punkt vorangestellt werden:
dialog.canClose?.()
person.awards?.[0]
Bei Verwendung des Nullish-Coalescing-Operators (??) wird der linke Ausdruck zurückgegeben, sofern er nicht null oder undefined ist, ansonsten der rechte Ausdruck. Diesen Operator gibt es schon seit längerem in C#. Genutzt wird er typischerweise, um Standard- oder Fallback-Werte zu definieren, sollte der gesuchte Wert nicht definiert sein:
const people = response.people ?? [];
Für diesen Operator gibt es auch eine passende Variante für Zuweisungen:
people ??= []
In allen gezeigten Fällen muss bedacht werden, dass es sich jeweils um implizite Verzweigungen handelt. Die zyklomatische Komplexität ist auf einem sehr kompakten Codeausschnitt folglich sehr hoch. Dafür lassen sich mithilfe von Optional Chaining und Nullish Coalescing auch kompliziertere Fälle in einer Zeile Code behandeln. Nachstehend wird der Fallback-Wert "Unbekannter Name" festgelegt, wenn entweder "person" oder "person.name" null oder undefined sind:
const name = person?.name ?? 'Unbekannter Name';
Während sich mithilfe der gezeigten Operatoren Fehler zur Laufzeit vermeiden lassen, bleibt zumindest in JavaScript das Problem, dass Entwicklern bekannt sein muss, welche Variable nullishe Werte enthalten kann. Hier eilt TypeScript zur Hilfe.
TypeScript bietet einen Compileroption namens strictNullChecks an, die das oben geschilderte Verhalten von Swift und Kotlin auch in TypeScript nachliefert. Der Wert undefined darf nur noch dann zugewiesen werden, wenn ein nullable Type verwendet wird:
const anna: Person = null; // Unzulässig mit strictNullChecks
const peter: Person | null = null; // Zulässig mit strictNullChecks
Bei Verwendung von nullable Typen müssen Entwickler erst prüfen, dass wirklich ein Objekt hinterlegt ist. Andernfalls sind Dereferenzierungen nicht erlaubt:
peter.name // Unzulässig mit strictNullChecksif (peter) {
peter.name // Zulässig mit strictNullChecks
}
Wenn Entwickler sich sicher sind, dass sich ein Wert in einer Variable mit nullable Typ befindet, gilt es zudem noch den Non-Null-Assertion-Operator – passenderweise ein Ausrufezeichen. Dann dürfen potenziell unsichere Zugriffe wieder durchgeführt werden:
peter!.name // Zulässig mit strictNullChecks
Da dieser Operator den Schutz jedoch wieder aushebelt, sollte nach Möglichkeit auf seinen Einsatz verzichtet werden. Vorsicht ist weiterhin geboten, da trotz strictNullChecks die Initialisierung einer Klasseneigenschaft nicht verpflichtend ist:
private anna: Person; // Zulässig mit strictNullChecks
Um auch aus dieser Fehlerquelle auszusteigen, kann die Compileroption strictPropertyInitialization aktiviert werden. Dann müssen alle Klasseneigenschaften, die nicht-nullable Typen aufweisen, immer zwingend mit einem Wert initialisiert werden. Es empfiehlt sich, diese Compileroption bei der Verwendung von strictNullChecks gleich mit zu aktivieren. Dann dürfte der Quelltext vor Nullreferenzausnahmen weitestgehend geschützt sein. Bei TypeScript gilt dies wohlgemerkt nur zur Compilezeit, denn während der Ausführung im Browser findet keine Typprüfung statt. Probleme kann es dann etwa geben, wenn der Server nicht mit der Antwort antwortet, die der TypeScript-Code erwartet.
Die spätere Migration einer Codebase auf strictNullChecks und strictPropertyInitialization zieht nicht selten einen hohen Aufwand nach sich und macht auch viele subtile Bugs sichtbar. Aus diesem Grund empfiehlt es sich, diese Compileroptionen bei neuen Projekten von vornherein anzuschalten oder eine anstehende Migration nicht lange aufzuschieben.
Auch wenn es viele Interpunktionszeichen in die Codebase einführt: Optional Chaining, Nullish Coalescing und Nullable Types verbessern die Robustheit von in JavaScript bzw. TypeScript geschriebenen Programmen erheblich, indem sie einen der häufigsten Laufzeitfehler zu vermeiden helfen. Für Anwendungen größeren Umfangs ist die Einführung einer strikteren Nullprüfung stark empfohlen. So schaltet auch das SPA-Framework Angular seit Version 12 für alle neuen Projekte automatisch strictNullChecks und strictPropertyInitialization ein.
URL dieses Artikels:https://www.heise.de/-6221457
Copyright © 2021 Heise Medien
