Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sneak Peek at WebAssembly Studio

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 103 posts

Re: Sneak Peek at WebAssembly Studio

#21

Post by laughingpine »

notheguyouthink wrote: post #19
danShumway wrote: post #18

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.

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

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

Re: Sneak Peek at WebAssembly Studio

#22

Post by danShumway »

notheguyouthink wrote: post #19
danShumway wrote: post #18

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.

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

Correct.

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

Re: Sneak Peek at WebAssembly Studio

#23

Post by skybrian »

kodablah wrote: post #16
kristiandupont wrote: post #4

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…

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

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

Re: Sneak Peek at WebAssembly Studio

#24

Post by Koshkin »

pjmlp wrote: post #10
kristiandupont wrote: post #4

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…

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

Re: Sneak Peek at WebAssembly Studio

#25

Post by berdon »

ropeadopepope wrote: post #5
berdon wrote: 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/

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

Re: Sneak Peek at WebAssembly Studio

#26

Post by xnaas »

danShumway wrote: post #18

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?

Re: Sneak Peek at WebAssembly Studio

#27

Post by mbebenita »

pjmlp wrote: post #14
bpicolo wrote: post #8

Earlier quoted context omitted.

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.

Re: Sneak Peek at WebAssembly Studio

#29

Post by haberman »

danShumway wrote: post #18

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)

Re: Sneak Peek at WebAssembly Studio

#30

Post by kodablah »

skybrian wrote: post #23
kodablah wrote: post #16

Earlier quoted context omitted.

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

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

Post reply on HN