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

71–80 of 103 posts

Re: Sneak Peek at WebAssembly Studio

#71

Post by pcwalton »

haberman wrote: post #29
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 th…

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.

Re: Sneak Peek at WebAssembly Studio

#72

Post by erikpukinskis »

epicide wrote: post #17
pjmlp wrote: 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.

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.

Re: Sneak Peek at WebAssembly Studio

#73

Post by wes-k »

alephnan wrote: post #55

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!

Re: Sneak Peek at WebAssembly Studio

#74

Post by tyingq »

dmix wrote: post #61
haberman wrote: post #29

Earlier quoted context omitted.

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

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.

Re: Sneak Peek at WebAssembly Studio

#75

Post by __s »

haberman wrote: post #29
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 th…

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

Re: Sneak Peek at WebAssembly Studio

#76

Post by jimmcslim »

tyingq wrote: post #74
dmix wrote: post #61

Earlier quoted context omitted.

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

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

Re: Sneak Peek at WebAssembly Studio

#77

Post by tyingq »

jimmcslim wrote: post #76
tyingq wrote: post #74

Earlier quoted context omitted.

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

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

Re: Sneak Peek at WebAssembly Studio

#78

Post by jeswin »

epicide wrote: post #17
pjmlp wrote: 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.

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?

Re: Sneak Peek at WebAssembly Studio

#79

Post by AnonCoward222 »

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.

Re: Sneak Peek at WebAssembly Studio

#80

Post by haberman »

pcwalton wrote: post #71
haberman wrote: post #29

Earlier quoted context omitted.

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

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

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:

https://news.ycombinator.com/item?id=1893686

https://web.archive.org/web/20101126142151/http://www.aminut...

https://www.infoq.com/news/2013/05/javascript-browser-byteco...

Post reply on HN