Live data from Hacker News

Sneak Peek at WebAssembly Studio

hacks.mozilla.org

31–40 of 103 posts

Re: Sneak Peek at WebAssembly Studio

#31
post #25

Earlier quoted context omitted.

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

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.

Re: Sneak Peek at WebAssembly Studio

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

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

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

Re: Sneak Peek at WebAssembly Studio

#34
post #17
post #13

Earlier quoted context omitted.

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.

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.

Re: Sneak Peek at WebAssembly Studio

#35

Earlier quoted context omitted.

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.

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

Re: Sneak Peek at WebAssembly Studio

#36
post #24
post #10

Earlier quoted context omitted.

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.

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, ...

Re: Sneak Peek at WebAssembly Studio

#38
post #12
post #3

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. https://webassembly.studio/

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).

Re: Sneak Peek at WebAssembly Studio

#40

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.
Post reply on HN