>>164947>Er kann pures JS halt nicht weglassen, weil dann keiner mehr seine Transensoftware nutzt.
Er soll es auch nicht weglassen, sondern anständig implementieren, und nicht Transpilierung mit 0,0 Optimierung benutzen.
>WASM ist sicher nicht böse gemeint.
Ja, jedoch führt die Kombination mit einer schlechten JS-Implementierung dann dazu, dass die Webseitenbetreiber die Schwierigkeit "angemessen" hoch für WASM-Nutzer einstellen, was dann bedeutet, dass die JS-Nutzer mit der schlechten Implementierung sehr lange warten müssen.
>Ich habe zwar einen Block vorerst übersprungen, aber war es nicht Performanz?
Das war der Grund/einer der Gründe für WASM. Dass Komplexitätsverringerung kein Ziel für die Brauserhersteller ist, ist bereits das Problem.
>Das will ich gerne glauben, aber wie oft machst du ein Audit bei regulärem JS? Wenn es laufen muss weil sonst gar nichts lädt bleibt nur konsumverzicht oder ausführen.
Das Problem ist die vergrößerte Angriffsoberfläche bei JS + WASM verglichen mit JS.
>Wenn du Komplexität rein als Angriffsfläche verstehst stehe ich natürlich hinter dir.
Ja! Aber Felix geht noch darüber hinaus: Komplexität macht eben auch Käfer, weshalb praktisch alle mindestens mittelgroße Weichware heutzutage karpott ist.
Die Weichware ist so karpott, dass man als Nutzer kleine Fehler bereits unbewusst ausfiltert. GIF relatiert enthält beispielsweise mindestens 5 Fehler.
Der Komplexitätsscheißeturm muss wachsen!
>TOR-Browser
Von denen habe ich auch etwas zu WASM gefunden (Strg+F "wasm"):
https://forum.torproject.org/t/new-release-tor-browser-15-0/20727
>Ist WASM abstellen nur das Web betreffend, oder nutzt dein uBO das dann auch nicht?
Wenn man
javascript.options.wasm = false
javascript.options.wasm_trustedprincipals = true
eingestellt hat (letztere Option ist Standard, d.h. einfach nur erstere umschalten) dann können Erweiterungen weiterhin WASM nutzen.
Felix hat das so und uBlock Origin sagt unter Support → [More] → [SNFE: Dump]:
Origin trie container:
Buffer size (Uint8Array): 848,615
Char segment size: 586,471
WASM: enabled
Request trie container:
Buffer size (Uint8Array): 7,378,188
Char segment size: 2,069,772
WASM: enabled
Pattern trie container:
Buffer size (Uint8Array): 9,972,304
WASM: enabledFelix fährt seit knapp 9 Jahren im Firefox ohne WASM, also eigentlich direkt nachdem WASM in Firefox implementiert wurde.
Felix vermisst praktisch gar nichts. Ca. einmal pro Halbjahr gibt es eine Seite, die dann nicht lädt, und in der Konsole steht was von WASM. Das sind dann meist irgendwelche Emulatoren wie z.B. vom Internet Archive, wenn man z.B. das originale Microsoft Excel 2.0 mal ausprobieren will. Die einzig andere Sache, die Felix noch einfällt, sind "Datenanalyse"-Seiten, bei denen man einen großen Datensatz dann mit bunten Balkendiagrammen analysieren kann. Alles andere, insbesondere Google Maps, sämtliche Kaufseiten, Strömseiten, funktioniert einfach ohne WASM.
(Das größte Problem von Felix ist noch immer
privacy.firstparty.isolate = true, weil damit schlechte Seiten (Deutsche Post, Deutsche Bahn), welche die falsche PayPal-Integration (Kommunikation via Cookies statt URL-Parametern) gewählt haben, nicht mit PayPal zusammen funktionieren.)
Das "Benutzer hat Vorteile, weil mehr Performanz"-Argument wird damit gewissermaßen zum Lückenbüßer: Die meiste Performanzsteigerung hätte man schlicht durch Verzicht auf riesige JS-Rahmenwerke, was auch durch WASM nicht ersetzbar wird. Dass man WASM tatsächlich zur Performanz braucht, wird nur in ganz wenigen Nischen (Emulatoren, Datenanalyse) überhaupt relevant. Das gesagt für Felix als C- und C++-Entwickler, der jeden Tag in die Disassembly reinschaut, um zu sehen, was da wieder vom Kompiler reingekotet wurde.
An der Stelle muss man auch mal das "Entwickler-Syndrom" ansprechen, was wie folgt aussieht: Ein Entwickler baut eine Seite, sieht "jo, schnell genug", und optimiert nichts mehr (auch nicht mit WASM). So kriegt man, wenn die Entwickler immer schnellere Hartware unter Schreibtisch stehen haben, dementsprechend immer langsamerere Weichware. Daraus folgt, dass auch immer weniger Entwickler WASM überhaupt in Betracht ziehen, weil der Dschobb von WASM -- Performanz in den Nischen -- immer seltener vom Entwickler nachgefragt wird und damit WASM immer weniger von Entwicklern genutzt wird. Die Nischen von WASM werden damit immer kleiner.
Statt "Science made God unnecessary" gibts nun "Core i9-14900K made WASM unnecessary". Gott und WASM als Lückenbüßer.