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

An Abridged Cartoon Introduction To WebAssembly

smashingmagazine.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#101

Post by throwasehasdwi »

copperx wrote: post #95
throwasehasdwi wrote: post #67

Earlier quoted context omitted.

It's not the overall objective but that's exactly the objective of a lot of people rooting for it. Think of how many people would be pissed off if they said "we're gonna try to replace javascript". Google did that with Dart and everyone gave them the finger... sunk cost fallacy. Better to develop something for "performance" that just happens to be able to replace JS as a side benefit. Makes it a lot easier to swallow

So what you're saying is that WASM is a Trojan horse.

If you disagree with javascript losing dominance I guess you could say so. It's really just a way to make it easy to run whatever language you want in the browser in a cross-platform compatible way. I don't see this as a bad thing at all.

Re: An Abridged Cartoon Introduction To WebAssembly

#102

Post by derefr »

adrianratnapala wrote: post #96
IvanK_net wrote: post #24

They often forget to mention, that WebAssembly is just a low-level programming language (much lower than C), it has extremely simple syntax (it has just four data types, no system calls, the specification takes 5 pages instead of 500 pages of C spec). You may call it a "bytecode", but typical bytecodes also have around-500-page specifications. Also, its relation to javascript is not any bigger than the relation to an…

I think your claim is right, but be wary about spec page counts. They blow out with age. As time goes on, more pages are devoted to nailing down corner-cases, and retroactively legislating either for or against assumptions had previously been common sense until someone in the real world violated them. WASM will see such growth in time. Think of how simple HTML was once upon a time.

HTML got complicated because they modified the assumptions whenever they were violated, to make the violation into a working case.

Specs grow much more slowly if, in response to such non-conforming implementations of a processing stage, they just codify the common sense, and maybe give methods for detecting the non-conforming outputs and rejecting them. XHTML is not a large spec.

Re: An Abridged Cartoon Introduction To WebAssembly

#103

Post by derefr »

rustyhacker wrote: post #43
throwasehasdwi wrote: post #18

Earlier quoted context omitted.

Realistically, as soon as WASM is a good alternative to JS a good part of websites won't use a single line of JS. Regardless of arguments for and against whether this is a good idea, market pressure to open floodgates to other languages will be far too high to ignore. My prediction is that WASM will quickly evolve into a new way to containerize applications, very close to a full-fledged VM/OS. The market constantly d…

I'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now. Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and second…

Alternate hypothesis: at least as of right now†, Web Workers still don't support thread-like behavior. If I wanted to program e.g. a game in C++ or Python, I'd be pulling in an engine and some libraries that all expect to have threads available. This code would not transpile.

You can write a native app in pretty much any language that can sit on top of the current web stack—but from the perspective of most programming languages, the result is very non-idiomatic code. Not only do you have to avoid consuming most of the library ecosystem of your language; you also have to code in the "Javascript style", with co-operatively scheduled async tasks running in a single execution-thread context (plus maybe some memory-isolated "secondary process"-like execution-threads you have to do message-passing IPC against) in order to make your native code "work" in a web browser after transpilation.

If we clear that hurdle, using arbitrary languages for the web will be a lot easier, and you'll see far more porting of native apps to the web.

† https://kripken.github.io/emscripten-site/docs/porting/pthre...

Re: An Abridged Cartoon Introduction To WebAssembly

#104

Post by adrianratnapala »

derefr wrote: post #102
adrianratnapala wrote: post #96

Earlier quoted context omitted.

I think your claim is right, but be wary about spec page counts. They blow out with age. As time goes on, more pages are devoted to nailing down corner-cases, and retroactively legislating either for or against assumptions had previously been common sense until someone in the real world violated them. WASM will see such growth in time. Think of how simple HTML was once upon a time.

HTML got complicated because they modified the assumptions whenever they were violated, to make the violation into a working case . Specs grow much more slowly if, in response to such non-conforming implementations of a processing stage, they just codify the common sense, and maybe give methods for detecting the non-conforming outputs and rejecting them. XHTML is not a large spec.

Very true. But HTML is not unique in this regard, other standards have done this too.

I picked on HTML because it is also a foundational web technology. Many of its standards setters are the same people who will influence WASM, and many of the same incentives will be at play with WASM as with HTML.

Re: An Abridged Cartoon Introduction To WebAssembly

#105

Post by sqeaky »

sova wrote: post #75
sqeaky wrote: post #60

Earlier quoted context omitted.

Last night I tried a web assembly demo of Ogre3d, an open source 3d rendering engine. It worked in Chrome and Firefox. (I will put the link here after work, it is sitting in my personal email) Whatever you are reading about the spec is not lining up with the reality of progress. We have two implementations now. I encourage you to read the article, it is a decent primer for someone with your apparent level of knowledg…

Thank you for taking the time to clarify the status of the project to a stubborn mule such as myself.

I just tested this in Firefox 53 and Chromium 58: https://ogrecave.github.io/ogre/wasm/

Space to jump, WADS to move, Q to draw and put away swords.

Re: An Abridged Cartoon Introduction To WebAssembly

#106

Post by binji »

IvanK_net wrote: post #24

They often forget to mention, that WebAssembly is just a low-level programming language (much lower than C), it has extremely simple syntax (it has just four data types, no system calls, the specification takes 5 pages instead of 500 pages of C spec). You may call it a "bytecode", but typical bytecodes also have around-500-page specifications. Also, its relation to javascript is not any bigger than the relation to an…

You may want to take a look at the formal spec here as well: https://webassembly.github.io/spec/

There's still some work to be done, but it is quite far along already.

Re: An Abridged Cartoon Introduction To WebAssembly

#107

Post by sova »

sqeaky wrote: post #105
sova wrote: post #75

Earlier quoted context omitted.

Thank you for taking the time to clarify the status of the project to a stubborn mule such as myself.

I just tested this in Firefox 53 and Chromium 58: https://ogrecave.github.io/ogre/wasm/ Space to jump, WADS to move, Q to draw and put away swords.

https://www.youtube.com/watch?v=BV32Cs_CMqo Unreal Engine 3 (may 2nd release vid) very cool! Can I use WebASM to do amazing music visualizations?
Post reply on HN