vruz
@vruz@mstdn.social  ·  activity timestamp 2 days ago

Direct WASM→DOM access doesn't leave JavaScript behind - JS could use the same fast path! We could even build Fagnani's exact templating API as a reference implementation on top of it. But unlike a JS-only solution, the platform stays open for potentially superior approaches in ANY language. Rust might build something faster. Zig might build something smaller. That's the kind of competition through collaboration that drives innovation. Everybody wins wins wins. #compsci#webdev #wasm#javascript
vruz
@vruz@mstdn.social  ·  activity timestamp 2 days ago

Frameworks already solved templating. They're good at it! What they CAN'T solve is the JS monopoly on DOM access. Open that up and watch innovation explode across the entire ecosystem. React, Vue, Svelte - they all work great. But imagine what could be built if any language had direct DOM access. New paradigms, new approaches, new frameworks we can't even conceive of yet. #compsci#webdev#javascript
vruz
@vruz@mstdn.social  ·  activity timestamp 2 days ago

Instead of standardizing one templating syntax (that'll be bikeshedded to death), give us the primitive: fast DOM access from any language. Let a thousand templating libraries bloom - in any language. Lower-level primitives enable more innovation than high-level APIs. That's the Unix philosophy. Simple, composable, powerful. Build the foundation right. #compsci#webdev #wasm #frontend#unix
vruz
@vruz@mstdn.social  ·  activity timestamp 2 days ago

Native JS templating: helps JavaScript developers. Direct WASM→DOM: helps EVERY language. Rust, Go, C#, Zig, Swift, Kotlin... all get first-class web UI performance. That's real platform evolution. We shouldn't be adding more JS-specific APIs when we could be opening the web to all languages equally. The web platform should be language-agnostic at its core. #compsci#webdev #webassembly#programming
vruz
@vruz@mstdn.social  ·  activity timestamp 2 days ago

The performance argument for native templating is weak - we're talking 2% gains, max. But remove the JS bridge for WASM? That's where real performance wins live. Fix the actual bottleneck. Every DOM call through JS is overhead we don't need. Direct access would unlock true native speeds for web UIs. Imagine game engines manipulating DOM at 60fps without JS overhead. #compsci#webdev #performance #wasm
vruz
@vruz@mstdn.social  ·  activity timestamp 2 days ago

Why add yet another JS templating API when WASM + direct DOM access solves the root problem? Every language could build efficient UIs without the JS bottleneck. More universal than blessing one syntax. Think beyond JavaScript - imagine Rust components with zero overhead, Go templates that actually perform, or C# Blazor without the bridge tax. That's true platform evolution. #compsci#webdev #wasm #webstandards
Karsten Schmidt
@toxi@mastodon.thi.ng  ·  activity timestamp 6 days ago

Various thi.ng updates, bug fixes, additions and new version of https://github.com/thi-ng/zig-thing/ — now fully compatible with current Zig v0.14.1

On a more diary/devlog note: I also updated several of my Zig based work-in-progress art pieces to the latest version (some of them not touched in 2+ years) and it's so good to see how the https://thi.ng/wasm-api toolchain has been holding up with various breaking Zig changes and also how this setup simplifies creating hybrid Zig/TypeScript projects (e.g. for using DOM/WebGL from Zig). Related, I also want to mention once more the #GenArtAPI Zig WebAssembly bindings[1] (updated a few weeks ago), which add another layer of flexibility & boilerplate reduction for generative/procedural/algorithmic art projects...

I will be attempting yet another few takes creating a video overview & mini-workshop/tutorial about https://thi.ng/genart-api, hopefully also touching on these aspects...

[1] https://github.com/thi-ng/genart-api/tree/main/packages/wasm

#ThingUmbrella#Zig#Ziglang#WebAssembly#WASM#GenArtAPI#Art#GenerativeArt#AlgorithmicArt