Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The web is hard to read because people have an incentive to use alternative languages/tooling to produce web content.

These alternatives wouldn't exist (or be so widely used) if the web provided the benefits that these tools give.

For example, look at how many people switched from CoffeeScript to ES6/7 once these languages started providing most of (and not all of) the benefits that CoffeeScript provides.

In all honesty, I don't think sourcemaps are the answer to the black-box problem.



I think you have a point, and (elsewhere here, among other places: https://brendaneich.com/2007/03/the-open-web-and-its-adversa...) I've argued that the Web's open-box nature matters. It's not just an accident or hindrance.

If I'm right, we won't see wasm overused such that the web becomes a sea of monolithic and opaque apps (as too many mobile OS homescreens are). Per the FAQ, wasm is also for hot kernel code and reusable libraries helping mostly-JS apps.

It's up to web devs to keep innovating ahead of browsers, to keep pushing for better HTML, CSS, JS, and beyond. One way to do this might be via wasm modules that extend the web. The https://extensiblewebmanifesto.org/ project continues.


I think the only way the web could remain mostly-JS apps, is if the benefits of writing mostly-JS apps would outweigh the benefits of writing, well, not-mostly-JS apps.

And I'm not sure if that's gonna be true.

For example, I'm sitting here, arguing for an open and readable web, and yet I can't wait for a rust-to-asm.js workflow to get stable enough so that I can move the perf-critical parts of my app to rust (you know, the part that could be learned from and hacked on by another developer).


Serious question: why could not those other devs learn from your Rust code, even decompile wasm back into it via their devtools and ye olde view source?


Because the source-map may not be available. And they might not know Rust. Or perhaps having to setup a Rust dev env to play with this code is too much work and it's just not worth it.

Anyway, I think I should explain my thoughts better instead of only pointing out a problem. I wrote this comment: https://news.ycombinator.com/item?id=9743859


Optimizing compilers.


Sometimes you must build with -g. WebDWARF ;-).


Can you please clarify? I've seen WebDWARF mentioned twice now, but when I Google, I get a bunch of results about a shareware clone of Dreamweaver.


DWARF is a debugging data format for ELF files.[1]

WebDWARF then would be to WebASM, as DWARF is to ELF files.

[1]https://en.wikipedia.org/wiki/DWARF


Thank you!


I'm suggesting that when debugging optimized code, you'll use -g as on native platforms. I'm speculating further that with wasm, decompilers will rise to the view source challenge.


I think it is perspective. I would prefer a web where I can use any language I want and not be forced to use only Javascript to create content. So in that sense this could give me more freedom.

For example I may chose to write my code in Rust and that imposes a burden on you (assuming you know only Javascript), but it does not curtail your freedom. Not as convenient as before for you since you now need to learn Rust. I think the freedom has spread to the person who is creating the content (code). The general consumer does not care, but the tinkerer/hacker now needs to put in more effort to parse the creation.


So long as the wasm blob can be read as Rust by a third party.

If it's a one-way Rust source -> wasm transformation, even a Rust user might have a hard time following what wasm spits out.


I agree that giving authors more freedom is a good thing, but as I argued, it also has serious downsides. But I think there are ways to keep the best of both worlds. I wrote a comment here with more detail: https://news.ycombinator.com/item?id=9743859




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: