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

31–40 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#31

Post by bigato »

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?

That only means that for now, languages will have to provide their own garbage collectors, like Go initially implemented their garbage collector in C which is a language that manages memory manually.

Re: An Abridged Cartoon Introduction To WebAssembly

#32

Post by JBiserkov »

copperx wrote: post #25
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 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?

So the next generation can't have nice things either :).

It seems to me that the history of computing so far can be summarized as "due to popular demand, things have been used far outside their creator's intended scope, with 3-4 non-horrible results".

(Lisp is definitely one, can't think of another on the top of my head).

Re: An Abridged Cartoon Introduction To WebAssembly

#33

Post by tyingq »

thaumasiotes wrote: post #27
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?

It is on the wasm roadmap, along with other things that sound more like a virtual machine, and less like ASM. I assume to allow for dynamically typed languages without a download of the entire runtime.

Re: An Abridged Cartoon Introduction To WebAssembly

#34

Post by white-flame »

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?

Dynamic, managed languages can compile to JS.

Static languages can compile to wasm. Low-level runtime implementations of other managed languages which don't mesh well with JS backends can compile to wasm.

Webasm doesn't replace JS, it complements it.

Re: An Abridged Cartoon Introduction To WebAssembly

#35

Post by vivin »

thaumasiotes wrote: post #27
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?

I wasn't talking about the language, but the runtime I guess.

Re: An Abridged Cartoon Introduction To WebAssembly

#36

Post by gavinpc »

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…

People could be perfectly happy with today's performance levels (or tomorrow's, or yesterday's) if the prevailing systems were designed to serve and empower them, rather than to exploit them.

The market wants people to want "more features and faster execution." The market doesn't care what it's selling per se. If the web-browser-as-OS seems like an inevitability in that context, it's only a side-effect, and one that could change at any time.

WASM also impacts the labor market, as you mention. But it's not, as we might like to believe, because programmers' demands for more freedom and expressive power are being honored; it's because, as monkmartinez suggests [0] (and maybe this is what you mean by "floodgates"), companies would rather not be limited to a smaller human-resource pool when developing web properties.

If I sound a little dystopian, it might be because I'm currently reading Cyber-Marx [1], an insightful book from 1999 about the "information revolution" and its relation to capital.

[0] https://news.ycombinator.com/item?id=14342983

[1] http://www.press.uillinois.edu/books/catalog/66mwg3pc9780252...

Re: An Abridged Cartoon Introduction To WebAssembly

#37

Post by mtvrandom »

copperx wrote: post #25
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 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?

No post body was provided.

Re: An Abridged Cartoon Introduction To WebAssembly

#38

Post by jimmaswell »

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

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?

Java applets were unfortunately ahead of their time for the hardware available and got a bad reputation for being slow, along with security problems, and now that Google extinguished plugins like Java and Flash (Google gets to skip the Extend step) we're stuck with whatever Chrome lets webasm do with no competition for this kind of VM-in-a-browser. The homogenization Google forced on the web is a travesty but everybody is too distracted by shiny new HTML5 features and the anti-plugin bandwagon to care.

Re: An Abridged Cartoon Introduction To WebAssembly

#39

Post by tamat »

after reading many tutorials about WASM I still figured out one of the most important questions for me:

Would I be able to call JS functions from WASM? or pass callbacks to WASM. Because WASM sounds like it goes agains the async nature of JS and I have the feeling that is going to be very annoying to merge both worlds.

Also if I cannot call any JS func from WASM it means I cannot call WebGL or Audio so I dont know what would I need the performance if I cannot access the most performance demanding APIs.

Re: An Abridged Cartoon Introduction To WebAssembly

#40

Post by Slackwise »

Oh cool, the text format[1] appears to be s-expressions!

Sounds like an easy dump from AST to text to wasm. Aside from what the Google Closure Compiler provides, I wonder what benefit, if any, this may give to ClojureScript. I'm guessing CLJS will just keep Google Closure for its optimizations, while Google Closure will output either wat files or wasm files. Unless optimizations can just be done during wat to wasm, which would be ideal for other language authors who can just translate to their intentions and not have to worry so much about fancy optimizations. (I'm rambling at this point. Sorry.)

[1]: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

Post reply on HN