6 ms·

I'm not sure if I like where this whole WebAssemby thing is going. On one hand I'm thrilled to the prospect of Python in the browser, on the other this seems li

I'm not sure if I like where this whole WebAssemby thing is going. On one hand I'm thrilled to the prospect of Python in the browser, on the other this seems like a huge layered mess just waiting to trouble those poor devs. I actually enjoy creating plain server side rendered web applications with just a dusting of client side Javascript where it makes sense. The development flow is simple and debugging is easy.

k__ 7y ago
I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. But well, I guess people will do it anyway, let's see how this plays out in the long run.
- josteink 7y ago
  > I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. This was one of the key features and benefits of NodeJS, and I won’t be surprised when I see others trying to replicate the experience via web-assembly.
  - k__ 7y ago
    I think the USP of Node.js was that the majority of devs already knew JS. What I want to say is, I question the premise that there are as many backend devs who just don't do frontent stuff because of JS as there were frontend devs who didn't do backend because JS wasn't an option. On the other hand the industry gets bigger by the day, maybe even a small percentage of devs doing Python frontends will be thousands of people :)
    - MuffinFlavored 7y ago
      How long until the industry doesn't get bigger by the day, and frontend devs + backend devs alike get automated away when AI can generate maintainable + readable code for 95% of the "API + UI plumbing" that is out there?
      - tracker1 7y ago
        Judging from every time someone has advertised "don't need programmers" services/software has actually worked, I doubt it will ever really happen in practice, at least not in the coming century or more.
        MuffinFlavored 7y ago
        I think high level business analysts could write some Markdown-like human readable syntax for things like: `apiRequest(method, url, requestParameters, headers, body)` `databaseQuery(credentials, sql, bindings)` The past 3-5 years of my professional career have just been shuffling data around from one point to another.
      - papito 7y ago
        This AI needs to understand first - in minor detail, what it is that it's actually building. Even two people can't understand each other sometimes, and what they are actually building. I installed RationalRose once, and... that was it. Code generation tools suck.
    - tracker1 7y ago
      I work in a company that currently has 2/3 of the teams using Blazor because they aren't comfortable/familiar enough with JS. My team being C# backend and React/Redux/Material-UI front end (using node scripts for all orchestration and ci/cd). It's a mostly MS shop and you'd be surprised how many developers in orgs really just don't do front end work because of JS.
      - k__ 7y ago
  - moron4hire 7y ago
    Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds up over time, draining batteries faster, drawing electricity from the power grid and burning carbon fuels. Each individual cycle may be cheap, but when we have a culture of development that doesn't respect performance, the waste adds up and has a real impact on the world. Just like all other resources, in aggregate, waste is harmful. Even on the spectrum of "developer productivity", you have to seriously consider if the operational cost of needing beefier servers to run slow-language-X is less than the operational cost of hiring fast-language-Y developers. I doubt anyone has done a serious study of the issue. Say C++ is 15x faster than Python. You might be able to say that a C++ dev is 2x the cost of a Python dev. Is the ratio of development cost to server cost more than 7.5x? What about other languages that aren't quite so fast, but aren't quite so expensive? You might find that C# is 10x faster than Python, but devs are only 1.25x the cost. Now your ratio of dev cost to server cost needs to be at least 8x to come ahead. And honestly, good developers are expensive, no matter what language they're working in. Choosing a programming language to be able to optimize for cheap developers could be optimizing for bad developers who can't create the features you need. They might be half the price, but can they get the job done--after all the reworks and defect fixes and other learning curves--in less than 2x the time? I've never seen a programming language on its own have that kind of impact on development. The point is not that "Language X is universally better than language Y". My point is more that "some languages are so incredibly wasteful that you seriously have to start considering whether or not you're saving money".
    - flmontpetit 7y ago
      It's simply not possible to quantify performance in this way, when comparing language implementations. Performance can also be constrained by environment and/or context on top of the expensive abstractions the compiler or interpreter are required to make. But I'm honestly just being pedantic. You make a good argument about the potential costs abstractions when they are applied at a very large scale. You are however ignoring the cost of things that may be prevented with high-level language features, like for instance errors in memory management which in my opinion are far worse than wasted cycles. I'd wager most would choose a marginally higher power bill over Heartbleed.
  - macspoofing 7y ago
    >On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. Transpilation is a better option if you just care about using the same language because you have better control over the DOM and you can use HTML and CSS markup (which is the best widget set across any platform).
  - s_y_n_t_a_x 7y ago
    Some people may feel that way, but the general plan is not to replace JS. It's mentioned multiple times in official docs and blog posts. https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript https://webassembly.org/docs/faq/#is-webassembly-trying-to-r...
flohofwoe 7y ago
A good use case for WASM outside the browser is application plugins, or tools where it's better to distribute "WASM binaries" because client-side compilation from C, C++ or Rust might take too long or is too much hassle for the user. It probably won't replace solutions that already work well, but it might be an option for the things that currently don't work.
- MuffinFlavored 7y ago
  Until you find out WebAssembly can't call any native functions (for example: to create a GUI, to call a .so / .dll export, etc.) There was discussion to add `dl_open` + `dl_sym` to WASI but it got shot down. WebAssembly seems to be in a weird state of "look, I can run in and out of the browser, but I can't actually do anything useful out of the browser, and I can't access the DOM without going through JavaScript in the browser"
  - flohofwoe 7y ago
    WASM embeddings like https://github.com/wasmerio/wasmer-c-api https://github.com/wasmerio/wasmer-c-api should allow that, at least calling from the embedder into WASM, and from WASM into the embedder. (e.g. see https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-c-api-example.c https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-...) There's similar embeddings for other languages here (python, go, ruby etc...): https://github.com/wasmerio https://github.com/wasmerio
    - MuffinFlavored 7y ago
      I can't think of any good use cases for loading WebAssembly modules into native code. I also think it's bad out of the gates that the WebAssembly community is so fragmented across the different runtimes (each offering different functionality at the moment).
      - flohofwoe 7y ago
        Think of plugins for applications like Autodesk Maya. Currently these are either cross-platform, but very slow Python plugins, or fast native DLLs which need to be compiled for each app-version/OS/CPU combination. If Maya had an embedded WASM runtime it could support plugins which are fast (at least much closer to native speed than Python scripts), and you only need to distribute a single WASM blob.
ScottFree 7y ago
WASM is still young. The tooling around it hasn't gained maturity yet. Do you remember trying to debug Javascript before the creation of the in-browser debugger? Desktop application developers back then probably felt the same way you do now. > this seems like a huge layered mess just waiting to trouble those poor devs. WASM is a VM. It's less complicated than a javascript engine. How complicated it seems in daily practice is going to come down to how good the tooling is.
- aidos 7y ago
  Minor nitpick. WebKit created a debugger a couple of years before chrome existed. https://webkit.org/blog/61/introducing-drosera/ https://webkit.org/blog/61/introducing-drosera/
  - ScottFree 7y ago
    Yes, the bike shed should definitely be green. I knew somebody was going to object to that little factoid despite its irrelevance to the point at hand. I've updated my comment to remove any reference to any specific in-browser debugger.
    - aidos 7y ago
      Apologies, didn’t intend to detract from your point. I thought people might be interested in the history of it since very few people even at the time seemed to know of its existence.
      - ScottFree 7y ago
        No worries. I should have chosen my words more carefully. And, to be fair, I didn't know webkit was the first to create an in-browser debugger either. I always thought it was either Chrome or Firefox.
        deleted 7y ago
        [deleted]

k__ 7y ago

I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. But well, I guess people will do it anyway, let's see how this plays out in the long run.

josteink 7y ago
> I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. This was one of the key features and benefits of NodeJS, and I won’t be surprised when I see others trying to replicate the experience via web-assembly.
- k__ 7y ago
  I think the USP of Node.js was that the majority of devs already knew JS. What I want to say is, I question the premise that there are as many backend devs who just don't do frontent stuff because of JS as there were frontend devs who didn't do backend because JS wasn't an option. On the other hand the industry gets bigger by the day, maybe even a small percentage of devs doing Python frontends will be thousands of people :)
  - MuffinFlavored 7y ago
    How long until the industry doesn't get bigger by the day, and frontend devs + backend devs alike get automated away when AI can generate maintainable + readable code for 95% of the "API + UI plumbing" that is out there?
    - tracker1 7y ago
      Judging from every time someone has advertised "don't need programmers" services/software has actually worked, I doubt it will ever really happen in practice, at least not in the coming century or more.
      - MuffinFlavored 7y ago
        I think high level business analysts could write some Markdown-like human readable syntax for things like: `apiRequest(method, url, requestParameters, headers, body)` `databaseQuery(credentials, sql, bindings)` The past 3-5 years of my professional career have just been shuffling data around from one point to another.
    - papito 7y ago
      This AI needs to understand first - in minor detail, what it is that it's actually building. Even two people can't understand each other sometimes, and what they are actually building. I installed RationalRose once, and... that was it. Code generation tools suck.
  - tracker1 7y ago
    I work in a company that currently has 2/3 of the teams using Blazor because they aren't comfortable/familiar enough with JS. My team being C# backend and React/Redux/Material-UI front end (using node scripts for all orchestration and ci/cd). It's a mostly MS shop and you'd be surprised how many developers in orgs really just don't do front end work because of JS.
    - k__ 7y ago
- moron4hire 7y ago
  Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds up over time, draining batteries faster, drawing electricity from the power grid and burning carbon fuels. Each individual cycle may be cheap, but when we have a culture of development that doesn't respect performance, the waste adds up and has a real impact on the world. Just like all other resources, in aggregate, waste is harmful. Even on the spectrum of "developer productivity", you have to seriously consider if the operational cost of needing beefier servers to run slow-language-X is less than the operational cost of hiring fast-language-Y developers. I doubt anyone has done a serious study of the issue. Say C++ is 15x faster than Python. You might be able to say that a C++ dev is 2x the cost of a Python dev. Is the ratio of development cost to server cost more than 7.5x? What about other languages that aren't quite so fast, but aren't quite so expensive? You might find that C# is 10x faster than Python, but devs are only 1.25x the cost. Now your ratio of dev cost to server cost needs to be at least 8x to come ahead. And honestly, good developers are expensive, no matter what language they're working in. Choosing a programming language to be able to optimize for cheap developers could be optimizing for bad developers who can't create the features you need. They might be half the price, but can they get the job done--after all the reworks and defect fixes and other learning curves--in less than 2x the time? I've never seen a programming language on its own have that kind of impact on development. The point is not that "Language X is universally better than language Y". My point is more that "some languages are so incredibly wasteful that you seriously have to start considering whether or not you're saving money".
  - flmontpetit 7y ago
    It's simply not possible to quantify performance in this way, when comparing language implementations. Performance can also be constrained by environment and/or context on top of the expensive abstractions the compiler or interpreter are required to make. But I'm honestly just being pedantic. You make a good argument about the potential costs abstractions when they are applied at a very large scale. You are however ignoring the cost of things that may be prevented with high-level language features, like for instance errors in memory management which in my opinion are far worse than wasted cycles. I'd wager most would choose a marginally higher power bill over Heartbleed.
- macspoofing 7y ago
  >On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. Transpilation is a better option if you just care about using the same language because you have better control over the DOM and you can use HTML and CSS markup (which is the best widget set across any platform).
- s_y_n_t_a_x 7y ago
  Some people may feel that way, but the general plan is not to replace JS. It's mentioned multiple times in official docs and blog posts. https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript https://webassembly.org/docs/faq/#is-webassembly-trying-to-r...

flohofwoe 7y ago

A good use case for WASM outside the browser is application plugins, or tools where it's better to distribute "WASM binaries" because client-side compilation from C, C++ or Rust might take too long or is too much hassle for the user. It probably won't replace solutions that already work well, but it might be an option for the things that currently don't work.

MuffinFlavored 7y ago
Until you find out WebAssembly can't call any native functions (for example: to create a GUI, to call a .so / .dll export, etc.) There was discussion to add `dl_open` + `dl_sym` to WASI but it got shot down. WebAssembly seems to be in a weird state of "look, I can run in and out of the browser, but I can't actually do anything useful out of the browser, and I can't access the DOM without going through JavaScript in the browser"
- flohofwoe 7y ago
  WASM embeddings like https://github.com/wasmerio/wasmer-c-api https://github.com/wasmerio/wasmer-c-api should allow that, at least calling from the embedder into WASM, and from WASM into the embedder. (e.g. see https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-c-api-example.c https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-...) There's similar embeddings for other languages here (python, go, ruby etc...): https://github.com/wasmerio https://github.com/wasmerio
  - MuffinFlavored 7y ago
    I can't think of any good use cases for loading WebAssembly modules into native code. I also think it's bad out of the gates that the WebAssembly community is so fragmented across the different runtimes (each offering different functionality at the moment).
    - flohofwoe 7y ago
      Think of plugins for applications like Autodesk Maya. Currently these are either cross-platform, but very slow Python plugins, or fast native DLLs which need to be compiled for each app-version/OS/CPU combination. If Maya had an embedded WASM runtime it could support plugins which are fast (at least much closer to native speed than Python scripts), and you only need to distribute a single WASM blob.

ScottFree 7y ago

WASM is still young. The tooling around it hasn't gained maturity yet. Do you remember trying to debug Javascript before the creation of the in-browser debugger? Desktop application developers back then probably felt the same way you do now. > this seems like a huge layered mess just waiting to trouble those poor devs. WASM is a VM. It's less complicated than a javascript engine. How complicated it seems in daily practice is going to come down to how good the tooling is.

aidos 7y ago
Minor nitpick. WebKit created a debugger a couple of years before chrome existed. https://webkit.org/blog/61/introducing-drosera/ https://webkit.org/blog/61/introducing-drosera/
- ScottFree 7y ago
  Yes, the bike shed should definitely be green. I knew somebody was going to object to that little factoid despite its irrelevance to the point at hand. I've updated my comment to remove any reference to any specific in-browser debugger.
  - aidos 7y ago
    Apologies, didn’t intend to detract from your point. I thought people might be interested in the history of it since very few people even at the time seemed to know of its existence.
    - ScottFree 7y ago
      No worries. I should have chosen my words more carefully. And, to be fair, I didn't know webkit was the first to create an in-browser debugger either. I always thought it was either Chrome or Firefox.
      - deleted 7y ago
        [deleted]