4 ms·

and js. eventually!

by 45h34jh53k4j 9y ago

and js. eventually!

austincheney 9y ago
JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.
- stcredzero 9y ago
  JS is a language and not a bytecode media. That's an arbitrary distinction that's driven by developer group politics, not a meaningful technical distinction. (Much like the old Rubyist, "It's an interpreter, not a VM.") Machine languages were originally intended to be used by human beings, as were punch cards and assembly language. There's no reason why a person couldn't program in bytecode. In fact, to implement certain kinds of language runtime, you basically have to do something close to this. Also, writing Forth is kinda close to directly writing in Smalltalk bytecode. History also shows us that what the language was intended for is also pretty meaningless. x86, like a lot of CISC ISAs, was originally designed to be used by human beings. SGML/XML was intended to be human readable, and many would debate that it succeeded.
  - austincheney 9y ago
    > That's an arbitrary distinction that's driven by developer group politics Not at all. JavaScript is a textual language defined by a specification. Modern JavaScript does have a bytecode, but it is completely proprietary to the respective JIT compiler interpreting the code and utterly unrelated to the language's specification. > There's no reason why a person couldn't program in bytecode. True, but that isn't this discussion.
    - tree_of_item 9y ago
      The point is that a "textual language defined by a specification" can serve the exact same purpose that a bytecode does. And JavaScript is very much on this path. That is this discussion, because the fact that people program directly in JavaScript does not prevent it from being in the same class of things as a bytecode.
- mastax 9y ago
  Yes but the point is JavaScript as the "one true way to do client side scripting" can be replaced by webassembly in that capacity.
  - austincheney 9y ago
    It cannot. WebAssembly bytecode does not have an API to web objects or the DOM. It is literally a sandbox for running bytecode only.
- fasquoika 9y ago
  >JS is a language and not a bytecode media Does it even matter when most people are using it as a compiler target (even just from newer versions of the language)?
- sli 9y ago
  I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense. It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folks will, replace Javascript. [1]: https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md [2]: https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom
  - austincheney 9y ago
    > It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access I am not going to say never. It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority. Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security so that people who are JavaScript challenged can feel less insecure.
    - wootness 9y ago
      It's not about being "javascript challenged", it's about wanting to use a non-crappy language riddled with problems.
    - tptacek 9y ago
      Which of the security concerns browser Javascript deals with do you think are intrinsic to the language, as opposed to the bindings the browser provides the language? If the security issues are in the bindings (ie: when and how I'll allow you to originate a request with credentials in it), those concerns are "portable" between languages.
      - austincheney 9y ago
        It isn't due to the language but to context of known APIs provided to the language that can only be executed a certain way by the language. How would a browser know to restrict a web server compiled into bytecode specifically to violate same origin? The browser only knowns to restrict this from JavaScript because such capabilities are allowed only from APIs the browser provides to JavaScript.
- sdfh238 9y ago
  I love it when computer nerds get so convinced ephemeral things are exactly that which they claim

and js. eventually!

austincheney 9y ago

JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.

stcredzero 9y ago
JS is a language and not a bytecode media. That's an arbitrary distinction that's driven by developer group politics, not a meaningful technical distinction. (Much like the old Rubyist, "It's an interpreter, not a VM.") Machine languages were originally intended to be used by human beings, as were punch cards and assembly language. There's no reason why a person couldn't program in bytecode. In fact, to implement certain kinds of language runtime, you basically have to do something close to this. Also, writing Forth is kinda close to directly writing in Smalltalk bytecode. History also shows us that what the language was intended for is also pretty meaningless. x86, like a lot of CISC ISAs, was originally designed to be used by human beings. SGML/XML was intended to be human readable, and many would debate that it succeeded.
- austincheney 9y ago
  > That's an arbitrary distinction that's driven by developer group politics Not at all. JavaScript is a textual language defined by a specification. Modern JavaScript does have a bytecode, but it is completely proprietary to the respective JIT compiler interpreting the code and utterly unrelated to the language's specification. > There's no reason why a person couldn't program in bytecode. True, but that isn't this discussion.
  - tree_of_item 9y ago
    The point is that a "textual language defined by a specification" can serve the exact same purpose that a bytecode does. And JavaScript is very much on this path. That is this discussion, because the fact that people program directly in JavaScript does not prevent it from being in the same class of things as a bytecode.
mastax 9y ago
Yes but the point is JavaScript as the "one true way to do client side scripting" can be replaced by webassembly in that capacity.
- austincheney 9y ago
  It cannot. WebAssembly bytecode does not have an API to web objects or the DOM. It is literally a sandbox for running bytecode only.
fasquoika 9y ago
>JS is a language and not a bytecode media Does it even matter when most people are using it as a compiler target (even just from newer versions of the language)?
sli 9y ago
I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense. It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folks will, replace Javascript. [1]: https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md [2]: https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom
- austincheney 9y ago
  > It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access I am not going to say never. It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority. Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security so that people who are JavaScript challenged can feel less insecure.
  - wootness 9y ago
    It's not about being "javascript challenged", it's about wanting to use a non-crappy language riddled with problems.
  - tptacek 9y ago
    Which of the security concerns browser Javascript deals with do you think are intrinsic to the language, as opposed to the bindings the browser provides the language? If the security issues are in the bindings (ie: when and how I'll allow you to originate a request with credentials in it), those concerns are "portable" between languages.
    - austincheney 9y ago
      It isn't due to the language but to context of known APIs provided to the language that can only be executed a certain way by the language. How would a browser know to restrict a web server compiled into bytecode specifically to violate same origin? The browser only knowns to restrict this from JavaScript because such capabilities are allowed only from APIs the browser provides to JavaScript.
sdfh238 9y ago
I love it when computer nerds get so convinced ephemeral things are exactly that which they claim