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

91–100 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#91

Post by bzbarsky »

ericfrederich wrote: post #55

Currently browsers only support JS. If you want another language you have to transpile to JS or implement your language in JS, etc. If the browser vendors were going to add another language I would have hoped it would be something so generic like LLVM instead of this WebASM which is too tied to JS.

LLVM bitcode doesn't make a great interchange format, because it's not really hardware agnostic, last I checked. Obviously you _can_ run it on hardware it's not created for, e.g. in an emulator or via some extra transpiling. But now you're introducing some serious inefficiency into the pipeline.

Re: An Abridged Cartoon Introduction To WebAssembly

#92

Post by [deleted] »

hmottestad wrote: post #23
acomjean wrote: post #22

Looks really interesting, but How does one debug the web assembly code?

Same way you would C code. Tell the compiler you want to compile for debugging, and then connect your debugger to the running program. Marks in the code will tell your debugger what things are called and which line in the source code you are on. JS today is often transpiled anyway, so you have to use some mapping to the source code to do debugging (eg. source maps).

[deleted]

Re: An Abridged Cartoon Introduction To WebAssembly

#93

Post by moron4hire »

paulddraper wrote: post #90
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…

Also: WASM is best as a target for languages that usually committee to machine code. E.g. it's great for C, but not really for Python.

Many languages--like Python--are implemented in C, so it's a pretty natural chain-of-events to get from there to WASM.

Re: An Abridged Cartoon Introduction To WebAssembly

#94

Post by [deleted] »

paulddraper wrote: post #90
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…

Also: WASM is best as a target for languages that usually committee to machine code. E.g. it's great for C, but not really for Python.

[deleted]

Re: An Abridged Cartoon Introduction To WebAssembly

#95

Post by copperx »

throwasehasdwi wrote: post #67
copperx wrote: post #25

Earlier quoted context omitted.

I agree, but at the same time I look at the Webassembly web page, and they explicitly state that replacing Javascript is not their objective. Why is that?

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.

Re: An Abridged Cartoon Introduction To WebAssembly

#96

Post by adrianratnapala »

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.

Re: An Abridged Cartoon Introduction To WebAssembly

#97

Post by gavinpc »

monkmartinez wrote: post #79
andrewflnr wrote: post #78

Earlier quoted context omitted.

I'm a little confused by this comment. Are you saying it would be better for the world if companies were limited to a "smaller human-resource pool"? Does anyone besides JS devs benefit from that scenario?

Me too, but I am drawing a different conclusion. Perhaps he/she means that companies ultimately drive the market forward as it were. I mean, most people do not strictly trade time/effort for no reward. Reward can mean different things for different people, but I would tend to land on most people trade labor for money. Companies invest in tools all the time, especially internet companies. They would have the bigger re…

Yes, I'm saying that this would not move forward without buy-in from non-programmers with influence. But language isn't the only thing. WASM is (correct me if I'm wrong) harder to reverse engineer, which must matter to those same stakeholders.

Re: An Abridged Cartoon Introduction To WebAssembly

#98

Post by dr_zoidberg »

gavinpc wrote: post #97
monkmartinez wrote: post #79

Earlier quoted context omitted.

Me too, but I am drawing a different conclusion. Perhaps he/she means that companies ultimately drive the market forward as it were. I mean, most people do not strictly trade time/effort for no reward. Reward can mean different things for different people, but I would tend to land on most people trade labor for money. Companies invest in tools all the time, especially internet companies. They would have the bigger re…

Yes, I'm saying that this would not move forward without buy-in from non-programmers with influence. But language isn't the only thing. WASM is (correct me if I'm wrong) harder to reverse engineer, which must matter to those same stakeholders.

I don't see how it would be harder to RE than .NETs IL (which is pretty easy to RE), or even plain old assembly -- which looks horrible, but can be disassembled and even "decompiled" (which generates a potential C source from the disassembled bytecode).

Re: An Abridged Cartoon Introduction To WebAssembly

#99

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.

Thank you for being reasonable, that is not very common. You were never rude and we are all... off sometimes.

and sorry I forgot the link, I am writing a note to myself on real dead tree so I can forget it easily.

Re: An Abridged Cartoon Introduction To WebAssembly

#100

Post by Rusky »

thaumasiotes wrote: post #82
Rusky wrote: post #44

Earlier quoted context omitted.

Java applets have a radically different security model from Javascript and wasm. There's only thing that makes wasm any closer to Java applets than Javascript already is- it's distributed as a bytecode that's not dynamically typed, rather than text. But Javascript's dynamically typed textual representation has nothing to do with what makes it better than Java applets. It's the security model, which wasm shares.

Wouldn't it be easier to change the security model on Java applets than to go through whatever the process of developing wasm is?

Perhaps, but there are other benefits to wasm than "lacks Java applets' downsides"- JVM bytecode is locked into the Java object model and garbage collector, while wasm doesn't impose any particular style of memory management. This makes it far more straightforward to use in high-performance situations than Java can ever be.
Post reply on HN