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

21–30 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#21

Post by monkmartinez »

throwasehasdwi wrote: post #18
gavinpc wrote: post #14

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a wo…

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 wholeheartedly agree with your statements. I think there are a legion of developers who would love to program for the web, but refuse to learn|use and simply can not keep up with JS.

The browser is one of the only truly cross platform development environments around. The popularity of the browser is directly coupled to that fact in my opinion. How many developers|companies and organizations would be over the moon excited with hiring a Python|Ruby|Lua|Rust|C# developer that could talk natively to the browser? My guess is a LOT.

Re: An Abridged Cartoon Introduction To WebAssembly

#23

Post by hmottestad »

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

Re: An Abridged Cartoon Introduction To WebAssembly

#24

Post by IvanK_net »

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 any other programming language (i.e. there is no relation). A WebAssembly VM could be made as an extension of any environment.

I recommend reading the official paper https://github.com/WebAssembly/spec/blob/master/papers/pldi2... (I learned more than about 50 "essays" that I read about WASM in the past).

Re: An Abridged Cartoon Introduction To WebAssembly

#25

Post by copperx »

throwasehasdwi wrote: post #18
gavinpc wrote: post #14

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a wo…

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

Re: An Abridged Cartoon Introduction To WebAssembly

#26

Post by vivin »

> For now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent.

Does this worry anyone else? Or I am getting worked up over nothing?

Re: An Abridged Cartoon Introduction To WebAssembly

#27

Post by thaumasiotes »

vivin wrote: post #26

> For now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Does this worry anyone else? Or I am getting worked up over nothing?

It seems like the normal thing to do would be to develop for a runtime that does feature GC?

Of all the things you've ever encountered called "assembly language", how many supported GC?

Re: An Abridged Cartoon Introduction To WebAssembly

#28

Post by acomjean »

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

Thanks

I figured the built in browser debuggers wouldn't work so well for this.

Re: An Abridged Cartoon Introduction To WebAssembly

#29

Post by thaumasiotes »

throwasehasdwi wrote: post #18
gavinpc wrote: post #14

I'm of two minds about WASM. There's the Alan Kay attitude that we can build entire systems on top of minimal VM's, rather than sacrificing power to bake in more facilities. But even he says that too much time has been wasted by teams reinventing the wheel (or flat tire) who didn't really have the chops to do it. The other side of that, then, is the great potential for interop that Javascript offers. We now have a wo…

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…

Something I ask in basically every WASM thread is: what is the conceptual difference between WASM ("good") and Java applets ("bad")? How does the system you describe differ from having the browser implement a JVM?
Post reply on HN