4 ms·

I don't know; honestly, I think the nicest part about wasm is that it might allow us to stop making more dialects of JS, get rid of JS altogether and compile to

I don't know; honestly, I think the nicest part about wasm is that it might allow us to stop making more dialects of JS, get rid of JS altogether and compile to the web whatever language we like (I'm looking at you Haskell).

woah 11y ago
I never really have understood this kind of sentiment. There are a huge number of people who like js, to the point that it is used in a bunch of places that are not the browser. In terms of dynamic scripting languages, it's a fast, easy, and flexible option.
- iopq 11y ago
  Some people want a statically-typed language for larger apps. Tooling support can be made a lot better for statically-typed languages because it's easier to analyze.
- halosghost 11y ago
  Disclaimer: the below text is just my opinion meant to answer the Parent's questions about my preferences. Please do not take it to be an attempt at starting a flamewar (or, for that matter, an invitation to do so). I have never enjoyed dynamic typing; it has always seemed like TheWrongSolution™ to me. And Haskell really drives that home for me (i.e., it is possible to have a static type system with all the benefits that gives you without any of the headaches). Additionally, I really dislike the trend of JS moving out of the web browser; it is incredibly easy to write impenetrable JS (particularly with the compile-to-js languages) which makes it much harder for me to understand what is running on my system, how to contribute to it and how to debug it. Furthermore, JS is fast in comparison to other interpreted dynamic languages, but is quite slow compared to most native code (like the kind you would get with Haskell). I am not trying to be one of the JS naysayers that gets into religious wars, but I will say that I am generally not a fan of the language, and the possibility of removing it from my life does seem like a net-positive. But again, my intention is not to start a flamewar, simply answer your questions about my preferences.
  - vmorgulis 11y ago
    I understand your point of view. I see asm.js and wasm as an evolution path. The same idea as JVM bytecode but twenty year after. It can provide the cross-platform and ubiquity advantages to most of existing projects and languages.
  - deleted 11y ago
    [deleted]
  - woah 11y ago
    Your choices are totally sensible. What I meant was the idea that everyone is just waiting for JS to go away seems like you're extrapolating your preferences onto other people.
    - halosghost 11y ago
      Well, while I would like to see many of the cool JS projects out there written in a language I am more amenable to (and thus, would like to see an end to JS), I recognize that not everyone agrees. So, in the meantime, I have the unfortunate stance of not using many of those projects that I would otherwise be interested in. Though, if a significant number of people feel similarly to me (that there are better options than JS and that wasm could catalyze the move towards those better options), then I do not really see a problem with JS going away. Perhaps that is just me. Again, I did not write this post with any intention of flaming or insulting those who like JS.
    - saosebastiao 11y ago
      He extrapolated to me quite well. The existence of hundreds of languages that compile to javascript is pretty good proof that there are tons of people that are waiting for JS to go away.
      - halosghost 11y ago
        Or, at the very least, that there are many people that feel unsatisfied with JS in its current form.
    - 11y ago
- rasz_pl 11y ago
  Yes, I really enjoy having my variables randomly swap between boolean, integer and float.
  - girvo 11y ago
    Hardly "randomly", although yes it doesn't follow the principle of least surprise.
    - rasz_pl 11y ago
      Its random all right, at least when I parse strings of numbers. Want to compare dates stored as integers? You better parseInt. My small client side js plugin for Wordpress saving date of last visit on every blog page in HTML Storage in order to be able to show you unread comments was randomly bugging out. Not often, just maybe once/twice per day, not enough to make me investigate for a very long time. Turns out Date.parse(list[i].getElementsByTagName("time")[0].childNodes[0].nodeValue.replace(" at ", ' ')) was randomly returning integer results converted to floats ?!?!
- the8472 11y ago
  > There are a huge number of people who like js Are you sure that it's not some sort of stockholm syndrome? Or a case of plato's cave?
  - drivingmenuts 11y ago
    I, for one, would much rather use Python to make the browser do it's scripting thing. But, alas, I'm stuck with Javascript. For the longest time, we had to specify which language we were using as part of the script tag. Which was fine, as long as we specified Javascript. Who invented that damn thing? Henry Ford?
  - vmorgulis 11y ago
    For nowadays beginners, it's like a BASIC. You just need a browser and do graphical stuff quickly.
- _frog 11y ago
  The problem here isn't with JavaScript in particular, but the complete lack of other options. When you're limited to a single language, what you end up with is a software engineering monoculture.
  - enraged_camel 11y ago
    >>When you're limited to a single language, what you end up with is a software engineering monoculture. Really? There are a plethora of JavaScript frameworks out there, mostly client-side but also some server-side, each with its own distinct culture, and new ones are coming out all the time. And each framework imposes its own way of doing things, and that attracts different types of people and creates a different culture. In fact, the JavaScript ecosystem is so vibrant and diverse right now that "monoculture" is the last word I'd use to describe it. If you want monoculture, look at Ruby. (Don't get me wrong, I love Ruby and it's my favorite language, but it's basically dominated by the monoculture of Rails.)
    - pmontra 11y ago
      I think you guys are using the word monoculture to mean different things but you share a common worry. _frog is worried by a language monoculture, having to develop for a platform in only one language: the platform mandates the language. Other examples: Java for Android, Objective-C for iOS (Swift now). You are worried by a framework monoculture, Rails dominating Ruby. That has no parallel in the JavaScript world. Other examples: iOS development dominating Objective-C and Swift? The common worry is that monocultures harm their environment (JavaScript harming the web and Rails harming Ruby). Given the success of Rails and the JavaScript-based Web one wouldn't say any of those type of monocultures are bad for making money (and look at real monocultures in agriculture and animal farming) but farming teaches that if you don't have enough diversity you are exposed to problems. Being able to program the web in many different languages would be both good (pick the tool you like most) and bad (example: "sorry, I can't take over this webapp because it's written in OCaml and I only do Ruby and Elixir, find somebody who knows OCaml") but not different from what we always did when developing for the desktop and the web server. Both did well. If we're heading there we'll cope with that (customers will stick with the "big" languages, as usual).
- mafribe 11y ago
  Javascript has several disadvantages that make it less than ideal as a general compilation target. * Javascript is verbose because it's plain text and was 'optimised' for human readability, rather than machine-parsability. That means parsing Javascript is expensive, too expensive for high-performance applications. * Javascript's being a dynamically typed language means a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML. Likewise, JS allows us radically to modify the behaviour of even built-in objects such as arrays. All this prevents the Javascript JIT compiler to optimise as aggressively as we'd like. * Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.
  - aardvark179 11y ago
    Your third point isn't just a problem with translating Javascript, it is a problem in the VM designs (because it's much faster to support the required dynamism if you don't need to worry about concurrency). For me one of the most interesting things about web assembly is that it ditches so much of the current JS VM requirements that it finally allows for a path toward multi-threaded concurrency. It's going to be a long road to get high level languages on there (because I'm not sure I want to implement optimising method dispatch & GC in web assembly, and I predict those will take some time to arrive in wasm itself), but it is at least a start.
    - mafribe 11y ago
      I agree with this. Given that Javascript is the undisputed king of browser languages, and the difficulties with Javascript as compilation target are becoming apparent, I expect that WebAssembly support will be something of a priority for browser makers. I also think that, as you point out, VM design in general has mostly focussed on sequential computation, and concurrency is bolted on later. In part that's because concurrency is much harder, and the underlying CPU support for concurrency is in flux.
- simula67 11y ago
  A large number of engineers are not interested in learning JavaScript since they may be very fluent in their language of choice. I think it would be better for everyone if they can bring in their expertise also to the web platform. Also I don't think they are being unambitious by not wanting to learn JavaScript since all languages have many warts and learning all of the peculiarities of how to do the same thing in different languages is not going to make you a better programmer.
- vidarh 11y ago
  A lot of the justification for running JS in "places that are not the browser" is the availability of VMs designed for sandboxing coupled with it being the best supported language in browsers. With wasm supporting VMs providing the same sandboxing and the ability to painlessly run more languages in the client, a lot of the incentive for running JS outside the browser will disappear for a lot of people.

woah 11y ago

I never really have understood this kind of sentiment. There are a huge number of people who like js, to the point that it is used in a bunch of places that are not the browser. In terms of dynamic scripting languages, it's a fast, easy, and flexible option.

iopq 11y ago
Some people want a statically-typed language for larger apps. Tooling support can be made a lot better for statically-typed languages because it's easier to analyze.
halosghost 11y ago
Disclaimer: the below text is just my opinion meant to answer the Parent's questions about my preferences. Please do not take it to be an attempt at starting a flamewar (or, for that matter, an invitation to do so). I have never enjoyed dynamic typing; it has always seemed like TheWrongSolution™ to me. And Haskell really drives that home for me (i.e., it is possible to have a static type system with all the benefits that gives you without any of the headaches). Additionally, I really dislike the trend of JS moving out of the web browser; it is incredibly easy to write impenetrable JS (particularly with the compile-to-js languages) which makes it much harder for me to understand what is running on my system, how to contribute to it and how to debug it. Furthermore, JS is fast in comparison to other interpreted dynamic languages, but is quite slow compared to most native code (like the kind you would get with Haskell). I am not trying to be one of the JS naysayers that gets into religious wars, but I will say that I am generally not a fan of the language, and the possibility of removing it from my life does seem like a net-positive. But again, my intention is not to start a flamewar, simply answer your questions about my preferences.
- vmorgulis 11y ago
  I understand your point of view. I see asm.js and wasm as an evolution path. The same idea as JVM bytecode but twenty year after. It can provide the cross-platform and ubiquity advantages to most of existing projects and languages.
- deleted 11y ago
  [deleted]
- woah 11y ago
  Your choices are totally sensible. What I meant was the idea that everyone is just waiting for JS to go away seems like you're extrapolating your preferences onto other people.
  - halosghost 11y ago
    Well, while I would like to see many of the cool JS projects out there written in a language I am more amenable to (and thus, would like to see an end to JS), I recognize that not everyone agrees. So, in the meantime, I have the unfortunate stance of not using many of those projects that I would otherwise be interested in. Though, if a significant number of people feel similarly to me (that there are better options than JS and that wasm could catalyze the move towards those better options), then I do not really see a problem with JS going away. Perhaps that is just me. Again, I did not write this post with any intention of flaming or insulting those who like JS.
  - saosebastiao 11y ago
    He extrapolated to me quite well. The existence of hundreds of languages that compile to javascript is pretty good proof that there are tons of people that are waiting for JS to go away.
    - halosghost 11y ago
      Or, at the very least, that there are many people that feel unsatisfied with JS in its current form.
  - 11y ago
rasz_pl 11y ago
Yes, I really enjoy having my variables randomly swap between boolean, integer and float.
- girvo 11y ago
  Hardly "randomly", although yes it doesn't follow the principle of least surprise.
  - rasz_pl 11y ago
    Its random all right, at least when I parse strings of numbers. Want to compare dates stored as integers? You better parseInt. My small client side js plugin for Wordpress saving date of last visit on every blog page in HTML Storage in order to be able to show you unread comments was randomly bugging out. Not often, just maybe once/twice per day, not enough to make me investigate for a very long time. Turns out Date.parse(list[i].getElementsByTagName("time")[0].childNodes[0].nodeValue.replace(" at ", ' ')) was randomly returning integer results converted to floats ?!?!
the8472 11y ago
> There are a huge number of people who like js Are you sure that it's not some sort of stockholm syndrome? Or a case of plato's cave?
- drivingmenuts 11y ago
  I, for one, would much rather use Python to make the browser do it's scripting thing. But, alas, I'm stuck with Javascript. For the longest time, we had to specify which language we were using as part of the script tag. Which was fine, as long as we specified Javascript. Who invented that damn thing? Henry Ford?
- vmorgulis 11y ago
  For nowadays beginners, it's like a BASIC. You just need a browser and do graphical stuff quickly.
_frog 11y ago
The problem here isn't with JavaScript in particular, but the complete lack of other options. When you're limited to a single language, what you end up with is a software engineering monoculture.
- enraged_camel 11y ago
  >>When you're limited to a single language, what you end up with is a software engineering monoculture. Really? There are a plethora of JavaScript frameworks out there, mostly client-side but also some server-side, each with its own distinct culture, and new ones are coming out all the time. And each framework imposes its own way of doing things, and that attracts different types of people and creates a different culture. In fact, the JavaScript ecosystem is so vibrant and diverse right now that "monoculture" is the last word I'd use to describe it. If you want monoculture, look at Ruby. (Don't get me wrong, I love Ruby and it's my favorite language, but it's basically dominated by the monoculture of Rails.)
  - pmontra 11y ago
    I think you guys are using the word monoculture to mean different things but you share a common worry. _frog is worried by a language monoculture, having to develop for a platform in only one language: the platform mandates the language. Other examples: Java for Android, Objective-C for iOS (Swift now). You are worried by a framework monoculture, Rails dominating Ruby. That has no parallel in the JavaScript world. Other examples: iOS development dominating Objective-C and Swift? The common worry is that monocultures harm their environment (JavaScript harming the web and Rails harming Ruby). Given the success of Rails and the JavaScript-based Web one wouldn't say any of those type of monocultures are bad for making money (and look at real monocultures in agriculture and animal farming) but farming teaches that if you don't have enough diversity you are exposed to problems. Being able to program the web in many different languages would be both good (pick the tool you like most) and bad (example: "sorry, I can't take over this webapp because it's written in OCaml and I only do Ruby and Elixir, find somebody who knows OCaml") but not different from what we always did when developing for the desktop and the web server. Both did well. If we're heading there we'll cope with that (customers will stick with the "big" languages, as usual).
mafribe 11y ago
Javascript has several disadvantages that make it less than ideal as a general compilation target. * Javascript is verbose because it's plain text and was 'optimised' for human readability, rather than machine-parsability. That means parsing Javascript is expensive, too expensive for high-performance applications. * Javascript's being a dynamically typed language means a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML. Likewise, JS allows us radically to modify the behaviour of even built-in objects such as arrays. All this prevents the Javascript JIT compiler to optimise as aggressively as we'd like. * Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.
- aardvark179 11y ago
  Your third point isn't just a problem with translating Javascript, it is a problem in the VM designs (because it's much faster to support the required dynamism if you don't need to worry about concurrency). For me one of the most interesting things about web assembly is that it ditches so much of the current JS VM requirements that it finally allows for a path toward multi-threaded concurrency. It's going to be a long road to get high level languages on there (because I'm not sure I want to implement optimising method dispatch & GC in web assembly, and I predict those will take some time to arrive in wasm itself), but it is at least a start.
  - mafribe 11y ago
    I agree with this. Given that Javascript is the undisputed king of browser languages, and the difficulties with Javascript as compilation target are becoming apparent, I expect that WebAssembly support will be something of a priority for browser makers. I also think that, as you point out, VM design in general has mostly focussed on sequential computation, and concurrency is bolted on later. In part that's because concurrency is much harder, and the underlying CPU support for concurrency is in flux.
simula67 11y ago
A large number of engineers are not interested in learning JavaScript since they may be very fluent in their language of choice. I think it would be better for everyone if they can bring in their expertise also to the web platform. Also I don't think they are being unambitious by not wanting to learn JavaScript since all languages have many warts and learning all of the peculiarities of how to do the same thing in different languages is not going to make you a better programmer.
vidarh 11y ago
A lot of the justification for running JS in "places that are not the browser" is the availability of VMs designed for sandboxing coupled with it being the best supported language in browsers. With wasm supporting VMs providing the same sandboxing and the ability to painlessly run more languages in the client, a lot of the incentive for running JS outside the browser will disappear for a lot of people.