Hacker News new | comments | show | ask | jobs | submit login
Sneak Peek at WebAssembly Studio (hacks.mozilla.org)
559 points by lainon 3 months ago | hide | past | web | favorite | 96 comments

I think WebAssembly is one of the most exciting efforts for the web right now, second maybe only to Houdini or IPFS.

I say that even as someone who works pretty much exclusively in Javascript now and who loves the language - a lower level format will be great for everyone. I can't wait for more native languages to start supporting it.

I completely agree. I remember all the years where the prevailing wisdom was "standard web byte-code isn't necessary/feasible/desirable/etc." It's nice to realize that such pronouncements aren't necessarily the final word. It turns out there is a way to give people the byte-code they always wanted.

(btw I know WebAssembly isn't, strictly speaking, byte-code. It's a compact binary encoding of an AST. But it has all the characteristics that people really cared about when they asked for byte-code: it's a low-level representation that is a good compilation target for compiled languages)

Yeah, I was one of the PNaCl naysayers. :) But wasm has different characteristics: (1) it has a forwards compatibility story because asm.js exists; (2) it's a custom IR that was designed from the ground up to not have undefined behavior; (3) it uses the Web APIs, rather than an alternate Pepper stack.

Issue (1)--the forwards compatibility story--is the tricky one. Was it necessary to have asm.js as a stepping stone, or could we have gone all the way to Web Assembly from the beginning? I don't know, and we might never know, but having asm.js around for browsers that don't support wasm certainly doesn't hurt.

Oh yeah, my post wasn't about PNaCl at all (I wasn't even thinking about PNaCl when I wrote it). It's very clear to me that wasm is a superior design compared to PNaCl, and I'm glad history went the way it did. :)

I was talking about about the sentiment that byte-code in general isn't necessary/feasible/desirable for the web.

Here are some example of the sentiment as I remember it. There was a lot of skepticism that it would be possible to design something that would be a better compilation target than JavaScript while still being fast, portable, and properly sandboxed:




Every year the page weight of JavaScript creeps up. And processors aren’t outstripping gains in bandwidth the way they used to. At some point the delay between first byte and first paint becomes noteworthy and it’s no longer a wait and see game.

The wasm guys may be right. Their predictions may have been accurate all along. But it may also be that we didn’t need this five years ago but we really do now.

It's not a binary encoded AST anymore, it's pretty much a stack machine (with constraints like .NET which allow for easy conversion to SSA)

Example: A Lua lexer, https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556...

It might be a bit early to claim success though. We're still basically waiting for some mainstream well-regarded adoptions and use-cases.

Not to say it's any less exciting in regards to it's potential. But it's important to keep expectations balanced by present outcomes.

The wasm folks will add gc, polymorphic inline cache, dom interop, some time soon. That will enable things like browser side Perl, Python, Go, Ruby, etc, without having to push the whole runtime.

Nonetheless, the bloat train will resume at that point. And, the frontend will start having the same amount of fragmentation as the backend.

Good news for us, though, is job security. The resulting complexity helps us, at least in one way.

Web apps will be on equal footing and fragmentation as the old client/server model (vb, powerbuilder, delphi, c/x11/motif, visual c++ / mfc, dart/flutter, etc).

What comes around, goes around. The cyclic nature is pretty funny.

> And, the frontend will start having the same amount of fragmentation as the backend.

Err, I think that boat has already sailed?...

E.g. Grunt, Gulp, Webpack, make, Parcel, Brunch, Browserify, etc, etc, etc.

As far as tooling, sure. But this will take it up a level to base language. Surely that's an exponential difference?

Frontend dev won't mean what it means today.

You mean like Dart, Elm, Haxe and whatever else already compiles to javascript?

Not sure any of those have the mindshare of the languages wasm will eventually enable.

> Good news for us, though, is job security. The resulting complexity helps us, at least in one way.

I don't think I despise an incentive as much as this one, even if it is a natural side-effect, not intentional. It's the reason why large and top-heavy bureaucratic organizations end up being a net-negative as a result of their structure. Despite their well intentioned attempts at 'fixing' the bumps in the road that natural free flowing systems generate, with top-down control and extreme risk management.

Instead of fostering common-sense and individual talent, it creates incentives and attracts people who care more about the organization itself, and their position within it, rather than the outcomes and value creation for which the organization was originally created.

Can someone link Houdini that OP is referring to? I'm having trouble finding it without context due to the ambiguous name

edit: is it this? https://github.com/w3c/css-houdini-drafts/wiki


Article talking about why Houdini is different from normal CSS polyfills: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...

And the related HN discussion (possibly a bit outdated): https://news.ycombinator.com/item?id=11357794

Yeah -- that should be the one they're talking about.

I haven't looked into IPFS in a long while. Is development going well? Has the userbase grown somewhat significantly in the past couple of years?

Development seems to be moving quite fast. I'm also seeing lots of third-party tools and services launching on top of it, which is very encouraging.

Glad to hear! I'll have to check back in on it this weekend. :)

I have to say I am pretty excited about WebAssembly.

I've been through many programming languages. C# might be my favourite and F# always seemed like it would be if I took the time to learn it properly but for quite a few years now, JS has simply had such gravitational pull that I felt like I had to go with it. And I have to say, I've learned to not only like but to love it. Save for the mutable data structures that it supplies per default, it offers solid functional programming features and the culture embraces those. Still, there are times where I wish I could use something else.

NPM features quite a few packages written in other languages, with JS "binaries" available which I think is pretty neat. To me, packages seem like a much nicer place to choose language rather than, say, per microservice. A parser might be much cleaner in some pure functional language while some I/O library might work better in something else. But there is still only a subset of languages that compile to JS and the quality varies. But with LLVM supporting WebAssembly, I can see a future where it truly becomes the global binary format. Which would allow you to either write a combination of desktop, mobile and web apps (plus backend) in any language of your choice. Or, easliy write different packages in different languages and combine them into one app.

> Or, easliy write different packages in different languages and combine them into one app.

Just because the binary format can be shared doesn't mean code easily can. There's a tradeoff between requiring lots of glue or sharing a common lib across the langs. Either way, in WASM's current state, only the raw memory is shared and the only types are numeric primitives that can be used to address that memory. How each language lays out, for example, strings may be incompatible and most of the time where I've had to combine WASM libs for things like strings, there is a fallback to C-style (null-term'd or passing the length around).

So, while the common binary format will help open new architectures to existing langs, combining code from different langs still requires manual work and may be underperforming due to requiring they speak to each other in the lowest common denominator of raw byte arrays. Maybe some group will step up and federate a new libc for the WASM generation (even if there's no code and it only defines memory layouts). Even other proposals (GC w/ records/structs, host binding, ref types, etc) that bring higher level features don't necessarily solve interoperability issues.

In practice, most WASM languages are going to want good interop with JavaScript, so if nothing else is done, I expect that would become the standard for foreign functions, much like C FFI is on the desktop. For example, look at what Rust is doing [1].

For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings aren't perfect (I prefer how Go does it) but they're usually good enough.

[1] https://github.com/koute/stdweb

> For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border?

This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").

> That has overhead.

Yeah, but if those strings are destined for, say, the DOM, in such a way where you're going to constantly mutate little bits of the string while it's in the DOM, then it's probably less overhead to keep the string as a foreign object handle that you can send commands to from WASM to modify the string in place in JS VM memory, than it is to keep the string in the WASM memory buffer and "blit" it to JavaScript land whenever you change it. (Consider: how would you implement something like the Atom editor in WASM with as little additional overhead as possible?)

Also, maybe this overhead can be reduced. Picture an enhanced ArrayBuffer type specifically for WASM to use, that acts like virtual memory, with an MMU API attached to map Javascript objects into it—facilitating a kind of DMA. Or, allowing you to define "IO ports" in the memory space that WASM can write to to generate Nagle-chunked message events for JS-land, and which will appear to JS-land as a Javascript Service Worker endpoint that can be addressed with messages that will be turned into a buffered stream of bytes WASM can pull out of the same IO port.

> it might be nice to use JavaScript strings directly, without needing to convert them at the border?

JavaScript strings are UTF-16, which is incompatible with most languages. How the strings are stored internally as bytes is different for different browsers (e.g. optimisations for const strings, short strings, ascii only strings, string buffers).

The best you could get would be an API for a "string object".

Bytecode formats as portable binaries have always been a thing on the mainframe world all the way back to the 60's, it has just taken quite a few decades to become commodity across mobile, desktop and web worlds.

Even GPU drivers compile shaders to the respective internal architecture of the GPU. Only desktops, laptops and commodity servers have managed to get stuck with x86 backwards compatiblity. It's probably rooted in microsoft's dependence on intel but nowadays even microsoft has a cross architecture SDK (UWP).

Googling this only turns up Java...

Then you need to improve your Google-fu.

Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM Language Environment, ...

Also Oberon SDE...

Indeed. AKA slim binaries.

If available it's better to use instantiateStreaming [0] for faster compilation, e.g. this:

    fetch('../out/main.wasm').then(response =>
    ).then(bytes => WebAssembly.instantiate(bytes))
could be expressed as this:

    fetch('../out/main.wasm').then(response =>
[0]: https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

Wouldn't that still require `response.arrayBuffer()`? For ex (line 2):

    fetch('../out/main.wasm').then(response =>
Otherwise it could just be:


I came here to complain about it being yet another standalone app.

I came back, after RTFA, to say that I'm pleasantly surprised that it runs completely in the web browser.


Funny. I came here to complain that it's not a standalone app and yet another crappy browser app.

I also would prefer standalone apps, but if my choice is between a browser app and a "standalone app" made with electron, the browser app wins in a landslide.

With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The standard does expect it to be ported natively to platforms eventually.

It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)

> It would be quite interesting when Browser Apps could also run as native apps without relying on electron (ie, being able to pull up their own UI when not provided one)

What do you see as the advantage of native at that point - having its own window?

Electron is basically a standalone browser tab. This is quite resource expensive.

If WASM apps simply use their own rendering, ie the Qt Toolkit they get a much more native feel on top of having a rendering engine that is more optimized for out of browser use (due to not having a DOM, etc.)

It would also slim down the applications a lot, notably when you dynamically link against the toolkit (which also means you share the lib with other apps instead of every app having it's own copy of electron)

Most likely filesystem access and other native features like desktop notifications.

Then there is the efficiency. My suspicion is that electron has a completely misconfigured caching system. Usually only one browser is running on a system and therefore many applications share the caching system. This means each electron application has an oversized cache that wastes memory and disk without meaningfully increasing performance.

so is web or electron more efficient?

Also, web now has desktop notifications - right?

Being able to use it without internet connectivity, as well as the local file system access and efficiency gains that another commentor pointed out.

When did Electron even enter the conversation from Mozilla's side? It seems like people are inserting that detail entirely on their own.

My principal complaint was going to be "why not a plugin" to the various editors that already exist (eg. VSCode, Sublime, Vim, etc). I saw the screenshot and thought, ugh, YAEA (yet another electron app).

The goal of the project is to help you "learn and teach others about WebAssembly", so it's more of a fiddle environment than an IDE.

This is how it should be, if one wants to build an application out of the Web stack, then please use the browser I already have installed and provide the best UI/UX within those constraints.

You've clearly never tried to support more than one browser.

That's the big benefit of Electron packing its own browser: you know exactly what engine it's running in and which version of said engine. It's not dependent on what the user wants to use, the last time they updated it, etc.

Are there downsides? Sure, but the upsides vastly outweigh them for most users.

> You've clearly never tried to support more than one browser.

Why do I keep seeing this style of comment on HN lately? Someone expresses an opinion about software architecture and someone begins their response “obviously you have zero experience working in this domain...”

It’s such an insulting way to start a conversation. And quite often a false assertion.

It seems like it’s becoming more and more toxic. It’s a place to get your product or project criticized and reduced to the sum of its parts, rather than support.

Well, criticism and reduction are both constructive though.

Baseless assertions about someone’s experience are just bullying rhetorical flourishes.

> You've clearly never tried to support more than one browser.

Sure I do, all the way back to when CGIs were still a thing, that is what Web development is all about.

It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards.

Anything else is just being lazy at user's expenses.

Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version.

> Just imagine game developers shipping a GPU with their game just to be sure it is the same OpenGL version.

Electron apps aren't shipping you hardware. I think the more apt analogy would be installing a specific version of DirectX with your game... which a lot do.

Ultimately, I'd rather a company/developer spend more time actually building a better interface/product rather than perpetually fixing browser compatibility bugs.

> that is what Web development is all about.

While fixing bugs and dealing with compatibility issues are part of building any software, I'd hardly say that's what they are all about. That still holds with web development.

Do you think <successful web company> is successful due to their ability to squash compatibility bugs? Hardly. It's a means to an end.

> It is no different than using any other programming language, graphical APIs, network API, or OS stacks backed up by standards.

I would love for everything to be standardized across browsers, but I don't expect that to ever happen (fully).

The problem with Electron apps is that they can be done well, or they can be done poorly. And if they're done poorly, wow, may as well add cryptominer code for the drain on battery you're going to cause.

That isn't to say Electron is bad, quite the contrary, but it isn't a silver bullet either.

To your "do you think..." question, I think it is an aspect in their success. Gone are the days where someone could say "this site requires IE 6/IE 7/Firefox/Chrome/etc." and be successful. Going onto Facebook, I don't think the site looks great, but it functionally works in any browser I've come across in an expected manner. But if they'd require a native electron or otherwise app? Wouldn't use it (don't have Facebook or Messenger installed on my phone or tablet, I only check messages where allowed which is desktop and tablet web sites, everything else I use it for works fine in mobile/tablet/desktop).

> You've clearly never tried to support more than one browser.

Please be as polite in a forum as you would be during a face to face conversation. You'd never start an office/remote work conversation with that line, would you?

I actually have started face to face conversations like that, but admittedly had tone of voice to soften it.

I can see how it can sound harsher than intended in text-only.

Did you mean for most developers? As a user I don't want to have my battery chewed up by Electron based bloatware.

Really nice.

I like these new in-browser IDEs.

They often bring a full-fledged build system with them.

Just open the URL, write your code, hit compile and download your build.

You know, now that I think about it... Node projects pretty much have all their tooling written in JavaScript already. I wonder how hard it'd be to run all that in the browser directly (right now I think this IDE is handling that on the server).

That's one of our goals, we're already doing a lot client side but the goal is to client side all things - https://github.com/wasdk/WebAssemblyStudio/projects/3

Depends on the project... for example, I was really sad that Sass won over Less only because the implementation for Sass was C/C++ (or Ruby), and Less was straight JS.

There are a number of C/C++ based node libraries... I think sass, sqlite are probably the two most popular. Any dependents of nan[0], node-gyp and node-pre-gyp are others.

[0] https://www.npmjs.com/browse/depended/nan

For those interested, this is using the Monaco editor https://github.com/Microsoft/monaco-editor

Yes! I was so happy when they pulled this out of VSCode. I really want to use it on a future project and I love the idea of code in the browser for sharing learning opportunities!

IIRC, Monaco was actually first, and VSCode was based on that :)

This is really cool!

I'd love to see the "Hello World" example template provided for all languages, not just C (or at least, for Rust as well, since the C++ version would be awfully close to the C one already).

EDIT: On a different note, I was confused when I loaded a template, hit "Run", and got nothing. I assumed running would automatically build first. It would be nice to somehow hint to the user if they run something that hasn't been built yet.

In my understanding, part of why they don't have that in Rust yet is the lack of Cargo support; you'd want to use https://github.com/rustwasm/wasm-bindgen (and its README.md has said hello example in it) but there's no easy way to use it just yet. It's coming though.

I'm waiting for the php implementation.

_Started_ working on it late December? That's an incredible amount of progress for less than 4 months.

Built on top of the great work of many : https://github.com/wasdk/WebAssemblyStudio#credits

The tools for working with WASM are here: https://github.com/WebAssembly/wabt

The compiler/converters are here: https://github.com/WebAssembly/binaryen

Maybe someone who knows more could help me understand better. It looks the toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend which then is converted to WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?). So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right? I don't really get if WASM has memory-managment / garbage-collection by default or it's something optional available to things like Javascript? Or the GC is written in WASM itself...?

With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing very very similar things - but I kinda get the rational there

> WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think? (can someone confirm?)


> So I guess going forwards WASM is the new crossplatform bytecode and not necessarily tied to the web - right?

Yes. Andreas Rossberg and other chief WASM people are touring conferences with talks called more or less "WebAssembly: Neither Web nor Assembly". It's a misnomer.

> I don't really get if WASM has memory-managment / garbage-collection by default

It doesn't. I'm not up to date, but last I heard the best that was offered was "at some point there will be APIs available for calling into the browser's runtime to get GC'd objects" or something like that.

Gotcha. After reading a bit more it sounds like WASM isn't supposed to really be the common target for all "web-languages". ie. Javascript won't be compiling to WASM any time soon. It's just a parallel mechanism to run code in the browser that's more extendable/flexible (b/c people where writing monsters to have their language compile to Javascript/asm.js)

I think it's a bit of both, and maybe more. For one thing, I think there are historical ties to asm.js (i.e., some of the same people went on to develop WASM), and asm.js should compile nicely to WASM. Once they have GC figured out.

For another thing, I think there is the long-term goal of using WASM as a way to migrate away from JavaScript, if desired. Once you can compile all (or most) of your JavaScript logic to WASM, you can start transparently replacing parts of that code with code written in other languages that compile to WASM. If the interfaces remain unchanged, the remaining JavaScript won't notice.

LLVM-IR is not really a standard and it is not backwards compatible across LLVM releases and usually the generated IR is also specific to the target platform. Of course it's still vastly easier recompile already generated IR to a different platform as opposed to writing an emulator but it's not supposed to be used this way.

It's simply not possible to compare LLVM-IR to WASM SPIR-V JVM BEAMVM CLR bytecode.

I love that AssemblyScript and bare Wat format are supported as well.

I hope they'll add Walt

I work with emscripten and webgl and this looks like a fantastic tool for optimization in particular. Really looking forward to using it. Thank you!

How much optimiztion can you squeeze out of webgl + wasm? Don’t you still have to call into JS?

Yes, it's definitely good practice to reduce calls to WebGL as much as possible (for instance through batching, instanced rendering, maintaining your own state cache etc...). Performance behaviour of WebGL is very different from a native GL implementation, but when keeping that in mind it's not too bad all in all.

What would be awesome is a way to easily visualize the code size.

Whoa, that's a lot of wasm to show a hello world, compared to "hello world" in assembly language.

I'm non-plussed. Their "Hello World" example in C is essentially unparseable for anyone who doesn't already know what's going on. Anyone care to explain it? I don't know how much of this example is written in js and how much in C, how much is boilerplate or anything. It's awful.

Well, that's kind of what the README file is there for.

Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me.

Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file.

So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.

That’s a very nice description of what’s going on. The example is there to illustrate how printf works. In fact this is a lot of what Emscripten does to make C/C++ applications just work.

typos: memeory, "pulling the struct iovec abart."

I thought the meme-ory was on purpose...

The video is unlistenable

I listened to the whole video and it has good audio all the way through.

not bad, but four(4) config files for a single code file?

Depends on the template really. Our goal was to not hide any of the magic, the tool only really needs a build.ts file, where you define what the Build button should do.

Where do you see 4? I see package.json only. Arguably the build script. And that number doesn't increase at all with more code.

The number of files is exactly the same as if you weren't using webassembly, other than the one rust/c source file.

On AssemblyScript I see:

- tsconfig.json

- gulpfile.js

- package.json

- setup.js

AssemblyScript is slightly more involved because the author of the template loads the compiler dynamically.

WebAssembly Studio is a neat project, and I'm very impressed at the quality of tooling.

It's just a shame that WebAssembly itself is a concept so deeply flawed in conception that it is unsalvagable, and that it'll hurt developers and users alike. Does opening the door to frontend development in C, Rust, Java, and the whole menagerie really seem like such a good idea?

Consider the mess we've made with Javascript--the spread of that mess to other languages to enable WASM and web support is going to be even worse.

Would you care to add some information about why you feel this way?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact