3 ms·

There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once s

by hajile 8y ago

There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.

cm2187 8y ago
The runtime is probably still be a fraction of the bandwidth consumed by all the photos and videos on modern websites. But the web is only one aspect. Web apps are likely going to take over a huge part of client development.
- hajile 8y ago
  Runtime size depends on a few things. The biggest is JIT vs native. If you're willing to dedicate the time to making (or interfacing with) a completely native compiler, then the runtime penalty isn't that large. In contrast, any halfway decent JIT is going to be several MB of code (and unlike an image, has to be parsed and executed -- potentially on slow phones). In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC. https://medium.com/dartlang/dart-on-llvm-b82e83f99a70 https://medium.com/dartlang/dart-on-llvm-b82e83f99a70
pjmlp 8y ago
That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.
- hajile 8y ago
  Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave. Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself). People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features. Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse. Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS. Not a great plan.
  - pjmlp 8y ago
    A plan that is already in motion regardless how much you hate it. Not all languages are like Python, a language that I only use for shell scripts anyway. Blazor, Qt, Unity are all getting there. Adobe can even bring Flash back.
    - hajile 8y ago
      I love the idea of wasm allowing other languages, but it's going to take at least a decade to be usable for anything aside from heavy number crunching with C++. For a webpage, replacing the DOM with UI toolkit X is a pipe dream with problems ranging from aria/accessibility to web crawling and indexing issues. Adobe won't be bringing flash back. It was basically just ES4. ESnext and HTML5 have almost all the good stuff plus quite a bit more while having far better performance than flash could achieve.
      - pjmlp 8y ago
- _o_ 8y ago
  I agree. DOM will come, thinking that GC can not be developed in language the browser (and javascript) is built in is a bit naive (not to mention GC is a complex solution for simple non-problem, I would rather use malloc/new and free/delete + destructors than relying on Terminator Skynet ripped AI doing this really simple task - tribute to java and inability to free memory when needed! Anyway with each tab running in separate process, system will take care about memory leaks ;) ) while the runtime - the last time I checked, the CDNs were serving javascript libraries over mb in size and I really see no problem for them serving python runtime, while for c++, the runtime can be the browser itself and even if you pull in libc or proxy to the existing browser functions, this can be really, really small. Believing that code, that was designed to be human readable (as js), can be shorter than the opcodes doesn't really fit here. I have heard this runtime considerations before but they are taking into account that someone will run webassembly compiled JRE in browser (and I am sure that right now, there are some freaks trying to achieve that). But there is still good old C++ (or Rust) not as productive as scripting languages but this is just due to much less open source "technological stack" (or some might argue, tribute to low quality of software today, "technological garbage") rather of not beeing capable of beeing competitive. I think that the coolest trick that web based technologies pulled out was to convince the world, that the whole GUI needs to be primitive, simplistic, as they were unable to create something that desktop applications were doing for decade (speed/size considerations) and it might just happen that we will return back to owner drawn controls, where you wont be able to make distinction if app is running locally or in browser (no, I don't mean Electron, pun intended). There js will be unable to compete. Anyway, push for webassembly is not here as corporations want to do something good. They want to push all computer users into old mainframe scenario, where you would have to rent space and cpu in a cloud and have just dumb terminal and javascript has hit its limits to replace desktop environment as it is, even with Windows Metro look (another simplification of GUI, done for mainframe scenario, Windows 365 are not far away) Javascript was usefull in era of simplistic web pages as a small hack into html, but for next step we need something more and here there are other languages that can offer much more but are now limited to running in backend as they don't have browser support. But this will change with webassembly.
  - pjmlp 8y ago
    One of those freaks is called Microsoft. https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/ https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...

by hajile 8y ago

cm2187 8y ago

The runtime is probably still be a fraction of the bandwidth consumed by all the photos and videos on modern websites. But the web is only one aspect. Web apps are likely going to take over a huge part of client development.

hajile 8y ago
Runtime size depends on a few things. The biggest is JIT vs native. If you're willing to dedicate the time to making (or interfacing with) a completely native compiler, then the runtime penalty isn't that large. In contrast, any halfway decent JIT is going to be several MB of code (and unlike an image, has to be parsed and executed -- potentially on slow phones). In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC. https://medium.com/dartlang/dart-on-llvm-b82e83f99a70 https://medium.com/dartlang/dart-on-llvm-b82e83f99a70

pjmlp 8y ago

That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.

hajile 8y ago
Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave. Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself). People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features. Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse. Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS. Not a great plan.
- pjmlp 8y ago
  A plan that is already in motion regardless how much you hate it. Not all languages are like Python, a language that I only use for shell scripts anyway. Blazor, Qt, Unity are all getting there. Adobe can even bring Flash back.
  - hajile 8y ago
    I love the idea of wasm allowing other languages, but it's going to take at least a decade to be usable for anything aside from heavy number crunching with C++. For a webpage, replacing the DOM with UI toolkit X is a pipe dream with problems ranging from aria/accessibility to web crawling and indexing issues. Adobe won't be bringing flash back. It was basically just ES4. ESnext and HTML5 have almost all the good stuff plus quite a bit more while having far better performance than flash could achieve.
    - pjmlp 8y ago
_o_ 8y ago
I agree. DOM will come, thinking that GC can not be developed in language the browser (and javascript) is built in is a bit naive (not to mention GC is a complex solution for simple non-problem, I would rather use malloc/new and free/delete + destructors than relying on Terminator Skynet ripped AI doing this really simple task - tribute to java and inability to free memory when needed! Anyway with each tab running in separate process, system will take care about memory leaks ;) ) while the runtime - the last time I checked, the CDNs were serving javascript libraries over mb in size and I really see no problem for them serving python runtime, while for c++, the runtime can be the browser itself and even if you pull in libc or proxy to the existing browser functions, this can be really, really small. Believing that code, that was designed to be human readable (as js), can be shorter than the opcodes doesn't really fit here. I have heard this runtime considerations before but they are taking into account that someone will run webassembly compiled JRE in browser (and I am sure that right now, there are some freaks trying to achieve that). But there is still good old C++ (or Rust) not as productive as scripting languages but this is just due to much less open source "technological stack" (or some might argue, tribute to low quality of software today, "technological garbage") rather of not beeing capable of beeing competitive. I think that the coolest trick that web based technologies pulled out was to convince the world, that the whole GUI needs to be primitive, simplistic, as they were unable to create something that desktop applications were doing for decade (speed/size considerations) and it might just happen that we will return back to owner drawn controls, where you wont be able to make distinction if app is running locally or in browser (no, I don't mean Electron, pun intended). There js will be unable to compete. Anyway, push for webassembly is not here as corporations want to do something good. They want to push all computer users into old mainframe scenario, where you would have to rent space and cpu in a cloud and have just dumb terminal and javascript has hit its limits to replace desktop environment as it is, even with Windows Metro look (another simplification of GUI, done for mainframe scenario, Windows 365 are not far away) Javascript was usefull in era of simplistic web pages as a small hack into html, but for next step we need something more and here there are other languages that can offer much more but are now limited to running in backend as they don't have browser support. But this will change with webassembly.
- pjmlp 8y ago
  One of those freaks is called Microsoft. https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/ https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...