Live data from Hacker News

Sneak Peek at WebAssembly Studio

hacks.mozilla.org

41–50 of 103 posts

Re: Sneak Peek at WebAssembly Studio

#41
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.

Re: Sneak Peek at WebAssembly Studio

#42
post #34
post #17

Earlier quoted context omitted.

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 s…

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

Re: Sneak Peek at WebAssembly Studio

#43
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.

Re: Sneak Peek at WebAssembly Studio

#45
post #38
post #12

Earlier quoted context omitted.

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

Re: Sneak Peek at WebAssembly Studio

#46
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.

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

Re: Sneak Peek at WebAssembly Studio

#47
post #26

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

Re: Sneak Peek at WebAssembly Studio

#48
post #43

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 somet…

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.

Re: Sneak Peek at WebAssembly Studio

#49

Earlier quoted context omitted.

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…

> 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, charCo…

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

Re: Sneak Peek at WebAssembly Studio

#50
post #43

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 somet…

I'm waiting for the php implementation.
Post reply on HN