7 ms·

This question is going to make me sound like a jerk, but why do you want to write your back-end in JS? Deno looks like a great improvement over node.js, but I d

by vlunkr 4y ago

This question is going to make me sound like a jerk, but why do you want to write your back-end in JS? Deno looks like a great improvement over node.js, but I don't feel compelled to use it. It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve. Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling. EDIT: I haven't learned typescript yet, based on the replies, it seems like that could be a good reason to choose it. Seems like a nice middle-ground between typical scripting and compiled languages.

timmg 4y ago
You're kinda stuck writing JS on the frontend. The (only) advantage of also using it on the backend is that you can share code. In some cases, I could see that being compelling. FWIW, I think Typescript would make an even stronger case. And I think(?) that's one thing Deno is trying to do.
- pmoleri 4y ago
  Sharing code is great, I've moved processing between backend and front-end or even share the same code in both. Makes SSR+SPA possible using the same code. Typescript is a must for me, but I don't need Deno for that. I haven't used beyond scripting but for the time being I don't see a mayor benefit over node or ts-node other than easier/zero project setup.
mrkurt 4y ago
I like TypeScript and would like to write backends in TypeScript. I'm coming around on Elixir. I never want to write Go that interacts with a database again. Rust seems complicated. I don't think I'm smart or committed enough to get anywhere with rust.
- kbd 4y ago
  > I never want to write Go that interacts with a database again. Why? I’ve been using sqlx and it seems fine.
  - cdelsolar 4y ago
    yeah, i'm using pgx and it rocks
  - christophilus 4y ago
    Sqlx is the way.
  - kureikain 4y ago
    sqlc.dev make it way easier to deal with db
    - rawoke083600 4y ago
      I hope so, last time i checked about 6 months ago, I spend a day trying to make the most basic of queries work with mysql8, was a complete disaster.
  - berkes 4y ago
    Not OP, but one answer I've often heard and experienced myself is that statically typed datastructures feel painful when you come from dynamic languages like Python, Ruby or JavaScript.
- norman784 4y ago
  > Rust seems complicated. I don't think I'm smart or committed enough to get anywhere with rust. Rust is a bit rough yet to do the front and backend development, but IMHO it will catch in a year or two. Also for backend rust now with (actix and axum) looks pretty similar to expressjs, so you will feel like home there, but for the frontend there's still no killer framework nor a settled architecture that fits better rust model.
- rawoke083600 4y ago
Hamcha 4y ago
I use Deno from time to time, and in my opinion more than a back-end language it's a really powerful scripting language. Being able to reference libraries by URL and the Go-like standard library mixed with Typescript async makes it a breeze to develop simple one-use CLI tools!
mattlondon 4y ago
It uses typescript predominantly, and only compiles down to JavaScript. (I think you can code in plain JavaScript directly but I don't think anyone would want to do that) The benefits are in my mind not that you can share code directly but more that the std lib is the same (mostly) between backend and frontend. This means no mental context switching for developers. The other bonus is that typescript is just such a lovely thing to code in. Expressive, universal and ubiquitous, performant - modern JS is a joy to use (...if you don't need to use NPM... If you need to use NPM at all then it is a shit show)
flohofwoe 4y ago
I may be the odd one out, but for me node.js (and hopefully in the future Deno) isn't about the backend, but instead it's a pretty nice scripting environment for tooling and automation. I've been using mainly Python for this in the past, but got burned out quite a bit by the python2=>3 transition. (but still: don't underestimate the raw performance of V8, for many things it's definitely good enough)
- mmcnl 4y ago
  I completely understand what you're saying, but Python is a lot better now. You don't have to worry about Python 2 anymore and the tooling is a lot better as well (Black, Flake8, Poetry are all really nice).
digitxpc 4y ago
I've written up an at-scale production backend in Node.js and can very much stand by the decision to use Node over Elixir or Go (which I was considering at the time). I think fundamentally, the power of a JS-based backend is its pragmatism--it's not the best at most things, but it comes very close to it in so many categories that it's a safe option for a lot of use cases. > It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve. I'd agree that Node.js performance is generally not the best reason to be writing a backend in it since a static language will often yield better performance, but for the amount of dynamic power you get, it's extremely performant by default[1]. The next most performant dynamic language for I/O is, like you said, probably Erlang/Elixir, but V8 is generally understood to have better CPU-bound performance than BEAM. [1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling. I've found that developers already knowing JS is a very practical reason, if not ideological. I'm in a team with a lot of generalists who like to work full-stack, and being able to use the same mental models and syntax is a lot of cognitive load lifted off our shoulders. It also doubles the hiring pool of people who can hit the ground running on the backend, because now anyone who has experience with JS on the frontend can jump over to the backend with relatively little training. The other key reason for a backend in JS is that the community is extremely large, which means that a lot of the troubleshooting I'd have to do in languages with smaller communities is done for me by someone who was kind enough to post a workaround online. This saves me a lot of time and energy, as does the plethora of packages.
- brundolf 4y ago
  And the performance argument isn't even just about CPU time, right? The fact that JS is heavily event-friendly, and all of its IO APIs are non-blocking by default, gives it an automatic advantage over busy-waiting languages like Python, and also languages where concurrency means writing threads manually. If your web server spends most of its time on IO (network, DB, file system), as many do, JS acts as a lightweight task-delegator to a highly parallel and performant native runtime. I haven't worked on a large-scale JS back-end myself, but this is the case I've heard others make
quickthrower2 4y ago
Hard to out my finger on a single reason for it but I prefer it for hobby projects. Part of the reason is I am already using node for tooling for the front end. It is less powerful than say C# for example in multitasking - but for hobby projects that rarely matters. Typescript makes a big difference. There is a lot of community support: stackoverflow, npm packages etc. Every SDK has a JS version. It is fast enough for my needs. NextJS is another good reason.
golergka 4y ago
I've written backends using C#, PHP back in the day, a little bit of Go, Java and naked SQL, and I prefer Typescript language and npm ecosystem, hands down. May be not for writing highload distributed systems that are critical at RAM & CPU, but IO-heavy business logic where managing requirements and their changes is the hardest challenge, it's a godsend.
Escapado 4y ago
I think developers knowing JS/TS is a highly compelling argument given the fact that most companies are struggling to find any devs at all. I would argue finding Rust/Go/Elixir developers is going to be _a lot_ harder for a lot of companies than finding JS developers. Also then sufficiently proficient frontend Devs have an easy in into backend development which has turned out to be a very good thing at 5 different companies I have worked for in the last 4 years. In addition to that not every backend or service needs much performance. I have written quite a few services that get hit maybe 3 or 4 times a minute at best and Node was great for that. Actually I have yet to work anywhere where performance was limited by the language choice and not by architectural decisions or inconsidered use of databases and data structures. I am not saying this does not exist but it does not mirror my experience with the majority of companies at all. I'd also say that despite npm and dependency hell being a real problem there is a vast ecosystem of packages out there. I know python has that going for it too. But Elixir is much less developed in that regard - simply by being less popular.
presentation 4y ago
Sharing code with the browser can be really sweet. At a past job we used TypeScript, and I had whipped up some shared types that our API was forced to conform to, and that automatically generated a strongly typed API client for the frontend to use. Sure, you can do that with some other protocol or server like GraphQL/Hasura/writing up a JSON schema, but it was pretty sweet that A) any of our engineers could figure out how to make the endpoints they needed to implement a new feature, B) these types could generally be inferred from the actual API implementation without having to explicitly write types out which completely eliminated bugs around API misuse with minimal extra code, and C) all of the code we wrote followed the same linters, formatters, idioms, and utilities (fetching, logging, error handling, and so on). There are projects out now that wrap up a lot of what I had done like tRPC [1], as a testament to the value of the shared abstractions. [1] https://trpc.io/ https://trpc.io/
rr888 4y ago
To me its very powerful to have the same developers do both front end and back end. With modern frameworks its probably easier for front end devs to do back end work than Rust/Go/Elixir devs to dirty themselves with JS. So even though ts is suboptimal it allows one language, one set of tools and developers.
hombre_fatal 4y ago
- Javascript's async-everything is rather unique. - Synchronous execution + async-everything is a great combo. - First class Promise abstraction. - Good general purpose language. Its warts are mostly smoothed over. It's not like Javascript from 20 years ago. I like writing Javascript. I certainly prefer it over the other popular dynamically typed languages. (I don't see what Ruby or Python offer me over JS as general languages) Rust and Go make different trade-offs. I would never default to either for general purpose projects. Meanwhile JS is my default for networked code.
- javajosh 4y ago
  >Python, Ruby I like js too, but both python and ruby are much better languages. It's just that js won distribution, which means it won adoption, which means you have 10MM devs smoothing it's rough edges. Just to take one language feature, consider pythons list and map comprehensions. js has nothing like that - but it also has 10 high quality libraries that do that and more, like lodash. Consider also the ridiculousness around javascript's "OOP" features, like the use of "this", or it's behavior around truthiness, or (arguably) the misfeature of prototypal inheretance - all of which can be forgiven because functions are, after all, first class in javascript, which means you can, with enough effort, fix all the things. In truth if you want to understand absolutely everything about your runtime, and have some feeling of safety in a sandbox, then the jvm is the best. The vmspec is great, as is the langspec. It's very fast. The tools are mature. Lots of languages are written for it. It's behavior under load is well-understood. Like PHP there is a lot of bad code written for it, which gives it a bad name, but it's still a real gem.
  - hombre_fatal 4y ago
    Well, they asked why someone would use JS if there were other options, and I'm saying that I don't think Ruby nor Python are better languages than JS. Part of that is due to their bolt-on async vs JS async everything, part of that is due to TS, but there's more. For example, you bring up Python's collection comprehensions, but I could easily point out Python's gimped lambda support and thus poor FP abstractions and the need for a special comprehension abstraction. I don't think it's worth arguing about. But I had to chime in before someone thinks there really are no objective nor subjective reasons why someone might prefer Javascript. I do. > then [X] is the best. Btw, there is no best. There are only trade-offs. One of my points is that you can't say something is the best. The only thing you can do is enumerate the trade-offs that made sense for you, and much of that is only personal/aesthetic.

by vlunkr 4y ago

timmg 4y ago

You're kinda stuck writing JS on the frontend. The (only) advantage of also using it on the backend is that you can share code. In some cases, I could see that being compelling. FWIW, I think Typescript would make an even stronger case. And I think(?) that's one thing Deno is trying to do.

pmoleri 4y ago
Sharing code is great, I've moved processing between backend and front-end or even share the same code in both. Makes SSR+SPA possible using the same code. Typescript is a must for me, but I don't need Deno for that. I haven't used beyond scripting but for the time being I don't see a mayor benefit over node or ts-node other than easier/zero project setup.

mrkurt 4y ago

I like TypeScript and would like to write backends in TypeScript. I'm coming around on Elixir. I never want to write Go that interacts with a database again. Rust seems complicated. I don't think I'm smart or committed enough to get anywhere with rust.

kbd 4y ago
> I never want to write Go that interacts with a database again. Why? I’ve been using sqlx and it seems fine.
- cdelsolar 4y ago
  yeah, i'm using pgx and it rocks
- christophilus 4y ago
  Sqlx is the way.
- kureikain 4y ago
  sqlc.dev make it way easier to deal with db
  - rawoke083600 4y ago
    I hope so, last time i checked about 6 months ago, I spend a day trying to make the most basic of queries work with mysql8, was a complete disaster.
- berkes 4y ago
  Not OP, but one answer I've often heard and experienced myself is that statically typed datastructures feel painful when you come from dynamic languages like Python, Ruby or JavaScript.
norman784 4y ago
> Rust seems complicated. I don't think I'm smart or committed enough to get anywhere with rust. Rust is a bit rough yet to do the front and backend development, but IMHO it will catch in a year or two. Also for backend rust now with (actix and axum) looks pretty similar to expressjs, so you will feel like home there, but for the frontend there's still no killer framework nor a settled architecture that fits better rust model.
rawoke083600 4y ago

Hamcha 4y ago

I use Deno from time to time, and in my opinion more than a back-end language it's a really powerful scripting language. Being able to reference libraries by URL and the Go-like standard library mixed with Typescript async makes it a breeze to develop simple one-use CLI tools!

mattlondon 4y ago

It uses typescript predominantly, and only compiles down to JavaScript. (I think you can code in plain JavaScript directly but I don't think anyone would want to do that) The benefits are in my mind not that you can share code directly but more that the std lib is the same (mostly) between backend and frontend. This means no mental context switching for developers. The other bonus is that typescript is just such a lovely thing to code in. Expressive, universal and ubiquitous, performant - modern JS is a joy to use (...if you don't need to use NPM... If you need to use NPM at all then it is a shit show)

flohofwoe 4y ago

I may be the odd one out, but for me node.js (and hopefully in the future Deno) isn't about the backend, but instead it's a pretty nice scripting environment for tooling and automation. I've been using mainly Python for this in the past, but got burned out quite a bit by the python2=>3 transition. (but still: don't underestimate the raw performance of V8, for many things it's definitely good enough)

mmcnl 4y ago
I completely understand what you're saying, but Python is a lot better now. You don't have to worry about Python 2 anymore and the tooling is a lot better as well (Black, Flake8, Poetry are all really nice).

digitxpc 4y ago

I've written up an at-scale production backend in Node.js and can very much stand by the decision to use Node over Elixir or Go (which I was considering at the time). I think fundamentally, the power of a JS-based backend is its pragmatism--it's not the best at most things, but it comes very close to it in so many categories that it's a safe option for a lot of use cases. > It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve. I'd agree that Node.js performance is generally not the best reason to be writing a backend in it since a static language will often yield better performance, but for the amount of dynamic power you get, it's extremely performant by default[1]. The next most performant dynamic language for I/O is, like you said, probably Erlang/Elixir, but V8 is generally understood to have better CPU-bound performance than BEAM. [1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling. I've found that developers already knowing JS is a very practical reason, if not ideological. I'm in a team with a lot of generalists who like to work full-stack, and being able to use the same mental models and syntax is a lot of cognitive load lifted off our shoulders. It also doubles the hiring pool of people who can hit the ground running on the backend, because now anyone who has experience with JS on the frontend can jump over to the backend with relatively little training. The other key reason for a backend in JS is that the community is extremely large, which means that a lot of the troubleshooting I'd have to do in languages with smaller communities is done for me by someone who was kind enough to post a workaround online. This saves me a lot of time and energy, as does the plethora of packages.

brundolf 4y ago
And the performance argument isn't even just about CPU time, right? The fact that JS is heavily event-friendly, and all of its IO APIs are non-blocking by default, gives it an automatic advantage over busy-waiting languages like Python, and also languages where concurrency means writing threads manually. If your web server spends most of its time on IO (network, DB, file system), as many do, JS acts as a lightweight task-delegator to a highly parallel and performant native runtime. I haven't worked on a large-scale JS back-end myself, but this is the case I've heard others make

quickthrower2 4y ago

Hard to out my finger on a single reason for it but I prefer it for hobby projects. Part of the reason is I am already using node for tooling for the front end. It is less powerful than say C# for example in multitasking - but for hobby projects that rarely matters. Typescript makes a big difference. There is a lot of community support: stackoverflow, npm packages etc. Every SDK has a JS version. It is fast enough for my needs. NextJS is another good reason.

golergka 4y ago

I've written backends using C#, PHP back in the day, a little bit of Go, Java and naked SQL, and I prefer Typescript language and npm ecosystem, hands down. May be not for writing highload distributed systems that are critical at RAM & CPU, but IO-heavy business logic where managing requirements and their changes is the hardest challenge, it's a godsend.

Escapado 4y ago

I think developers knowing JS/TS is a highly compelling argument given the fact that most companies are struggling to find any devs at all. I would argue finding Rust/Go/Elixir developers is going to be _a lot_ harder for a lot of companies than finding JS developers. Also then sufficiently proficient frontend Devs have an easy in into backend development which has turned out to be a very good thing at 5 different companies I have worked for in the last 4 years. In addition to that not every backend or service needs much performance. I have written quite a few services that get hit maybe 3 or 4 times a minute at best and Node was great for that. Actually I have yet to work anywhere where performance was limited by the language choice and not by architectural decisions or inconsidered use of databases and data structures. I am not saying this does not exist but it does not mirror my experience with the majority of companies at all. I'd also say that despite npm and dependency hell being a real problem there is a vast ecosystem of packages out there. I know python has that going for it too. But Elixir is much less developed in that regard - simply by being less popular.

presentation 4y ago

Sharing code with the browser can be really sweet. At a past job we used TypeScript, and I had whipped up some shared types that our API was forced to conform to, and that automatically generated a strongly typed API client for the frontend to use. Sure, you can do that with some other protocol or server like GraphQL/Hasura/writing up a JSON schema, but it was pretty sweet that A) any of our engineers could figure out how to make the endpoints they needed to implement a new feature, B) these types could generally be inferred from the actual API implementation without having to explicitly write types out which completely eliminated bugs around API misuse with minimal extra code, and C) all of the code we wrote followed the same linters, formatters, idioms, and utilities (fetching, logging, error handling, and so on). There are projects out now that wrap up a lot of what I had done like tRPC [1], as a testament to the value of the shared abstractions. [1] https://trpc.io/ https://trpc.io/

rr888 4y ago

To me its very powerful to have the same developers do both front end and back end. With modern frameworks its probably easier for front end devs to do back end work than Rust/Go/Elixir devs to dirty themselves with JS. So even though ts is suboptimal it allows one language, one set of tools and developers.

hombre_fatal 4y ago

- Javascript's async-everything is rather unique. - Synchronous execution + async-everything is a great combo. - First class Promise abstraction. - Good general purpose language. Its warts are mostly smoothed over. It's not like Javascript from 20 years ago. I like writing Javascript. I certainly prefer it over the other popular dynamically typed languages. (I don't see what Ruby or Python offer me over JS as general languages) Rust and Go make different trade-offs. I would never default to either for general purpose projects. Meanwhile JS is my default for networked code.

javajosh 4y ago
>Python, Ruby I like js too, but both python and ruby are much better languages. It's just that js won distribution, which means it won adoption, which means you have 10MM devs smoothing it's rough edges. Just to take one language feature, consider pythons list and map comprehensions. js has nothing like that - but it also has 10 high quality libraries that do that and more, like lodash. Consider also the ridiculousness around javascript's "OOP" features, like the use of "this", or it's behavior around truthiness, or (arguably) the misfeature of prototypal inheretance - all of which can be forgiven because functions are, after all, first class in javascript, which means you can, with enough effort, fix all the things. In truth if you want to understand absolutely everything about your runtime, and have some feeling of safety in a sandbox, then the jvm is the best. The vmspec is great, as is the langspec. It's very fast. The tools are mature. Lots of languages are written for it. It's behavior under load is well-understood. Like PHP there is a lot of bad code written for it, which gives it a bad name, but it's still a real gem.
- hombre_fatal 4y ago
  Well, they asked why someone would use JS if there were other options, and I'm saying that I don't think Ruby nor Python are better languages than JS. Part of that is due to their bolt-on async vs JS async everything, part of that is due to TS, but there's more. For example, you bring up Python's collection comprehensions, but I could easily point out Python's gimped lambda support and thus poor FP abstractions and the need for a special comprehension abstraction. I don't think it's worth arguing about. But I had to chime in before someone thinks there really are no objective nor subjective reasons why someone might prefer Javascript. I do. > then [X] is the best. Btw, there is no best. There are only trade-offs. One of my points is that you can't say something is the best. The only thing you can do is enumerate the trade-offs that made sense for you, and much of that is only personal/aesthetic.