9 ms·

I'm tired of the 'too fractured' trope. Backend programming is too fractured too then- should I use Java? Go? Python? Rust? What database? What build system? Wh

I'm tired of the 'too fractured' trope. Backend programming is too fractured too then- should I use Java? Go? Python? Rust? What database? What build system? What CI system? Frontend is massive, why would one suppose that a single solution would work for everyone? Horrible metric, GitHub stars: - 104k React - 58k Angular.js - 43k Go - 42k WebPack

slimsag 8y ago
The backend can also be too fractured. Isn't that one of the reasons why people pitch Node.js for backend applications? "Write in one language, reduce fracturing"? I would not argue one solution fits all. I think having the ability to write frontend+backend in JS _and_ Go is a good thing.
- yulaow 8y ago
  It could actually very good for productivity for teams who use other languages in the backend. I mean, I bet that as soon as possibile all the c# consultancy companies - just to pick a common example of big teams using a single language for the backend systems of all the projects of the company - would switch also their frontend to c# when it is supported by all major browsers
AsyncAwait 8y ago
For back-end programming, once you pick up a language, you use its standard set of tooling like you would for every other type of program and by making a choice of language, you can select the style of programming you prefer, (functional, OO), or tap into your existing knowledge. With JavaScript, it is the only choice available, so if you want a different style of programming you have to involve all kinds of additional tooling in addition to the language's native tooling, on top of having to involve JavaScript's tooling, frontend package manager, backend package manager, transpillers, babel, gulp etc. etc. it's just a mess, not really comparable with having to invoke Bundler or Cargo for the backend side of things. > Frontend is massive, why would one suppose that a single solution would work for everyone? The problem is that JavaScript is the single solution that essentially has to work for everyone right now, hence the push for WebAssembly.
- abritinthebay 8y ago
  WASM solves a set of problems orthogonal to most JS use though. It doesn’t touch the DOM and there’s a VERY good reason for that. To which most advocates end up saying that’s because the DOM is bad and should be scrapped. Maybe, but now we have put the cart firmly so far in front of the horse that’s is a few days ride away.
  - behindmyscreen 8y ago
    https://www.reddit.com/r/WebAssembly/comments/7wlmjt/will_wasm_be_able_to_manipulate_the_dom_ever/ https://www.reddit.com/r/WebAssembly/comments/7wlmjt/will_wa...
    - abritinthebay 8y ago
      Yes, I’m very familiar with host bindings. Are they here yet? No. Are they performant yet? No idea because they don’t exist. They’re always brought up by WASM advocates like they solve anything. But they don’t... because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. So far the signs aren’t positive.
      - AsyncAwait 8y ago
        > Are they here yet? No. Are they performant yet? No idea because they don’t exist. Right, they're not here yet, so you don't know. > because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. WASM solves the problem of allowing languages with different semantics, strong type systems, different paradigms etc. that JS doesn't provide. Some of us care about the language we program in because we want to have somewhat enjoyable experience while doing it and for some JS does not provide that. That is the problem WASM solves. Whether host bindings would give us sufficiently fast access to the DOM isn't clear yet, as you yourself admitted, but I don't see why not and I certainly don't see what you're arguing about here - the problem WASM solves is, again, primarily not about DOM access that is somehow faster than JS, people are even expecting a bit of a penalty, at least initially, but as long as we can get rid of JS monopoly on the front-end, I think WASM achieved its goal.
tigershark 8y ago
Seriously go has 43k stars? Either I’m missing something or software development commoditisation is much more extensive that I’d have thought possible...

slimsag 8y ago

The backend can also be too fractured. Isn't that one of the reasons why people pitch Node.js for backend applications? "Write in one language, reduce fracturing"? I would not argue one solution fits all. I think having the ability to write frontend+backend in JS _and_ Go is a good thing.

yulaow 8y ago
It could actually very good for productivity for teams who use other languages in the backend. I mean, I bet that as soon as possibile all the c# consultancy companies - just to pick a common example of big teams using a single language for the backend systems of all the projects of the company - would switch also their frontend to c# when it is supported by all major browsers

AsyncAwait 8y ago

For back-end programming, once you pick up a language, you use its standard set of tooling like you would for every other type of program and by making a choice of language, you can select the style of programming you prefer, (functional, OO), or tap into your existing knowledge. With JavaScript, it is the only choice available, so if you want a different style of programming you have to involve all kinds of additional tooling in addition to the language's native tooling, on top of having to involve JavaScript's tooling, frontend package manager, backend package manager, transpillers, babel, gulp etc. etc. it's just a mess, not really comparable with having to invoke Bundler or Cargo for the backend side of things. > Frontend is massive, why would one suppose that a single solution would work for everyone? The problem is that JavaScript is the single solution that essentially has to work for everyone right now, hence the push for WebAssembly.

abritinthebay 8y ago
WASM solves a set of problems orthogonal to most JS use though. It doesn’t touch the DOM and there’s a VERY good reason for that. To which most advocates end up saying that’s because the DOM is bad and should be scrapped. Maybe, but now we have put the cart firmly so far in front of the horse that’s is a few days ride away.
- behindmyscreen 8y ago
  https://www.reddit.com/r/WebAssembly/comments/7wlmjt/will_wasm_be_able_to_manipulate_the_dom_ever/ https://www.reddit.com/r/WebAssembly/comments/7wlmjt/will_wa...
  - abritinthebay 8y ago
    Yes, I’m very familiar with host bindings. Are they here yet? No. Are they performant yet? No idea because they don’t exist. They’re always brought up by WASM advocates like they solve anything. But they don’t... because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. So far the signs aren’t positive.
    - AsyncAwait 8y ago
      > Are they here yet? No. Are they performant yet? No idea because they don’t exist. Right, they're not here yet, so you don't know. > because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. WASM solves the problem of allowing languages with different semantics, strong type systems, different paradigms etc. that JS doesn't provide. Some of us care about the language we program in because we want to have somewhat enjoyable experience while doing it and for some JS does not provide that. That is the problem WASM solves. Whether host bindings would give us sufficiently fast access to the DOM isn't clear yet, as you yourself admitted, but I don't see why not and I certainly don't see what you're arguing about here - the problem WASM solves is, again, primarily not about DOM access that is somehow faster than JS, people are even expecting a bit of a penalty, at least initially, but as long as we can get rid of JS monopoly on the front-end, I think WASM achieved its goal.

tigershark 8y ago

Seriously go has 43k stars? Either I’m missing something or software development commoditisation is much more extensive that I’d have thought possible...