Live data from Hacker News

What makes WebAssembly fast?

hacks.mozilla.org

101–110 of 238 posts

Re: What makes WebAssembly fast?

#101

Earlier quoted context omitted.

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.

Re: What makes WebAssembly fast?

#102

On one hand, I'm excited about performance improvements. On the other, I lament the fact that this will kill one of the best parts of the web: the fact that the source is sent to the end user instead of a binary. It now makes the code and how it works opaque, thus killing the spirit of innovation and learning.

This is the same situation we're already in with minification. The debugger can reformat or decompile it, and if you have source maps you'll see the original source, even if the original source wasn't even javascript.

Re: What makes WebAssembly fast?

#103

On one hand, I'm excited about performance improvements. On the other, I lament the fact that this will kill one of the best parts of the web: the fact that the source is sent to the end user instead of a binary. It now makes the code and how it works opaque, thus killing the spirit of innovation and learning.

The specifics of how this will work are not totally clear to me, but web assembly will have a text format that will be human readable and editable according to:

[0] http://webassembly.org/

[1] http://webassembly.org/docs/faq/#will-webassembly-support-vi...

Re: What makes WebAssembly fast?

#104
post #41

Earlier quoted context omitted.

Not a problem, we can just wait for the inevitable security vulnerabilities.

If it's "not a problem", it should be easy to write a Web page that opens calc.exe. Can you do that? Can anyone on HN do that?

I think the parent was joking.

Though there are people on HN who can do that, given some development time, like me.

Re: What makes WebAssembly fast?

#105
post #69

Earlier quoted context omitted.

> Nothing improved for me as a consumer Nothing to install, no updates, no license key, not tied to a machine.... ?

> Nothing to install Modern app stores like the Mac App Store make installing an one click affair. It will take me more clicks to login to their Word website... Also, "nothing to install" means "nothing to own". > no updates There will still be updates, only I won't be controlling them, and I wont be able to stick with an older version. Besides, it has been ages since updates for apps have been totally painless (e.g.…

None of these things are true about MS Office (native - not online 365) right now, which was the specific subject this sub-thread.

Re: What makes WebAssembly fast?

#106
post #74

Earlier quoted context omitted.

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.

Yes. People really hate JavaScript that much. ES6 brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.

Re: What makes WebAssembly fast?

#107

Earlier quoted context omitted.

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.

But webassembly will allow for typescript or you language of choice, c/c++ and rust first, and as the OP suggests others too.

Re: What makes WebAssembly fast?

#108

Earlier quoted context omitted.

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.

Typescript is a type safe language that "compiles" into javascript. The Microsoft implementation compiles on save, so you work in your file.ts and a program running somewhere fires when the file is saved and converts it to file.js which you would distribute.

I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers supported it as a built in language.

https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing...

If you watch the video, you'll notice the argument notation is name: type rather than type name. I think Anders is reminiscing about his Delphi days.

Re: What makes WebAssembly fast?

#109
post #76

Earlier quoted context omitted.

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Wild guess? Oracle with Java.

Java failed to be what JavaScript became for a number of reasons, but I think the primary was the fact that it never integrated with HTML as cleanly as JS.

It could have been JS, but it was strangled to death by Sun (on the client).

Re: What makes WebAssembly fast?

#110
post #50

> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly…

You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if man…

Can someone explain what the option is for accessing the dom initially? Is there some wrapper JS that will be needed to call into the wasm?
Post reply on HN