Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Is WebAssembly Going to Get DOM Support?

queue.acm.org

Post reply on HN
Print view View original

181–190 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#181

Post by austin-cheney »

JambalayaJimbo wrote: post #175
austin-cheney wrote: post #44

This is one of those self-taught versus college educated subjects. See this for some background https://news.ycombinator.com/item?id=44599228 This subject is interesting because your typical college educated developer HATES the DOM with extreme passion, because it’s entirely outside their area of comfort. The typical college educated developer is typically educated to program in something like Java, C#, or C++ and is…

Why would college educated developers hate node or tree structures? That’s half of our degrees!

I have 20 years of experience writing software with hundreds and hundreds of other developers for mega dot coms that indicates many, possibly most, developers do everything possible to hide from tree structures. I don’t know why that is because it’s neither scary nor challenging.

It’s also strange that my prior comment here is maximally downvoted when the similar comment it linked to was upvoted to triple digits. This further reaffirms my assumption that WASM primarily appeals to insecure developers.

Re: When Is WebAssembly Going to Get DOM Support?

#182

Post by Spivak »

flohofwoe wrote: post #26
weinzierl wrote: post #5

Earlier quoted context omitted.

"Definitely some feeling of being rug-pulled in the shift here." Definitely feeling rug-pulled. What I think all the people that hark on the "Don't worry, going through JS is good enough for you." are missing is the subtext of their message. They might objectively be right, but in the end what they are saying is that they are content with WASM being a second class citizen in the web world. This might be fine for ever…

> that they are content with WASM being a second class citizen in the web world Tbh, most of the ideas so far to enable more direct access of Javascript APIs from WASM have a good chance of ruining WASM with pointless complexity. Keeping those two worlds separate, but making sure that 'raw' calls between WASM and JS are as fast as they can be (which they are) is really the best longterm solution. I think what people…

Wouldn't the path forward be that the browser acts more like a kernel with a syscall interface which both V8 and WASM use? You wouldn't access "Web APIs" from WASM because those would be written in JS but you get access to the same primitives used to implement the JS API.

Sure, probably equally a pipedream but if there was any serious effort to make WASM a first class citizen in the browser it would probably be something like this rather than a crappy FFI to JS which has to obey JS semantics and deal with JS types.

Re: When Is WebAssembly Going to Get DOM Support?

#183

Post by flohofwoe »

Spivak wrote: post #182
flohofwoe wrote: post #26

Earlier quoted context omitted.

> that they are content with WASM being a second class citizen in the web world Tbh, most of the ideas so far to enable more direct access of Javascript APIs from WASM have a good chance of ruining WASM with pointless complexity. Keeping those two worlds separate, but making sure that 'raw' calls between WASM and JS are as fast as they can be (which they are) is really the best longterm solution. I think what people…

Wouldn't the path forward be that the browser acts more like a kernel with a syscall interface which both V8 and WASM use? You wouldn't access "Web APIs" from WASM because those would be written in JS but you get access to the same primitives used to implement the JS API. Sure, probably equally a pipedream but if there was any serious effort to make WASM a first class citizen in the browser it would probably be somet…

Yeah something like that would be nice, it would probably increase the attack surface though (since each internal web api implementation now has two surfaces, one that's exposed to JS and one lower level C-like API that directly connects to the WASM import table).

Re: When Is WebAssembly Going to Get DOM Support?

#184

Post by pjmlp »

mananaysiempre wrote: post #176
pjmlp wrote: post #94

Earlier quoted context omitted.

On the contrary, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines And looking at other bytecode based systems, enough runtimes with multiple vendors. https://en.wikipedia.org/wiki/Bytecode

I don’t know, I feel myself shifting the goalposts here, but at the same time, I don’t feel I’m unjustified in doing that. You’re probably not going to complain that the list of JVMs you linked is incomplete, even though there are probably small-scale JVMs in SIM cards and other such minuscule environments that are not listed there, and those could easily be something entirely unique that was written by a couple of g…

So if it is about shifting the goalposts, bytecode based environments, multilingual as well, exist since UNCOL became an idea in 1958.

https://en.wikipedia.org/wiki/UNCOL

Plenty of history lessons available on digital archives, for those that care to learn about them.

As for "single vendor", it isn't as if as usual only a couple of big shots aren't driving the standard.

Re: When Is WebAssembly Going to Get DOM Support?

#185

Post by renox »

adastra22 wrote: post #174
renox wrote: post #173

Earlier quoted context omitted.

What I mean is that portable execution is only a very small part of 'good' SW: you need also security, i18n, a11y etc.

All of that exists at a way higher level. It's like saying ELF binaries don't provide good i18n or a11y. I don't even know how to interpret that.

Sure, but as a 'dream' portable executable is kind of funny when execution by itself brings you nothing (except heating the CPU), you also need portable IO, security, i18n, a11y..

Re: When Is WebAssembly Going to Get DOM Support?

#186

Post by serbuvlad »

jauntywundrkind wrote: post #178
serbuvlad wrote: post #171

Earlier quoted context omitted.

My point is that that's exactly the deployment model of Docker. So if I have 20 apps that are a Go binary + config on top of Alpine, that Alpine layer will only exist once and be shared by all the containers. If I have 20 apps that depend on a 300MB bundle of C++ libraries + ~10MB for each app, as long as the versions are the same, and I am halfway competent at writing containers, the storage usage won't be 20 * 310M…

> "Ah, but each container will run it's own separate runtime process." Sure, but the most valuable resource that probably wastes is a PID (and however many TIDs). Processes exec'ing the same program will share a .text and .rodata sections and the .data and .bss segments are COW'ed. In terms of memory footprint, I can allow that the OS may be smart enough to share a lot of the exec'ed process if it's run multiple time…

If you want small function-style services then yea, that's valid, because p_i is really small.

The question is really if you want hundreds of big and medium-sized services on a server, or tens of thousands of tiny services. This is a design question. And while my personal preference would be for the former, probably because that's what I'm used to, I'll admit there could be certain advantages to the latter.

Good job, you've convinced me this can be valid.

Re: When Is WebAssembly Going to Get DOM Support?

#187

Post by 3cats-in-a-coat »

apatheticonion wrote: post #68
3cats-in-a-coat wrote: post #50

Earlier quoted context omitted.

Give me one thing that your theoretical WASM can "revolutionize". Aside from more efficient covert crypto mining on shady sites.

High performance web-based applications is pretty high on my list. Low memory usage and low CPU demand may not be a requirement for all websites because most are simple, but there are plenty of cases where JavaScript/TypeScript is objectively the wrong language to be using. Banking apps, social network sites, chat apps, spreadsheets, word processors, image processors, jira, youtube, etc Something as simple as multith…

But... we already have all that.

Multithreading could've been a bit more convenient, but if you want it, you can get it. Don't tell me those revolutionaries that want to revolutionize the web give up so easily.

Re: When Is WebAssembly Going to Get DOM Support?

#188

Post by 3cats-in-a-coat »

tpm wrote: post #71
3cats-in-a-coat wrote: post #50

Earlier quoted context omitted.

Give me one thing that your theoretical WASM can "revolutionize". Aside from more efficient covert crypto mining on shady sites.

With access to DOM it could run with no (or just very little) js, no ts-to-js transpiler, no web-framework-of-the-month wobbly frontends perpetually reinventing the wheel. One could use a sane language for the frontend. That would be quite the revolution.

You already can do that. You need a tiny shim and you can forget it's JS and use all WASM.

Re: When Is WebAssembly Going to Get DOM Support?

#189

Post by bdhcuidbebe »

immibis wrote: post #161
octopoc wrote: post #111

Earlier quoted context omitted.

You know what would be cool? A built in way for your browser to automatically download and run local-first software as a docker container, in the background without user confirmation. The problem with that idea is docker isn’t as secure as wasm is. That’s one big difference: wasm is designed for security in ways that docker is not. The other big difference is that wasm is in-process, which theoretically should reduce…

That wouldn't be cross-platform. Browsers couldn't even ship SQL because it would inevitably tie them to sqlite, specifically, forever. They definitely can't ship something that requires a whole Linux kernel.

> Browsers couldn't even ship SQL because it would inevitably tie them to sqlite, specifically, forever.

Nonsense.

Chrome store their sqlite db in C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default\databases

And Firefox:

> Why Firefox Uses SQLite

> Cross-Platform Compatibility: Works seamlessly across all platforms Firefox supports.

https://www.w3resource.com/sqlite/snippets/firefox-sqlite-gu...

Re: When Is WebAssembly Going to Get DOM Support?

#190

Post by [deleted] »

9dev wrote: post #105
austin-cheney wrote: post #59

Earlier quoted context omitted.

The biggest problem solved by WASM is runtime portability. For security reasons many users and organizations will not download or install untrusted binaries. WASM provides a safer alternative in an often temporary way. The universal nature is an unintended byproduct of a naive sandbox, though still wonderful.

Why would WASM be any less secure than JavaScript?

[deleted]
Post reply on HN