5 ms·

I'm a C# developer at what I think is a really good dev environment. Tons of smart people here and we're highly productive. I like C# and I honestly feel boring

I'm a C# developer at what I think is a really good dev environment. Tons of smart people here and we're highly productive. I like C# and I honestly feel boring software is better. I can't get behind chasing the latest trends. Why should I learn Node instead? Does writing backend Javascript mean you're a better developer?

barce 7y ago
Why node? 2 reasons: async which C# has too, and coding in just one language. And no, writing backend JavaScript doesn't mean you're better.
- klodolph 7y ago
  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.
  - excursionist 7y ago
    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.
    - everybodyknows 7y ago
      >same JavaScript engine (v8 for chrome) That way lies surrender by default to the Google empire.
      - excursionist 7y ago
        What? It's just a simple fact that Node, Chrome and Chromium all use V8 - which is an open source BSD licensed project.
    - klodolph 7y ago
      My experience is different. I write a decent amount of JS code each year and try to catch up with current best practices where I can, but every year it’s been a bit of a pain to write any code that’s shared between browser and client. Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async (shockingly, with backend support lagging). These days my main strategy is to have three TypeScript projects—frontend, backend, and common. I then whitelist imports in the common libraries. > It's the same language, using the same JavaScript engine (v8 for chrome). I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.
      - excursionist 7y ago
        > Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code. > I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later. The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.
        klodolph 7y ago
        > New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code. For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client. My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place. Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc. There’s a whole pipeline between your source code and the JavaScript engine, and that pipeline has a different shape for backend and frontend, and typically uses completely different libraries to make it work. > The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS. I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine. I haven’t figured out a way to leverage that fact to give me any additional productivity. For the projects I’ve worked on, it can end up taking me quite a bit of time figuring out how to make one piece of code work in both frontend and backend, even though I can trivially make it work in either environment as I please. Maybe other people have already solved this, but I recently went through and made a bunch of PRs to fix a common issue I saw in other people’s codebases and it was super rare to see any code shared between frontend and backend.
  - honopu 7y ago
    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.
    - egeozcan 7y ago
      The purpose of next (and perhaps nuxt, I've never used it) is more in the direction of a front-backend. The API-implementing level is usually very different than the one consuming it, even when the consumer is on the server-side. If this wasn't the case, IMHO, projects like Meteor would be immensely more popular.
- igreulich 7y ago
  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. And at the end of the day, $LANG is a tool.
  - deusofnull 7y ago
    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.
  - osdiab 7y ago
    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.
thawaway1837 7y ago
My problem with C# server development until recently has been the reliance on visual studio. A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS. And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS, but you end up spending a lot of time and energy trying to figure out what might be wrong before going that route. Fortunately, both of these issues have been resolved with the open source .Net Core, and while we continue to use .Net Framework, I’m looking forward to doing more .Net Core development going forward.
- vsareto 7y ago
  >My problem with C# server development until recently has been the reliance on visual studio. TBH there are very few IDEs or environments that match Visual Studio. If you've never used it, of course you'll be less productive. >A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS. Project and solution files have been XML for a long while. I think the example here would be early UI work with WinForms and WPF? But everyone would think you're crazy to edit those text-only when you had a WYSIWYG editor. >And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS >Fortunately, both of these issues have been resolved with the open source .Net Core If there's an issue with Kestrel, I think you'll still be spending a long amount of time debugging that. I don't think much has changed on that front. .NET Core isn't a magic solution to this.
- skrebbel 7y ago
  I ran the tech team at a startup around 2014 and we had a C# stack with almost no visual studio. Most people were on mac or Linux and used MonoDevelop. We ran it on Mono in docker containers (which was brand new those days) on Linux VPSes. Truth is, for a long time already, C# has been a decent boring cross-platform language. The only reason people refused to use it was hype and stigma. There was no deep rational reason. Sure, mono was slower than .net-on-windows at the time (.net core fixed this), but it was still way faster than the then-default Rails setup. Whenever I told people about our setup at eg tech events they got very confused. Some dismissed me as a moron but to be honest most people were just surprised you could run a cross platform C# devteam and deploy to Linux. People simply didn't seem to know this was possible. That's been some pretty bad marketing in Microsoft's part.
ethbro 7y ago
To people who only know how to write backend javascript, yes. I think companies underappreciate this. If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience? Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java.
- msla 7y ago
  > If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience? > Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java. Blub languages aside, a candidate focusing on how they do things in $LANGUAGE_WE_DONT_USE_HERE means they're going to have to get their feet under them to read our existing code fluently, to write code in our style, and to get all of the other language- and tooling-specific institutional knowledge existing programmers here have.
  - ethbro 7y ago
    On the flip side, they're also going to bring ideas from $LANGUAGE_WE_DONT_USE_HERE. Short term vs long term optimization. Neither strictly better.
chucksmash 7y ago
Your point is taken although I wouldn't say Node qualifies as the latest trend at this point. It feels like it has moved on to "just another tool to choose from" status to me. I suppose trendiness is relative but if you use a Google Trends search for "Isomorphic JavaScript" as a proxy for Node's trendiness[1], it was at its trendiest in 2016 and has fallen off quite a bit. [1]: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fg%2F11d_1b3jmc https://trends.google.com/trends/explore?date=all&geo=US&q=%...
- rumanator 7y ago
  > Your point is taken although I wouldn't say Node qualifies as the latest trend at this point. Honest question: does Node offer any advantage other than CV points wrt established backend tech stacks?
  - BubRoss 7y ago
    Javascript is a flexible and fluid language in my opinion. Using modern JITs gets you a scripting language that is many times faster than other languages, but Node.js itself is based around async callbacks for the simplest stuff with no easy way out, which makes it worth avoiding. Lua JIT however is sane, simple and even faster, but the infrastructure and tools surrounding it are bare in comparison.
    - edwinjm 7y ago
      "but Node.js itself is based around async callbacks for the simplest stuff with no easy way out, which makes it worth avoiding". Huh? Async code is so powerful. You can use promises instead of callbacks. And you can easily make a async call "synchronous" by adding the await keyword in front of it.
      - _lacroix 7y ago
        It's not that other languages don't have async code...they just do it using multiple threads or other patterns that are nicer to work with than JS.
doublement 7y ago
> Why should I learn Node instead? Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser. You can write command-line scripts, run them with "node [scriptname]", and learn. Having done that, I've found that Node is great for fast prototyping of servers, even if those are going to be written in C/C++ ultimately. In not-super-formal work environment, you can very quickly write something that runs with the correct behavior, and treat that as the spec for the final performant code.
- rumanator 7y ago
  > Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser. Honestly, to me Node always sounded like the exact opposite of your description: a way for frontend development experience to leak into the backend at least in appearance so that people who were able to hack around DOM updates could argue that they could develop for the backend as well, thus paving the way to pad resumes with "full stack" experience.
  - doublement 7y ago
    I think it can work both ways, but I was looking at it from the perspective of the parent post.
folkhack 7y ago
> Does writing backend Javascript mean you're a better developer? Absolutely not. But as someone who does write backend Javascript I don't tolerate Microsoft development tooling because I don't tolerate Microsoft. Period. When their core product offering is literally adware/spyware (Windows 10) to the point I have to use special builds that are difficult/expensive to get a hold of (LTSB/LTSC) I get pretty turned off in regards to the whole ecosystem. Microsoft tooling may be right for you, but it is not for me... and Node is an outstanding tool for rapid application development with solid async capability that's open source. I can also find/hire way ECMA devs way easier vs C#. Also before someone rips me saying "well Visual Studio is better than everything else" - Intellij offers the same general "nice-to-haves" and doesn't come with a dependency on a broken OS.
BubRoss 7y ago
Node is a total nightmare even if you like javascript. The async everything nonsense makes basic tasks impossible without nesting callbacks within callbacks within callbacks.
- andor 7y ago
  Promises and async/await fix this. The Node API unfortunately is built around callbacks, but can be turned into a Promise-based API using the built-in "promisify" tool: https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...
- edwinjm 7y ago
  Then you're doing it wrong. With async-await, asynchronous programming becomes quite easy.

barce 7y ago

Why node? 2 reasons: async which C# has too, and coding in just one language. And no, writing backend JavaScript doesn't mean you're better.

klodolph 7y ago
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.
- excursionist 7y ago
  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.
  - everybodyknows 7y ago
    >same JavaScript engine (v8 for chrome) That way lies surrender by default to the Google empire.
    - excursionist 7y ago
      What? It's just a simple fact that Node, Chrome and Chromium all use V8 - which is an open source BSD licensed project.
  - klodolph 7y ago
    My experience is different. I write a decent amount of JS code each year and try to catch up with current best practices where I can, but every year it’s been a bit of a pain to write any code that’s shared between browser and client. Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async (shockingly, with backend support lagging). These days my main strategy is to have three TypeScript projects—frontend, backend, and common. I then whitelist imports in the common libraries. > It's the same language, using the same JavaScript engine (v8 for chrome). I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.
    - excursionist 7y ago
      > Various ES features will have different levels of support in different layers, and this is especially tough once you take into account the various transpilers or polyfills, and the big sticking points for me over the past two years have been ES imports and async New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code. > I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later. The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.
      - klodolph 7y ago
        > New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code. For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client. My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place. Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc. There’s a whole pipeline between your source code and the JavaScript engine, and that pipeline has a different shape for backend and frontend, and typically uses completely different libraries to make it work. > The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS. I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine. I haven’t figured out a way to leverage that fact to give me any additional productivity. For the projects I’ve worked on, it can end up taking me quite a bit of time figuring out how to make one piece of code work in both frontend and backend, even though I can trivially make it work in either environment as I please. Maybe other people have already solved this, but I recently went through and made a bunch of PRs to fix a common issue I saw in other people’s codebases and it was super rare to see any code shared between frontend and backend.
- honopu 7y ago
  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.
  - egeozcan 7y ago
    The purpose of next (and perhaps nuxt, I've never used it) is more in the direction of a front-backend. The API-implementing level is usually very different than the one consuming it, even when the consumer is on the server-side. If this wasn't the case, IMHO, projects like Meteor would be immensely more popular.
igreulich 7y ago
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. And at the end of the day, $LANG is a tool.
- deusofnull 7y ago
  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.
- osdiab 7y ago
  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.

thawaway1837 7y ago

My problem with C# server development until recently has been the reliance on visual studio. A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS. And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS, but you end up spending a lot of time and energy trying to figure out what might be wrong before going that route. Fortunately, both of these issues have been resolved with the open source .Net Core, and while we continue to use .Net Framework, I’m looking forward to doing more .Net Core development going forward.

vsareto 7y ago
>My problem with C# server development until recently has been the reliance on visual studio. TBH there are very few IDEs or environments that match Visual Studio. If you've never used it, of course you'll be less productive. >A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS. Project and solution files have been XML for a long while. I think the example here would be early UI work with WinForms and WPF? But everyone would think you're crazy to edit those text-only when you had a WYSIWYG editor. >And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS >Fortunately, both of these issues have been resolved with the open source .Net Core If there's an issue with Kestrel, I think you'll still be spending a long amount of time debugging that. I don't think much has changed on that front. .NET Core isn't a magic solution to this.
skrebbel 7y ago
I ran the tech team at a startup around 2014 and we had a C# stack with almost no visual studio. Most people were on mac or Linux and used MonoDevelop. We ran it on Mono in docker containers (which was brand new those days) on Linux VPSes. Truth is, for a long time already, C# has been a decent boring cross-platform language. The only reason people refused to use it was hype and stigma. There was no deep rational reason. Sure, mono was slower than .net-on-windows at the time (.net core fixed this), but it was still way faster than the then-default Rails setup. Whenever I told people about our setup at eg tech events they got very confused. Some dismissed me as a moron but to be honest most people were just surprised you could run a cross platform C# devteam and deploy to Linux. People simply didn't seem to know this was possible. That's been some pretty bad marketing in Microsoft's part.

ethbro 7y ago

To people who only know how to write backend javascript, yes. I think companies underappreciate this. If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience? Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java.

msla 7y ago
> If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience? > Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java. Blub languages aside, a candidate focusing on how they do things in $LANGUAGE_WE_DONT_USE_HERE means they're going to have to get their feet under them to read our existing code fluently, to write code in our style, and to get all of the other language- and tooling-specific institutional knowledge existing programmers here have.
- ethbro 7y ago
  On the flip side, they're also going to bring ideas from $LANGUAGE_WE_DONT_USE_HERE. Short term vs long term optimization. Neither strictly better.

chucksmash 7y ago

Your point is taken although I wouldn't say Node qualifies as the latest trend at this point. It feels like it has moved on to "just another tool to choose from" status to me. I suppose trendiness is relative but if you use a Google Trends search for "Isomorphic JavaScript" as a proxy for Node's trendiness[1], it was at its trendiest in 2016 and has fallen off quite a bit. [1]: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fg%2F11d_1b3jmc https://trends.google.com/trends/explore?date=all&geo=US&q=%...

rumanator 7y ago
> Your point is taken although I wouldn't say Node qualifies as the latest trend at this point. Honest question: does Node offer any advantage other than CV points wrt established backend tech stacks?
- BubRoss 7y ago
  Javascript is a flexible and fluid language in my opinion. Using modern JITs gets you a scripting language that is many times faster than other languages, but Node.js itself is based around async callbacks for the simplest stuff with no easy way out, which makes it worth avoiding. Lua JIT however is sane, simple and even faster, but the infrastructure and tools surrounding it are bare in comparison.
  - edwinjm 7y ago
    "but Node.js itself is based around async callbacks for the simplest stuff with no easy way out, which makes it worth avoiding". Huh? Async code is so powerful. You can use promises instead of callbacks. And you can easily make a async call "synchronous" by adding the await keyword in front of it.
    - _lacroix 7y ago
      It's not that other languages don't have async code...they just do it using multiple threads or other patterns that are nicer to work with than JS.

doublement 7y ago

> Why should I learn Node instead? Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser. You can write command-line scripts, run them with "node [scriptname]", and learn. Having done that, I've found that Node is great for fast prototyping of servers, even if those are going to be written in C/C++ ultimately. In not-super-formal work environment, you can very quickly write something that runs with the correct behavior, and treat that as the spec for the final performant code.

rumanator 7y ago
> Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser. Honestly, to me Node always sounded like the exact opposite of your description: a way for frontend development experience to leak into the backend at least in appearance so that people who were able to hack around DOM updates could argue that they could develop for the backend as well, thus paving the way to pad resumes with "full stack" experience.
- doublement 7y ago
  I think it can work both ways, but I was looking at it from the perspective of the parent post.

folkhack 7y ago

> Does writing backend Javascript mean you're a better developer? Absolutely not. But as someone who does write backend Javascript I don't tolerate Microsoft development tooling because I don't tolerate Microsoft. Period. When their core product offering is literally adware/spyware (Windows 10) to the point I have to use special builds that are difficult/expensive to get a hold of (LTSB/LTSC) I get pretty turned off in regards to the whole ecosystem. Microsoft tooling may be right for you, but it is not for me... and Node is an outstanding tool for rapid application development with solid async capability that's open source. I can also find/hire way ECMA devs way easier vs C#. Also before someone rips me saying "well Visual Studio is better than everything else" - Intellij offers the same general "nice-to-haves" and doesn't come with a dependency on a broken OS.

BubRoss 7y ago

Node is a total nightmare even if you like javascript. The async everything nonsense makes basic tasks impossible without nesting callbacks within callbacks within callbacks.

andor 7y ago
Promises and async/await fix this. The Node API unfortunately is built around callbacks, but can be turned into a Promise-based API using the built-in "promisify" tool: https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...
edwinjm 7y ago
Then you're doing it wrong. With async-await, asynchronous programming becomes quite easy.