3 ms·

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 b

by 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
    Thankfully Microsoft thinks otherwise. https://blogs.msdn.microsoft.com/webdev/2018/05/02/blazor-0-3-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/05/02/blazor-0-... https://channel9.msdn.com/Events/Build/2018/BRK2151 https://channel9.msdn.com/Events/Build/2018/BRK2151
_o_ 8y ago
Sorry but I believe you are wrong in basic presumptions. If they will do it properly, in c++ compiled to webassembly scenario, there will be no need for parsing (except some headers). Browser code (V8 in chrome?) will just take the opcodes and execute them, similar as CPU execute machine code in native applications. But normally, if this is a scripting language like, lets say python, that webassembly compiled python "runtime" will need to parse python source code (or not, there are pycs if I remember correctly) and there will be parsing overhead. But for compiled languages there will be "no" overhead (browser on its own is overhead) and in any case far less than for javascript (that really needs to be parsed). Anyway, if you remeber flash, there was one runtime for all flash apps and once you had it, this was it (until next security update :D), and with todays CDNs, it will be no different than, for example, angular. Downloaded once, cached forever.
- hajile 8y ago
  First, I suppose I'm obligated to say that I'm a huge fan of Wasm (and was a huge fan of pnacl for years before that). Wasm (like asm.js before it) is target at unmanaged languages. A C++ codebase likely does very well with good performance. That was not what I was talking about. Convincing a game company to write their games in C++ is trivial. Convincing that same game company to write their normal CRUD website in C++ would be incredibly difficult. Looking at apps, there's still issues. Consider Qt. While it's very possible to write everything in C++, loads of companies jumped straight onto the QML/JS bandwagon because its (generally speaking) much faster to write safe code in JS (also, running the v8 version that Qt requires would be terribly slow compared to the native engine). UI development is hard no matter what and C++ doesn't do it any favors. JS features like closures and dynamic objects make many things easier than static classes functions. This means we need to look away from C++ to something that is managed and has faster code turnaround times. The best possible languages for this are (IMO) Scheme (or maybe Common Lisp) and SML (or maybe Ocaml or F#). You could also make arguments for something in the vein of Dart or Kotlin. How do you bring these languages to wasm? If you use a JIT, you run into a rather large payload (4-10mb of code is going to have obvious impacts). In some cases like Ocaml where a native compiler to wasm is in the works, you still have a GC issue (basically, you can make an advanced GC that is slow or a basic GC that is "fast", but with other issues). The addition of DOM API will solve the GUI issues (and maybe they'll rework them to be more like dart's API). Adding hooks into the builtin GC would reduce payload size down to something closer to unmanaged languages. 10 years after those are added (when outdated browsers can finally be ignored), wasm will finally be ready to replace JS. Adding those features doesn't seem to be highest priority. Unfortunately, you and I will probably be nearing retirement age before they are generally usable. As a point of interest, JS code could be getting much smaller and much faster to parse (plus becoming a better compilation target) with the JS binary AST proposal. https://github.com/binast/ecmascript-binary-ast https://github.com/binast/ecmascript-binary-ast

by hajile 8y ago

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
  Thankfully Microsoft thinks otherwise. https://blogs.msdn.microsoft.com/webdev/2018/05/02/blazor-0-3-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/05/02/blazor-0-... https://channel9.msdn.com/Events/Build/2018/BRK2151 https://channel9.msdn.com/Events/Build/2018/BRK2151

_o_ 8y ago

Sorry but I believe you are wrong in basic presumptions. If they will do it properly, in c++ compiled to webassembly scenario, there will be no need for parsing (except some headers). Browser code (V8 in chrome?) will just take the opcodes and execute them, similar as CPU execute machine code in native applications. But normally, if this is a scripting language like, lets say python, that webassembly compiled python "runtime" will need to parse python source code (or not, there are pycs if I remember correctly) and there will be parsing overhead. But for compiled languages there will be "no" overhead (browser on its own is overhead) and in any case far less than for javascript (that really needs to be parsed). Anyway, if you remeber flash, there was one runtime for all flash apps and once you had it, this was it (until next security update :D), and with todays CDNs, it will be no different than, for example, angular. Downloaded once, cached forever.

hajile 8y ago
First, I suppose I'm obligated to say that I'm a huge fan of Wasm (and was a huge fan of pnacl for years before that). Wasm (like asm.js before it) is target at unmanaged languages. A C++ codebase likely does very well with good performance. That was not what I was talking about. Convincing a game company to write their games in C++ is trivial. Convincing that same game company to write their normal CRUD website in C++ would be incredibly difficult. Looking at apps, there's still issues. Consider Qt. While it's very possible to write everything in C++, loads of companies jumped straight onto the QML/JS bandwagon because its (generally speaking) much faster to write safe code in JS (also, running the v8 version that Qt requires would be terribly slow compared to the native engine). UI development is hard no matter what and C++ doesn't do it any favors. JS features like closures and dynamic objects make many things easier than static classes functions. This means we need to look away from C++ to something that is managed and has faster code turnaround times. The best possible languages for this are (IMO) Scheme (or maybe Common Lisp) and SML (or maybe Ocaml or F#). You could also make arguments for something in the vein of Dart or Kotlin. How do you bring these languages to wasm? If you use a JIT, you run into a rather large payload (4-10mb of code is going to have obvious impacts). In some cases like Ocaml where a native compiler to wasm is in the works, you still have a GC issue (basically, you can make an advanced GC that is slow or a basic GC that is "fast", but with other issues). The addition of DOM API will solve the GUI issues (and maybe they'll rework them to be more like dart's API). Adding hooks into the builtin GC would reduce payload size down to something closer to unmanaged languages. 10 years after those are added (when outdated browsers can finally be ignored), wasm will finally be ready to replace JS. Adding those features doesn't seem to be highest priority. Unfortunately, you and I will probably be nearing retirement age before they are generally usable. As a point of interest, JS code could be getting much smaller and much faster to parse (plus becoming a better compilation target) with the JS binary AST proposal. https://github.com/binast/ecmascript-binary-ast https://github.com/binast/ecmascript-binary-ast