Der Informatikpionier Peter Naur formulierte 1985 in seinem Aufsatz „Programming as Theory Building“ die These, dass Programmieren im Kern bedeutet, eine Theorie zu entwickeln – als tiefes Verständnis eines Problems und als seine Lösung. Diese Perspektive erklärt, warum Änderungen an bestehenden Systemen so schwierig sind, wie Legacy-Software entsteht, und weshalb iterative Softwareentwicklung so wirkungsvoll sein kann.

In dieser Episode von software-architektur.tv diskutiert Eberhard Wolff Naurs Überlegungen und bezieht sie zu aktuellen Herausforderungen der Softwareentwicklung – etwa zur verbreiteten Vorstellung im Kontext generativer KI, Programmieren bestehe primär lediglich im Erzeugen von Code.

Livestream am 27. Februar

Die Ausstrahlung findet am Freitag, 27. Februar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.

(map)

Mit Deno 2.7 veröffentlicht das Team ein Update, das sowohl Web-Standards als auch die Node.js-Kompatibilität weiter voranbringt. Im Mittelpunkt stehen die Stabilisierung der Temporal API und eine erweiterte Kontrolle über Abhängigkeiten in package.json. Daneben liefert das Release offizielle Builds für Windows on ARM, zahlreiche Node.js-Fixes sowie ein Upgrade auf V8 14.5.

Temporal API jetzt ohne Flag nutzbar

Mit Deno 2.7 verlässt die Temporal-API den experimentellen Status. Das bisher notwendige Flag --unstable-temporal entfällt. Damit folgt Deno der Entwicklung im V8-Ökosystem: Seit Chrome 144 (Januar 2026) ist die Temporal API ebenfalls standardmäßig verfügbar, nun holt Deno im Zuge des Upgrades auf V8 14.5 auf.

Ein Beispiel aus dem Ankündigungsbeitrag soll die Neuerung verdeutlichen:

const today = Temporal.Now.plainDateISO();
const nextMonth = today.add({ months: 1 }); // immutable - today unchanged

const meeting = Temporal.ZonedDateTime.from(
  "2026-03-15T14:30[America/New_York]",
);
const inTokyo = meeting.withTimeZone("Asia/Tokyo"); // same instant

Die Temporal-API soll die bekannten Schwächen des Date-Objekts beheben und bietet klar definierte Typen für Zeitpunkte, Datumsangaben, Zeitspannen und Zeitzonen. Entwicklerinnen und Entwickler erhalten damit präzisere Werkzeuge für komplexe Datums- und Zeitberechnungen – etwa bei wiederkehrenden Terminen, internationalen Anwendungen oder der Verarbeitung von Zeitstempeln mit Zeitzonenbezug.

Für Deno-Projekte bedeutet die Stabilisierung vor allem Planungssicherheit: Anwendungen können die Temporal-API produktiv einsetzen, ohne mit API-Änderungen rechnen zu müssen. Gleichzeitig soll sich die Interoperabilität mit modernen Browser-Umgebungen verbessern.

Feingranulare Kontrolle mit package.json-Overrides

Ein zweites zentrales Feature ist die Unterstützung des overrides-Felds in der package.json. Deno baut damit seine Unterstützung für Node.js-Projekte weiter aus. Ziel bleibt laut Ankündigungsbeitrag, bestehende Node.js-Anwendungen mit möglichst wenigen Anpassungen unter Deno lauffähig zu machen.

Mit overrides lassen sich Versionen transitiver Abhängigkeiten gezielt überschreiben. Entwickler können so etwa eine verwundbare Unterabhängigkeit global auf eine sichere Version festnageln oder eine bestimmte Version erzwingen, wenn es Inkompatibilitäten gibt. Auch das vollständige Ersetzen einzelner Pakete innerhalb des Abhängigkeitsbaums ist möglich.

Gerade in größeren Projekten mit tief verschachtelten Dependency-Trees soll das die Kontrolle erheblich erhöhen. Sicherheits-Patches lassen sich schneller durchsetzen, ohne auf Upstream-Updates warten zu müssen. Für Teams mit strengen Compliance-Vorgaben ist das ein wichtiger Baustein.

Windows on ARM und mehr Node.js-Kompatibilität

Neben den beiden Kernneuerungen liefert Deno 2.7 erstmals offizielle Builds für Windows on ARM (aarch64-pc-windows-msvc). Auf Geräten wie dem Surface Pro X oder Snapdragon-basierten Notebooks läuft Deno damit nativ – ohne Emulationsschicht und die damit verbundenen Performance-Einbußen.

Auch bei der Node.js-Kompatibilität legt das Team deutlich nach. Zahlreiche Anpassungen in node:worker_threads, node:child_process, node:zlib oder node:sqlite schließen Lücken zum Node.js-Verhalten. Ergänzt wird das durch neue oder angepasste APIs wie navigator.platform, SHA3-Unterstützung in der Web Crypto API oder Brotli-Support in CompressionStream und DecompressionStream.

Nähere Informationen bietet der Blogbeitrag. Wer Deno bereits nutzt, aktualisiert wie gewohnt per deno upgrade. Erst Anfang Februar hatte Deno zudem seine Serverless-Plattform Deno Deploy allgemein verfügbar gemacht und damit das Ökosystem rund um die Runtime strategisch ausgebaut.

(mdo)

Googles Pläne, App-Installationen auf zertifizierten Android-Geräten mit einer zentralen Registrierung ihrer Entwickler zu verbinden, stehen weiter in der Kritik. In einem offenen Brief werfen Akteure und Unternehmen aus der Open-Source-Szene sowie aus der Zivilgesellschaft dem Unternehmen vor, das offene Ökosystem Androids zu gefährden. Sie fordern eine Abkehr von der Registrierungspflicht. Unterzeichnet wurde der Brief unter anderem vom Chaos Computer Club, der Free Software Foundation, dem Mailanbieter Tuta, den Machern des Vivaldi-Browsers und der GitHub-Alternative Codeberg.

Unter anderem wird im Brief kritisiert, dass sich Google mit einer solchen Entwicklerüberprüfung zum Torwächter fremder Distributionskanäle erheben würde. Wer seine Apps über eigene Websites, alternative App-Stores von Drittanbietern, Unternehmensvertriebssysteme oder ähnliches verbreite, müsse nämlich auch die Genehmigung von Google durch einen obligatorischen Verifizierungsprozess einholen. Das umfasse die Zustimmung zu den Geschäftsbedingungen, die Zahlung einer Gebühr und das Hochladen eines amtlichen Ausweises.

Ebenfalls kritisieren die Autoren des Briefs, dass künstliche Zugangshürden geschaffen würden, und befürchten Datenschutzrisiken durch eine zentrale Datenbank von Android-Entwicklern in der Hand des Unternehmens. Ferner könne es zu Wettbewerbsverzerrungen kommen, wenn Google über eine solche Registrierung Daten sammelt, wer welche Apps anbietet.

Kein Verbot von Sideloading

Google hatte vergangenen August zunächst bekannt gemacht, dass ab Herbst 2026 auf zertifizierten Android-Geräten nur noch Anwendungen installiert werden können, deren Herausgeber sich zuvor bei Google registriert und dann die jeweilige Anwendung signiert hat. Bislang galt eine solche Registrierungspflicht nur für Entwickler, die Apps über Googles Play Store anbieten.

Nach Protesten schien das Unternehmen zurückzurudern und betonte, man wolle Installationen aus alternativen App-Stores sowie – auch als Sideloading bezeichnete – Direkt-Installation von Anwendungsdateien damit nicht untersagen. Vielmehr gehe es darum, einen „neuen, fortschrittlichen Ablauf“ zu entwickeln, der es „erfahrenen Benutzern“ ermöglichen soll, „die Risiken der Installation nicht verifizierter Software zu akzeptieren“. Das solle die Sicherheit von Android verbessern.

Wie sieht der „fortschrittliche Ablauf“ aus?

Wie genau Google dann Hürden bei der Installation unverifizierter Apps setzt, ist noch nicht klar. F-Droid-Entwickler Marc Prud’hommeaux kritisierte, dass Google den „fortschrittlichen Ablauf“ bislang nicht öffentlich gemacht habe. Auch das Versprechen, frühzeitiges Feedback zum Design dieser Funktion zu sammeln, habe Google nicht eingehalten.

Codeanalysen deuten darauf hin, dass der Prozess einen Warndialog enthalten könnte sowie eine aktive Komponente, für die eine Internetverbindung erforderlich ist. Ist keine verfügbar, erhalten Nutzer eine Warnung, dass der Entwicklerstatus nicht überprüft werden kann.

Bis Nutzer zertifizierter Android-Versionen in Europa diese neuen Installationshürden zu Gesicht bekommen, dürfte es ohnehin noch dauern. Ab September 2026 soll die Installation anonymer Apps zunächst in Brasilien, Indonesien, Singapur und Thailand erschwert werden. Ab 2027 folgt dann schrittweise der Rest der Welt. Die Verifizierung für alle Entwickler soll bereits ab März 2026 verfügbar sein.

(axk)