9 ms·

> A web without javascript would be welcome. Why? What is it that wasm or c++ provides you in making a DOM call that modern JS does not?

pjmlp 8y ago
The 2nd coming of Flash?
- knightofmars 8y ago
  You may have said this in jest and are getting down-voted for it but this isn't an impossible scenario. I think of this article in relation to what WebAssembly means. https://dzone.com/articles/java-getting-back-to-the-browser https://dzone.com/articles/java-getting-back-to-the-browser
  - pjmlp 8y ago
    I trully believe it will happen in a couple of years, unless browser vendors change course regarding WebAssembly. Ongoing POC of running Unity games, .NET, Go, Qt and many others already show it is the direction many are moving into.
    - knightofmars 8y ago
      I agree and think it's amazing. I'm looking forward to that day and when it comes. The other side is that it's also likely to open up a whole new avenue for web based security exploits.
      - pjmlp 8y ago
        One issue regarding security is that until WebAssembly gets some kind of fat pointers or tagging, modules generated by unsafe languages can be exploited by corrupting internal state, thus changing the behaviour of exported entry points. You can easily test it by creating a WebAssembly module in C with a function that overwrites an internal memory buffer, placed besides other data, which is used to parametrize behaviour of another function, for example a boolean stating that the user is authenticated.
        Rusky 8y ago
        "Some kind of fat pointers or tagging" is exactly the sort of thing WebAssembly was created to get away from. You can use a language that provides them and targets WebAssembly, without taking away the thing that makes the platform uniquely useful.
        pjmlp 8y ago
        Right, but how can you trust a WebAssembly library? It might have been compiled from Ada, Rust or plain C, just as an example. Telling just to use a language we trust is not an option if one is just using other people libraries. Thus bringing to the web the same security level as depending on regular native libraries, because a regular user is not going to check what a web page depends on.
        danShumway 8y ago
        If you're bringing in multiple separate WASM libraries, they'll run separately from each other. Don't give them access to any memory they shouldn't have access to. Note that this is considerably better than Javascript, because without going out of your way to make an iframe, separate Javascript scripts aren't isolated from each other, so you don't know if one of them is modifying a prototype or hooking around other variables in the global scope. By default, separate WASM modules don't have access to the same memory.
        pjmlp 8y ago
        The whole point is about corrupting WASM modules INTERNAL memory via public exported functions, just because they happen to have typical out-of-bounds errors. Linux Security Summit 2018 had a report that 68% of kernel exploits are caused by out-of-bounds errors. User space doesn't write on kernel level, but can call syscalls, which happen to trigger such exploits. WebAssembly is no different, regardless how they are sandboxed between modules.
        danShumway 8y ago
      - kbenson 8y ago
        > I'm looking forward to that day and when it comes. That is the day where the open web is a little closer to dead. Possibly a lot closer. The move away from flash was a move towards empowering users. That did cost a little bit for developers, as they had worse tools to control the experience, but that also meant that it was more likely (eventually) that the experience they did develop would work in more cases. How many flash sites dealt with different size displays well, or dynamically resized and flowed correctly? How many worked with screen readers? That's one of the benefits we've reaped by pushing the framework to the browser, and using open standards. Items that traditionally would haven't gotten much attention were also seen as important, and saw advances. I don't know how much some random React-like framework that just draws on the canvas would focus on screen reader support, but I suspect it wouldn't be high on their priority list. And even if it is on theirs, what about the 5 other main competitors that will be sharing market space with it? I just hope that the sites that opt for these types of system are few and far between, and have specific operating needs that make it worthwhile. I think it's good that we can, but usually we shouldn't.
        Bizarro 8y ago
        WebAssembly can't close the open web anymore than it's already closed today. The vast majority of JS in the browser today is minified jibberish. WebAssembly doesn't take away HTML and CSS.
        kbenson 8y ago
        WebAssembly makes it much more feasible to implement your own layout and display engine on top of a canvas element.
        Bizarro 8y ago
        Why more feasible?
        kbenson 8y ago
        Because an application like that is both computationally expensive and expensive to ship as a runtime. WebAssembly can provide benefits in both cases (WASM binaries can be close an order of magnitude smaller than equivalent JS code, in select cases), and is quick to start. As a simple example, it's not impossible that Adobe could literally take the flash VM code, compile to WASM with emscripten, and ship it along with an SWF file and a little setup code. This completely bypasses the need for a browser plugin for flash. Now, I suspect the flash VM might be large enough to make this noticeable, but it probably wouldn't be hard for Adobe to streamline it, and then re-purpose a lot of those tools used to build flash that everyone loves to rave about... I believe there are financial incentives for this to happen, therefore I think it's only a matter of time until it does.
    - danShumway 8y ago
      For what it's worth, I think I remember that .NET is still using reasonable web standards under the hood. It's a framework, but it's still using CSS/HTML for actual rendering. If I'm remembering correctly, I wouldn't put that in the same category as Unity and Qt.
      - pjmlp 8y ago
        Unity is also .NET, and then there is UNO as well, UWP for WebAssembly https://playground.platform.uno/ https://playground.platform.uno/
        danShumway 8y ago
        Blazor[0] was what I was referring to, but you're right, I shouldn't treat .NET like it's only being used in that context. [0]: https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/ https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-start...
- danShumway 8y ago
  Hopefully not. Some devs are treating WASM as an entire runtime and outputing canvas/webGL code. I think that is mostly a mistake, and I'll be very disappointed if that becomes the defacto approach for new web devs. However, the cool thing about WASM is that it's just the code part. So you can build an app that's still normal CSS/HTML, just like every web-app should be, and then you can replace all of your JS with WASM (with the current exception of a little bit of JS-to-DOM binding code which Mozilla has promised to eventually get rid of). In the world of Flash/Java you're essentially working in a completely separate platform, it just happens to be launched from a web browser. So shortcuts don't work, accessibility is awful, users can't customize the page, extensions are broken, etc, etc... With WASM, you don't have to be in that position. You can say, "I'm a web developer, I treat the web like a medium, I write responsive HTML/CSS. I just use C instead of Javascript."
  - pjmlp 8y ago
    > In the world of Flash/Java you're essentially working in a completely separate platform, it just happens to be launched from a web browser. So shortcuts don't work, accessibility is awful, users can't customize the page, extensions are broken, etc, etc... True, but until Web development catches up with the state of Flash and other native RAD GUI designers, it is a very attractive proposition. One thing I hate when doing web development is playing around with CSS and tag soup while trying to make it work the same way across all target platforms required by the customer, that in native code would be a couple of graphical calls to the visualization engine and platform widgets, which also provide layout managers. Stuff like Web Components and Houdini would make it better, but who knows when they will be widely available.
    - danShumway 8y ago
      > while trying to make it work the same way across all target platforms This goes back to what I was talking about with treating the web like a medium, not a distribution platform. Fundamentally, the web is about giving you a "controlled" way to give up control. The native paradigm is "I want control over what each individual pixel looks like", and the web paradigm is, "heck off, well-written apps don't do that." I understand why it's attractive, and why it'll continue to be attractive. And I highly agree about Houdini being an exciting development (I don't personally think that Web Components are offering much, but whatever). I'm really looking forward to being able to polyfill CSS. But that difference you're talking about is probably not ever going to go away completely, because the web is optimizing to solve different problems than most native frameworks. Not to say one approach is better than the other (Flash had some legitimate use cases), but I find that there is an actual cultural difference between how web-apps and native apps are designed and how they balance between user control and developer control. It's not just technology.
- finchisko 8y ago
  This is one of my nightmares. But considering how much devs hate js it's inevitable. I almost see it. HTML replaced with some binary WASM bs framework.
  - wetpaws 8y ago
    Then someone will reimplement a dom and a script language in wasm. History is going in circles.
    - Felz 8y ago
      Not quite a circle. There'd be progress in that you could choose your "Javascript" and "DOM", which really opens up a lot of possibility for progress. No need to force eternal compatibility or put up with bad APIs- just pick a better version.
      - v_lisivka 8y ago
        This! You will be able to implement your own browser in the browser, with your own brand new accessibility API, i18n and l17n API's, and your own bugs, of course. We can compile Chrome or WebKit into Wasm and then use them everywhere, even in Firefox!
  - krapp 8y ago
    But you'd still need a browser that supports HTML to load the WASM and display it. Realistically, that would be not much different than current sites using JS, or Flash when that was a thing, or even Java applets. None of those deprecated or replaced HTML, and WASM won't either. At worse, it will be just another thing you can block with a script blocker.
- cm2187 8y ago
  Minified javascript does as much to obfuscate the code than wasm if your concern is the black box model.
  - v_lisivka 8y ago
    I can reformat minified JS, then pause at a function, see it arguments, understand it purpose, rename variables, add a comment, and so on. Can I do all that in Wasm? For practical purposes of reverse engineering, minified JS is far better than Wasm. Wasm is the new Flash.
- mr_toad 8y ago
  Hopefully without the Swiss cheese security.
_wmd 8y ago
Choice The ability to use existing non-JS code The ability to write loops involving non-trivial computations without spamming a hundred million heap objects etc.
- CyberDildonics 8y ago
  > The ability to write loops involving non-trivial computations without spamming a hundred million heap objects How does being able to call the DOM from webasm give you that? That's what webasm is for in the first place.
  - _wmd 8y ago
    > > > Why? What is it that wasm or c++ provides you in making a DOM call that modern JS does not? > > The ability to write loops involving non-trivial computations without spamming a hundred million heap objects > How does being able to call the DOM from webasm give you that? That's what webasm is for in the first place. The tell parent comment that, not me.
  - icebraining 8y ago
    I think the idea is that they can't use webasm (exclusively) to do that without also being able to call the DOM from it.
Spivak 8y ago
Wasm promises a better compiler target than JS for alternative languages. It always seems odd to me that JS is so heavily defended when pretty much everything that makes up a modern JS stack are other compile-to-js languages: JSX, Elm, TypeScript, Clojurescript, Coffeescript -- hell even ES6 is for all practical purposes a compile to JS language. Changing the game into "browsers run WASM" and JS is a built-in JIT compiler for it promises to make everyone's lives much easier.
- skybrian 8y ago
  If you're working directly with the DOM or other JavaScript APIs it's still going to be a garbage-collected, object-oriented data model. The JavaScript object model is likely to remain fundamental for cross-language within-browser interop, just like C api's are fundamental for foreign function calls in other environments. (Or Java API's in a JVM.)
  - rickycook 8y ago
    i’d imagine that at its core, all the DOM access will be just another WASM call, and WASM has no concept of objects AFAIK? it would be up to each language to represent those bindings however it likes. i don’t think the functions would even have names per se; similar to minified JS you know some magic reference number but a human readable name is not relevant all assumptions here
    - skybrian 8y ago
      If you're willing to custom-design a new API by hand, you can do it however you like. But if you want to, say, autogenerate bindings from a typescript definition file (the defacto standard for describing Javascript API's), you're probably going to end up using or adapting their function names, type names, parameter names, and so on, or you'll confuse the developers. It can be minified if both the web assembly and foreign code pass through the same minifier, but source code still has to be readable.
bayesian_horse 8y ago
The big thing isn't so much the performance of WASM by itself, but rather that this performance enables the use of data models which are different from Javascript. Typescript, Coffeescript and a host of similar options have essentially the same data model. What makes other languages, like Java, Rust or Python actually useful is their way of handling data. Which is why you can't transcribe these languages to Javascript trivially. Still, the ecosystem of javascript is a lot better than the languages which compile to WASM as of right now. I guess that will change...
monocularvision 8y ago
wasm makes using a statically-typed language possible in web applications. For those that have embraced JS, that may not be compelling but for those of us that prefer strong, static typing it is a positive development.
- eridius 8y ago
  Emscripten let you do that too, compiling to asm.js. WebAssembly certainly is an improvement, but it's not like you couldn't do this at all before. And heck, even without that, there are languages that transpile directly to JavaScript.
  - monocularvision 8y ago
    Look at the comment I was responding to: I wasn’t claiming there weren’t other ways to do this. I was responding to the question as to why you might use wasm over JS. I understand it was based on previous efforts like asm.js. Also, for several languages, specifically those based on LLVM, the path to wasm is much clearer than compiling to JS.
- sacado2 8y ago
  I'm using typescript, so I already have a statically-typed language for my web apps. What is compelling with WASM is that it lets me provide a web-browser version of my C++ libraries, for stuff which needs decent execution speed and cannot afford a GC.
jillesvangurp 8y ago
Well, kind of looking forward to getting back to using languages like Java, Kotlin, C#, Swift, ObjectiveC and other languages people have been using to make UIs for quite some time in a browser. It will take some time for proper frameworks to emerge. But things are moving fast. Driving the DOM via react and other js frameworks from these languages is kind of possible. But it's probably just a stepping stone for getting something a bit more appropriate to these languages. I have high hopes for Kotlin here. With Kotlin native they are targeting native IOS and native Android. Being able drive browsers from the same code-base via WASM seems like it will be a useful feature. Also, they seem to be really serious about tool support with Kotlin; providing dom/webgl and other bindings, and having decent end to end support with IDEs and other tools. I imagine, Microsoft might have similar plans for C#. And it wouldn't surprise me if Apple was working on some Swift WASM support either.

pjmlp 8y ago

The 2nd coming of Flash?

knightofmars 8y ago
You may have said this in jest and are getting down-voted for it but this isn't an impossible scenario. I think of this article in relation to what WebAssembly means. https://dzone.com/articles/java-getting-back-to-the-browser https://dzone.com/articles/java-getting-back-to-the-browser
- pjmlp 8y ago
  I trully believe it will happen in a couple of years, unless browser vendors change course regarding WebAssembly. Ongoing POC of running Unity games, .NET, Go, Qt and many others already show it is the direction many are moving into.
  - knightofmars 8y ago
    I agree and think it's amazing. I'm looking forward to that day and when it comes. The other side is that it's also likely to open up a whole new avenue for web based security exploits.
    - pjmlp 8y ago
      One issue regarding security is that until WebAssembly gets some kind of fat pointers or tagging, modules generated by unsafe languages can be exploited by corrupting internal state, thus changing the behaviour of exported entry points. You can easily test it by creating a WebAssembly module in C with a function that overwrites an internal memory buffer, placed besides other data, which is used to parametrize behaviour of another function, for example a boolean stating that the user is authenticated.
      - Rusky 8y ago
        "Some kind of fat pointers or tagging" is exactly the sort of thing WebAssembly was created to get away from. You can use a language that provides them and targets WebAssembly, without taking away the thing that makes the platform uniquely useful.
        pjmlp 8y ago
        Right, but how can you trust a WebAssembly library? It might have been compiled from Ada, Rust or plain C, just as an example. Telling just to use a language we trust is not an option if one is just using other people libraries. Thus bringing to the web the same security level as depending on regular native libraries, because a regular user is not going to check what a web page depends on.
        danShumway 8y ago
        If you're bringing in multiple separate WASM libraries, they'll run separately from each other. Don't give them access to any memory they shouldn't have access to. Note that this is considerably better than Javascript, because without going out of your way to make an iframe, separate Javascript scripts aren't isolated from each other, so you don't know if one of them is modifying a prototype or hooking around other variables in the global scope. By default, separate WASM modules don't have access to the same memory.
        pjmlp 8y ago
        The whole point is about corrupting WASM modules INTERNAL memory via public exported functions, just because they happen to have typical out-of-bounds errors. Linux Security Summit 2018 had a report that 68% of kernel exploits are caused by out-of-bounds errors. User space doesn't write on kernel level, but can call syscalls, which happen to trigger such exploits. WebAssembly is no different, regardless how they are sandboxed between modules.
        danShumway 8y ago
    - kbenson 8y ago
      > I'm looking forward to that day and when it comes. That is the day where the open web is a little closer to dead. Possibly a lot closer. The move away from flash was a move towards empowering users. That did cost a little bit for developers, as they had worse tools to control the experience, but that also meant that it was more likely (eventually) that the experience they did develop would work in more cases. How many flash sites dealt with different size displays well, or dynamically resized and flowed correctly? How many worked with screen readers? That's one of the benefits we've reaped by pushing the framework to the browser, and using open standards. Items that traditionally would haven't gotten much attention were also seen as important, and saw advances. I don't know how much some random React-like framework that just draws on the canvas would focus on screen reader support, but I suspect it wouldn't be high on their priority list. And even if it is on theirs, what about the 5 other main competitors that will be sharing market space with it? I just hope that the sites that opt for these types of system are few and far between, and have specific operating needs that make it worthwhile. I think it's good that we can, but usually we shouldn't.
      - Bizarro 8y ago
        WebAssembly can't close the open web anymore than it's already closed today. The vast majority of JS in the browser today is minified jibberish. WebAssembly doesn't take away HTML and CSS.
        kbenson 8y ago
        WebAssembly makes it much more feasible to implement your own layout and display engine on top of a canvas element.
        Bizarro 8y ago
        Why more feasible?
        kbenson 8y ago
        Because an application like that is both computationally expensive and expensive to ship as a runtime. WebAssembly can provide benefits in both cases (WASM binaries can be close an order of magnitude smaller than equivalent JS code, in select cases), and is quick to start. As a simple example, it's not impossible that Adobe could literally take the flash VM code, compile to WASM with emscripten, and ship it along with an SWF file and a little setup code. This completely bypasses the need for a browser plugin for flash. Now, I suspect the flash VM might be large enough to make this noticeable, but it probably wouldn't be hard for Adobe to streamline it, and then re-purpose a lot of those tools used to build flash that everyone loves to rave about... I believe there are financial incentives for this to happen, therefore I think it's only a matter of time until it does.
  - danShumway 8y ago
    For what it's worth, I think I remember that .NET is still using reasonable web standards under the hood. It's a framework, but it's still using CSS/HTML for actual rendering. If I'm remembering correctly, I wouldn't put that in the same category as Unity and Qt.
    - pjmlp 8y ago
      Unity is also .NET, and then there is UNO as well, UWP for WebAssembly https://playground.platform.uno/ https://playground.platform.uno/
      - danShumway 8y ago
        Blazor[0] was what I was referring to, but you're right, I shouldn't treat .NET like it's only being used in that context. [0]: https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-started-building-net-web-apps-in-the-browser-with-blazor/ https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-start...
danShumway 8y ago
Hopefully not. Some devs are treating WASM as an entire runtime and outputing canvas/webGL code. I think that is mostly a mistake, and I'll be very disappointed if that becomes the defacto approach for new web devs. However, the cool thing about WASM is that it's just the code part. So you can build an app that's still normal CSS/HTML, just like every web-app should be, and then you can replace all of your JS with WASM (with the current exception of a little bit of JS-to-DOM binding code which Mozilla has promised to eventually get rid of). In the world of Flash/Java you're essentially working in a completely separate platform, it just happens to be launched from a web browser. So shortcuts don't work, accessibility is awful, users can't customize the page, extensions are broken, etc, etc... With WASM, you don't have to be in that position. You can say, "I'm a web developer, I treat the web like a medium, I write responsive HTML/CSS. I just use C instead of Javascript."
- pjmlp 8y ago
  > In the world of Flash/Java you're essentially working in a completely separate platform, it just happens to be launched from a web browser. So shortcuts don't work, accessibility is awful, users can't customize the page, extensions are broken, etc, etc... True, but until Web development catches up with the state of Flash and other native RAD GUI designers, it is a very attractive proposition. One thing I hate when doing web development is playing around with CSS and tag soup while trying to make it work the same way across all target platforms required by the customer, that in native code would be a couple of graphical calls to the visualization engine and platform widgets, which also provide layout managers. Stuff like Web Components and Houdini would make it better, but who knows when they will be widely available.
  - danShumway 8y ago
    > while trying to make it work the same way across all target platforms This goes back to what I was talking about with treating the web like a medium, not a distribution platform. Fundamentally, the web is about giving you a "controlled" way to give up control. The native paradigm is "I want control over what each individual pixel looks like", and the web paradigm is, "heck off, well-written apps don't do that." I understand why it's attractive, and why it'll continue to be attractive. And I highly agree about Houdini being an exciting development (I don't personally think that Web Components are offering much, but whatever). I'm really looking forward to being able to polyfill CSS. But that difference you're talking about is probably not ever going to go away completely, because the web is optimizing to solve different problems than most native frameworks. Not to say one approach is better than the other (Flash had some legitimate use cases), but I find that there is an actual cultural difference between how web-apps and native apps are designed and how they balance between user control and developer control. It's not just technology.
finchisko 8y ago
This is one of my nightmares. But considering how much devs hate js it's inevitable. I almost see it. HTML replaced with some binary WASM bs framework.
- wetpaws 8y ago
  Then someone will reimplement a dom and a script language in wasm. History is going in circles.
  - Felz 8y ago
    Not quite a circle. There'd be progress in that you could choose your "Javascript" and "DOM", which really opens up a lot of possibility for progress. No need to force eternal compatibility or put up with bad APIs- just pick a better version.
    - v_lisivka 8y ago
      This! You will be able to implement your own browser in the browser, with your own brand new accessibility API, i18n and l17n API's, and your own bugs, of course. We can compile Chrome or WebKit into Wasm and then use them everywhere, even in Firefox!
- krapp 8y ago
  But you'd still need a browser that supports HTML to load the WASM and display it. Realistically, that would be not much different than current sites using JS, or Flash when that was a thing, or even Java applets. None of those deprecated or replaced HTML, and WASM won't either. At worse, it will be just another thing you can block with a script blocker.
cm2187 8y ago
Minified javascript does as much to obfuscate the code than wasm if your concern is the black box model.
- v_lisivka 8y ago
  I can reformat minified JS, then pause at a function, see it arguments, understand it purpose, rename variables, add a comment, and so on. Can I do all that in Wasm? For practical purposes of reverse engineering, minified JS is far better than Wasm. Wasm is the new Flash.
mr_toad 8y ago
Hopefully without the Swiss cheese security.

_wmd 8y ago

Choice The ability to use existing non-JS code The ability to write loops involving non-trivial computations without spamming a hundred million heap objects etc.

CyberDildonics 8y ago
> The ability to write loops involving non-trivial computations without spamming a hundred million heap objects How does being able to call the DOM from webasm give you that? That's what webasm is for in the first place.
- _wmd 8y ago
  > > > Why? What is it that wasm or c++ provides you in making a DOM call that modern JS does not? > > The ability to write loops involving non-trivial computations without spamming a hundred million heap objects > How does being able to call the DOM from webasm give you that? That's what webasm is for in the first place. The tell parent comment that, not me.
- icebraining 8y ago
  I think the idea is that they can't use webasm (exclusively) to do that without also being able to call the DOM from it.

Spivak 8y ago

Wasm promises a better compiler target than JS for alternative languages. It always seems odd to me that JS is so heavily defended when pretty much everything that makes up a modern JS stack are other compile-to-js languages: JSX, Elm, TypeScript, Clojurescript, Coffeescript -- hell even ES6 is for all practical purposes a compile to JS language. Changing the game into "browsers run WASM" and JS is a built-in JIT compiler for it promises to make everyone's lives much easier.

skybrian 8y ago
If you're working directly with the DOM or other JavaScript APIs it's still going to be a garbage-collected, object-oriented data model. The JavaScript object model is likely to remain fundamental for cross-language within-browser interop, just like C api's are fundamental for foreign function calls in other environments. (Or Java API's in a JVM.)
- rickycook 8y ago
  i’d imagine that at its core, all the DOM access will be just another WASM call, and WASM has no concept of objects AFAIK? it would be up to each language to represent those bindings however it likes. i don’t think the functions would even have names per se; similar to minified JS you know some magic reference number but a human readable name is not relevant all assumptions here
  - skybrian 8y ago
    If you're willing to custom-design a new API by hand, you can do it however you like. But if you want to, say, autogenerate bindings from a typescript definition file (the defacto standard for describing Javascript API's), you're probably going to end up using or adapting their function names, type names, parameter names, and so on, or you'll confuse the developers. It can be minified if both the web assembly and foreign code pass through the same minifier, but source code still has to be readable.

bayesian_horse 8y ago

The big thing isn't so much the performance of WASM by itself, but rather that this performance enables the use of data models which are different from Javascript. Typescript, Coffeescript and a host of similar options have essentially the same data model. What makes other languages, like Java, Rust or Python actually useful is their way of handling data. Which is why you can't transcribe these languages to Javascript trivially. Still, the ecosystem of javascript is a lot better than the languages which compile to WASM as of right now. I guess that will change...

monocularvision 8y ago

wasm makes using a statically-typed language possible in web applications. For those that have embraced JS, that may not be compelling but for those of us that prefer strong, static typing it is a positive development.

eridius 8y ago
Emscripten let you do that too, compiling to asm.js. WebAssembly certainly is an improvement, but it's not like you couldn't do this at all before. And heck, even without that, there are languages that transpile directly to JavaScript.
- monocularvision 8y ago
  Look at the comment I was responding to: I wasn’t claiming there weren’t other ways to do this. I was responding to the question as to why you might use wasm over JS. I understand it was based on previous efforts like asm.js. Also, for several languages, specifically those based on LLVM, the path to wasm is much clearer than compiling to JS.
sacado2 8y ago
I'm using typescript, so I already have a statically-typed language for my web apps. What is compelling with WASM is that it lets me provide a web-browser version of my C++ libraries, for stuff which needs decent execution speed and cannot afford a GC.

jillesvangurp 8y ago

Well, kind of looking forward to getting back to using languages like Java, Kotlin, C#, Swift, ObjectiveC and other languages people have been using to make UIs for quite some time in a browser. It will take some time for proper frameworks to emerge. But things are moving fast. Driving the DOM via react and other js frameworks from these languages is kind of possible. But it's probably just a stepping stone for getting something a bit more appropriate to these languages. I have high hopes for Kotlin here. With Kotlin native they are targeting native IOS and native Android. Being able drive browsers from the same code-base via WASM seems like it will be a useful feature. Also, they seem to be really serious about tool support with Kotlin; providing dom/webgl and other bindings, and having decent end to end support with IDEs and other tools. I imagine, Microsoft might have similar plans for C#. And it wouldn't surprise me if Apple was working on some Swift WASM support either.