4 ms·

WebAssembly will not displace Server Side languages. "oh but it compiles once and then runs everywhere!!!!"...ceased to be an argument over 15y ago, when it be

WebAssembly will not displace Server Side languages. "oh but it compiles once and then runs everywhere!!!!"...ceased to be an argument over 15y ago, when it became clear that the "backend" is synonymous with linux, and almost every machine has the same architecture. Plus, the time required by the compilation step is not prohibitive in a CI/CD pipeline.

Chris2048 5y ago
I understand that compilation is not an issue, but WDYM by the other stuff? Even python is a bit of a PITA to package and run where interpreters already exist, not all distros are the same - The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. JS, in virtue of being properly sandboxed, seems to be in a position to prevent coupling outside expected interfaces, and hence reduces the scope for compatibility creep. maybe? ...
- usrbinbash 5y ago
  > Even python is a bit of a PITA to package and run where interpreters already exist That's mostly a result of everything and everyone having a different opinion where python modules should live in the filesystem, and the default behavior of a lot of package managing software to replace python installations between versions instead of shoving them into different packages and be done with it. > The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. The same advantage exists for compiled languages, provided that dependencies are either staticaly compiled, unambigously listed, or shipped with the software as a package. A similar effect is achieved in Python Projects by virtualenving everything, essentially stuffing all dependencies, including the correct version of the interpreter, in one location as a single package.
  - Chris2048 5y ago
    there are also differences between lib/interpreter versions (str differences, use of Byte arrays) and stuff like Unicode/crypto support, the c-lib used (e.g. musl). The "provided that" is exactly what I'm sceptical of - if the language is general use, not everyone will play ball unless the language/language-derivative is for the explicit purpose of maintaining this compatibility, and this is somewhat enforced. Python packaging would also be great if it shipped with an unambiguous and bulletproof/portable solution, but it didn't, and then the wheel was (partially) reinvented several times. This is before we even consider bad-actors purposefully attacking (python packages are also susceptible to this I believe).

Chris2048 5y ago

I understand that compilation is not an issue, but WDYM by the other stuff? Even python is a bit of a PITA to package and run where interpreters already exist, not all distros are the same - The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. JS, in virtue of being properly sandboxed, seems to be in a position to prevent coupling outside expected interfaces, and hence reduces the scope for compatibility creep. maybe? ...

usrbinbash 5y ago
> Even python is a bit of a PITA to package and run where interpreters already exist That's mostly a result of everything and everyone having a different opinion where python modules should live in the filesystem, and the default behavior of a lot of package managing software to replace python installations between versions instead of shoving them into different packages and be done with it. > The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. The same advantage exists for compiled languages, provided that dependencies are either staticaly compiled, unambigously listed, or shipped with the software as a package. A similar effect is achieved in Python Projects by virtualenving everything, essentially stuffing all dependencies, including the correct version of the interpreter, in one location as a single package.
- Chris2048 5y ago
  there are also differences between lib/interpreter versions (str differences, use of Byte arrays) and stuff like Unicode/crypto support, the c-lib used (e.g. musl). The "provided that" is exactly what I'm sceptical of - if the language is general use, not everyone will play ball unless the language/language-derivative is for the explicit purpose of maintaining this compatibility, and this is somewhat enforced. Python packaging would also be great if it shipped with an unambiguous and bulletproof/portable solution, but it didn't, and then the wheel was (partially) reinvented several times. This is before we even consider bad-actors purposefully attacking (python packages are also susceptible to this I believe).