Hacker News Reader

> The subset of native (for example, x86) assembly that is equivalent to webassembly is already perfectly secure. You just limit the native assembly to pure computations without any system calls.

You need portability on the Web. NaCl was abandoned in favor of PNaCl for a reason.

No you don't.

The Web as a distribution method has supported the downloading of native applications since forever. Instead of trying so hard to make it so that users don't need to install native applications, then I think that it would be much more optimal if development efforts instead went into making the native installation-process much more streamlined. For example, browsers could have some kind of functionality that makes it so that end-users do not need to choose the correct type of executable themselves (such as choosing between x86-windows7, x86-windows10, Linux, etc) and instead just click a single installation button.

> No you don't.

How would we have made the 32-bit ARM-to-AArch64 transition if the Web were not portable? Remember that Apple cut 32-bit support very quickly, and no longer ships with it. For that matter, how could Apple have gotten away with shipping a usable browser at all on the ARM architecture in 2007, in the native world?

Remember that the x86 architecture is proprietary to Intel and is covered by a patent thicket. You'd be handing Intel a monopoly over the Web forever.

> For example, browsers could have some kind of functionality that makes it so that end-users do not need to choose the correct type of executable themselves (such as choosing between x86-windows7, x86-windows10, Linux, etc) and instead just click a single installation button

They've had this for decades [1].

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Us...

You use 32-bit ARM assembly on 32-bit ARM, AArch64 assembly on AArch64, and x86 assembly on x86. There is no handing over a monopoly to anyone.

While the mentioned browser functionality have existed for decades, then that does not change the fact that for the past decade then almost everytime I have had to download a native application I have had to select the correct type of executable myself. So the argument still stands. Developers should implement the mentioned functionality on a download page for their native application, instead of trying to make everything a web application.

I think that saying what someone should be doing is very short sighted, it's almost certain that they will not listen to you, especially since you're making their jobs harder and it's unsafe for the end user. Instead, let's focus on things that the developers actually want, like WASM, so we can have something decent out of it; dismissing it is definitely not going to help and WASM is already here to stay.

BTW how do you propose to safely run untrusted application with no built in support of parallelization in parallel, maybe even on multiple machines? How do you safely directly reference an object that is owned by another (again, untrusted) module, again, maybe even on a different machine (e.g. using RDMA through Infiniband)? These are just some of the possibilities that WASM is offering.

> While the mentioned browser functionality have existed for decades, then that does not change the fact that for the past decade then almost everytime I have had to download a native application I have had to select the correct type of executable myself.

Think about why that is. It's because Web site authors frequently don't "do the right thing", and they instead do what is most convenient. Following that line of reasoning, it is naive to think that Web site authors would have offered ARM executables at all back in 2007. That is the entire problem.

> The subset of native (for example, x86) assembly that is equivalent to webassembly is already perfectly secure. You just limit the native assembly to pure computations without any system calls.

Defining a subset of x86 that is well defined, secure, and doesn't subject your vendors to the AMD/Intel licencing duopoly, is worse than starting over with anything else.. There was even a bug quite recently about everyone misunderstanding the normal boot sequence instructions since 1980 (or so?) Then the other question is: why did you make it run so poorly on the newer mobile architectures?

It certainly seems like one could have chosen from among the existing llvm-ir RISC hardware targets and then made everyone implement an emulator.. But making a JS compatible target is accessing pre-existing emulators available on anything meant for an end user.

As a JS programmer, I don't really look forward to encountering wasm from others on sites. But I do like that I can try out any llvm language that I might be experimenting with in the web environment that I'm already familiar with.

I would never do wasm on a normal website, but it could make a lot of sense in an electron like setup. That might be a bit insane, but no more than using the Java VM was 10 years back, and without as much risk of lock in and extortion from a company like Oracle in another 10 years.

Even without other languages, it is a matter of time before my transpiler chooses wasm for me, as it is now a subset to be prioritized for optimizations across browsers..

There is no need to define anything new. Native assembly already exist for each platform.

A native assembly has the least access to a common cross platform environment of all possible languages.. So it doesn't seem like an explanation for anything being unnecessary.

The native assembly would obviously not be cross-platform... It would be native...

That sounds as unhelpful as the current random PC/Mac/"redhat" binaries floating around sourceforge like lost socks.

(That bits of your favorite assembly are floating around the web is a problem in my world that drags me down dead ends, not a solution to anything I want to do. Existing jar files on the other hand.. they are not great but often enough if I have the patience for Java tweaking.

AFAIK wasm will develop toward an open replacement of JVM that uses browser UX that has undergone some critical processes instead of the Sun's random idea UXes followed by attempts at alternatives.)

> I doubt that all of the web developers who have invested in becoming javascript "experts" want to see the ecosystem change and see all of their "experience" and "expertise" become worthless.

Can you expand on what you mean when quoting those words in this context? I can't put my finger on what point you're trying to make here.

I am just a bit biased when it comes to my perception of most javascript developers. I should probably have left out the quotation marks. That would have made the comment more focused. However, with that being said, then the point is, that I find that there are significantly more developers who identify as being javascript experts than there are actual javascript experts, and that both groups contribute to the inertia.

First time I read JS and inertia side by side. I heard/read way more often complaints about its speed...

> invested in becoming javascript "experts"

Why the condescending quotes? Are you somehow above a programming language?