Live data from Hacker News

An Abridged Cartoon Introduction To WebAssembly

smashingmagazine.com

81–90 of 107 posts

Re: An Abridged Cartoon Introduction To WebAssembly

#81
Question...

The issue is that JIT js is hard to improve performance on because it's a dynamically typed language. Even with Web Assembly, something will still need to compile down into the bytecode to run. So perf is going to depend on that step in whatever language you write in and how easily that converts and optimizes into web assembly standards.

Does this mean that strongly typed languages have a performance advantage, given that they will be able to easily compile down into optimized typed bytecode?

Re: An Abridged Cartoon Introduction To WebAssembly

#82
post #44

Earlier quoted context omitted.

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

Re: An Abridged Cartoon Introduction To WebAssembly

#83

Earlier quoted context omitted.

The addressable memory space doesn't include code, globals, stack, etc, but only that memory which could be considered the heap. Pointers into memory are 32bit base + 32bit offset, non-wrapping, so 33-bit distances from a base pointer. Each memory access needs a check to that (relatively non-changing) pointer. Memory spaces can request expansion in multiples of 64KB, and can have configured maximum sizes. This leaves…

> The addressable memory space doesn't include code, globals, stack, etc Really? In that case, how does a language like Rust, where stack allocation is used regularly, compile to WASM?

GP is referring to the call stack. It is still possible to use the WASM heap as a stack, by maintaining a stack pointer and a base pointer.

Re: An Abridged Cartoon Introduction To WebAssembly

#84

In 20 years of software development and trying different platforms, JavaScript has been the most frustrating and the most rewarding of all of them. I find a lot of value in using JavaScript as a cross-platform shell. I personally do a lot of work on all of the major operating systems. I primarily (a light primary, like maybe 67%, not 90%) work on Windows, but most of my users are working on macOS. And we're all writi…

It sounds like you want to program in TypeScript.

Re: An Abridged Cartoon Introduction To WebAssembly

#85

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.

> Currently browsers only support JS.

Except Chrome and Firefox, which both support WebAssembly.

Re: An Abridged Cartoon Introduction To WebAssembly

#86
post #77

Earlier quoted context omitted.

Well, possibly no faster than can currently be achieved by asm.js if the JIT likes you, but I think discussions of raw speed miss the point. 1. Parsing text based JS is much slower than parsing something like WASM. 2. Initialising data required for programs can take significant time in JS as that data is just a program that must be parsed and run. 3. Those first two points, along with better type support should help…

> WASM seems to provide a pretty good basis for building many things low level things on, but less useful for higher level languages which might want garbage collection Would it be possible to implement a garbage collector in WASM? And could it be a concurrent garbage collector, using advanced techniques such as memory barriers? It would be cool if we could run e.g. Haskell or Go in WASM. Or even C programs which rel…

Sure, why not implement a GC? There's a heap. You don't need much else.

Re: An Abridged Cartoon Introduction To WebAssembly

#87
post #57

Earlier quoted context omitted.

On the one hand, I hear you and don't disagree - programming ergonomics is a big deal, and access to the language you like is important. I for one really don't want to program in a language that uses significant whitespace, if I can avoid it. On the other hand, "keep up with JS" is something of a misnomer here. It's not javascript that's moving super-fast, it's the web ecosystem (plus the node one, in parallel). It's…

I am not sure I am qualified to really debate the merits of the JS ecosystem; perceived or real at this time. I tried to do front-end stuff when Knockout and Backbone were popular and Node was just starting. Maybe a better phrase is; I had a hard time keeping up... it was the paradigm changes (as you mentioned), but it was also the volume. Paralyzation due to choice and only so much time to evaluate each framework. C…

I think there's room all over for different kinds of ergonomics for software development. Languages play a big role here, for sure, and having access to more languages for the front end feels like it will be good by definition- more choices is usually better. There's a lot lot lot of new stuff for sure in JS, and it can be pretty overwhelming.

I think, though, that you could pretty easily take a break from JS dev and come back and still use the tools you had six or twelve months ago, just fine. For example, I maintain a pretty big angular 1 application that has a lot of pre-1.4 code in it. It runs fine, and I haven't touched my build tooling in over a year. There's still a lot of very relevant questions and answers on stackoverflow and so on.

Now, I may well want to use react or angular4 or something else for my next project, but nothing is stopping me from using angular 1, or backbone, or just plain jquery for that matter. They all still work.

As to the virtual DOM - abstraction libraries are really cool (although the vDOM isn't really that), but they introduce just yet another thing that changes over time. At the end of the day, the DOM is a pretty complicated thing, between its own structure, event models, css, and everything else, so the API to interact with it is going to be complicated no matter what language you use. Most frameworks (backbone, jquery, angular, react, etc) are all just different attempts to manage that complication, and all they ever really do is shove the complication from one place to another, but (for example with functional reactive models) that other place is something a group of people is willing to deal with.

Re: An Abridged Cartoon Introduction To WebAssembly

#88

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'm not entirely convinced that the reason why people aren't using their preferred language is due to the absence of WASM up until now. Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web. I think the reasons why programmers aren't using their preference when coding for web is, firstly because of the lack industry approval/support and second…

> Almost all of the popular programming language have a js transpiler allowing programmers to code in their lang and use it on web.

Because transpilers are an incredibly leaky abstraction. You have to know your language, the language you're transpiling to and quite often you need to know about how that translation occurs.

That's before you even get into the idiomatic differences between languages and libraries.

Re: An Abridged Cartoon Introduction To WebAssembly

#89

In 20 years of software development and trying different platforms, JavaScript has been the most frustrating and the most rewarding of all of them. I find a lot of value in using JavaScript as a cross-platform shell. I personally do a lot of work on all of the major operating systems. I primarily (a light primary, like maybe 67%, not 90%) work on Windows, but most of my users are working on macOS. And we're all writi…

It sounds like you want to program in TypeScript.

TypeScript and I have had many bouts in the past. It is not the solution to my particular problems.

Re: An Abridged Cartoon Introduction To WebAssembly

#90

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.

Post reply on HN