Hacker News Reader

Comment by be_erik | Hacker News Reader

This is absolutely incredible. I never thought this would be possible-- wasm opens a new phase of software development and deployment.

View on HN

Yeah, right.

As if Flash (http://adobe-flash.github.io/crossbridge/), PNaCL (https://developer.chrome.com/native-client/reference/pnacl-b...) never existed.

Wasm is company and technology independent and went through the proper process for becoming a standard rather than being forced in by some corp hoping to take over the internet.

It also doesn't have any of the security issues because its limited to things JavaScript can do.

Both alternatives that I mentioned, Flash and PNaCL did have open source implementations available, it is just a matter of following the links I posted.

WASM doesn't offer any security over internal data corruption as buffer access within linear memory aren't validated for data bounds or nullability.

So it is possible, for a WASM module generated from C or C++ code, to provide input data to its functions in such a way that it would compromise its behavior from the outside, even though it doesn't escape the sandbox.

Politics.

> Both alternatives that I mentioned, Flash and PNaCL did have open source implementations available, it is just a matter of following the links I posted.

At least for Flash I remember that the OSS implementations couldn't run many real-world flash programs. Did this change later?

It was good enough to run Unreal.

That's slightly interesting. But it doesn't change the fact that some programs fail to run on the open implementations. And why is that? Presumably it's a secret. This unknown difference in behavior is significant, even if the actual difference is small. It means one can intentionally write a program the only runs on proprietary implementations.

Wasm linear memory is a building block, if you want higher security boundaries, stitch together multiple Wasm envs and communicate via webworkers.

Wasm is nearly identical, but different in the ways that matter. You are being blinded by being ahead of the curve, but the curve has moved now.

I am eagerly waiting for the first set of CVEs related to WASM, and the "you are holding it wrong" comments from WASM advocates.

It would be interesting to force Wasm through an asm.js polyfill for non tier-1 trusted sites. Then one would have higher assurance that malicious Wasm couldn't do anything that js couldn't do.

Wasm will be absolutely pervasive at all levels of the stack.

> .... will be absolutely pervasive at all levels of the stack.

Yeah, I heard that before.

> Both alternatives that I mentioned, Flash and PNaCL did have open source implementations available, it is just a matter of following the links I posted.

You know that open source is not the same thing as open standards, right?

CrossBridge is a cross compiler. Where is the open source flash runtime?

GNU Gnash and Lightspark.

Or just use regular Vim and not think that everything needs to run inside of a web browser, especially if you value user privacy and computer resources.

Would be nice to be able to use vim (or any other editor of your choice) in web text boxes.

There are browser extensions that offer this. E.g. the excellent Tridactyl for Firefox lets you pop up a gVim window for any text box if you press Ctrl+i.

This has been possible for years with Vimperator and then Pentadactyl. Unfortunately it's awkward and can't take advantage of text fields with real time JavaScript processing (e.g.: Gmail, Markdown preview).

There is surfingkeys for chrome. You press `shift+I` to go into into insert mode.

[surfing keys](https://github.com/brookhong/Surfingkeys)

This is the logic that makes everyone move their workflow into emacs. A lot of what we do is text editing, so having a good text editor everywhere makes sense. Some programs like mutt can also drop in to your editor of choice when composing an email. Imagine if we all had vim for typing up these HN comments. I'd like something like this to be more feasible. Maybe there could be a standard for forums that gives you vim editing in the same way many give you markdown. It could also be cool to support org-mode syntax.

Imagine if programs knew how to interact with one another and could plumb data between them instead of everything living in one monolithic application.

Or use emacs.

Don't immediately hand wave away the value of these sorts of things. I don't think anyone would use this as their primary editor, but I'd love something like this in our merge request / code review process, as that's currently entirely browser based already.

Makes more sense for that process to move to the editor than for the editor to move to the browser. That way you keep all your plugins and whatever other context the same regardless of what you're doing.

There is some benefits you may not see atm...

I'd love to have my VIM with my config just available as a web service to use it on every device! That's what I already love about NextCloud and the likes - just one install and every device can access it. If you know how you can also make it secure enough for every day stuff - I think to be really secure going offline is not enough anymore.

Exactly. The first question that came to my mind is: "are the keystrokes logged?"

I don't think that's necessary.

here's a VNC server in your browser:

https://github.com/novnc/noVNC

or an x window system tutorial, with an in-browser x server

https://magcius.github.io/xplain/article/index.html

personally I think this will lead to more hiding of what internet sites are doing, and prevent blocking of undesirable behavior.

The latency in Safari on a MacBook is better than VSCode. Which makes total sense, but is impressive and demonstrates how much better electron could be.

Probably next step would be to run nginx/node in browser!

This will enable doing full web development in browser only

I have seen a project which runs a js webserver in a service worker; it's not a terribly far-fetched idea.

Actually I wonder how hard it would be to run node in a browser, given that it's already JavaScript. You obviously have to have to implement some amount of API surface at a minimum and it's possible that browsers are geared to be servers and clients, but it certainly sounds plausible at a first pass.

Reply on news.ycombinator.com