HNHacker News
TopNewBestAskShowJobs

pocketaces

2 karma · joined July 20, 2018

submissionscomments
pocketaces··on The future of WebAssembly – A look at upcoming features and proposals
The native assembly would obviously not be cross-platform... It would be native...
pocketaces··on The future of WebAssembly – A look at upcoming features and proposals
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.

pocketaces··on The future of WebAssembly – A look at upcoming features and proposals
There is no need to define anything new. Native assembly already exist for each platform.
pocketaces··on The future of WebAssembly – A look at upcoming features and proposals
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.

pocketaces··on The future of WebAssembly – A look at upcoming features and proposals
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.
pocketaces··on The future of WebAssembly – A look at upcoming features and proposals
I hope not.

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. It will also always be significantly faster than webassembly. When it comes to the security of system calls, then both webassembly and native assembly needs to make sure that whatever platform-calls that are available are secure. webassembly have no benefits over native assembly when it comes to this.

Also, I doubt that it will gain as much popularity as some people predict. asm.js (the "original" webassembly) has been available for quite a long time already (and the technology behind it have existed for very very long), and if it were going to create a flood of developers targeting it instead of using javascript, then I think it would have happened by now. Inertia when it comes to development tools should not be underestimated and 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.