5 ms·

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but a

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add stuff like graphql, and wasm looks so ridiculously old aged before it’s even born. Of course that kind of defeatist attitude is silly, and I’m looking forward to see where wasm goes in the coming years, because if people just gave up, I wouldn’t have been able to make a pretty app in vue either.

vvanders 8y ago
On the other side I see huge potential for WASM because all the things I worked with in C/C++/Rust that required a client-side install are now available to me on the browser. Stuff like UnrealEngine running in browser, low-latency audio processing, etc. Lots of potentially cool solutions where you need strong control over allocations and memory placement.
goatlover 8y ago
Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries). Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just your standard web app.
- marcosdumay 8y ago
  > Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?
  - bolb 8y ago
    There are programmers who haven’t worked with anything but the HTML+JS+CSS ecosystem, especially on the front-end. Lots of sunk costs there. Presenting WASM as a threat will lead to it facing stiff resistance from entrenched interests (amazing that people in their 20s and 30s are entrenched interests, but that’s modern front-end development). A more gradual, evolutionary, low-hype approach seems prudent, as the platform matures and until/if someone makes the “killer app”.
    - goatlover 8y ago
      Yeah, look at what happened to Dart in the browser, which is a shame.
  - edflsafoiewq 8y ago
    If there's some better environment to be found in non-JS-land, why is Electron and its ilk so popular?
    - discreteevent 8y ago
      "better environment" - worse is better. Its explained in the comment above you about entrenched interests. Whether js and html are worse in the browser is one thing but I think you could argue strongly that they are worse on the desktop. As a user, the experience for me is pretty bad.
      - eksemplar 8y ago
        Is electron really worse though? I use VS and VSC professionally and VSC is the best ide I’ve ever used. VS is great too, but it’s performance is really, really, terrible when your documents and settings directory is on one network drive and your codebase is on another. Not exactly VS’s fault, but it’s an ide for enterprise that can’t function with the most basic enterprise drive setup? VSC, the electron app on the other hand doesn’t give two shits. People usually tell me VSC is the one off unicorn. But isn’t discord better than team speak and ventrilo? Isn’t slack excellent? I don’t think sunk cost is a negative when people are building better tools with it.
ergothus 8y ago
> another important reason is how productive modern JS is Some people will argue on this, but I'm actually in agreement. That said, it is important to realize WHY the JS productivity is so important: We're iterating a LOT. Web is so young, web interfaces are so young, the problems we are trying to solve on web are ever changing, and the devices we use to interface with web are changing almost as fast. We have to iterate again and again to be decent at the problem we're trying to solve only to toss it aside in favor of the new problem. Some of this is wasteful, some of this is just part of being part of a big technological change. (I'm sure TV, radio, fax, printers, copiers, etc all had similar iterations, albeit at not quite the same speeds). But regardless of the "if we should" aspect, it's important to note that the current JS needs are both (1) currently real - trying to adopt some philosophically "pure" tenet in the defiance of these needs will fail and (2) not necessarily permanent - We can extrapolate into the near future from this, but I'm hard pressed to say much about more than 2 years in the future. > Add stuff like graphql Funny, I thought about graphql when the article mentioned HTTP caches, since graphQL _can't_ make use of that (most graphQL implementations use non-GET for everything, so you have to rely on server-side or client-app caching, since you can't rely on the network or browser) and took it as a hit on graphQL, not wasm. That said, I'm interested to see where wasm goes - short term, we're in agreement that anyone expecting it to be the "Js-killer" is missing the mark, but long term I don't expect it to be dead-on-arrival, just used for not-what-was-expected.
- pjmlp 8y ago
  I was iterating a lot with Smalltalk, Caml Light, Prolog, Oberon, Delphi and C++ Builder during the 90's.
rifung 8y ago
I'm not really sure wasm is meant to compete with JS like that though? To me the main benefits of wasm are that you can * make web pages with languages besides JS * do lower level things not possible with JS (low latency real time games?) If you already know JS well and want to make a normal website I don't think you need WASM necessarily although it will enable those who don't know JS or want to use JS to make them too.
- tyingq 8y ago
  Once they add GC, threads, polymorphic inline cache, and some sort of stdlib, it will be possible to have popular scripting languages run in the browser without the current problems of download size for the runtime and performance. So, it may not be completely intentional, but WASM does have roadmap items that may end up competing with JS. WASM starts to look more like a general purpose VM over time.
vardump 8y ago
> I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. You don't need a jet engine to make paper airplanes. Gluing jet engines to paper airplanes would indeed be counterproductive. > and wasm looks so ridiculously old aged before it’s even born. Wasm is about achieving near native level performance. For libraries and such. Stuff that your pretty high level js frameworks might use.

vvanders 8y ago

On the other side I see huge potential for WASM because all the things I worked with in C/C++/Rust that required a client-side install are now available to me on the browser. Stuff like UnrealEngine running in browser, low-latency audio processing, etc. Lots of potentially cool solutions where you need strong control over allocations and memory placement.

goatlover 8y ago

Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries). Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just your standard web app.

marcosdumay 8y ago
> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?
- bolb 8y ago
  There are programmers who haven’t worked with anything but the HTML+JS+CSS ecosystem, especially on the front-end. Lots of sunk costs there. Presenting WASM as a threat will lead to it facing stiff resistance from entrenched interests (amazing that people in their 20s and 30s are entrenched interests, but that’s modern front-end development). A more gradual, evolutionary, low-hype approach seems prudent, as the platform matures and until/if someone makes the “killer app”.
  - goatlover 8y ago
    Yeah, look at what happened to Dart in the browser, which is a shame.
- edflsafoiewq 8y ago
  If there's some better environment to be found in non-JS-land, why is Electron and its ilk so popular?
  - discreteevent 8y ago
    "better environment" - worse is better. Its explained in the comment above you about entrenched interests. Whether js and html are worse in the browser is one thing but I think you could argue strongly that they are worse on the desktop. As a user, the experience for me is pretty bad.
    - eksemplar 8y ago
      Is electron really worse though? I use VS and VSC professionally and VSC is the best ide I’ve ever used. VS is great too, but it’s performance is really, really, terrible when your documents and settings directory is on one network drive and your codebase is on another. Not exactly VS’s fault, but it’s an ide for enterprise that can’t function with the most basic enterprise drive setup? VSC, the electron app on the other hand doesn’t give two shits. People usually tell me VSC is the one off unicorn. But isn’t discord better than team speak and ventrilo? Isn’t slack excellent? I don’t think sunk cost is a negative when people are building better tools with it.

ergothus 8y ago

> another important reason is how productive modern JS is Some people will argue on this, but I'm actually in agreement. That said, it is important to realize WHY the JS productivity is so important: We're iterating a LOT. Web is so young, web interfaces are so young, the problems we are trying to solve on web are ever changing, and the devices we use to interface with web are changing almost as fast. We have to iterate again and again to be decent at the problem we're trying to solve only to toss it aside in favor of the new problem. Some of this is wasteful, some of this is just part of being part of a big technological change. (I'm sure TV, radio, fax, printers, copiers, etc all had similar iterations, albeit at not quite the same speeds). But regardless of the "if we should" aspect, it's important to note that the current JS needs are both (1) currently real - trying to adopt some philosophically "pure" tenet in the defiance of these needs will fail and (2) not necessarily permanent - We can extrapolate into the near future from this, but I'm hard pressed to say much about more than 2 years in the future. > Add stuff like graphql Funny, I thought about graphql when the article mentioned HTTP caches, since graphQL _can't_ make use of that (most graphQL implementations use non-GET for everything, so you have to rely on server-side or client-app caching, since you can't rely on the network or browser) and took it as a hit on graphQL, not wasm. That said, I'm interested to see where wasm goes - short term, we're in agreement that anyone expecting it to be the "Js-killer" is missing the mark, but long term I don't expect it to be dead-on-arrival, just used for not-what-was-expected.

pjmlp 8y ago
I was iterating a lot with Smalltalk, Caml Light, Prolog, Oberon, Delphi and C++ Builder during the 90's.

rifung 8y ago

I'm not really sure wasm is meant to compete with JS like that though? To me the main benefits of wasm are that you can * make web pages with languages besides JS * do lower level things not possible with JS (low latency real time games?) If you already know JS well and want to make a normal website I don't think you need WASM necessarily although it will enable those who don't know JS or want to use JS to make them too.

tyingq 8y ago
Once they add GC, threads, polymorphic inline cache, and some sort of stdlib, it will be possible to have popular scripting languages run in the browser without the current problems of download size for the runtime and performance. So, it may not be completely intentional, but WASM does have roadmap items that may end up competing with JS. WASM starts to look more like a general purpose VM over time.

vardump 8y ago

> I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. You don't need a jet engine to make paper airplanes. Gluing jet engines to paper airplanes would indeed be counterproductive. > and wasm looks so ridiculously old aged before it’s even born. Wasm is about achieving near native level performance. For libraries and such. Stuff that your pretty high level js frameworks might use.