Haben wir uns bei effizienter Softwareentwicklung verirrt?

• Beim Versuch, ein etwa 30 MB großes Word-Dokument im Browser zu bearbeiten, kam es zu Eingabeverzögerungen – ein spürbares Beispiel für die Performance-Kosten moderner Web-Apps
• Obwohl das Dokument größtenteils aus Text bestand und nur einige Bilder und Tabellen enthielt, ließ es sich in Google Docs bzw. Chrome nicht flüssig bearbeiten
• In LibreOffice, das statt des kostenpflichtigen Microsoft Office installiert wurde, lief dasselbe Dokument deutlich schneller – der Unterschied zwischen Web-Apps und nativen Apps wurde klar sichtbar
• Da moderne Webanwendungen immer mehr Arbeitsspeicher und CPU-Leistung verlangen, entsteht die Frage, ob leistungsfähigere Hardware mit ressourcenintensiven Web-Apps zusammenhängt
• Auch wenn sich PWAs und browserbasierte UIs weiter verbreiten, bleiben natives Rendering und effizientes Softwaredesign für die tatsächliche Nutzbarkeit weiterhin wichtig

---

Performance-Probleme von Web-Apps, sichtbar an einem 30-MB-Dokument

• Google Docs wurde zuerst gewählt, weil sich damit ein Google-Konto und automatische Cloud-Synchronisierung nutzen lassen
• Nach dem Hochladen des Dokuments in Google Docs dauerte es beim Tippen mehrere Sekunden, bis Zeichen auf dem Bildschirm erschienen
• Die Datei war etwa 30 MB groß und enthielt einige Bilder sowie einfache Tabellen, bestand aber größtenteils aus Text
• Der Autor kam zu dem Schluss, dass Chrome oder Google Docs dieses Dokument nicht richtig verarbeiten konnte
• Microsoft Office schied aus, weil es kostenpflichtig ist; im stattdessen installierten LibreOffice lief dasselbe Dokument sehr schnell

Die größere Frage nach Effizienz

• Der Fall regt dazu an, zu hinterfragen, ob moderne Tools, Frameworks und Sprachen Software in puncto Performance schwerfälliger machen
• Die Hardware-Spezifikationen seien gestiegen, um ressourcenintensive Webanwendungen zu bewältigen; gäbe es nur rein native Apps, könnten diese Anforderungen möglicherweise geringer sein
• Als Beispiel wird angeführt, dass Mobilgeräte inzwischen 16 GB RAM benötigen; kritisiert wird der zunehmende Ressourcenverbrauch von Software
• Das Web sollte nicht nur ein Wrapper für einfache UI-Rendering-Engines bleiben, sondern eine Effizienz auf dem Niveau von nativem Rendering erreichen
• Der Apollo-Computer von 1966 ermöglichte die Mondlandung mit 2 KB RAM, während es 2024 im Browser schon schwierig ist, mit einem rund 30 MB großen Dokument zu arbeiten – dieser Kontrast unterstreicht die Notwendigkeit von Optimierung

[GN⁺]

Meinungen auf Hacker News

• Selbst wenn man native Apps entwickeln möchte, fühlt es sich so an, als würden Apple und Microsoft einem ständig Steine in den Weg legen. Man muss Entwicklerkonten, Zertifikate zum Signieren von Binärdateien und sogar 30 % Umsatzprovision ohne besonderen Grund in Kauf nehmen; besonders bei Microsoft haben sich die APIs verwirrend verändert.
  Deshalb entscheidet man sich am Ende für das einfachere und günstigere Web

  • Unter macOS braucht man das Apple Developer Program nur, wenn man Binärdateien signieren oder über den Mac App Store vertreiben möchte. Auch bei Microsoft fallen Kosten nur an, wenn man im Microsoft Store veröffentlicht oder Visual Studio nutzt, während das Unternehmen eine bestimmte Größenordnung überschreitet.
    Nicht signierte Apps lassen sich unter Windows und macOS zwar ausführen, zeigen aber mehr Warnhinweise. Die 30-%-Provision gilt ebenfalls nur bei Nutzung des Mac App Store oder Microsoft Store; beim Microsoft Store scheint es keine Provision zu geben, wenn es kein Spiel ist und man ein eigenes Zahlungssystem verwendet.
  • Einer der Gründe, warum ich nach langer C/C++-Entwicklung zur JavaScript-Webentwicklung gewechselt bin, war genau das. Der Prozess, eine iPhone-App in den Apple App Store zu bringen, war die Hölle, während Web-Apps keine Lizenzen, Freigaben oder Installer brauchen.
  • Kurz gesagt: Bei Microsoft sind das Anlegen eines Entwicklerkontos, das Signieren von Binärdateien und eine Umsatzbeteiligung von 30 % nicht verpflichtend. Ich würde Microsofts APIs auch nicht als chaotisch bezeichnen; es gibt Optionen wie Win32, .NET und UWP, und sie funktionieren ziemlich gut und flexibel.
    Bei Apple weiß ich es nicht genau, aber Mac-Apps kann man wahrscheinlich auch ohne Entwicklerkonto erstellen; für das iPhone braucht man ein Entwicklerkonto. Der Preis, den ich früher gesehen habe, lag bei 99 $ pro Jahr, und wenn man ernsthaft Apps entwickeln will, ist das keine große Summe.
  • Wenn man Kartenzahlungen im Web direkt integriert, zahlt man an Stripe 2,9 % + 30 ¢. Erst bei 10 Dollar Umsatz sinkt die Transaktionsgebühr auf etwa 6 %, wodurch Untergrenzen beim Preis und Einschränkungen beim Abrechnungsmodell entstehen.
    Chargebacks und Rückerstattungen kosten ebenfalls Geld, und man muss Zeit in den Kundensupport stecken oder jemanden dafür einstellen. Bei einem Jahresumsatz von unter 1 Million Dollar beträgt Apples Gebühr 15 %, sodass Apple bei günstigen Apps oder Apps mit Mehrwert das bessere Geschäft sein kann als die eigene Zahlungsabwicklung.
  • Beim Erstellen nativer Apps für macOS, Windows und Linux musste ich so etwas nie tun; ich verwende einfach Qt.

• Ironisch ist, dass dieser Beitrag auf Medium erschienen ist, das für einen einzigen Artikel mit 265 Wörtern 10,88 MB ausliefert.

  • Aus Sicht von Medium ist die Werbung der eigentliche Inhalt. Der Artikel ist nur das Transportmittel, das den eigentlichen Inhalt, nämlich die Werbung, bis in den Browser bringt, und für die Auslieferung von Werbung ist viel Komplexität nötig.
  • In Firefox about:process zeigte sich, dass dieser Artikel selbst 10 Minuten nach dem Laden noch 239 MB Speicher und 0,06–0,2 % CPU nutzte; 45 % der CPU-Zeit scheinen von Google reCAPTCHA verbraucht zu werden.
    Ich wünschte, Organisationen wie Mozilla oder Google würden CPU-, Speicher- und Energieverbrauch pro Domain sammeln und Entwickler, die sich nicht um Performance kümmern, öffentlich bloßstellen.
  • Browser sind größer geworden als die meisten Betriebssysteme, und auch das Ökosystem fühlt sich geschlossen an. WASM hat noch viele Einschränkungen, und in der Webentwicklung bleiben praktisch nur JS/HTML/CSS als realistische Optionen.
    Das Web fühlt sich wieder an wie 2005. Nur dass die Pop-ups diesmal in die Seite eingebettet sind.
  • In solchen Fällen öffne ich im Gemini-Browser gemini://gemi.dev/bin/waffle.cgi und füge die URL ein. Wer das Gemini-Netzwerk nicht nutzt, kann in der URL medium.com durch scribe.rip ersetzen.
  • In einem Textmodus-Browser ist es in Ordnung.

• Ja, wir haben uns verirrt, und der Grund ist einfach: weil wir es konnten. Es war der Weg des geringsten Widerstands, also haben wir ihn gewählt.
  Software hat sich über Jahrzehnte auf Kosten des Hardwarefortschritts treiben lassen, besonders im Web und bei Desktop-Apps. Moores Gesetz war Segen und Fluch zugleich, und die Software, die wir heute nutzen, wurde von Leuten entwickelt, die ihr Handwerk auf dem Höhepunkt dieses Mitnahmeeffekts gelernt haben.

  • Was man mit Computern macht, bleibt von Jahr zu Jahr fast gleich, aber Software wird immer schwergewichtiger — das macht mich wahnsinnig. Noch 2010 belegte eine Linux-Distribution mit geladener Desktop-Umgebung direkt nach dem Start 100 MB RAM, optimierte Varianten etwa 60 MB.
    Heute sind Computer mit weniger als 8 GB praktisch unbenutzbar, und selbst 8 GB sind gerade so erträglich. Neue Software nutzt Electron, frisst mindestens 1 GB RAM, und alles, einschließlich Browsern, verbraucht absurd viel Speicher.
    Windows ist noch unverständlicher. Jedes Mal, wenn ich meiner Mutter am Computer helfe, ist der PC trotz aktuellem i5 und 8 GB RAM viel zu langsam; Booten, Programmstart und Updates dauern ewig. Wenn ein Computer länger als eine Minute zum Booten braucht, möchte ich ihn am liebsten aus dem Fenster werfen.
  • Stimmt. Viele der schwierigen Probleme in der Software wurden meiner Ansicht nach nicht gelöst, sondern umgangen. Container sind ein perfektes Beispiel.
    Man hat die Bereitstellung von Anwendungen über verschiedene Sprachen und Umgebungen hinweg nicht gelöst, sondern ist ihr mit einer Container-Engine ausgewichen. Man könnte Nutzern zwar ein Build-Skript geben, das bei Bedarf Compiler und Tools installiert, aber das ist schwer zuverlässig zu testen, also nutzt man am Ende Container.
    Redbean und Cosmopolitan libc schienen diesem Problem am nächsten an einer „Lösung“ zu sein. Wenn man will, dass Nutzer Apps einfach und zuverlässig bereitstellen können, haben Container einen Wettbewerbsvorteil, und dann kommen sofort über 100 MB auf der Festplatte plus eine Container-Engine dazu.
  • Wenn man die Logik „weil man es kann“ bis zu Schwärmen von KI-Killerbots weiterdenkt, landet man bei Slaughterbots.
    Solange Wettbewerb zwischen Staaten oder Unternehmen als zentrales Prinzip technologischer Entwicklung gilt, lassen sich globale Krisen wie Klimawandel, Zerstörung von Ökosystemen und tödliche KI schwer kontrollieren. Als oberstes Organisationsprinzip brauchen wir Zusammenarbeit und Kooperation; Wettbewerb erzeugt enorme negative Externalitäten für den ganzen Planeten.
  • Ich stimme nicht zu. Die Ursache sind Frameworks und Sicherheitsfunktionen von Betriebssystemen, etwa Telemetrie, sowie deren Bibliotheken.
    Programme, die mit Lazarus, also Free Pascal, geschrieben sind, laufen selbst auf aktuellem Windows wie Windows 11 sehr schnell. Für Geschwindigkeit und Stabilität ist es am besten, Desktop-Software zu pflegen, die für einen konkreten Zweck geschrieben wurde.
    Jede Modernisierung von Software, sowohl bei Hardware als auch bei Frameworks, wirkt wie eine Steuer auf den gesamten bestehenden Funktionsumfang.
  • Der Ausdruck „Weg des geringsten Widerstands“ gefällt mir. Auf diesem Weg scheint auch eine enorme Menge an CV-getriebener Entwicklung verstreut zu sein.
    Die Komplexität hat sich an völlig falschen Stellen angesammelt.

• Diese Klage wiederholt sich, aber faktisch ist das ein Zustand, den niemand ernsthaft ändern will.
  Entwickler mögen das Web als vollständig integrierte, vernetzte Universal-Computing-Plattform, und Nutzer scheinen sich nicht groß um Performance zu kümmern, solange sie gut genug ist. Am Ende darf Software so schlecht werden, bis zu dem Punkt, an dem sie die Nutzer gerade noch nicht zu sehr nervt.
  Auch das Management hat kein Interesse daran, bessere Software zu bauen, wenn bereits ausreichend gute Software entwickelt wurde. Solange niemand entscheidet, dass ein drastischer Bruch nötig ist, ändert sich nichts, und aus keiner Perspektive gibt es viel Anreiz für Veränderung.

  • Die Leute beschweren sich durchaus über Performance und Download-Größe, drücken es aber meist über die Nebenwirkungen aus. Etwa indem sie fragen, warum ihr Laptop heiß wird oder warum ihr iPhone „einfriert“.
    Menschen, die auf einem Handy mit schwachem Empfang große Apps herunterladen, in Gegenden mit instabilem Internet leben oder in einkommensschwachen Haushalten bzw. Entwicklungsländern ältere Geräte nutzen, sind von großen, langsamen Apps frustriert. Wenn man den Eindruck hat, dass ihnen Performance und App-Größe egal sind, stellt man womöglich den falschen Leuten die falschen Fragen.
  • Software-Bloat ist kein neues Phänomen. Beschwerden darüber gibt es mindestens seit Mitte der 1990er, und Ältere würden sagen, dass es bis in die 1980er oder 1970er zurückreicht.
    Mit der Zeit wirken nur noch die Beschwerdeführer ungewöhnlich; der Rest rüstet auf, nimmt den Bloat hin oder nutzt weiter alte Software.
    Allerdings muss man auch sehen, welchen Nutzen dieser Bloat bringt. Wäre Google Docs nur ein Word-Klon gewesen, würde es wohl kaum breit genutzt; manche nutzen es wegen Kostenlosigkeit, Zugriff von mehreren Geräten und reibungsloser Zusammenarbeit.
    Außerdem ist manches, was wie Bloat aussieht, in Wirklichkeit ein Komfortgewinn. Funktionen wie proportionale Schriftarten, die in jeder Größe gut aussehen, Unicode-Schriften, das Bearbeiten von Dokumenten, die größer als der Arbeitsspeicher sind, der Wechsel zwischen Arbeitsdokumenten und Materialien oder Speicherschutz verbrauchen viele Ressourcen, erhöhen aber die Lebensqualität.
  • Ich frage mich, ob das wirklich so ist. Für Webentwickler mag das gelten, aber ich habe selbst kaum direkte Webentwicklung gemacht. Ein Webinterface ist eine Entscheidung, und ein großer Treiber scheint die geschäftliche Notwendigkeit zu sein, Abo-Umsätze zu erzielen und Einmalkäufe zu vermeiden.
    Die moderne Cloud-basierte oder halb online geprägte Welt ist aus Nutzersicht ziemlich unnatürlich, und Fälle wie OpenOffice, die keine Monetarisierungsnotwendigkeit haben, können Desktop-Anwendungen bleiben.
  • Eines der erfolgreichen Startups war eine Single-Page-App, die ein 5-MB-Bundle herunterlud und Daten vorab einlas; der Start dauerte fast 10 Sekunden.
    Niemand beschwerte sich darüber, und selbst wenn die Performance einzelner App-Teile miserabel war, gab es selten Kundenbeschwerden. Erst bei Ladezeiten von etwa 60 Sekunden begannen Beschwerden.
    Trotzdem wurde die Software von Kunden gelobt, weil sie ein sehr wertvolles Problem löste und eine Aufgabe, die eine Woche gedauert hatte, auf wenige Minuten verkürzte. Als der Wettbewerb härter wurde, waren Verbesserungen nötig, aber den meisten war es wirklich egal, und es stand immer ganz unten auf der Prioritätenliste.
  • Am stärksten merkt man diesen Unterschied, wenn man Software nutzt, die nicht in diese Falle getappt ist. Systeme wie MYOB EXO/CRM oder SAP ERP haben Codebasen, die Jahrzehnte alt sind und nur sehr langsam verändert wurden; im Grunde sind sie Technik der 2000er und daher weiterhin unbequem zu benutzen, aber genau das wird zu einem großen Vorteil.
    Es macht Spaß, den Task-Manager zu öffnen und zu sehen, dass sie nur 20–30 MB RAM verwenden, obwohl ein erheblicher Teil der aktuellen Datenbank geladen ist. VLC und Blender sind ähnliche Beispiele.

• Interessant ist, dass die meisten den Entwicklern die Schuld geben, realistisch betrachtet sind es aber alles Geschäftsentscheidungen.
  Der Gang in die Cloud passiert, weil Unternehmen die stabilen Einnahmen von Abos mögen; Unternehmenskunden müssen kein IT-Team einstellen, und da die Verantwortung nach außen verlagert wird, können sie hohe Verfügbarkeit verlangen. Performance muss für Endnutzer nur „gut genug“ sein.
  Kunden, die Upgrades von On-Premises-Software verweigern, führten zu langen Wartungszyklen und endlosen Patches, und einmal fürs Web zu entwickeln ist geschäftlich attraktiver, als für jede Plattform eigene Entwickler und Tester vorzuhalten. Entwicklerexpertise allein kann diese grundlegenden Kräfte nicht verändern.

  • Nach einer gewissen Zeit funktioniert diese Software für den Kunden einfach gut. Photoshop ist ein gutes Beispiel.
    Die schicken neuesten Funktionen kann man zwar nicht nutzen, aber CS4 läuft auf einer Win7-Maschine ohne zusätzliche Kosten immer noch.
  • Auch in der Cloud kann man effiziente Web-Apps bauen. Am Ende sind es nur Server.
    Das Problem ist, dass Entwickler auf Maschinen entwickeln, deren Performance sich Nutzer nicht leisten können, und sich nicht um Performance und effizienten Code kümmern.
  • Viele Entwickler würden vermutlich dieselben Entscheidungen treffen. Plattformversionen derselben Software separat zu pflegen ist mühsam, und der Umgang mit Servern frisst Entwicklungszeit.

• Anfang der 90er passte MS Word auf ein paar Disketten, und die Haupt-Executable war, soweit ich mich erinnere, 2 MB groß. Es lief auch auf einem 16-MHz-386 mit insgesamt 2 MB RAM problemlos.
  Das meiste von dem, was man heute macht, konnte man damals auch schon; im Grunde fehlte nur so etwas wie eine Grammatikprüfung. Heute rechnen wir in GB, es ist um den Faktor 1000 größer geworden, und ich weiß nicht, was wir dafür bekommen haben. Wir haben nicht nur den Weg verloren, sondern wissen auch nicht mehr, wo das Ziel ist.

  • Bekommen haben wir Funktionen und Grafik.
    Allein dict.words unter Linux ist zum Beispiel 4,8 MB groß, und Arial Unicode ist eine Schriftart von rund 20 MB. Ein einzelnes App-Icon, an dem ich gerade arbeite, hat 400 KB, und auch der Google-Crashpad-Handler für Absturzbehandlung ist ein paar MB groß.
    Ein 4K-True-Color-Bildschirm ist 138-mal größer als ein 640x480-Bildschirm mit 16 Farben.
  • Vor ein paar Jahren habe ich als Aprilscherz DOS-/Windows-3.11-Disk-Images auf einen PXE-Netzwerk-Bootserver gelegt. Darin enthalten war ein funktionierendes Word 6 for Windows, und das gzip-komprimierte Image passte in 12 MB.
    PCs aus dieser Zeit konnten noch ohne UEFI booten, und richtig konfiguriert startete Windows 3.11 fast sofort; auch Word öffnete sich direkt.
    Word hat heute ziemlich viele sehr kleine und ein paar große Funktionen dazubekommen, aber ich bin überzeugt, dass Microsoft den Speicherverbrauch auf ein Zehntel senken könnte, wenn sie sich nur darum kümmern würden. Es gibt nur keinen Anreiz. Computer sind schnell, Speicher ist reichlich vorhanden, und man ist nicht mehr auf Disketten angewiesen – es würde nur mehr kosten.
    Ich denke, dass Software-Bloat durchaus einen nicht zu vernachlässigenden Einfluss auf die Umwelt haben könnte, aber solange es keinen ausreichend starken Unmut oder so etwas wie ein EU-Gesetz gegen Software-Bloat gibt, wird sich daran nichts ändern.
    Kürzlich habe ich auf GitHub auch den Quellcode von MS Word for Windows 1.0 gesehen. Die ursprüngliche Veröffentlichung liegt beim Computer History Museum und ist unter https://computerhistory.org/blog/microsoft-word-for-windows-... zu finden. Es war reines C, große Teile waren aber Assembler; der Code war im Vergleich zu heutigen C/C++-Standards, Patterns und Sprachfeatures unvorstellbar chaotisch.
  • Auf einem alten PowerBook Duo, das zur Entsorgung hereinkam, habe ich aus Nostalgie einmal Word 5.1 gestartet.
    Ich habe einmal die Formulierung gelesen, Software sei wie ein Gas: Sie dehnt sich aus, bis sie den verfügbaren Raum ausfüllt.
    Bei Live-Distributionen ist es ähnlich. Früher waren sie 700 MB groß, weil sie auf eine CD-R passen mussten; heute findet man kaum noch etwas, das auf einen 2-GB-USB-Stick passt. Immerhin ist es erfreulich, dass „minimal“ wieder an Bedeutung gewinnt.
  • In der Firma ist die Docker-Datei, mit der Machine-Learning-Code läuft, 6 GiB groß. Die Modelldateien sind nicht einmal enthalten.
    Nvidia, was genau sollen wir da eigentlich alles herunterladen? Tausende Kombinationen von generiertem Code, die wir nie verwenden werden?
  • Die Funktionen aus Word 6 sind im Grunde die, die man auch im neuesten Word noch benutzt.
    Nur braucht man länger, um sie zwischen all den hinzugekommenen aufgeblähten Funktionen zu finden.

• Minimalistische Software gibt es, aber die Leute entscheiden sich selten dafür. Man muss ziemlich viel Zeit darauf verwenden, Abhängigkeiten konservativ auszuwählen, und das führt dann zu einem leichten, performanten Stack.
  Heutzutage bevorzuge ich Tools wie Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2] und Mako Server[3]. Hervorragende, leichte, stabile und effiziente Software gibt es kostenlos, aber man muss dafür ein wenig abseits der ausgetretenen Pfade gehen. Das sind nicht unbedingt Dinge, die man auf Stack Overflow ständig hört.
  Beim Frontend bin ich etwas hin- und hergerissen. Ich bevorzuge native Apps und Webseiten, nutze aber täglich Tiddlywiki und sehe durchaus einen Platz für Web-Apps. Wenn allerdings ein Tab mit einer 6-MB-Tiddlywiki-Datei 155 MB RAM verbraucht, während eine stark angepasste Emacs-Session nur 88 MB braucht, stimme ich der Problemwahrnehmung des Autors zu.
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua ist das am meisten unterschätzte Programmierwerkzeug, das ich kenne. Lua wirklich zu beherrschen ist eine der besten Möglichkeiten, die eigenen Programmierfähigkeiten zu verbessern.
    Natürlich kann man es auch falsch einsetzen, aber im Vergleich zu den meisten anderen Sprachen ist es fast schockierend, wie klein und effizient Lua-Programme sein können.

• Ich sehe das Problem ungefähr so: Ein Unternehmensvorstand entscheidet, dass Entwickler für die Wettbewerbsfähigkeit High-End-Hardware brauchen, und die Entwickler bauen Web-Apps auf einem von der Firma gestellten High-Performance-Notebook mit 128 GB RAM.
  Und dann testen sie nicht in Umgebungen wie dem Familien-PC von 2010, den der Vater benutzt, oder sie testen nicht häufig und gründlich genug, um zu bemerken, dass vieles kaputt oder praktisch unbenutzbar ist.

  • Bei Netzwerkverbindungen ist es genauso. Die Erfahrung von jemandem, der die App im Büro mit Wifi 7 und symmetrischer Gigabit-Glasfaser nutzt, ist zwangsläufig eine andere als die von jemandem, der sie über den miesen WLAN-Router einer Wohnanlage und einen Consumer-Internetanschluss verwendet.
  • Das lässt sich leicht beheben. Beim Entwickeln stellt man die Entwicklertools auf mobile Nutzung und eingeschränkte Verbindung ein.
    Dann werden Mobile-first-Responsiveness, begrenzter Bildschirmplatz und potenzielle Probleme bei schlechter Verbindung zu Themen erster Ordnung.
    Normalerweise weist man den Product Owner auf das Problem hin, und es wird einfach abgetan. Daher könnte man den dritten Punkt in „Wir testen zwar auch auf einem Familien-PC von 2010, aber für die wichtigeren Stakeholder ist das kein Thema“ ändern.
  • Ein Teil meiner aktuellen Arbeit besteht darin, auf älterer Hardware oder leistungsschwächerer Hardware, in weiterhin genutzten alten Browsern und insbesondere auf Mobilgeräten zu testen.
  • Das ist keine völlig abwegige Vermutung. Allerdings behandelte der Text selbst ein ausgedachtes Problem.
  • In diesem Zusammenhang frage ich mich, ob Google-Android-Ingenieure Android-Smartphones tatsächlich selbst verwenden und damit testen. Ich vermute, die meisten sind Apple-Nutzer.

• Kürzlich wurde eine alte Seite von reinem HTML mit Backend-Generierung auf React umgestellt, und ein Dropdown mit etwa tausend Einträgen brauchte mehrere Sekunden zum Öffnen. Früher öffnete sich die ganze Seite in etwa 100 ms
  Zunächst kam der Vorschlag, nur die ersten 100 Einträge anzuzeigen und erst zu rendern, wenn der Nutzer drei Zeichen eingibt. So ist die Realität heute nun einmal
  In Wirklichkeit wurde natürlich der miese React-Code repariert, sodass es sofort rendert

  • Stimmt. Das ist üblich. Während es immer mehr Performance-Artikel über Dinge wie Time to First Paint gibt, hat React eine völlig neue Kategorie solcher Probleme geschaffen
  • Man kann ein serverseitiges Rendering-Framework wie Turbo verwenden. Ich habe viele der clientseitigen Frameworks ausprobiert, die die Leute heute wollen, aber bei vielen Daten waren sie alle langsam; Turbo war die einzige Ausnahme
  • Ein Auswahlfeld mit Tausenden Optionen wirkt wie eine miserable User Experience
    Wenn ein neues Framework das Problem so deutlich sichtbar macht, dass jemand einen echten Anlass hat, es zu beheben, spricht das eher noch mehr dafür, dieses Framework zu verwenden

• Wenn man Texte wie „idiomatic Ruby“ oder „Premature optimization is the root of all evil“ hochhält und sagt: „Entwicklungszeit ist wichtiger als Performance“, kommt eben so etwas dabei heraus
  Früher gab es Entwickler, die in weniger Zeit besseren Code geschrieben haben

  • Dem stimme ich nicht zu. Heute gibt es deutlich mehr Materialien als früher, die dabei helfen, effizienten Code zu schreiben
    Ich habe auch viel schrecklichen alten Code gesehen, der heute so nicht mehr entstehen würde