Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

Post reply on HN
Print view View original

291–300 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#291

Post by fb03 »

aargh_aargh wrote: post #287
afarrell wrote: post #207

Earlier quoted context omitted.

Yes, but the existence of ssh on chrome makes it much much easier to teach a windows user how to try out the linux command line. PuTTY is annoying as hell to help a new person get working and they might not have enough space for vagrant+virtualbox.

Just curious - why do you think PuTTY is annoying?

I love PuTTY, but my best PuTTY is actually KiTTY, since it saves profiles in a local config file instead of the ominous Windows Registry. Much easier to move around :-)

http://www.9bis.net/kitty/

Re: Goodbye PNaCl, Hello WebAssembly

#292

Post by hashhar »

smitherfield wrote: post #208
krzyk wrote: post #203

Earlier quoted context omitted.

How is it better than WebAssembly?

It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.

That won't be platform independent though I think. WebAsm can run on ARM as well as x86 and even PPC.

Re: Goodbye PNaCl, Hello WebAssembly

#293

Post by dgacmu »

candiodari wrote: post #280
dgacmu wrote: post #152

Earlier quoted context omitted.

You can choose what kind of laptop you want. ChromeOS is one of the options, and security (+ trivial exchange-ability) is one of the selling points for using a Chromebook. I tried it for a while, but I'm too used to the Mac to have made the switch more easily, so I moved back. But I know quite a few folks who use and love them. Opinions, as I'm sure you can guess, vary widely. It was surprisingly not-bad, even for a…

I wonder about that. Can you use a mac laptop to write software for the Google infrastructure ? That seems unlikely, if only for the security implications (would apply to any laptop of course, nothing to do with macos or chromeos)

Yes. Remember, there's not really "the Google infrastructure" as some separate component. With a few exceptions, it's all One Big Repository (https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... ).

Google is a very large engineering organization, and (my opinion here, but one shared by others) recognizes that there's a lot of diversity in what engineers like for their workflow. There's obviously a set of standards for what you can choose from as far as laptops (since the company is buying them), but it's pretty broad.

Here's a Quora answer that goes into more detail: https://www.quora.com/What-computer-or-laptop-do-software-en...

You can read more about Google's security model in a USENIX ;login article from last year: https://static.googleusercontent.com/media/research.google.c...

(source: The above cited sources, plus I'm part-time at Google.)

Re: Goodbye PNaCl, Hello WebAssembly

#294

Post by camgunz »

roca wrote: post #182
bitmapbrother wrote: post #116

Earlier quoted context omitted.

How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's asm.js and Google's PNaCl. Also, the team working on WebAssembly are from Mozilla, Microsoft, Google and Apple. The real winner here are users because we now have a standard among all major browsers.

Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which…

There's no denying Mozilla played a huge role, but PNaCl was an critical step away from "JS as the bytecode of the web". That approach simply couldn't compete with mobile platforms running on (more or less) native code.

Re: Goodbye PNaCl, Hello WebAssembly

#295

Post by steveklabnik »

k__ wrote: post #46
sjrd wrote: post #17

Earlier quoted context omitted.

I don't think WebAssembly will become more common than JavaScript anytime soon. And even when it will be, it means the tooling will have become so good that you won't even have to think about WebAssembly. That will be left to the people who create compilers to WebAssembly. Hopefully you'll just use whatever language your org/team/etc. uses, and have it compiled to JS or WebAssembly as is most appropriate for said lan…

I guess the first ones jumping on the WebAssembly wagon will be Web developers, so we will probably get WASM modules written in languages they see appropriate, when JS doesn't cut it anymore. I guess it will be Rust or Go. Rust because of Cargo (for npm users a big +) and Mozilla (good marketing of Rust). Go because of Google (also a Web company with good marketing) and because I read some Node.js developers already…

Rust already supports compiling to wasm as well.

Re: Goodbye PNaCl, Hello WebAssembly

#296

Post by camgunz »

lmm wrote: post #239
pcwalton wrote: post #194

Earlier quoted context omitted.

It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.) What's not to like?

What do unsigned ints bring to the table? I'd use them in C to avoid undefined behaviour, but that's not a problem on the JVM. Value types sure, I guess, but they don't seem super important. Can't we just make DOM bindings for the JVM and reuse the huge existing library base?

Without unsigned types you have to use the next larger type and mask. It's ugly, a pain, and slower. You run into this problem a lot when dealing with binary data.

Re: Goodbye PNaCl, Hello WebAssembly

#297

Post by johncolanduoni »

_0w8t wrote: post #261
roca wrote: post #258

Earlier quoted context omitted.

That's true, although NaCl's design made that difficult because the native code sandbox had to be a different process so interacting with the page's DOM would have required IPC.

I am curious what made it necessary to run NaCl in a different process? I thought the main idea behind NaCl was to allow the same-process native sandboxes.

Probably for the same reason Chrome runs V8 in a different process: planning for inevitable vulnerabilities in the implementation.

Re: Goodbye PNaCl, Hello WebAssembly

#298

Post by johncolanduoni »

roca wrote: post #213
sangnoir wrote: post #212

Earlier quoted context omitted.

> Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard Google has been doing this for a long time, I doubt it's unintentional. If there is functionality that they want which is not standardized, they go ahead and implement it. When a workable standard is ready or detailed enough, they switch over to it. The earliest instance of this that I can recall w…

Sure but the asm.js/Wasm approach was always an option. They didn't have to go down the path they did.

Was it an obvious option? I don't think I'd give the asm.js and WebAssembly developers so little credit.

Re: Goodbye PNaCl, Hello WebAssembly

#299

Post by lmm »

camgunz wrote: post #296
lmm wrote: post #239

Earlier quoted context omitted.

What do unsigned ints bring to the table? I'd use them in C to avoid undefined behaviour, but that's not a problem on the JVM. Value types sure, I guess, but they don't seem super important. Can't we just make DOM bindings for the JVM and reuse the huge existing library base?

Without unsigned types you have to use the next larger type and mask. It's ugly, a pain, and slower. You run into this problem a lot when dealing with binary data.

You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?

I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).

Re: Goodbye PNaCl, Hello WebAssembly

#300

Post by johncolanduoni »

azakai wrote: post #133
__s wrote: post #129

Earlier quoted context omitted.

There's a high performance asm.js implementation of WASM (converting WASM to asm.js at runtime). ie if a browser didn't implement WASM, but had a JIT which executed asm.js at high speed, it could execute WASM at high speed

There isn't such a polyfill. There is currently no good tool to translate wasm into asm.js (or general JS) on the client. The best that exists is to run the wasm in a wasm interpreter, very slowly. In theory a translator could be written into asm.js, but there would still be wasm code that won't run fast, such as 64-bit ints, unaligned loads and stores, bitcasts, and other operations.

Yes, but emscripten can compile to both (with or without using the new native LLVM WebAssembly backend). It's stretching the word polyfill, but emscripten users have pretty close to a turnkey solution for producing code that detects WebAssembly support and falls back to asm.js.
Post reply on HN