Intro to WebAssembly • Hacker News Board

Re: Intro to WebAssembly

#11

Post by kjksf » Fri, Jun 30, 2017, 3:53 AM UTC

bluejekyll wrote: post #8

I'm really surprised to read an article like this that doesn't mention Rust. The reason is that I find it hard to believe that developers will want to move to unsafe languages like C/C++. Many of the other languages mentioned require runtimes, runtimes that will need to be built on top of webassembly. Rust doesn't have any of these drawbacks, is runtime free, and can already target webassembly. Given that both of the…

WebAssembly is in a large part about re-using vast quantities of existing C/C++ code in the browser.

C++ will dominate in that space over Rust for the same reason it'll dominate in all other spaces: the amount of existing C++ code and the number of existing C++ programmers will always dwarf the amount of Rust code and Rust programmers.

Even if Rust was uniformly 10-20% better than Rust, economics dictate that for most people it'll make most sense to continue with C++ than rewrite thousands or millions lines of code in C++ or embark on months-long retraining of large number of programmers, some of which will not be happy about going from being proficient C++ programmers to beginner Rust programmer.

And that's why we don't need to mention Rust when writing about WebAssembly. At this point in time it's immaterial to the subject.

Re: Intro to WebAssembly

#12

Post by michaelchisari » Fri, Jun 30, 2017, 4:20 AM UTC

jjn2009 wrote: post #7

Klathmon wrote: post #3

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all. JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really im…

the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.

Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards.

But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code.

People talk about Javascript fatigue, and it's real and exhausting to keep up with the constant framework churn. But I think the biggest reason at the root of it all is Javascript. Nobody talks about Unix fatigue, and all the different languages and frameworks that you can use to build your backend services. When we have a truly open-ended platform to build on, we're not going to feel this fatigue, I don't think.

Re: Intro to WebAssembly

#13

Post by [deleted] » Fri, Jun 30, 2017, 4:22 AM UTC

bluejekyll wrote: post #8

I'm really surprised to read an article like this that doesn't mention Rust. The reason is that I find it hard to believe that developers will want to move to unsafe languages like C/C++. Many of the other languages mentioned require runtimes, runtimes that will need to be built on top of webassembly. Rust doesn't have any of these drawbacks, is runtime free, and can already target webassembly. Given that both of the…

[deleted]

Re: Intro to WebAssembly

#14

Post by michaelchisari » Fri, Jun 30, 2017, 4:22 AM UTC

bluejekyll wrote: post #8

I'm really surprised to read an article like this that doesn't mention Rust. The reason is that I find it hard to believe that developers will want to move to unsafe languages like C/C++. Many of the other languages mentioned require runtimes, runtimes that will need to be built on top of webassembly. Rust doesn't have any of these drawbacks, is runtime free, and can already target webassembly. Given that both of the…

Rust is a great language, but it appeals to a very specific set of engineering goals and a specific type of programmer who wants a lot of control while also wanting strong guarantees. So far, the web has provided neither. So for this reason, I think Rust adoption on the front-end will be slow, but still meaningful.

Re: Intro to WebAssembly

#15

Post by nevi-me » Fri, Jun 30, 2017, 4:47 AM UTC

If the author states that there are already a number of Hello World examples, why not spend a bit more time and create something else that's still simple enough?

As a self-taught programmer, one of the difficulties I found (before SO) was that the many articles one read up on would typically repeat what someone else said. This especially with new technologies.

I think if authors pointed us to an existing "Hello World", and then expanded on that, in the long-run, beginners would sometimes find it easier to learn fadter.

Re: Intro to WebAssembly

#16

Post by [deleted] » Fri, Jun 30, 2017, 4:48 AM UTC

kjksf wrote: post #10

zzo38computer wrote: post #4

I like the idea of WebAssembly too; it is another kind of VM code. However, is there a C API to WebAssembly? Having a JavaScript API that is usable in both HTML and Node.js (and could easily be added to any other JavaScript too) is good, but a C API can also help (and I have written on some file on my computer what are some ideas for making a C API). (I did not read the linked document much though, but only the offic…

It's like asking "is there JavaScript API to JavaScript". WebAssembly is a portable instruction set, a simplified CPU. The main use case for WebAssembly is compiling C/C++ code to that instruction set using emsscripten, which is a clang-based C/C++ compiler that emits WebAssembly modules. Depending on how you look at it, the answer to "is there C API to assembly?" is: a) yes, that's the first API there ever was and i…

[deleted]

Re: Intro to WebAssembly

#17

Post by couchand » Fri, Jun 30, 2017, 4:50 AM UTC

bluejekyll wrote: post #9

Klathmon wrote: post #3

The official FAQ specifically states the opposite of the second bullet point. Web Assembly is not meant to be a replacement for JavaScript. And although the blog doesn't explicitly say it, it's alluding to it being easy to create entire applications without using JavaScript at all. JavaScript is going to continue to be used as "glue code" at the very least, and UI code in the majority of cases. I think it's really im…

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It…

I'm excited but I'm also cautious. I'm not sure that WASM has a slam dunk story in terms of many web-native concepts, for instance asynchronous execution. The browser APIs will likely lag far behind JS, and DOM integration is just one thing there - also fetch, indexeddb/localstorage, and so forth. WASM gives us some additional tools for the web toolbelt, but it will be a long, long time before it's mature enough to completely replace JS.

That being said, I hope I'm proven wrong.

Re: Intro to WebAssembly

#18

Post by zzo38computer » Fri, Jun 30, 2017, 4:52 AM UTC

jjn2009 wrote: post #6

zzo38computer wrote: post #4

I like the idea of WebAssembly too; it is another kind of VM code. However, is there a C API to WebAssembly? Having a JavaScript API that is usable in both HTML and Node.js (and could easily be added to any other JavaScript too) is good, but a C API can also help (and I have written on some file on my computer what are some ideas for making a C API). (I did not read the linked document much though, but only the offic…

DOM manipulation isn't currently supported, for now you will need to provide a javascript layer between the C code and DOM. Its in the roadmap to create these interfaces. Web assembly is better suited for CPU intensive tasks which you would want to offload from javascript but keep on the client.

I think that DOM manipulation should not be a part of WebAssembly, although the other way around may make some sense, where for example, the "window.wasm" property might be a WebAssembly module for accessing the HTML DOM (otherwise the module is not included and the WebAssembly code is sandboxed and cannot access DOM). If the WebAssembly module is loaded directly using a "script" tag in a HTML document, then it can automatically include the HTML DOM module.

Re: Intro to WebAssembly

#19

Post by couchand » Fri, Jun 30, 2017, 4:59 AM UTC

michaelchisari wrote: post #12

jjn2009 wrote: post #7

Earlier quoted context omitted.

the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.

Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards. But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code. People talk about Javascript fatigue, and it's real and exhausting to keep up with the constan…

If the problem is really just JavaScript itself WASM won't be able to help -- WASM is basically just asm.js, which is just a restricted subset of JavaScript, but easier to parse and optimize.

Re: Intro to WebAssembly

#20

Post by zzo38computer » Fri, Jun 30, 2017, 5:02 AM UTC

kjksf wrote: post #10

zzo38computer wrote: post #4

I like the idea of WebAssembly too; it is another kind of VM code. However, is there a C API to WebAssembly? Having a JavaScript API that is usable in both HTML and Node.js (and could easily be added to any other JavaScript too) is good, but a C API can also help (and I have written on some file on my computer what are some ideas for making a C API). (I did not read the linked document much though, but only the offic…

It's like asking "is there JavaScript API to JavaScript". WebAssembly is a portable instruction set, a simplified CPU. The main use case for WebAssembly is compiling C/C++ code to that instruction set using emsscripten, which is a clang-based C/C++ compiler that emits WebAssembly modules. Depending on how you look at it, the answer to "is there C API to assembly?" is: a) yes, that's the first API there ever was and i…

b) is what I meant. I know that would not have been the original intention but I still think it can be useful in some cases, and there does not seem anything wrong with it. (It clearly wouldn't be for static linking WebAssembly codes with C codes, like what you might do with JavaScript, although it can have different uses.)