11 ms·

Is there any limitation or reason for not implementing WASM on nodejs?

pizlonator 9y ago
Is there any limitation of reason for forcing people to rewrite their Node.js apps in something else just to get modern features?
- gcb0 9y ago
  in this case, yes, a feature that breaks backward compatibility. So someone suggested rewriting in another language, since the new feature will not fit the only advantage nodejs have: same language as browser. The alternative is to rewrite in a type of JS that will not run on the browser either.
  - pizlonator 9y ago
    Te proposal for concurrency in the post does not break backward compatibility.
stupidcar 9y ago
Of course not, and hopefully it will come to V8, but its mere existence does not preclude enhancing JavaScript, any more than the existence of PInvoke or JNI precludes enhancing .NET and Java. When people say "JS shouldn't support feature X", when feature X is supported in every other serious language, I can't help but guess that their real problem is with JS itself, and they just don't think people should be using it at all. Fine, if that's their opinion, but they should come right out and say it.
- pizlonator 9y ago
  So true! Lots of people actually like using JS. I think it makes sense to understand what features can be added to this language.
- chrisco255 9y ago
  Well for me it adds complexity to JS. One nice thing about JS is that it is single threaded and you don't have to deal with locks or inconsistencies there. An entire class of problems goes away, and since JS event loop is reasonably fast as it is, it's pretty nice not having to worry about concurrency.
  - threatofrain 9y ago
    I would think that it's owing to the frequently single-threaded context of JS that concurrency becomes even more vital for maintaining the liveliness of your app. I also think that identifying aspects of concurrency often means free parallelism speedups, and the user doesn't even have to be aware -- no extra mental price.
Ajedi32 9y ago
No. In fact, AFAIK it's already implemented on Node, behind the --expose-wasm flag: http://thecodebarbarian.com/getting-started-with-webassembly-in-node.js.html http://thecodebarbarian.com/getting-started-with-webassembly...
thehardsphere 9y ago
There may or may not be, but that doesn't address that Node.js was created to specifically avoid a threaded concurrency model in the first place.
jensvdh 9y ago
What's the point? Why not write your server directly in say Python or Java then? I thought WASM is meant to get around the restriction that the browser only understands JS right now.
- pitaj 9y ago
  > why not use X Because X doesn't run in a browser
  - kornakiewicz 9y ago
    Do you need to run your server in a browser?
    - geldan 9y ago
      No, but it's very nice to be able to share code for things like view rendering or form validation between the server and client without jumping through hoops.
      - shurcooL 9y ago
        So you use language X. Compile it and run it natively on server, compile it to wasm and run that in the browser.
        chr1 9y ago
        Why should i use language X that i don't like, instead of nice dynamic language, without compilation step that i like, and which only misses this tiny feature?

Is there any limitation of reason for forcing people to rewrite their Node.js apps in something else just to get modern features?

gcb0 9y ago
in this case, yes, a feature that breaks backward compatibility. So someone suggested rewriting in another language, since the new feature will not fit the only advantage nodejs have: same language as browser. The alternative is to rewrite in a type of JS that will not run on the browser either.
- pizlonator 9y ago
  Te proposal for concurrency in the post does not break backward compatibility.

stupidcar 9y ago

Of course not, and hopefully it will come to V8, but its mere existence does not preclude enhancing JavaScript, any more than the existence of PInvoke or JNI precludes enhancing .NET and Java. When people say "JS shouldn't support feature X", when feature X is supported in every other serious language, I can't help but guess that their real problem is with JS itself, and they just don't think people should be using it at all. Fine, if that's their opinion, but they should come right out and say it.

pizlonator 9y ago
So true! Lots of people actually like using JS. I think it makes sense to understand what features can be added to this language.
chrisco255 9y ago
Well for me it adds complexity to JS. One nice thing about JS is that it is single threaded and you don't have to deal with locks or inconsistencies there. An entire class of problems goes away, and since JS event loop is reasonably fast as it is, it's pretty nice not having to worry about concurrency.
- threatofrain 9y ago
  I would think that it's owing to the frequently single-threaded context of JS that concurrency becomes even more vital for maintaining the liveliness of your app. I also think that identifying aspects of concurrency often means free parallelism speedups, and the user doesn't even have to be aware -- no extra mental price.

Ajedi32 9y ago

No. In fact, AFAIK it's already implemented on Node, behind the --expose-wasm flag: http://thecodebarbarian.com/getting-started-with-webassembly-in-node.js.html http://thecodebarbarian.com/getting-started-with-webassembly...

thehardsphere 9y ago

There may or may not be, but that doesn't address that Node.js was created to specifically avoid a threaded concurrency model in the first place.

jensvdh 9y ago

What's the point? Why not write your server directly in say Python or Java then? I thought WASM is meant to get around the restriction that the browser only understands JS right now.

pitaj 9y ago
> why not use X Because X doesn't run in a browser
- kornakiewicz 9y ago
  Do you need to run your server in a browser?
  - geldan 9y ago
    No, but it's very nice to be able to share code for things like view rendering or form validation between the server and client without jumping through hoops.
    - shurcooL 9y ago
      So you use language X. Compile it and run it natively on server, compile it to wasm and run that in the browser.
      - chr1 9y ago
        Why should i use language X that i don't like, instead of nice dynamic language, without compilation step that i like, and which only misses this tiny feature?