3 ms·

So this is a scripting language on top of a scripting language? It's a bit sad. The idea is cool, but why wasn't it implemented w/ wasm?

capableweb 5y ago
> So this is a scripting language on top of a scripting language? It's a bit sad. What a low-effort takedown. Why don't you at least explain why it's such a sad idea? > The idea is cool, but why wasn't it implemented w/ wasm? How are you planning to interact with the DOM with WASM? Sounds like you know enough to criticize yet don't understand your proposed alternative enough to know why it wouldn't work.
- intc 5y ago
  Via https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom? (for example). For every complex self generated challenge there is an even more complex solution?
  - tbranyen 5y ago
    This is a virtual domain implementation, like React, not interacting with the actual DOM like the demo in the OP. WASM is awesome, but seems like folks don't really understand it and the limitations. I bet DOM access in WASM is totally doable, just gonna be a lot harder than how this project implemented it.
    - intc 5y ago
      "By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this." Quoted from: https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...
samwillis 5y ago
Wasm doesn’t have any built in garbage collector (yet) and so by building on top of Javascript (especially for a language like Lua that has a lot of alignment with it) you are reusing that machinery which is easer. True you could take an existing lua implementation and compile to WASM but then as the other comment explained interacting with the DOM would need to be implemented.
boondaburrah 5y ago
I remember seeing lua for the browser quite some years ago (not sure if it was fengari or not) that worked similarly (include the script and then anything of type `application/lua` would execute using it). I ran into it in 2014. If fengari is that, then I think it predates wasm. Edit: it is not, since my memory is from 2014. However, the git history says fengari was started 5 years ago and wikipedia says wasm came out 4 years ago.
DonHopkins 5y ago
Do tell, what's your definition of a "scripting language" anyway, and what is it about that definition that implies you shouldn't be happy about implementing one scripting language in another scripting language? Especially when the hosted scripting language can take advantage of the garbage collection and the incredible amount of optimizations that have been put into the hosting scripting language. You know there's a reason people have put so much time and effort into optimizing JavaScript. Is there a reason it's sad to take advantage of that? Or would it make you happier if everyone wrote their own garbage collectors and optimizing JIT compilers and portable operating system independent runtimes from scratch every time?

capableweb 5y ago

> So this is a scripting language on top of a scripting language? It's a bit sad. What a low-effort takedown. Why don't you at least explain why it's such a sad idea? > The idea is cool, but why wasn't it implemented w/ wasm? How are you planning to interact with the DOM with WASM? Sounds like you know enough to criticize yet don't understand your proposed alternative enough to know why it wouldn't work.

intc 5y ago
Via https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom? (for example). For every complex self generated challenge there is an even more complex solution?
- tbranyen 5y ago
  This is a virtual domain implementation, like React, not interacting with the actual DOM like the demo in the OP. WASM is awesome, but seems like folks don't really understand it and the limitations. I bet DOM access in WASM is totally doable, just gonna be a lot harder than how this project implemented it.
  - intc 5y ago
    "By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this." Quoted from: https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

samwillis 5y ago

Wasm doesn’t have any built in garbage collector (yet) and so by building on top of Javascript (especially for a language like Lua that has a lot of alignment with it) you are reusing that machinery which is easer. True you could take an existing lua implementation and compile to WASM but then as the other comment explained interacting with the DOM would need to be implemented.

boondaburrah 5y ago

I remember seeing lua for the browser quite some years ago (not sure if it was fengari or not) that worked similarly (include the script and then anything of type `application/lua` would execute using it). I ran into it in 2014. If fengari is that, then I think it predates wasm. Edit: it is not, since my memory is from 2014. However, the git history says fengari was started 5 years ago and wikipedia says wasm came out 4 years ago.

DonHopkins 5y ago

Do tell, what's your definition of a "scripting language" anyway, and what is it about that definition that implies you shouldn't be happy about implementing one scripting language in another scripting language? Especially when the hosted scripting language can take advantage of the garbage collection and the incredible amount of optimizations that have been put into the hosting scripting language. You know there's a reason people have put so much time and effort into optimizing JavaScript. Is there a reason it's sad to take advantage of that? Or would it make you happier if everyone wrote their own garbage collectors and optimizing JIT compilers and portable operating system independent runtimes from scratch every time?