Recent searches

No recent searches

Search options

Not available on photog.social.
photog.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for your photos and banter. Photog first is our motto Please refer to the site rules before posting.

Administered by:

Server stats:

247
active users

photog.social: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.3

#wasm

1 post1 participant0 posts today
Replied in thread
*
vruz

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

Replied in thread
vruz

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

Replied in thread
vruz

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

Continued thread
vruz

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

Various thi.ng updates, bug fixes, additions and new version of 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 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 thi.ng/genart-api, hopefully also touching on these aspects...

[1] github.com/thi-ng/genart-api/t

#ThingUmbrella#Zig#Ziglang
just small circles 🕊

Hi @neil the gist of this may be interesting (without the AI, and the project isn't open source afaics):

> I [built] Tritium. Tritium aims to be the #lawyer's #VSCode: an all-in-one drafting cockpit that treats a deal's entire document suite as a single, searchable, AI-enhanced workspace while remaining fast, local, and secure.

> Tritium is implemented in Rust. It is cross-platform and I'm excited for the prospect of lawyers running #Linux as their daily driver.

news.ycombinator.com/item?id=4

news.ycombinator.comShow HN: Tritium – The Legal IDE in Rust | Hacker News
#wasm
Jan :rust: :ferris:

Owi

github.com/OCamlPro/owi

Symbolic execution for #Wasm, #C, C++, #Rust and #Zig

"#Owi is an open-source framework for advanced #WebAssembly analysis and manipulation, with a focus on practical symbolic execution and robust tooling. It is designed for researchers, engineers, programming language enthusiasts and practitioners requiring precise, flexible, and extensible support program reasoning."

GitHubGitHub - OCamlPro/owi: Symbolic execution for Wasm, C, C++, Rust and ZigSymbolic execution for Wasm, C, C++, Rust and Zig. Contribute to OCamlPro/owi development by creating an account on GitHub.
#FormalVerification#SoftwareTesting#Testing
Karsten Schmidt

#ReleaseMonday — New version (v0.27.0) of thi.ng/genart-api, a platform-independent extensible API for browser-based computational/algorithmic/generative art projects:

This version features an overhaul of the platform provided PRNG (pseudo-random number generator) handling and makes it easier to create multiple PRNGs for artworks which require/desire them...

Related section in the README:
github.com/thi-ng/genart-api/b

Also, just as a reminder, the project has:

- no external dependencies
- adapters for 3 art platforms (EditArt, fxhash, Layer)
- 6 example projects
- testing/dev sandbox with two parameter editors
- WebAssembly bindings & demo (currently for #Zig only)

Happy coding! :)

thi.ng/genart-apithi.ng/genart-api
#GenArtAPI#GenerativeArt#AlgorithmicArt
*
𝕂𝚞𝚋𝚒𝚔ℙ𝚒𝚡𝚎𝚕

»6 Fehler, die sich Rust-Devs sparen sollten:
Wenn Sie Rust-Code schreiben, sollten Sie dieses halbe Dutzend Verfehlungen tunlichst vermeiden.«

Das Programmieren in Rust auch nicht an einem Wochenende gelernt ist, wie viele Scriptsprachen, ist klar. Durch deren Präzision aber auch sehr sicher (Fehler sind überall von Menschen einfließbar) und schnell, auch per WASM im Webbrowser.

🦀 computerwoche.de/article/28340

Computerwoche6 Fehler, die sich Rust-Devs sparen solltenWenn Sie Rust-Code schreiben, sollten Sie dieses halbe Dutzend Verfehlungen tunlichst vermeiden.
#rust#rustdev#rustlang
Live feeds
About