5 ms·

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs develope

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code. I really don't see how anyone choses nodejs/deno to anything. Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime. Next on my list is to give rust a go, since I'm intrigued by its features, but if I was to go fast I'd go with java any day.

bxparks 4y ago
Your post is a great example why I wish Go lang was named something different. Because you use the lower cased versions java, rust, js, ts, nodejs, deno, etc. But all your 'go' refer to the verb, not the Go language.
ye-olde-sysrq 4y ago
"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right choice if you're a full-stack dev or a solo dev and you mainly know js and you get a lot of agility and correctness by using what you know instead of trying to use a "better" choice but one that you yourself are less likely to use correctly or quickly in your own use case. It can also be the right choice if you're a big backend java/etc guru but you know you want to set this thing up but then just monitor/oversee frontend/fullstack devs being the ones who do incremental modifications to it. But yeah - without additional outside constraints and everything else being equal, it doesn't make a lot of sense to use nodejs as opposed to basically anything more boring - be it java, rails, etc. The thing that surprises me the most about node based backends is that they forego both the platform maturity and static-safety of java AND the ridiculous amount of batteries included into django and rails, just to be able to use javascript, of all things. What you could rails-g in a minute you could instead spend a day looking for an npm package that won't be abandoned in a month or spend eternity rolling your own everything and then maintaining it.
- legerdemain 4y ago
  This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in Java and Go. There aren't any, and senior people in those communities are hostile to the very idea. (Maybe remembering Java Nashorn?) Maybe the only people friendly to the idea of interoperable back ends are Rust people (where you have libraries like Yew/Sycamore/Dioxus/Leptos that actively imitate JS frameworks). But yes, your claim is that the only reason to write JS back ends is ignorance and enfeeblement is ignorant and repugnant.
  - zozbot234 4y ago
    > want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.
    - legerdemain 4y ago
      > You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients. Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.
      - 4y ago
8note 4y ago
I find typescript makes the most common things I do in business app software as straightforward as possible. That is, making copies of objects with slightly different structure to pass them to some other system. Typescript is just fantastic for plumbing. To do the same in java means making a billion model files with a billion transformation functions on them
- xyzzy4747 4y ago
  Yup. I view TypeScript as the best "get things done quickly without too much code and minimal bugs" language.
nazka 4y ago
You should try NestJS with Prisma or Typeorm and Postgres. Plus all the classic other stuff. It's a great stack.
pdntspa 4y ago
And the IDEs which practically write your code for you. I mean yeah Java is so verbose but most of that word vomit is me just tabbing through autocomplete I went back and prototyped a slightly similar app in Python w/ a gui toolkit and I felt like I was driving through exception city. I have made my career writing in dynamic languages so I forgot just how pleasant it was to write in a static one!
- nawgz 4y ago
  > Python w/ a gui toolkit Sorry, this is always the wrong choice, which is why it felt so bad. Writing a UI in TypeScript with any of the major frontend frameworks will not require you to wade through run-time exceptions Java native GUI toolkits are also far more mature Python and TKinter and similar stuff is always just awful, I've never seen someone put together anything half decent with that stack
  - pdntspa 4y ago
    Calibre, the ebook client, is a python GUI app. wxWidgets I think? Theres another app that I use for renaming downloaded video files that uses a GUI toolkit. I've written GUIs in pyGTK for industrial apps and it was a wonderful experience. The only reason I couldn't get it to work now because I can't get pygobject to compile on Windows (the offered solution of MSYS2... wasnt) Unfortunately this project was working with Stable Diffusion, so I had to use something in Python In any case I don't like this idea of a right or wrong answer here. LIke way too many people think Electron is a right answer and I think that's just dumb

bxparks 4y ago

Your post is a great example why I wish Go lang was named something different. Because you use the lower cased versions java, rust, js, ts, nodejs, deno, etc. But all your 'go' refer to the verb, not the Go language.

ye-olde-sysrq 4y ago

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right choice if you're a full-stack dev or a solo dev and you mainly know js and you get a lot of agility and correctness by using what you know instead of trying to use a "better" choice but one that you yourself are less likely to use correctly or quickly in your own use case. It can also be the right choice if you're a big backend java/etc guru but you know you want to set this thing up but then just monitor/oversee frontend/fullstack devs being the ones who do incremental modifications to it. But yeah - without additional outside constraints and everything else being equal, it doesn't make a lot of sense to use nodejs as opposed to basically anything more boring - be it java, rails, etc. The thing that surprises me the most about node based backends is that they forego both the platform maturity and static-safety of java AND the ridiculous amount of batteries included into django and rails, just to be able to use javascript, of all things. What you could rails-g in a minute you could instead spend a day looking for an npm package that won't be abandoned in a month or spend eternity rolling your own everything and then maintaining it.

legerdemain 4y ago
This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in Java and Go. There aren't any, and senior people in those communities are hostile to the very idea. (Maybe remembering Java Nashorn?) Maybe the only people friendly to the idea of interoperable back ends are Rust people (where you have libraries like Yew/Sycamore/Dioxus/Leptos that actively imitate JS frameworks). But yes, your claim is that the only reason to write JS back ends is ignorance and enfeeblement is ignorant and repugnant.
- zozbot234 4y ago
  > want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.
  - legerdemain 4y ago
    > You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients. Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.
    - 4y ago

8note 4y ago

I find typescript makes the most common things I do in business app software as straightforward as possible. That is, making copies of objects with slightly different structure to pass them to some other system. Typescript is just fantastic for plumbing. To do the same in java means making a billion model files with a billion transformation functions on them

xyzzy4747 4y ago
Yup. I view TypeScript as the best "get things done quickly without too much code and minimal bugs" language.

nazka 4y ago

You should try NestJS with Prisma or Typeorm and Postgres. Plus all the classic other stuff. It's a great stack.

pdntspa 4y ago

And the IDEs which practically write your code for you. I mean yeah Java is so verbose but most of that word vomit is me just tabbing through autocomplete I went back and prototyped a slightly similar app in Python w/ a gui toolkit and I felt like I was driving through exception city. I have made my career writing in dynamic languages so I forgot just how pleasant it was to write in a static one!

nawgz 4y ago
> Python w/ a gui toolkit Sorry, this is always the wrong choice, which is why it felt so bad. Writing a UI in TypeScript with any of the major frontend frameworks will not require you to wade through run-time exceptions Java native GUI toolkits are also far more mature Python and TKinter and similar stuff is always just awful, I've never seen someone put together anything half decent with that stack
- pdntspa 4y ago
  Calibre, the ebook client, is a python GUI app. wxWidgets I think? Theres another app that I use for renaming downloaded video files that uses a GUI toolkit. I've written GUIs in pyGTK for industrial apps and it was a wonderful experience. The only reason I couldn't get it to work now because I can't get pygobject to compile on Windows (the offered solution of MSYS2... wasnt) Unfortunately this project was working with Stable Diffusion, so I had to use something in Python In any case I don't like this idea of a right or wrong answer here. LIke way too many people think Electron is a right answer and I think that's just dumb