You may technically be coding in one language, but JS written for Node looks radically different from JS written to run in the browser. In my experience, there’s rarely more than some small chunks of code that you touch that will run in both environments.
If you get some better tooling for multi-language development, it will usually pay off a lot faster than choosing Node for your backend will.
JS in Node and JS in browser is not that different. It's the same language, using the same JavaScript engine (v8 for chrome). The difference is in the APIs provided by Node vs Browser, which is pretty minor. Many popular JS libraries will run in Node just as well as Browser. That being said, JS is a pretty shit language and I don't know why anyone would want to use it for backend work.
Depends. It sure is nice to write helper functions that I can import on the serverside js and in the client side. Also if you use next or nuxt or something like that you get universal rendering, which is nice. Totally depends on your use case.
You just have to keep an eye on your client bundle size if these shares functions ref something like underscore, moment or something like that where you’re pulling in the entire thing for one function. I’m aware you can just pick pieces with {} and import, but not everyone is aware and often require the entire thing.
So coding in one language is a BIT of a red herring.
It only works if the paradigms your app uses are the same in the front and back. And I have nott seen a project where the KIND of problems that need solving (in the front vs back) were close enough for the same language to be a benefit.
I mean at the end of the day, I can build a house with JUST a screwdriver, but man, I'd rather use the right tool fot the specific job.
My company uses Node with Typescript on the front and backend; we’ve strongly typed our APIs and thanks to the excellent io-ts library we’ve also automated the marshaling and unmarshaling data as it crosses the network boundary so that we can continue to use the strongly typed data, and also are constrained by the types to only call our APIs in valid ways.
Some subset of that can be achieved with stuff like GraphQL or Swagger and what not though I haven’t given it a serious try since we’ve never run into hiccups yet with this system, reliant on a very simple library.
We also use the same package manager (NPM) on both ends and can therefore invoke scripts all over our codebase with the same syntax; and although react code and node code is quite different in structure, they all have the same idioms and async syntax and stuff, so the amount of retraining necessary to convert someone from backend to full stack isn’t very large due to the same environment, and keeping code style consistent across the project is also easy.
So I feel like there’s definitely stuff to profit off of with sharing a single language.
Reminds me of yesterday's hn frontpager, the paper about a "programble programming language". they were talking about how domain specific languages within a single language become super distinct and ungrokable to people who are otherwise fluent in the parent language. Think like, an angular dev reading nest.js node backend stuff. With javascript this is sorta everywhere. JS DSLs arent like explicitly uninterpretable to otherwise-experienced JS devs but there is a context shift cost for sure.
Ive not worked with c# much, but is that not as much of a problem with it? Like, is there more of a standardized way of doing things? Python is kinda like that i guess.
klodolph|6 years ago
If you get some better tooling for multi-language development, it will usually pay off a lot faster than choosing Node for your backend will.
excursionist|6 years ago
honopu|6 years ago
You just have to keep an eye on your client bundle size if these shares functions ref something like underscore, moment or something like that where you’re pulling in the entire thing for one function. I’m aware you can just pick pieces with {} and import, but not everyone is aware and often require the entire thing.
igreulich|6 years ago
It only works if the paradigms your app uses are the same in the front and back. And I have nott seen a project where the KIND of problems that need solving (in the front vs back) were close enough for the same language to be a benefit.
I mean at the end of the day, I can build a house with JUST a screwdriver, but man, I'd rather use the right tool fot the specific job.
And at the end of the day, $LANG is a tool.
osdiab|6 years ago
Some subset of that can be achieved with stuff like GraphQL or Swagger and what not though I haven’t given it a serious try since we’ve never run into hiccups yet with this system, reliant on a very simple library.
We also use the same package manager (NPM) on both ends and can therefore invoke scripts all over our codebase with the same syntax; and although react code and node code is quite different in structure, they all have the same idioms and async syntax and stuff, so the amount of retraining necessary to convert someone from backend to full stack isn’t very large due to the same environment, and keeping code style consistent across the project is also easy.
So I feel like there’s definitely stuff to profit off of with sharing a single language.
deusofnull|6 years ago
Ive not worked with c# much, but is that not as much of a problem with it? Like, is there more of a standardized way of doing things? Python is kinda like that i guess.