6 ms·

I can't wait for web assembly to get direct access to dom. Javascript cannot be gone soon enough.

flohofwoe 8y ago
There are already several libs that compile to WebAssembly and let you manipulate the DOM, e.g. https://github.com/mbasso/asm-dom 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).
oblio 8y ago
There's probably billions of lines of Javascript code out there, code many people paid a lot of money to be written. Javascript isn't going anywhere. 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.
- davidgrenier 8y ago
  Most of said languages are already adopted. You can expect languages running server-side to target WebAssembly first. The other great thing is that WASM libraries written in all sorts of languages will be available to all of them.
  - oblio 8y ago
    Most of the pre-existing server side come with their own baggage. PHP powers most of the internet, just saying :)
    - davidgrenier 8y ago
      I don't have a problem using good WASM libraries that were written in PHP. To target WASM, a PHP compiler would have to respect the WASM semantics which is what I will consume.
      - RussianCow 8y ago
        For a dynamic language to run on WASM, you would have to bundle its runtime with your application, which is probably a deal-breaker for many use cases.
  - amelius 8y ago
    There are still problems with WASM in the areas of multithreading, shared data structures, and memory barriers (think advanced/concurrent GC implementations). Because of this, languages do not automatically, cleanly and efficiently map to WASM yet.
pjmlp 8y ago
Besides what WebAssembly offers as general purpose VM, in an ideal world TypeScript would take JavaScript's place.
- 18973294 8y ago
  Why would it do that? Javascript is more appropriate in the early stages of a project. You don't want to go to the trouble of declaring types everywhere only to realize everything has to change. Once you stabilize you can add in typescript, which is the great thing about it.
  - pjmlp 8y ago
    Some of us only see a value in dynamic typing for shell scripts, burned too many times in large code bases.
  - phillipburch 8y ago
    No matter what stage of the project, you're implicitly writing code to a specific type whether you know it or not. Typescript just makes types explicit, and makes clear all the places you've made type assumptions. So if you need to change types later in the project, you can do so with confidence knowing that you've handled all the cases you made type assumptions.
  - lucian1900 8y ago
    It is precisely when you want to change everything that types are useful, because the compiler will helpfully point you to all cases that you forgot to change.
18973294 8y ago
I like javascript and think a lot of other people do as well so it probably won't go away just because of web assembly. I don't see too many people writing c# in browsers. I worked with c# backend and javascript front-end for 4 years and got sick of having to create classes for no other reason than because c# needed a type and other things like that.
- davidgrenier 8y ago
  The independence WebAssembly brings it that you'll still be able to use JavaScript whether or not you are using a compiler targeting WASM and giving everybody else the liberty of that choice. What's also great, is that even if you stick to your guns, you'll be able to use libraries written in other languages targeting WebAssembly. 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.
  - davidgrenier 8y ago
    Oh and I forgot to mention: Elm (also an ML), TypeScript and what already looks to be Rust/Go/C/C++ already targeting WASM.
  - 18973294 8y ago
    There must be a cost involved in everybody using different languages even though you can use the libraries of any language. 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.
imjasonmiller 8y ago
Wouldn’t a UI in WebAssembly make it impossible to block ads? The recent QT announcement renders to Canvas doesn’t it? I thought the idea was to mostly use WebAssembly for parts that are performance critical, not replace all of it?
- shawnz 8y ago
  This has always been possible if you just write sufficiently obfuscated JavaScript. However a UI that is entirely rendered in a canvas element would basically be unusable by anyone with a disability, so that technique is useless for big orgs.
  - gnode 8y ago
    The cynic in me can't help but expect most web companies to care more about pushing unblockable ads down everyone's throats than about the disabled.
    - acdha 8y ago
      That’s why decent countries have regulation to make them care about things other than short-term profit.
  - jopsen 8y ago
    What stopping anyone from adding accessibility features to single element canvas apps? A UI framework developed exclusively for canvas-apps could probably add many such features.
  - pjmlp 8y ago
    It is not correct, but most big orgs don't care about those details unless they are legally enforced by the government. I am yet to have worked in any web project where stuff like ARIA was even on the requirements list.
  - Ajedi32 8y ago
    Unless they spent a _ton_ of effort re-implementing the DOM/native browser UI in canvas, it'd probably be basically unusable by anyone without a disability too.
ZitchDog 8y ago
Java didn't go away when the JVM got invokedynamic. JS will be the default language of the web for some time - although it's great that other languages can now be citizens.
- reitanqild 8y ago
  But Java is an actual well designed language. A bit verbose yes. Lacking generics early on, yes. 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.
  - reitanqild 8y ago
    Multiple downvotes, no correction. 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: )
draw_down 8y ago
I always love when you guys drop the “best tool for the job” routine, and say how you really feel. ;)
H1Supreme 8y ago
I'm all for this, but I'll hold my breath until I see a responsive GUI emerge.
- volvopriced 8y ago
  yeah
jhpriestley 8y ago
So my estimate is that this is going to happen approximately never. 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).
- steveklabnik 8y ago
  Direct DOM access is a pretty high priority for the Wasm folks; that said, the consistent message of WebAssembly since forever has been augment, not replace. You can find the proposal here: https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...
- amelius 8y ago
  Yes, we first need to define an ABI. But that can be quite simple. Passing floats, for example could be done by passing the bytes that define the IEEE float. For strings, you could pass UTF-8. Etc.
rasz 8y ago
I also cant wait for binary blob websites.

There are already several libs that compile to WebAssembly and let you manipulate the DOM, e.g. https://github.com/mbasso/asm-dom 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).

oblio 8y ago

There's probably billions of lines of Javascript code out there, code many people paid a lot of money to be written. Javascript isn't going anywhere. 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.

davidgrenier 8y ago
Most of said languages are already adopted. You can expect languages running server-side to target WebAssembly first. The other great thing is that WASM libraries written in all sorts of languages will be available to all of them.
- oblio 8y ago
  Most of the pre-existing server side come with their own baggage. PHP powers most of the internet, just saying :)
  - davidgrenier 8y ago
    I don't have a problem using good WASM libraries that were written in PHP. To target WASM, a PHP compiler would have to respect the WASM semantics which is what I will consume.
    - RussianCow 8y ago
      For a dynamic language to run on WASM, you would have to bundle its runtime with your application, which is probably a deal-breaker for many use cases.
- amelius 8y ago
  There are still problems with WASM in the areas of multithreading, shared data structures, and memory barriers (think advanced/concurrent GC implementations). Because of this, languages do not automatically, cleanly and efficiently map to WASM yet.

pjmlp 8y ago

Besides what WebAssembly offers as general purpose VM, in an ideal world TypeScript would take JavaScript's place.

18973294 8y ago
Why would it do that? Javascript is more appropriate in the early stages of a project. You don't want to go to the trouble of declaring types everywhere only to realize everything has to change. Once you stabilize you can add in typescript, which is the great thing about it.
- pjmlp 8y ago
  Some of us only see a value in dynamic typing for shell scripts, burned too many times in large code bases.
- phillipburch 8y ago
  No matter what stage of the project, you're implicitly writing code to a specific type whether you know it or not. Typescript just makes types explicit, and makes clear all the places you've made type assumptions. So if you need to change types later in the project, you can do so with confidence knowing that you've handled all the cases you made type assumptions.
- lucian1900 8y ago
  It is precisely when you want to change everything that types are useful, because the compiler will helpfully point you to all cases that you forgot to change.

18973294 8y ago

I like javascript and think a lot of other people do as well so it probably won't go away just because of web assembly. I don't see too many people writing c# in browsers. I worked with c# backend and javascript front-end for 4 years and got sick of having to create classes for no other reason than because c# needed a type and other things like that.

davidgrenier 8y ago
The independence WebAssembly brings it that you'll still be able to use JavaScript whether or not you are using a compiler targeting WASM and giving everybody else the liberty of that choice. What's also great, is that even if you stick to your guns, you'll be able to use libraries written in other languages targeting WebAssembly. 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.
- davidgrenier 8y ago
  Oh and I forgot to mention: Elm (also an ML), TypeScript and what already looks to be Rust/Go/C/C++ already targeting WASM.
- 18973294 8y ago
  There must be a cost involved in everybody using different languages even though you can use the libraries of any language. 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.

imjasonmiller 8y ago

Wouldn’t a UI in WebAssembly make it impossible to block ads? The recent QT announcement renders to Canvas doesn’t it? I thought the idea was to mostly use WebAssembly for parts that are performance critical, not replace all of it?

shawnz 8y ago
This has always been possible if you just write sufficiently obfuscated JavaScript. However a UI that is entirely rendered in a canvas element would basically be unusable by anyone with a disability, so that technique is useless for big orgs.
- gnode 8y ago
  The cynic in me can't help but expect most web companies to care more about pushing unblockable ads down everyone's throats than about the disabled.
  - acdha 8y ago
    That’s why decent countries have regulation to make them care about things other than short-term profit.
- jopsen 8y ago
  What stopping anyone from adding accessibility features to single element canvas apps? A UI framework developed exclusively for canvas-apps could probably add many such features.
- pjmlp 8y ago
  It is not correct, but most big orgs don't care about those details unless they are legally enforced by the government. I am yet to have worked in any web project where stuff like ARIA was even on the requirements list.
- Ajedi32 8y ago
  Unless they spent a _ton_ of effort re-implementing the DOM/native browser UI in canvas, it'd probably be basically unusable by anyone without a disability too.

ZitchDog 8y ago

Java didn't go away when the JVM got invokedynamic. JS will be the default language of the web for some time - although it's great that other languages can now be citizens.

reitanqild 8y ago
But Java is an actual well designed language. A bit verbose yes. Lacking generics early on, yes. 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.
- reitanqild 8y ago
  Multiple downvotes, no correction. 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: )

draw_down 8y ago

I always love when you guys drop the “best tool for the job” routine, and say how you really feel. ;)

H1Supreme 8y ago

I'm all for this, but I'll hold my breath until I see a responsive GUI emerge.

volvopriced 8y ago
yeah

jhpriestley 8y ago

So my estimate is that this is going to happen approximately never. 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).

steveklabnik 8y ago
Direct DOM access is a pretty high priority for the Wasm folks; that said, the consistent message of WebAssembly since forever has been augment, not replace. You can find the proposal here: https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...
amelius 8y ago
Yes, we first need to define an ABI. But that can be quite simple. Passing floats, for example could be done by passing the bytes that define the IEEE float. For strings, you could pass UTF-8. Etc.

rasz 8y ago

I also cant wait for binary blob websites.