3 ms·

Was that really the intent? I made a longer rant elsewhere in this thread but I sure got the impression it was really for compiler implementers and not for any

Was that really the intent? I made a longer rant elsewhere in this thread but I sure got the impression it was really for compiler implementers and not for anyone really writing in it at all. It’s sort of a false Lisp and a false Forth when I really should have not been afraid of the ARM vs x86 split and brushed up on a real assembly. :)

jasonwatkinspdx 3y ago
WASM grew out of the earlier asm.js, which was explicitly designed as a subset of javascript: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ The core idea there was to identify a subset of JS that was high performance on browsers and could be used as a compile target. WASM appeared because once asm.js got some momentum, people naturally asked "hey if browsers could implement just a couple extra things how much better could we make this?"
- kragen 3y ago
  wasm isn't compatible with asm.js or with js tho they could have totally made it forthier if they thought that was a good idea, but their objective was rapid generation of efficient, secure code
  - jasonwatkinspdx 3y ago
    Except that would be strongly against the familiarity of the community momentum already built.
    - kragen 3y ago
      what they actually came up with was just as strongly against the familiarity of the community momentum already built, wasn't it? what features do you have in mind of the current wasm spec that are (1) in common with asm.js and (2) not in common with a hypothetical more-forth-like spec for efficient secure execution in browsers?