Build Your First Thing with WebAssembly | Hacker News Reader

Build Your First Thing with WebAssembly

cultureofdevelopment.com

195 pointsNickLarsen56 comments

Nice investigation! A minor point about your description of wasm: "WebAssembly or wasm is a bytecode specification for writing performant, browser agnostic web components." The term "web components" already has a pretty specific meaning referring to the in-progress specs for custom html ui elements and surrounding technologies (see https://developer.mozilla.org/en-US/docs/Web/Web_Components). You probably don't want to overload that term given how close the domains already are.

That's fair. Originally asm.js was named capsule.js but that was taken and didn't really mean what it was. We could also call it modules but there is another very related spec out there for that as well. What would you call it instead?

Object files?

https://en.m.wikipedia.org/wiki/Object_file

Of course the term "object" is confusingly overloaded too...

web object file?

Not like anyone aside from Apple uses WebObjects seriously anymore...

I believe "module" in classic Javascript already corresponds to a "self-contained" Javascript file.

How about a "Web Assembly Module Object"? I don't know if that is technically correct, but it does let you call them a "WAMO" file.

code components?

OpenDoc used 'part'. IIRC, all parts had a presence in the GUI, though.

This, I think is just a library or archive (in the ar/ranlib sense; https://sourceware.org/binutils/docs/binutils/ar.html#ar) of code that the browser loads over the Internet.

Java hit a jackpot calling such a thing a jar, a word that is both shorthand for "Java archive" and a noun describing a container. That suggests looking at words such as 'bottle', 'box', 'cask', 'pot' (nice word, but its connotations do not make it a winner), 'cup', 'amphora', 'pithos' (not well-known enough, and typically unmovable), 'crate' (taken by rust), or 'vase' but I can't find a nice alternative interpretation as an abbreviation ('Jug' has a 'j' that could mean JavaScript, but I think we would be looking for something with a W for 'web' or I for 'internet') or even something that sounds good ('crate' is growing on me, but already taken by rust. That shows that other terms might grow to become acceptable, too. Maybe 'jug' could be such a word?)

Plus jug will give us great opportunities for immaturity, like hey Bob, can you take a look at my jugs? Are my jugs too big?

I'm not sure if that's a plus (because I think it's hilarious) or minus (as a top-heavy female developer.)

Have an upvote and a ಠ_ಠ.

It's interesting that the discussion in this thread centers around what to call modules, components, and packaging units. It's like saying that JVM bytecode is a way to author JARs, when it's actually the other way around: JARs are a way to package classes packaging JVM bytecode, which is a compilation target for various languages. WASM is similarly a compilation target for code; whether it's a module of code or a capsule of code or a script tag of code isn't really the point, and "source code" remains an uncountable noun (http://www.edufind.com/english-grammar/countable-and-uncount...). And that it's supposed to be browser-agnostic is cool, but surely the bigger picture is that it's source-language-agnostic.

Initially my thought was to compare it to the first compiler, back in the days when punch cards were the interface, but I decided against any history lessons that go that far back. In that analogy, the byte code is the machine, and now we all need to be writing compilers for it. This is why so many languages compile to javascript, it's the assembly of the web (not my trademark), in the browser world at least. If you want this code to run in that browser, you gotta pay the penalty of cross compilation inefficiency.

I actually think being browser agnostic is more important; it is sort of the reason we're even looking at wasm replacing asm.js in the first place. asm.js is still javascript, even though it gets handled differently under the covers. Having a second option of language supported by all major browsers is a huge deal, especially one with static typing.

As for the naming thing, a little bit of bikeshedding is healthy from time to time.

We've been calling them modules, but I'm not certain that's what we'll end up with.

Also, there's a reason the description is a bit fuzzy on the WebAssembly landing page. It's not just a binary format (in fact, we didn't have a binary format for a while after we started). I like to think that it's a specification of execution semantics that can be expressed in many different formats (text, binary, AST, etc.). Not sure that's the easiest way to explain it though.

Sounds like a processor to me, let's just call them kernels.

Web libraries?

It's already a confusing mess, and you aren't getting that genie back in the bottle. "Web Assembly Component" would probably be the best compromise.

I suspect webassembly will fail miserably. If it succeeds anywhere it will be for gaming applications. I could be totally wrong, but most web developers who build applications and sites will not be likely to embrace this given the leverage JS provides and the simplicity of use.

Again, I am not extremely against wasm, but this writeup is pretty well done and my take away was that it was non-trivial to pickup, buggy and has poor documentation. I am curious who web assembly is for and who is really excited about it. Is it gaining traction in gaming, and also what am I missing(serious)?

edit: Can advertisers bypass content blockers by compiling to wasm?

The idea is that we will be able to write web applications in a sane, proper language like C# or similar, and then compile to Web Assembly. I, for one, embrace this idea whole heartedly.

I can respect that. However, my point is, are you a web developer who primarily writes code for the web at your day job. Anecdotally, I haven't seen a lot of overlap between people writing web applications and C# developers. I have seen a lot of C family devs think this is awesome, but have no plans to actually develop directly for the front-end web.

edit: the first major demonstration was Unity's angry bots according to Wikipedia. So it appears this is for game devs, and game developers who want to build for the browser will be excited about this. I just think webassembly to be really far down on the ist of improvements we should make to the browser.

I would rather have a permanent top-level tracking banner section built right into my browser as long as I don't have to write JS anymore. It's very high on my priority list.

Web Assembly is exciting to me precisely because I'm not a web developer, and the whole idea of being a web developer as distinct from any other kind of developer is a bit absurd, especially considering the ubiquity of the web and the fact that it basically means you're a JavaScript programmer of some variant. Your language choice shouldn't determine your infrastructure.

> You language choice shouldn't determine your infrastructure.

Of course. I am a js dev and work mostly with nodejs. However, I would push back here and say that JS is the only real choice for web development as you must code for a browser which most often interprets html/css and js. So not surprisingly, and especially with the proliferation of nodejs, all the people writing code for the web are javascript programmers. React, Angular, VueJS, Meteor ect all provide rich javascript frameworks/libs for writing web applications and a full stack can be written with a single language.

My point is that asm.js seems to provide a lot of leverage as an option and internet speed and machi ne resources also are improving. I would not say that the web, the browser or the current situation is ideal-- far from it, but webassembly seems like a very small improvement patch. It basically allows games devs who want to code specifically for the non-mobile browser to have slightly better performance by learning a very obtuse new language paradigm that is brand new.

- It doesn't improve on marking up apps in IBM markup language from the 60s which was originally developed for research papers.

- It doesn't improve security. I think it may actually be net bad for security given the obfuscation.

- It is targeted at a very narrow community

- It is largely embraced and championed by people who do not currently write web apps. It is unclear if their enthusiasm will carry over to them actually coding in it.

The web ecosstem is horribly broken. I would love something as innovative as javascript to come along again, when Eich put Scheme into the browser people were very excited. They could do something new and 10x better than previously possible. Given that there are such glaring problems in with the web right now (and I do admit performance is one of them) this marginal improvement, if indeed it proliferates and in fact does improve things, seems so minimal at a pretty steep cost to learn it, that I don't find it exciting and expect it to have virtually no impact.

They should do so much more than this. Imagine even if browser companies put a python or ruby interpreter (or even a native c++ one) into the browser. Imagine all the possiblities of adding natice scss support, limiting or removing very old unused feature support and refactoring the codebases. ect. Imagine not using 1960s era research paper syntax to write a web app. There is so much room for improvement that making something that requires me (and so many others) how to write applications for very little benefit will be met with crickets. or extreme enthusiasm from people who don't write web apps and never will, but find it reminiscient of their mem-mgmt c-like language they use for mobile or systems programming.

You could say the same thing about any assembly language though. But they are still important, even if only a few people need to truly master them. The main advantages web assembly should provide are that it be a simpler target for compilers, minimizes overhead for doing so, and that its performance be independent of that of a higher-level-language like javascript.

All the things you want require a standardized, performant web assembly to meaningfully and portably implement.

We (at Stack Overflow) have a new documentation product coming down the pipe with an emphasis on examples and I thought it would be awesome if we could expand our stack snippets feature to languages beyond javascript. A reproducible example right there on the webpage. In researching existing solutions, nothing was satisfying, and then I had the idea to just use asm.js and write an MSIL interpreter. I spoke with some people familiar with asm.js and decided that it wasn't particularly difficult, but it had a ton of limitations from js file sizes to ways to get all of the libraries people ask about uploaded, and of course regular breaking changes in the browser. Wasm seemed like it could help with some of the issues being a formal web specification with representatives from multiple browsers.

Other than that, I can see a lot of uses for it, from small neural nets in the browser to high performance applications like photo editing, and of course gaming. It might not be for all applications, but it certainly has a spot.

Nick,

Great writeup. I am a big proponent of the idea of webassembly as I believe many are. The browser is one of the greatest apps, and it is easy to look past many of its flaws because it provides a universal environment to develop for. I have always been a harsh critic of the balkanization apps provide when they are unneccessarily trying to extend functionality already provided by the browser and live natively on my device providing virtually nothing but more access to "my" resources.

That said, while I don't love writing apps in an old IBM GML and pulling in heaps of scripts to get the functionality I need, it is easy and well understood (which is why it has proliferated). If we are to change this, I think an entirely new paradigm would be easier to use and embrace than something like wasm because the browser has a lot of access to resources and this has a fairly narrow use-case relative to it's complexity.

I could be wrong, as this technology is super nascent and people as intelligent and synonomous with the web like BRendan Eich are openly supporting it, I just don't see it being embraced at the sort of tipping point neccessary to proliferate.

It will be very hard to build a community of people doing things like you have here: providing great resources and tutorials and a community of code base to build on. A new standard or tech must be 10x better than the current one and I do not feel this is.

WebAssembly will eventually have access to the same APIs as JavaScript does now. Then it's just a matter of using an ES2016->wasm compiler rather than an ES2016->ES5 compiler.

Also you can't trivially copy/debug a web component built using web assembly(so far) and play with it which is kinda a death sentence for any tech on the web unless it's championed as being a killer tool for some usecases-which this doesn't seem to be so far

I suspect wasm is a long-term bet on the part of web advocates (including Google and individuals like Eich) to ensure the web remains center stage in the age of mobile native apps that sit on top pretty powerful mobile hardware. As I understand, it's essentially asm.js repackaged in a more formal, standardized manner and has already gained support from all the major browser vendors.

Once integrated properly in desktop and mobile browsers (maybe two years from now), it would probably reduce most of the "useful" performance lead that native apps have over web apps. But, it's still a bet - because of course, no one really knows for sure what things will look like two years from now.

> I am curious who web assembly is for and who is really excited about it.

In particular, I'm curious what web assembly is supposed to be offering that Java applets didn't.

Java applets ran through browser plugins that sidestepped the sandboxed browser environment that keeps users secure on the web. This would be an assembly level compile target for the Javascript VM instead.

How about not requiring a plug-in?

What's the difference between doing a lot of browser development work to add a web assembly VM, and doing the work to add a JVM?

The WebAssembly VM is already there. It's the same VM as is used for JavaScript.

Speaking as a front-end-heavy developer (but someone who knows quite a lot about the back end too), the ideal of WebAssembly definitely excites, but the bridge to actually engaging with the technology is too cumbersome to actually do anything with it yet.

My take is two-fold. First, the tooling needs to mature. Second, a community of more hard-core developers (i.e., those who work regularly with C, C#, C++, etc.) needs to crop up.

Without those two things, I think you're right, it will never take off. But my bet is that both of those things happen; larger companies will at some point bank on it, and throw a bunch of tooling and development resources at it. Just a guess.

It's not even released yet. Of course it will be buggy and poorly documented.

On one hand, I want to bash WebAssembly because it takes away our ability to see what we're running on our own PCs. On the other, it helps us slowly get away from the mess that is modern JavaScript.

Totally agree. I really think it's important for the community that there be a easy, free, and open way to view the source code (or some readable not obfuscated version) of any site.

Yes, definitely use source maps in all of your JS.

With Javascript build tools and minimisers, it's already usually impossible to understand what you're running.

I think "this javascript mess" is largely bourne out of an attempt to mitigate content blocking. asm.js is pretty fast and I am not sure how much improvement wasm will provide, but if given access to more of the low-level environment I am concerned advertisers will implement maliscious code and pop-ups in wasm that is non-trivially blocked.

It's the same VM as JS, so why would it be any less secure?

I am not sure exactly how it can be implemented, but I imagine that compiling and serving a binary file could allow for some maliscious things. My biggest worry is that many content blockers override js and search scripts for keywords and functionality which they muitigate. I could see a binary file executing code which provides pop-ups, advertisements or drm which would be harder to eliminate than it is now.

I am not 100% sure if this is true, but it seems possible.

Serving a binary file is in principle no different than serving a string file. What can be done with WebAssembly today can most likely also be done with asm.js.

Thanks for the writeup! I had a hard time figuring out how to compile C++ to WebAssembly a couple of weeks ago and finally gave up given the lack of maturity of the implementation. I am sure this will help more people get interested in WebAssembly!

I had the exact same problem when I first started. Someone once told me "what we can throw away to solve this problem", so I kept removing parts until I got here which I think is currently the easiest way to get started.

Ultimately you should be able to use your C compiler and generate wasm files directly, rather than go through asm.js.

There is an experimental backend of LLVM that you can try, but it will require building LLVM from source currently. Emscripten has an option to do this automatically, I believe.

You can also write the AST format by hand, which IMO is much easier to do than writing asm.js by hand, just more verbose. I wouldn't advise anyone do this, as the format has been changing over time.

Finally, there is work on specifying a true "text format" that is meant to be used with view-source and directly maps to the binary format. You can see some proposals if you look at the pull requests in the design repo. When a proposal is accepted and we implement the tooling, you will be able to generate a binary directly from this format, which will be much nicer.

I'm familiar with the LLVM direct to wasm tool, but I was unable to get it working using the steps from the emscripten docs. The binaryen toolchain is pretty easy to digest, but I've been using the emsdk almost exclusively for the convenience. Once you have to rework part of it from source, I just don't know enough about it to debug it yet.

Thanks for the info on where to find outstanding proposals.

Hey, the intermediate language is actually a nice step up from JS.

Huh, the AST looks pretty human readable. Anyone have tips for writing WebAssembly without using asm.js? Even a pointer to decent documentation would be great.

Well, if you're comfortable with that AST text-format, check [1] for docs and examples (the .wast files in the links). If you're super brave, there's hints about the Binary AST format here [2]

[1] https://github.com/WebAssembly/design/blob/master/TextFormat...

[2] https://github.com/WebAssembly/design/blob/master/BinaryEnco...

github.com/WebAssembly/sexpr-wasm-prototype

github.com/WebAssembly/spec

github.com/WebAssembly/design

See my comment above, ultimately you should be able to generate WebAssembly directly from your C compiler (and other languages too). You can write it by hand as well, but that's not the primary goal of the specification.

We should have a text format soon too, which will be nicer than the AST format to read/write by hand.

This is super useful and helpful, thanks for writing it up!

I have a problem with making designing websites more complicated. This snobbery of finding a new complex way of doing something that should be made easier... not harder.

If you understand the problem - that a dynamically typed, interpreted language has performance issues that prevent it being useful in computationally intensive scenarios, but can't be replaced easily - then this solution is actually quite reasonable.

I still see a lot of misunderstanding here about what WebAssembly is. It's not really a "bytecode" like JVM's. The best simplest way to describe it is a virtual ISA for compilers to target.

So the languages that make use of it will be compiled languages like C, C++, Pascal, Fortran etc.

Reply on news.ycombinator.com