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

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

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

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

Obelisk is a workflow engine that uses WebAssembly components for the workflows themselves. Separates deterministic computations (workflows) from i/o and network side-effects (activities). Interesting 👀

https://obeli.sk/blog/introducing-obelisk/

#WebAssemblyComponent #wasm #webassembly #obelisk