3 ms·

JavaScript is hell. You can get so much done with the basic supplied libraries when programming for .Net, JVM or Cocoa. What a giant leap back we made in terms

by dep_b 3y ago

JavaScript is hell. You can get so much done with the basic supplied libraries when programming for .Net, JVM or Cocoa. What a giant leap back we made in terms of ecosystem and language by going for JavaScript everywhere.

bitwize 3y ago
Goddamnit, the JavaScript ecosystem needs its own Visual Basic. Something that comes with everything you need to build and deploy a basic, but functional, real-world application. * Any dependencies need to be installed to build a real world (server + UI or API) application = non-starter. * Any shell commands needed to write, build, or deploy the app in a container = non-starter. * Any code necessary to lay out the UI (including HTML, CSS) = non-starter. I haven't kept abreast with the Microsoft ecosystem. Does Visual Studio have something like this for Node apps? Is ASP still a thing for C#?
- strokirk 3y ago
  How do you use Visual Basic on unixes?
- Shawnj2 3y ago
  https://xkcd.com/927/ https://xkcd.com/927/ This but JavaScript frameworks
  - tankenmate 3y ago
    Exactly, front end coders are very design driven (obviously) so they often value "ooh the shinies" brand new framework, etc over "let's engineer this correctly" battle tested not so shiny code.
JodieBenitez 3y ago
I understand the Javascript fatigue, but why going for Javascript everywhere ? Keep it where it belongs, in the browser, then it's not so bad (or rather, it is bad but it's getting better).
- tankenmate 3y ago
  Personally I have gone for golang everywhere; via WASM. The golang standard library is much cleaner than the Javascript ecosystem and in almost all ways is performant under WASM. Obviously you also get the benefit of having the same code on the server and the browser. You can't avoid the DOM, but you can do some pretty amazing things with SVG if you take it easy (browsers are renowned for their inefficiencies with too many SVG images on a page). For most web sites it's a good fit. And unlike Javascript golang heavily leans you toward doing the right thing (although you can always stuff things up if you try). The only real pain point is that WASM is still finding its feet.
  - JodieBenitez 3y ago
    Care to share some examples ?
    - tankenmate 3y ago
      I can't share any of my own examples, but most of the work I do was originally based on Vugu[0] which is open source. It is loosely modelled on Vue, so template files have both HTML and Go source (for the view / front end / ui handling) in the one file.[1] The code I have written has since diverged a bit from Vugu but at its core it's handled the same way. People are still working on Vugu (you can check the issues / branches) but there hasn't been a new release in a while; it's still somewhat experimental. [0] https://www.vugu.org/ https://www.vugu.org/ [1] https://github.com/vugu-examples/simple/blob/master/root.vugu https://github.com/vugu-examples/simple/blob/master/root.vug...
pavlov 3y ago
I first used Node around 2010 to write some little TCP servers and local event processing tools. It was fun and simple with just the standard library, and I remember thinking: "A great thing about this Node package manager is that it's obviously so intentionally primitive, nobody would try to use it to create those massive framework dependency monsters like in other languages. So this will remain a simple and fast runtime." How profoundly wrong I was (not for the first time).

by dep_b 3y ago

bitwize 3y ago

Goddamnit, the JavaScript ecosystem needs its own Visual Basic. Something that comes with everything you need to build and deploy a basic, but functional, real-world application. * Any dependencies need to be installed to build a real world (server + UI or API) application = non-starter. * Any shell commands needed to write, build, or deploy the app in a container = non-starter. * Any code necessary to lay out the UI (including HTML, CSS) = non-starter. I haven't kept abreast with the Microsoft ecosystem. Does Visual Studio have something like this for Node apps? Is ASP still a thing for C#?

strokirk 3y ago
How do you use Visual Basic on unixes?
Shawnj2 3y ago
https://xkcd.com/927/ https://xkcd.com/927/ This but JavaScript frameworks
- tankenmate 3y ago
  Exactly, front end coders are very design driven (obviously) so they often value "ooh the shinies" brand new framework, etc over "let's engineer this correctly" battle tested not so shiny code.

JodieBenitez 3y ago

I understand the Javascript fatigue, but why going for Javascript everywhere ? Keep it where it belongs, in the browser, then it's not so bad (or rather, it is bad but it's getting better).

tankenmate 3y ago
Personally I have gone for golang everywhere; via WASM. The golang standard library is much cleaner than the Javascript ecosystem and in almost all ways is performant under WASM. Obviously you also get the benefit of having the same code on the server and the browser. You can't avoid the DOM, but you can do some pretty amazing things with SVG if you take it easy (browsers are renowned for their inefficiencies with too many SVG images on a page). For most web sites it's a good fit. And unlike Javascript golang heavily leans you toward doing the right thing (although you can always stuff things up if you try). The only real pain point is that WASM is still finding its feet.
- JodieBenitez 3y ago
  Care to share some examples ?
  - tankenmate 3y ago
    I can't share any of my own examples, but most of the work I do was originally based on Vugu[0] which is open source. It is loosely modelled on Vue, so template files have both HTML and Go source (for the view / front end / ui handling) in the one file.[1] The code I have written has since diverged a bit from Vugu but at its core it's handled the same way. People are still working on Vugu (you can check the issues / branches) but there hasn't been a new release in a while; it's still somewhat experimental. [0] https://www.vugu.org/ https://www.vugu.org/ [1] https://github.com/vugu-examples/simple/blob/master/root.vugu https://github.com/vugu-examples/simple/blob/master/root.vug...

pavlov 3y ago

I first used Node around 2010 to write some little TCP servers and local event processing tools. It was fun and simple with just the standard library, and I remember thinking: "A great thing about this Node package manager is that it's obviously so intentionally primitive, nobody would try to use it to create those massive framework dependency monsters like in other languages. So this will remain a simple and fast runtime." How profoundly wrong I was (not for the first time).