HTML-in-Canvas brengt DOM naar GPU-interfaces; Tov-claims vragen eerlijke Rust-vergelijking

Chrome test een API waarmee interactieve DOM-elementen rechtstreeks in een canvas- of GPU-textuur kunnen landen. Dat biedt interessante routes voor complexe interfaces, maar het is nog een experimentele Chrome-functie met duidelijke prestatie- en compatibiliteitsgrenzen.

Een tegenanalyse zet bovendien vraagtekens bij de benchmarkclaims van de nieuwe taal Tov. De bruikbare les is niet welke taal wint, maar dat vergelijkingen alleen iets zeggen wanneer datatypen, datastructuren en abstraheringsniveau werkelijk gelijk zijn.

HTML-in-Canvas laat DOM en GPU-rendering samenkomen

Chrome heeft HTML-in-Canvas als origin trial beschikbaar gemaakt voor Chrome 148 tot en met 150. De experimentele API kan een DOM-element in een 2D-canvas tekenen of in een WebGL- of WebGPU-textuur kopiëren, terwijl dat element interactief en toegankelijk blijft. Daarmee probeert Chrome een grens te overbruggen die bij canvasinterfaces vaak hard is: lage-niveau rendering enerzijds, tekstselectie, formuliervelden, browserzoom, toegankelijkheidsboom en zoekfunctie anderzijds.

Dat is vooral interessant voor zware visuele applicaties, 3D-scenes en games die nu zelf tekstinvoer, selectie en toegankelijkheid nabouwen. De documentatie noemt al experimentele ondersteuning in Three.js en PlayCanvas. De tegenprestatie is dat ontwikkelaars de DOM-transformatie met de getekende positie moeten synchroniseren; bij WebGL/WebGPU is die matrixvertaling expliciet onderdeel van de integratie.

Dit is nadrukkelijk nog geen breed inzetbare webstandaard. De API werkt niet met cross-origin iframes. Ook blijven scrolling en animaties binnen de canvasroute afhankelijk van JavaScript op de main thread, anders dan gewone DOM-content. In de HN-discussie worden verder zorgen geuit over de omvang en interoperabiliteit van weer een grote browser-API; dat is geen technische weerlegging, wel een reden om eerst een afgebakend prototype te bouwen. Chrome over API, trial en beperkingen · HN-discussie

Tov versus Rust: tegenanalyse ziet geen eerlijke benchmarkbasis

Tov positioneert zich als een TypeScript-achtige taal voor coding agents die via C naar native binaries compileert, met de claim Rust te verslaan. Een nieuwe tegenanalyse onderzoekt drie van de aangehaalde benchmarks — big-integer-Fibonacci, dynamische dispatch en hash-map-inserts — op drie Linux-opstellingen.

De auteurs vervangen in de Rust-varianten onder meer trait objects en Box-allocaties door een enum en array, en de standaard HashMap door AHashMap; in hun metingen zijn die aangepaste Rustprogramma’s meestal even snel of sneller dan Tov. Bij de dispatchproef is het grote verschil verklaarbaar doordat de oorspronkelijke Rustcode dynamische dispatch gebruikt, waar de C/Tov-variant volgens de analyse een directere representatie heeft. De auteurs rapporteren ook flinke spreiding in sommige runs.

Hun conclusie dat de oorspronkelijke benchmarks bewust misleidend zijn, is een beschuldiging van één tegenpartij en geen onafhankelijk vastgesteld feit. De technische les is steviger: vergelijk native talen niet met willekeurige voorbeeldprogramma’s. Leg compileropties, gebruikte libraries, allocatiepatronen, datastructuren, invoer, warm-up en foutmodel vast — en laat dezelfde semantiek uitvoeren. Tov is daarmee niet gediskwalificeerd als experiment, maar de aangehaalde snelheidsclaims zijn zonder zo’n vergelijking onvoldoende voor een taalkeuze. Tegenanalyse met code en meetlogs · Lobsters-discussie

Eén provocatieve prompt meet vooral trainings- en promptpatronen

ModelCompare vroeg twaalf tekstmodellen drie keer naar hun ‘meest controversiële’ visie op mensen, zonder systeem-prompt of retries. De site deelt 29 van 35 antwoorden handmatig in bij één thema: mensen zouden groepsbinding, status of een eigen verhaal vaker boven waarheid of principes plaatsen. Vier modellen gaven ook afwijkende antwoorden; één antwoord weigerde.

Dat resultaat is een aardig demonstratiemateriaal voor de neiging van modellen om bekende, goed verwoorde culturele patronen terug te geven. Het onderbouwt echter niet dat modellen dezelfde overtuiging hebben, onafhankelijk tot dezelfde conclusie kwamen of een algemene bias delen. Er zijn slechts drie antwoorden per model, één sterk sturende vraag en een door de site zelf gemaakte categorisering. Ook de HN-discussie levert vooral tegenvoorbeelden en persoonlijke ervaringen op, geen onafhankelijke toets van de proef.

Wie modelgedrag wil vergelijken, heeft daarom meer aan vooraf vastgelegde rubrieken, veel prompts en variatie in formulering, sampling en context. Anders meet je gemakkelijk de aantrekkingskracht van één prompt en een populaire stijlfiguur. Proefopzet, antwoorden en prompt · HN-discussie

Verder nog

• OnKey brengt zangtracking naar Apple Silicon: deze MIT-gelicentieerde Mac-app leert na één keer afspelen lokaal de melodie van de leadzang, toont later toonhoogte en timing tijdens het meezingen en bewaart opnamen en geleerde melodieën op de Mac. De app vraagt wel systeemaudio- en microfoontoegang; voor songherkenning, lyrics, metadata en updates kunnen optionele externe diensten worden gebruikt. De app meet vooral toonhoogte en timing, niet de bredere zangtechniek. OnKey: werking en privacyoverzicht · HN-discussie
• jank combineert Clojure met C++-interop: het project laat Clojure-achtige code rechtstreeks C++-headers, templates, exceptions en RAII gebruiken, en bouwt op een Clang-gebaseerde JIT voor REPL-werk. Dat kan aantrekkelijk zijn voor snelle native prototypes; de claims over naadloze interop komen van het project zelf en de agentervaringen in de discussie zijn anekdotisch. jank: taal- en buildmodel · HN-discussie