frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Test Results for AMD Zen 5

https://www.agner.org/forum/viewtopic.php?t=287&start=10
158•matt_d•3h ago•16 comments

OCaml Programming: Correct and Efficient and Beautiful

https://cs3110.github.io/textbook/cover.html
25•smartmic•1h ago•1 comments

How We Rooted Copilot

https://research.eye.security/how-we-rooted-copilot/
200•uponasmile•6h ago•87 comments

Resizable Structs in Zig

https://tristanpemble.com/resizable-structs-in-zig/
15•rvrb•42m ago•2 comments

What went wrong for Yahoo

https://dfarq.homeip.net/what-went-wrong-for-yahoo/
77•giuliomagnifico•4h ago•77 comments

Purple Earth hypothesis

https://en.wikipedia.org/wiki/Purple_Earth_hypothesis
128•colinprince•2d ago•38 comments

Epic Recall, Epic Fail

https://taipology.substack.com/p/epic-recall-epic-fail
11•hunglee2•1h ago•0 comments

Rust running on every GPU

https://rust-gpu.github.io/blog/2025/07/25/rust-on-every-gpu/
439•littlestymaar•12h ago•149 comments

Large ancient Hawaiian petroglyphs uncovered by waves on Oahu

https://www.sfgate.com/hawaii/article/hawaii-petroglyphs-uncovered-20780579.php
48•c420•3d ago•14 comments

Getting decent error reports in Bash when you're using 'set -e'

https://utcc.utoronto.ca/~cks/space/blog/programming/BashGoodSetEReports
21•zdw•2d ago•6 comments

The Sail instruction-set semantics specification language

https://alasdair.github.io/manual.html
18•weinzierl•2h ago•3 comments

Font-size-adjust Is Useful

https://matklad.github.io/2025/07/16/font-size-adjust.html
145•Bogdanp•3d ago•45 comments

Inverted Indexes: A Step-by-Step Implementation Guide

https://www.chashnikov.dev/post/inverted-indexes-a-step-by-step-implementation-guide
52•klaussilveira•3d ago•17 comments

The natural diamond industry is getting rocked. Thank the lab-grown variety

https://www.cbc.ca/news/business/lab-grown-diamonds-1.7592336
71•geox•10h ago•95 comments

CCTV footage captures video of an earthquake fault in motion

https://www.smithsonianmag.com/smart-news/cctv-footage-captures-the-first-ever-video-of-an-earthquake-fault-in-motion-shining-a-rare-light-on-seismic-dynamics-180987034/
393•chrononaut•19h ago•75 comments

Shallow Water Is Dangerous Too

https://www.jefftk.com/p/shallow-water-is-dangerous-too
36•surprisetalk•3d ago•6 comments

Open Sauce is a confoundingly brilliant Bay Area event

https://www.jeffgeerling.com/blog/2025/open-sauce-confoundingly-brilliant-bay-area-event
294•rbanffy•3d ago•169 comments

Ageing accelerates around age 50 ― some organs faster than others

https://www.nature.com/articles/d41586-025-02333-z
157•rntn•6h ago•85 comments

Breaking the WASM/JS communication performance barrier

https://github.com/ealmloff/sledgehammer_bindgen
112•weinzierl•3d ago•19 comments

Bringing a decade old bicycle navigator back to life with open source software

https://raymii.org/s/blog/Bringing_a_Decade_Old_Bicycle_Navigator_Back_to_Life_with_Open_Source_Software_and_DOOM.html
146•mtlynch•11h ago•27 comments

It's time for modern CSS to kill the SPA

https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/
681•tambourine_man•1d ago•438 comments

The rise and fall of the Hanseatic League

https://worksinprogress.co/issue/the-rise-and-fall-of-the-hanseatic-league/
148•loeber•3d ago•50 comments

Simon Tatham's Portable Puzzle Collection

https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
170•sogen•15h ago•34 comments

Yes, the Book of PF, Fourth Edition Is Coming Soon

https://bsdly.blogspot.com/2025/07/yes-book-of-pf-4th-edition-is-coming.html
108•turtleyacht•3d ago•34 comments

Where are vacation homes located in the US?

https://www.construction-physics.com/p/where-are-vacation-homes-located
63•rufus_foreman•4h ago•56 comments

Svalbard winter warming is reaching melting point

https://www.nature.com/articles/s41467-025-60926-8
56•toomuchtodo•4h ago•14 comments

The Rise of Shippable Microfactories

https://www.thesisdriven.com/p/the-rise-of-shippable-microfactories
43•mhb•9h ago•12 comments

Project Lyra – Exploring Interstellar Objects

https://i4is.org/what-we-do/technical/project-lyra/
25•andsoitis•3d ago•1 comments

Users claim Discord's age verification can be tricked with video game characters

https://www.thepinknews.com/2025/07/25/discord-video-game-characters-age-verification-checks-uk-online-safety-act/
139•mediumdeviation•18h ago•143 comments

Upsides and Downsides

https://calv.info/upsides-and-downsides
41•nohide•2d ago•1 comments
Open in hackernews

Breaking the WASM/JS communication performance barrier

https://github.com/ealmloff/sledgehammer_bindgen
112•weinzierl•3d ago

Comments

andyferris•9h ago
The whole UTF-8 vs UTF-16 thing makes this way more messy than it should be.

I'd love for some native way of handling UTF-8 in JavaScript and the DOM (no, TextEncoder/TextDecoder do not count). Even a kind of "mode" you could choose for the whole page would be a huge step forward for the "compile native language to WASM + web" thing.

theSherwood•8h ago
100%. If we could get a DomString8 (8-bit encoded) interface in addition to the existing DomString (16-bit encoded) and a way to wrap a buffer in a DomString8, we could have convenient and reasonably performant interfaces between WASM and the DOM.
continuational•7h ago
The extra DOM complexity that would entail seems like a loss for the existing web.
ethan_smith•7h ago
The TC39 proposal for "Resizable ArrayBuffer" and "String.prototype.isWellFormed" methods are steps in this direction, though we still need proper zero-copy UTF-8 string views.
samwillis•9h ago
It's great that the rust community are finding ways to improve the performance of decoding strings from WASM to js, it's one of the major performance holes you hit when using WASM.

The issue comes down to the fact that even if your WASM code can return a utf16 buffer, to use it as a string in JS code the engine needs to make a copy at some point. The TextDecoder api does a first good job of making this efficient, ensuring there is just a single copy, but it's still overhead.

Ideally there should be a way to wrap an array buffer with a "String View", offloading the responsibility of ensuring its utf16 to the WASM code, and there being no copy made. But that brings a ton of complexities as strings need to be immutable in js, but the underlying buffer could still be changed.

breve•7h ago
The JS string built-ins proposal for WebAssembly:

https://github.com/WebAssembly/js-string-builtins/blob/main/...

samwillis•5h ago
Personally I feel this is backwards - I don't want access to js literals and objects from WASM, I just want a way to wrap an arbitrary array buffer that contains a utf16 string as a js string.

It keeps WASM simple and provides a thin layer as an optimisation.

vanderZwan•4h ago
> It keeps WASM simple

At the cost of complicating JS string implementations, probably to the point of undoing the benefits.

Currently JS strings are immutable objects, allowing for all kinds of optimization tricks (interning, ropes, etc.). Having one string represented by a mutable arraybuffer messes with that.

There's probably also security concerns with allowing mutable access to string internals inside the JS engine side.

So the simple-appearing solution you suggested would be rejected all major browser vendors who back the various WASM and JS engines.

Access to constant JS strings without any form of mutability is the only realistic option for accessing JS strings. And creating constant strings is the only one for sending them back.

nhatcher•8h ago
I wrote a while back about a somewhat related issue:

https://www.nhatcher.com/post/should_i_import_or_should_i_ro...

The code is a bit outdated, but the principle of linking against the browser implementation stands

bcardarella•8h ago
How does the performance compare to projects like Wasmtime?
Evan-Almloff•8h ago
The two projects have different usecases so they can't be directly compared. Slegehammer bindgen makes calling javascript from rust faster in the browser. Wasmtime is a native runtime for WASM outside of the browser
CyanLite2•8h ago
Sad that this isn’t natively in browsers…
vanderZwan•4h ago
> Wasm-bindgen calls TextDecoder.decode for every string. Sledgehammer only calls TextEncoder.decode once per batch.

So they decode one long concatenated string and then on the JS side split it into substrings? I wonder if that messes with the GC on the JS side of things.

boomskats•3h ago
How would splitting it into substrings be different from decoding individual strings from an allocation/gc perspective? If anything I'd assume splitting a substring was more efficient - i expect there's a ton of optimisations in js for sliced strings or whatever as it's been around for ages.
vanderZwan•2h ago
I imagine it's faster during creation because there's fewer allocations for a backing array for the string content (one, basically, unless they move stuff around). But then that can also mean holding on to the entire backing array even if only one of the strings is still "alive", unless there are optimizations for reclaiming memory in those situations too.
MuffinFlavored•3h ago
I think there is a ton of room left on the table here for innovation.

Context: as far as I know Electron is still the king if you want to do (unsafe but performant) "IPC/RPC" between native and a webview.

All of the other options that exist in other languages (Deno, Rust, you name it) do the same "stringified JSON back and forth" which really isn't great for performance in my opinion.

It'd be cool if (obviously in a sandboxed or secure way) you could opt in to something albeit a bit reckless, but some way to provide native methods for the WASM part of V8 and its WebView (thinking Electron-esque here) to call.

boomskats•3h ago
I'm not sure if I'm understanding you correctly, but vanilla wasm ipc works by sharing linear memory, where it's up to the implementation to choose the data encoding (arrow/proto/whatever). In the case of wasm-bindgen's dom manipulation api, the implementation serialises individual commands and sends them over the boundary, with any string params for each command being deserialised individually, and this project improves on that by batching them all into one big string thus reducing the deserialisation overhead. However, the string encoding is specific to that use case - it's not a general wasm ipc mechanism.

VSCode IPC is kinda similar as it's designed to facilitate comms over an enforced process isolation barrier to protect the main thread from slow extensions etc. but it's actually IPC there (as in, there are multiple processes at the os level). The wasm/js stuff is handled within the same v8 context - it's not actually ipc.

(Happy to be corrected here, but this is my understanding)

MuffinFlavored•2h ago
https://github.com/webview/webview_deno

Tell me how you'd do "native C/C++ FFI (to like a .so or .dylib or .dll)" between the webview using WASM or anything other than "WebKit's built in JSON-string based IPC"

Like a <button> that triggers a DLL call. How would you achieve it with WASM? How does WASM act as the bridge to the DOM and/or native? It doesn't, right?

Evan-Almloff•6m ago
Most of the optimizations apply equally to calling into webview JS from a native application for something like dom manipulation. There is a wry example that uses the system webview in the repo: https://github.com/ealmloff/sledgehammer_bindgen/blob/master...