Live data from Hacker News

WebAssembly 101: A developer’s first steps

blog.openbloc.fr

61–70 of 153 posts

Re: WebAssembly 101: A developer’s first steps

#61

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

Well writing in languages for native code is still just as popular, and we're moving in such a direction to allow for the same application to be available both on the web and on your machine. The pure-Javascript approach to offering the same is to package a browser with a web-app and disguise this as a standalone application, which is ass-backwards.

Re: WebAssembly 101: A developer’s first steps

#62

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth.

WebAssembly is the first steps to truly breaking that chokehold, and truly seeing how popular JavaScript the language really is.

Re: WebAssembly 101: A developer’s first steps

#63

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

Even web assembly needs to call back to javascript API's to perform webgl interactions. Emscripten provides an easy to use SDL library that makes it a bit less painful. Should be noted that due to security layers there's quite a few webgl, networking and system calls that are not available. In addition good luck getting any threads working, you can fake that out by simply calling them in a setTimeout. In addition its very low level; and if you toss in libraries you'll find your binaries being VERY large.

Re: WebAssembly 101: A developer’s first steps

#64
post #29

Remember when you could hit "View Source" to see how the web was built? I don't like where this is going. Minification was bad enough, now we're going to be getting more non-free blobs shoved into our browsers and this is being touted as a great new feature for us. It will end up being a tool of control and surveillance like always. This guy says it a bit more eloquently than I can: https://lobste.rs/s/wjtu7c/webasse…

Bullshit. Wasm can't do anything js can't. Especially with asm.js. Don't try to argue that minified or transpiled js is somehow more readable than wasm. At least it's easier to decompile in theory. It's absolutely not a "tool for surveillance". How exactly are you going to surveil anything with it? It's not even a replacement for js, or at least it shouldn't be used that way. No GC for instance. And if you are doing…

Yep. WebAssembly today is literally just a better/faster asm.js.

The argument against it linked above is nonsense. Most arguments like this that I see tend to fall into one of these boxes:

1. Using wasm as springboard to argue against something else they don't like.

— e.g. disliking closed source code / source obfuscation / minification is a fair position, but it's not helpful to anyone to pretend that wasm introduces anything different here (as has been pointed out, wast's inclusion of type information actually makes it slightly more readable than minified JS).

2. Arguing against something that wasm could maybe one day become.

— Right now wasm doesn't enable anything​ you can't already do with​ asm.js, so the idea that it somehow kills JavaScript or whatever is wrong; anything that can compile to wasm can compile to asm.js. Sure, maybe one day wasm will gain DOM/GC/etc. functionality, but asm.js could just as easily gain a lot of the same proposed features. (And wasm/asm.js aside, plenty of languages already compile to JS quite successfully; this hypothetical future wasm would just make them faster.)

3. Seeming to have only a vague sense of what wasm actually is. I think arguments like #1 and #2 have led to a set of talking points that don't at all reflect reality but sound correct to developers who don't have direct experience with asm.js/wasm.

— e.g. the argument from the linked Lobsters comment that "It solves problems that we don’t have. ... If performance is the important thing you pull on your big kid pants and write C/C++/D/Rust and if ... performance isn’t important, you just write in JS." neatly summarises exactly the point of wasm while somehow trying to frame it as an argument against it.

Re: WebAssembly 101: A developer’s first steps

#65

Earlier quoted context omitted.

Political views aside, I think I understand a key difference in that, presuming one wants to run Free (Libre) software, it's relatively easy to do if you are running one of the FSF recommended Linux distributions. By contrast, if in common usage people are only running software compiled to Web Assembly, then: 1. You probably have some work to do to figure out the licensing of the code running in your browser. 2. The…

1. is identical on linux distros. How many licenses are you using right now? Probably 20+ distinct licenses as a lowball guess. It's not easy to figure this out, and if it's something you and others really want, i'm sure a standard could be thought up to be able to on-demand get a list of software licenses used in a project which could then be built into browsers similar to sourcemaps. 2. might be more possible with…

1. Eh, if I'm running, say, Ubuntu and haven't turned on the non-free stuff I can make some reasonable assumptions about my baseline rights.

2. I don't think anyone is claiming minified JS is awesomely transparent. WASM is certainly worse than the unobfuscated, unminified JS, which until not long ago was the norm.

Re: WebAssembly 101: A developer’s first steps

#66
post #57

Earlier quoted context omitted.

I think it's a bit more than that given that the project has amassed more than 16.000 commits so far. You must not forget that JS does not provide support for many of the things that are required to run a C program (e.g. printing), so emscripten needs to take care of providing alternative implementations for all these things.

Oh, alright. We are speaking about two different things. I was thinking about compilation and specifically supporting complex language features which are mostly handled by a compiler frontend which is this case is clang. And it seems that you are thinking about runtime libraries (or the whole tool chain).

Ah yes you're right, that part is luckily covered by LLVM.

Re: WebAssembly 101: A developer’s first steps

#67
post #29

Remember when you could hit "View Source" to see how the web was built? I don't like where this is going. Minification was bad enough, now we're going to be getting more non-free blobs shoved into our browsers and this is being touted as a great new feature for us. It will end up being a tool of control and surveillance like always. This guy says it a bit more eloquently than I can: https://lobste.rs/s/wjtu7c/webasse…

https://github.com/WebAssembly/design/blob/master/FAQ.md#wil... The text form of Wasm looks like it's going to be far easier to read than minified JS.

The text format has been finalized, you can see examples of it here:

http://webassembly.org/docs/text-format/

Re: WebAssembly 101: A developer’s first steps

#68

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

I think javascript is so popular because it's the only language for browsers. I think if you got better alternatives in the browser then javascript would lose much of it's popularity. It's not going to die overnight but my guess is that it's popularity will decline

Re: WebAssembly 101: A developer’s first steps

#69

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

> I'm not sure people will want to move away from it for most development.

    x = 1 + '2' //12
    x = 1 - '2' //-1
Oh yes, yes we do.

Re: WebAssembly 101: A developer’s first steps

#70
post #62

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth. WebAssembly is the first steps to truly breaking that chokehol…

Right, however javascript will still be the only full featured language having its runtime and libraries included with the browser. That means that for other languages, only the ones with fairly light runtimes and libraries could be suitable for inclusion in most web apps. This will limit the choices for non javascript general development. It may be possible to do a webassembly/webgl rendering engine to replace html/css using a limited set of dependencies.
Post reply on HN