Live data from Hacker News

What makes WebAssembly fast?

hacks.mozilla.org

191–200 of 238 posts

Re: What makes WebAssembly fast?

#191
post #141
post #24

Earlier quoted context omitted.

Is this universally true – i.e. baked in to the wasm spec – or is it just true in a browser environment? Consider things like NW.js[1] or Electron[2] – might we see cross platform apps being developed where all or parts of it are written in and compiled to wasm, then packaged up with a runtime and delivered as a "native" application for desktop, mobile, or whatever? [1]: https://nwjs.io [2]: https://electron.atom.io

What would be the benefit of that? Might as well just compile to native and distribute that without all the overhead, no?

I probably should have specified but I was referring to GUI applications specifically. For things without a GUI, or that require deeper system integration than you get with these runtimes you're absolutely right – there's little point. But for a very large class of GUI applications it makes a lot of sense, working with technologies that not only have stood the test of time and are good enough for plenty of use cases, but also mean you can with very little effort package your application for multiple operating systems. Some of these applications will need stronger performance than can be provided by the JS engine, so hence the question re: wasm.

Does that make more sense?

Re: What makes WebAssembly fast?

#192

When compiled from C/C++, does WASM do bounds checking of pointers and arrays? What kind of memory safety does it offer?

No, it's like a virtual proccess but with simpler memory layout. If you try to read or write memory outside of the allowed range it will trap (which is like segmentation fault on Linux) but it doesn't check any individual array for out of bound access because it doesn't actually know where are arrays in the memory.

Re: What makes WebAssembly fast?

#193
post #41
post #9

Earlier quoted context omitted.

WebAssembly won't give you unlimited power. You will still have the browser sandboxing and security / privacy policies in place. Accessing to the local file system is for instance constrained in the browser for good reasons. WebAssembly apps will be able to do what Web APIs let any page do.

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

Receiving megabytes of untrusted blobs of compiled code from websites? Perhaps even DRM encrypted? What could possibly go wrong.

At least js could be unminified and many standard libraries are somewhat trusted.

Re: What makes WebAssembly fast?

#194

What makes a compiled executable faster than interpreted code seems kind of self evident.

I see what you mean, but it's actually possible for JITed code to be faster than compiled code, as JIT can make run-time optimisations that aren't visible at compile-time.

True fact but not really useful if this only applies to 0.01% of the cases.

Re: What makes WebAssembly fast?

#195
post #166

Earlier quoted context omitted.

In all fairness, javascript should have never even been required to display a news article. Javascript makes up for a lot of the shortcomings of HTML.

JS isn't required to display a news article, and never has been. You can make a fast, beautiful and modern news site using only HTML and CSS, without a byte of JS. Take a look at the source for any molasses-slow news site. The only site-specific JS will be jQuery, and a few basic event handlers to do things like show and hide elements, which could have been done with CSS. 99.9% of the JS will be advertising, analytic…

And adaptive design, auto-complete, client side validation of forms, etc. But all of which should be handled by a better CSS/HTML

Re: What makes WebAssembly fast?

#196

My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript. Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iO…

Leading to real IDEs, real languages, real libraries.

downsides will be some proprietary solutions will crop up.

Re: What makes WebAssembly fast?

#197

Earlier quoted context omitted.

SPAs are still considered too fat. how do you miss the nearly daily "web bloat crisis" stories on HN?

You're probably access web sites sitting at home or office, where you have decent 10+ Mbps channel. All this changes when you travel and you use either slow public WiFi or phone tethering. Yes, there's 4G, but in most places in most countries 4G coverage is very poor: it's only in the most populated areas. I travel between countries and of course I hate staying in huge cities because they're expensive and noisy. But…

>>10+ Mbps channel

that's peasant level net :P. 100 or bust {literally what I have home and better at work). seriously though, indeed the web is overbloated and I don't think there is coming back

Re: What makes WebAssembly fast?

#198

What's the point if you can't interact with the DOM? Almost all examples of webassembly just render to a canvas. Does this mean instead of a normal "native app" I'm going to start getting C applications compiled with wasm and distributed in electron? What does this possibly gain the end user?

forget the DOM it's a steaming pile. In future we'll be thinking either rasters,vectors or something higher level like ratios and components.

Re: What makes WebAssembly fast?

#199

My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript. Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iO…

JS provided that already without WebAssembly, no?

Re: What makes WebAssembly fast?

#200

Earlier quoted context omitted.

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 suppor…

Thats not really what he asked though. If in the end a developer can work 98% in TS, do they really care if it runs as JS or something else if it solves their problems with the language ? I have heard from people that love TS, but surprisingly many that also prefer pure ES6 JS.

The only concerns I would have is I believe you have to debug the javascript rather than the typescript.
Post reply on HN