4 ms·

I've never really thought this argument was a good one. "Hey, we've got a pretty terrible system in place, so instead of fixing it, or replacing it with somethi

I've never really thought this argument was a good one. "Hey, we've got a pretty terrible system in place, so instead of fixing it, or replacing it with something better, lets just give up and replace it with something worse!" I think WASM can and will bring a lot of cool stuff to the web, just like JS did. What worries me is that we learned virtually nothing from the mistakes that we made with JS.

wtetzner 9y ago
> What worries me is that we learned virtually nothing from the mistakes that we made with JS. Just out of curiosity, what did you learn from JS's mistakes? What would you like to see happen in place of WASM?
- CaptSpify 9y ago
  This is quick and dirty, but... Giving a lot of power to the server is a bad idea. Users should be able to audit, control and modify how the data is processed in a very granular way. Strong artificial limiters on how many resources something can use. Basically, it should be a fully tunable VM for each process. Readable and modifiable by the end-user, without a lot of hoops to jump through. tl;dr: the more power that the end-user has over the code, the better.
  - wtetzner 9y ago
    Ah, I see. I even mostly agree with you. But it seems unlikely things will go that way. People are motivated by what they can make webapps do, and will take the quickest way to get there. Doing it right, where the end user has the most control, is more work to design and implement, so people won't bother.
    - CaptSpify 9y ago
      Agreed, which is why we need to severely limit what the servers can do with the clients. The security and usability fallout from this is going to be terrible, and it pains me to see the internet I love head this direction just to make a couple bucks.
greenhouse_gas 9y ago
The lesson I learned from JS is that you don't (or at least try not to) hardcode a language as a scripting solution. Especially a not-so-fast one as JS (yes, it's been worked on like crazy over the past decades, but writing fast scripts requires black magic (intimate knowledge of runtime), decades of work by the V8 team and hundreds of engineers)

wtetzner 9y ago

> What worries me is that we learned virtually nothing from the mistakes that we made with JS. Just out of curiosity, what did you learn from JS's mistakes? What would you like to see happen in place of WASM?

CaptSpify 9y ago
This is quick and dirty, but... Giving a lot of power to the server is a bad idea. Users should be able to audit, control and modify how the data is processed in a very granular way. Strong artificial limiters on how many resources something can use. Basically, it should be a fully tunable VM for each process. Readable and modifiable by the end-user, without a lot of hoops to jump through. tl;dr: the more power that the end-user has over the code, the better.
- wtetzner 9y ago
  Ah, I see. I even mostly agree with you. But it seems unlikely things will go that way. People are motivated by what they can make webapps do, and will take the quickest way to get there. Doing it right, where the end user has the most control, is more work to design and implement, so people won't bother.
  - CaptSpify 9y ago
    Agreed, which is why we need to severely limit what the servers can do with the clients. The security and usability fallout from this is going to be terrible, and it pains me to see the internet I love head this direction just to make a couple bucks.

greenhouse_gas 9y ago

The lesson I learned from JS is that you don't (or at least try not to) hardcode a language as a scripting solution. Especially a not-so-fast one as JS (yes, it's been worked on like crazy over the past decades, but writing fast scripts requires black magic (intimate knowledge of runtime), decades of work by the V8 team and hundreds of engineers)