3 ms·

I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, we

by cm3 10y ago

I haven't been following WebAssembly, but I've asked myself why, given the elevated level of security threats, there is not effort to design a safer, tinier, web page scripting system. I have the feeling that based on the experience we could streamline and simplify much of the web client stack to allow (1) safer implementations, (2) smaller implementations and (3) less interpretation of the standards.

deleted 10y ago
[deleted]
sievebrain 10y ago
Once upon a time Javascript was tiny. Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs. Could you build a smaller, simpler, safer web? Sure. It's called HTML4.
- cm3 10y ago
  I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement. The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking what we build today building the smallest possible DSL and its engine around it. At some point we have to do a cut like that or we'll have browsers that'll have to support many, many HTML profiles and become monstrosities.
  - vmorgulis 10y ago
    I expect a reboot of the web with wasm. As wasm defines a VM, the browser could become useless.
    - cm3 10y ago
      Given how single page web sites are more or less like Flash in that they don't follow the document model anymore, maybe it's for the best, giving real web pages a chance to revive an effort like XHTML and get us document standards.
wrmsr 10y ago
in my mind, as it is aimed at replacing the sprawling forests of javascript many pages are powered by, wasm pretty clearly addresses your three points. with wasm web applications delivered to browsers can be written in c++, rust, haskell, whatever, and compiled and linked and optimized and profiled and reoptimized on developer machines before deployment to end users. the result of this is that performant applications won't require as much (or any) runtime optimization like javascript engines necessarily do now: - arbitrarily dynamic code needn't be jitted and traced and rejitted to raw machine code at runtime - object structure needn't be inferred and shared and monitored and reshaped - primitive types don't have to be inferred and guarded - functions needn't be inlined and guarded because they are all dynamically bound - objects needn't be tracked and freed and moved around - javascript is weird and irregular. half a point here but just look at the equality table. you can say that 'well formed' javascript eases the pain on these poor beasts but they still have to strive to support as much of the common language as they can, no matter how awful, because it's their job. wasm has to do exactly none of this: - jitting can occur once, at load, statically like the CLR not dynamically like HotSpot or luajit as inlining happened on some jenkins box somewhere. - there are no objects, there are four types and they're all 4 or 8 byte primitives and if you need a gc you baked it into your binary. no vm-level object or allocation headers, no gc-related finalizer bugs. - desugared there's about 20 instructions (expressions). implement those and you've implemented webassembly. standard lib? that was compiled into the binary*. because there's so much less to its job it will be safer, smaller, and more widely consistent than javascript. it's still young and definitely not without its warts but these three points are home runs. * ..ish, but it's definitely more spartan: https://webassembly.github.io/demo/AngryBots/Release/AngryBots.js ... that'll buff out :p edit: wow i suck at HN formatting

by cm3 10y ago

deleted 10y ago

[deleted]

sievebrain 10y ago

Once upon a time Javascript was tiny. Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs. Could you build a smaller, simpler, safer web? Sure. It's called HTML4.

cm3 10y ago
I get what you're saying, but what I meant is that it's surely possible to keep the current features while streamlining it into something coherent, much smaller, and easier to implement. The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking what we build today building the smallest possible DSL and its engine around it. At some point we have to do a cut like that or we'll have browsers that'll have to support many, many HTML profiles and become monstrosities.
- vmorgulis 10y ago
  I expect a reboot of the web with wasm. As wasm defines a VM, the browser could become useless.
  - cm3 10y ago
    Given how single page web sites are more or less like Flash in that they don't follow the document model anymore, maybe it's for the best, giving real web pages a chance to revive an effort like XHTML and get us document standards.

wrmsr 10y ago

in my mind, as it is aimed at replacing the sprawling forests of javascript many pages are powered by, wasm pretty clearly addresses your three points. with wasm web applications delivered to browsers can be written in c++, rust, haskell, whatever, and compiled and linked and optimized and profiled and reoptimized on developer machines before deployment to end users. the result of this is that performant applications won't require as much (or any) runtime optimization like javascript engines necessarily do now: - arbitrarily dynamic code needn't be jitted and traced and rejitted to raw machine code at runtime - object structure needn't be inferred and shared and monitored and reshaped - primitive types don't have to be inferred and guarded - functions needn't be inlined and guarded because they are all dynamically bound - objects needn't be tracked and freed and moved around - javascript is weird and irregular. half a point here but just look at the equality table. you can say that 'well formed' javascript eases the pain on these poor beasts but they still have to strive to support as much of the common language as they can, no matter how awful, because it's their job. wasm has to do exactly none of this: - jitting can occur once, at load, statically like the CLR not dynamically like HotSpot or luajit as inlining happened on some jenkins box somewhere. - there are no objects, there are four types and they're all 4 or 8 byte primitives and if you need a gc you baked it into your binary. no vm-level object or allocation headers, no gc-related finalizer bugs. - desugared there's about 20 instructions (expressions). implement those and you've implemented webassembly. standard lib? that was compiled into the binary*. because there's so much less to its job it will be safer, smaller, and more widely consistent than javascript. it's still young and definitely not without its warts but these three points are home runs. * ..ish, but it's definitely more spartan: https://webassembly.github.io/demo/AngryBots/Release/AngryBots.js ... that'll buff out :p edit: wow i suck at HN formatting