5 ms·

> 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

> 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
    Can you show some apps using Blazor?
    - tracker1 7y ago
      Nothing is public/demoable at this point, sorry. They're using Bootstrap with a Material Design theme applied, nothing too special (CRUD). The app I'm working on has a more complex UI.
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...

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
  Can you show some apps using Blazor?
  - tracker1 7y ago
    Nothing is public/demoable at this point, sorry. They're using Bootstrap with a Material Design theme applied, nothing too special (CRUD). The app I'm working on has a more complex UI.

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...