Hacker News Reader

For years, I've laughed (from skull throne) at the "whyyyy no bytecode" posts on HN. Now bytecode, still complaints. Still laughing, too.

I never complained about no bytecode. And I'm not complaining about bytecode now. I'm complaining about an apparent lack of commitment to bringing any of these projects to a useful status.

Don't you think developer tools should have good UX, too? Microsoft does, and Visual Studio just works. Oracle does, and Java and Netbeans just work. Even setting up Node and NPM was a better overall experience than trying to get Emscripten working correctly and integrated into my projects.

Emscripten and NaCL are both like 4 years old now. Why hasn't there been greater adoption of these tools? I postulate it's the bad UX. I mean, Emscripten only working with VS2010, three whole versions behind latest, is a pretty good indicator that there is a whole class of users that have just written it off. Is there any concern for that with WebAssembly?

I know, I kid.

Things took a while because vendors had their own prior paths to pursue, while asm.js had to prove it could get close enough to native perf. (You could say Mozilla's prior path was JS.)

Tools for JS are pretty good; VS does TypeScript and JS, will do wasm. Firefox devtools are giving Chrome devtools a run for their (bigger) money.

I think tools are the least of it, while agreeing they make a difference (see Mandreel with VS integration, vs. Emscripten).

NaCl (PNaCl, you must mean) never went cross browser as such, nor could it. WebAssembly is the PNaCl end-game, and a pretty good one.

As for Emscripten, it's a huge win that both Unity and Epic (Unreal Engine) support JS/WebGL as first-class targets. This happened over the last few years, tools built into the game engines. Doesn't disprove your point, you could be right! Let's find out.

Hey Brendan, thanks for not flipping a huge bird to the web community and sticking with it.

For myself, I've had very little to complain about web development since '08 or '09. It became an application platform for me with the emergence of the canvas tag, and since then it has grown into a full operating environment of sorts. There have always been awkward and limiting features to the web because it is such a hodgepodge and I think that's where most of the complaints come from. But the browser compatibility situation continues to improve, which has always been my biggest gripe.

I worry a bit about the exploit potential of WebAssembly as more features are layered atop what Asm.js offers. Don't add too much, okay? ;)

Thanks, Ed.

I see any web-scale runtime standard inevitably having versions spread across the installed base of any server, so prone to the same pressure JS was, which led to polyfills, graceful degradation, object detection, monkey-patching in full. People who complain about this are complaining about physics.

You're right to worry about security, which is why the "MVP" for wasm is co-expressive with asm.js, just faster-to-parse syntax. After that, we must be even more careful.

Not to mention that you still have the option of using vanilla ES5 as long as you like (and it's what I'm doing until I can move to a VS version with built-in TypeScript/ES6/JSX support). That's one of the best things about working with JavaScript: nobody is going to stop supporting the older version anytime soon.

And great work, this is very exciting news.

That's true. I literally have 15 year old JS that still runs. It's not pretty, but it still works as expected.

>"Is there any concern for that with WebAssembly?"

Not really. NaCL was limited to a single browser, and asm.js was a stepping stone towards a bytecode for the web. WebAssembly has support from the major browser makers, plus a (mostly) clean slate for developing a bytecode suitable for the web. This is a golden opportunity for the web to evolve into a high performance application platform.

As for tooling, C# and Java are anomalies, no other languages come close. What sets those two languages apart? They're very popular in the commercial world, and they're based on virtual machines (C++ and JS may have decent tools, but I'd rather debug C# than, and part of that is the ability of the compiler to understand the program structure). A universally supported bytecode for the web is very likely to decent tooling.

I think the emscripten and NaCl (core) teams should concentrate on the tool chain, not on UI tools or IDE integration, IDE support is only useful with full debugger support, and that's a massive amount of work, and I guess every new version of Visual Studio requires a lot more work.

I spent a bit of time to write a set of python cmake wrapper scripts which make cross-compiling to 'esoteric' targets easier (see here: http://floooh.github.io/fips/), it doesn't solve the problem to directly develop/debug for emscripten or NaCl in an IDE, but it lets you easily switch between cross-compile-target configurations, with the idea that you write and debug your code as native desktop application in VStudio, Xcode or QtCreator (or any other IDE supported by cmake), and then only cross-compile to emscripten, NaCl or Android NDK on the command line. In my experience, 99% of bugs happen in the platform-neutral high-level code, and are caught by debugging the native desktop version.

My comments aren't about GUIs. A command-line interface is still a user interface. It still needs to be designed for the user experience. I count developers as a type of user, and just as much care should to be put into the discoverability, accessibility, and usability in the software that developers must use as is put into the software that end users must use.

On the command line I don't see it as an issue. Both emscripten and NaCl provide standard gcc-style cross-compiling toolchains that are easy to integrate with other higher level build systems. That's IMHO the only way that makes sense when providing a C/C++ compiler toolchain. The big missing piece in the puzzle is interactive debugging, hopefully with WebAssembly we also get proper debug information format (something better then source-maps), and can then debug-step in the browser through the original source code (this sort-of already works with emscripten since it can generate source maps, but it is quite rough for big scripts, and mapping back variable names doesn't work very well).

So I should give up on JS programming, go back to C/C#/C++/Java/Swift and have them generate wasm? Kinda sad, I like JS. But I like performance too.

Is there a possibility for JS tooling? Babel etc? Or any compile-to-JS language like CoffeeScript, TypeScript etc being able to emit/convert to wasm?

Or maybe I'm missing the whole point of this? :)

Chances are JS will remain a first-class citizen. WASM is just for those who would prefer to not use JS. Basically, if you like JS hopefully nothing will change for you, if you don't like JS you will have better options than cross compiling to JS.

Boy do I hope you're right! Performance is likely an issue tho. Wasm is designed to be faster, both loading/parsing and execution.

I did notice that es6 import/export works for Wasm, so I can write performant segments in C. Whew!

> Wasm is designed to be faster, both loading/parsing and execution.

If you want that from your JS codebase, I'm sure it would happily compile to Wasm - you'd probably find that a JS-to-Wasm compiler would be one of the first proofs-of-concept for Wasm.

This misses the division of labor behind wasm (and asm.js, and PNaCl). JS is a dynamic language, in full it needs JITting, speculative optimization based on runtime profile feedback, statically unsound type inference rescued by dynamic checks that have low-enough cost.

In contrast, wasm is for C and C++ first, and in due course many languages. The C/C++-first design point is a way of limiting scope creep and catering to important native-code use-cases (games, AI, CV, etc.). It's the starting point, not the final state. But it involves the usual static types trade-off that reduces runtime overhead.

Therefore a full JS engine in wasm would not run very fast compared to today's in-browser JS VMs, which are evolving to be JS/wasm VMs. For dynamic languages to compile to efficient wasm, we'll need the future JIT-generated wasm support and other desiderata on the roadmap. These come after the "MVP" that is co-expressive with asm.js.

So the proof of concept for wasm must start with asm.js and grow to PNaCl in full (which has had APIs and optimizations that asm.js or JS and the Web APIs have not provided yet), and then on to dynamic language runtime support. HTH.

That makes a ton of sense, thanks for taking the time to clarify.

No problem. I could go on (but should cut myself short to save time for other things).

Another dynamic language support part of wasm's roadmap that's post-MVP: GC support, both for GC of allocations from wasm code, and for references from wasm memory into the JS (DOM whatever) object space. One GC to rule them all, and one VM too.

> I just don't get how someone could have at any point said "yes, this is a good path, we should continue with this" for all these custom build systems in the wild on these projects.

I guess nobody ever said that. What people most likely were saying was: "This is a mess, but the expected costs of continuing this path will probably not be greater than the expected costs of changing course".

Note that there's a double "expected" in there. Making decisions under uncertainty is hard. On the other hand, taking a look from the outside and replacing every "expected costs" with whatever turned out to be the case is easy.

" I can't even get through getting Clang, LLVM, and Emscripten built from source as it is,"

I have no experience building emscripten, but clang/llvm, i do.

Clang/LLVM are really easy to configure using cmake on any platform, and the configuration process just works. So why don't we start with: "What is the exact problem you seem to be hitting in doing this"?

> braindead NPM dependency manager

Among all dependency managers I've used, npm is by far my favourite so this comment took me a bit by surprise. Which dependency manager do you like ?

NPM has a nice user interface, but having every dependency keep its own copy of its sub-dependencies is bad. What "npm dedupe" does to move modules up the npm_modules tree as long as version numbers don't clash is also incorrect. What should be done is to have the npm_modules directory have sub directories for each named module, then each named module have sub directories for each version that is required. Then, no module would ever have to have its own npm_modules directory and disk usage would be kept to a minimum. And yes, disk usage has been a problem on some of my larger projects.