I can't wait for web assembly to get direct access to dom. Javascript cannot be gone soon enough.
What might happen instead is that there will be a sudden burst of front end languages running on WASM, which will allow some front end people to completely avoid Javascript.
It's hard to predict what the adoption of those languages will look like, there's a million factors in play and few of them are technical.
The other great thing is that WASM libraries written in all sorts of languages will be available to all of them.
And finally, to appease your OO concerns, in fact... I became progressively annoyed by the state of the web as it seemed to make heavy adoption of OO patterns (thinking angular). The ML family of programming languages has offered a much better software development experience in typed programming languages since the 1970s. There are already several compilers for those languages targeting JavaScript which are only waiting to target WASM. (WebSharper for F# & C#, ocsigen for OCaml, Scala.js for Scala, I'm sure plenty others).
JavaScript was conceived as Lisp with all the good parts removed. Note that ClojureScript is a delivery of Lisp that target JavaScript. I'm not a Clojure developer myself but I would have to agree that Clojure developers seems to be the most productive programmers out there.
For example, the API between your language and the other language is probably not going to match your languages style. You see it all the time with APIs that seem to be written for java but are in another language.
If the library has to write different APIs for all the different langauges, then that is an additional cost.
Then there is the fact that less people will know a "standard" language, because they will all be using different languages, so they can't contribute back to the libraries that they use so easily. For example, if I am using a scala library and want to change something or commit a bug fix or whatever, I will have to learn scala.
Your second point is fair, however I think programmers tend to stick to their "favourite programming language" like a religion and fail to appreciate that learning a new programming language can be done in 2 weeks while learning the ecosystem of libraries of a platform is a multi-year endeavour. In particular, you'll be able to carry your knowledge of all the WASM libraries you've learned to love when you decide to make a switch from say JS to XXX.
I've been writing Python for longer than I've been writing C#, but I'm nowhere near as productive in Python.
As for the second, there's zillions of things that can explain that and I'm definitely not clear that your being less productive in Python than in C# has anything to do with how much time you've spent on either. Which is the whole point, programming languages aren't equal. Neither are libraries.
If you set aside the time to learn the libraries and narrow it down only to syntax, that certainly the time to learn it will vary from person to person but isn't a multi-month task for anyone. I think you are scoping it in the larger context of non-shared libraries.
The best example I could give would be learning VB.NET when you already know C# (or vice versa).
For basic support these languages need support for GC - some degree of stackwalking if they don't want to use shadow stacks. That support should be coming soon.
But you can't get around the fact that you need to ship a runtime to support these languages, so you're not just shipping your code, but the runtime required to run it.
But a runtime alone doesn't give you fast execution - you need to jit. And JITs require a lot of deep access into the architecture. You need to be able to generate and inject executable code into the program. You need to be able to patch code at runtime. For security purposes you'd ideally like a separate process that manages the codegen to provide fast w^x support for jitcode.
For the forseeable future, any real dynamic language support on the web will require direct runtime support, namely the regular JS engine.
Disclaimer: I'm a JS JIT developer at Mozilla, have worked on the IonMonkey optimizing compiler and did a good chunk of the design and implementation of our baseline JIT.
I'm excited at the prospect of wasm being a portable, tight runtime that'll eventually be a good cross-platform target for writing dynamic language, but there is quite a bit of infrastructure required within wasm before it can support that.
https://github.com/mbasso/asm-dom
You can already call out to small JS code snippets that work on the DOM from WAM, and since DOM manipulation is slow anyway, the small overhead you get for calling into JS won't make a difference. So I'd say, go ahead and manipulate the DOM from WASM, even if WASM supports direct DOM access later it won't make much of a difference (apart from slightly less and cleaner code in the DOM-access library).
JavaScript however is in a way similar to PHP and I'd say more dangerous as, unlike PHP it doesn't have a ugly syntax to warn you.
I've been working in the JS ecosystem lately and suddenly crazy knowledge from my life as PHP programmer turns out to be useful:
- adding statements above a function or a class? No problem: will be run on loading the file just line in PHP.
- == not checking if things are equal? Just use === like in PHP
Thst said I'm really impressed with the ecosystem. It is just JavaScript the language that needs to be replaced.
I guess that is either the "shoot the messenger strategy" or what I said was so horribly wrong I should have seen it myself.
Whoever wonders which one is true can verify for themselves that except for the syntax modern PHP and JavaScript are surprisingly similar: )
The challenges to offering a direct DOM api are numerous. The DOM API uses the full complement of javascript types; whereas WebAssembly only has integers. So you need to either standardize a binary representation of javascript objects, arrays, functions, pointers, etc., or you need to modify all the hundreds of API calls to use different semantics, e.g. a C-style string for a node name, a wasm function-table index for a callback.
References of all kinds would be a huge sticking point, especially with garbage collection involved. If you store them c-style as integers, then how do you dereference them safely, or what if you add 50 to a reference etc. If they're stored as opaque references then that's an entire new system added on to wasm.
All of this could be done in theory, but I don't see it happening with WebAssembly. WebAssembly is a deliberately conservative and simple project. It was partly a reaction to the more aggressive NaCl project which had threads and its own low-level API pepper etc. WebAssembly is moving at the glacial pace typical of browser consensus, and the stakeholders involved don't actually want it to take over the web ecosystem (Apple doesn't want web apps to be as good as App Store apps; Google doesn't want opaque web apps that can't be easily injected with ads and analytics; Mozilla doesn't want the browser to be a simple, commodity VM).
You can find the proposal here: https://github.com/WebAssembly/host-bindings/blob/master/pro...
I thought the idea was to mostly use WebAssembly for parts that are performance critical, not replace all of it?
A UI framework developed exclusively for canvas-apps could probably add many such features.
I am yet to have worked in any web project where stuff like ARIA was even on the requirements list.
In the future machine learning will be applied to detect and disable ads visually.