The language doesn't matter, but the ecosystem does. It is when it comes to "non-CRUD apps" that an ecosystem will really start to matter. One is probably not better than the other but getting started is hard.

Take the case of Node and JavaScript itself. The ecosystem is huge. The tooling is complex. A newbie starting out will not even be able to get many examples to run without a mesh of transpilers and build tools. There are roadblocks everywhere; what's the type annotation there? What's with the strange JSX syntax? What's a transpiler? Add to that, EcmaScript itself is a moving target, more so than any other language.

Similar issues exist in other languages. C# is a simple language to master, .Net is a huge ecosystem. There's not going to be a lot of resistance moving from C# to F#. But for the newbie, the challenges are daunting. Should you use Microsoft's preferred ORM which ships with .Net or write your own SQL? Which UI tooling should I use? There is plenty of advice on the web, yet it needs an experienced developer to make those decisions.

Consider this. if you chose SilverLight a few years back, your product is soup today.

Picking an ecosystem is not easy. Has never been.

> I'm worried that node.js articles are the same kind of echo chamber that Rails articles were 10 ago.

I tend to agree.

> That, and nose.js developers seem to repeat the claim that node.js makes delivery faster…

The qualification was "if your team already knows JavaScript". OK... If the team already knows Java... building something like this in Java would be faster to deliver, and wouldn't hit some of those issues the author brought up (4 vs 1, single vs threaded, etc).

And the whole "oh, you know language X" - means almost nothing when the project is more than trivial hello world. Every project I've been brought in on, the qualifier was "must know tech X". And almost always (there were exceptions) I knew more about tech X and software dev in general than the original developers, and the crunch was not "how do I do XYZ in this tech?" it was "how do I get the other developers to actually use version control?" or "use version control sanely?" or "document anything?" or "write tests" or "have test data" or "have a repeatable build process"?

Knowing ASP or PHP or Ruby or whatever, but going in to a project without repeatable build process, tests, documentation, requirements or version control, is a recipe for disaster. Stressing the "deliver quickly" aspect of any language, if you're actually trying to deliver for a business or with a team of people, is extremely destructive short term thinking. And yes, sometimes, in rare cases, it may be a necessary evil, but I think it's become the norm with words like "agile" being thrown around as synonyms for "don't have to write anything down".

> I'm also really not interested in how things work for "typical CRUD apps"

You mean you're not interested in what a huge part of the industry is doing? Well then that explains why you don't see the benefit.

There's tons of work creating user interfaces, transform some business logic and shove it back in a DB. No one said it was going to be a life-fulfilling experience. It's just work.

Now many of these shops want a native ui, mobile ui, responsive design and a back-end developer all in one. Many times they hire for specific frameworks so that you're ready to be productive day 1.

If I were staffing up a team to do a CRUD app, or even more complex, I'd staff up with JS developers.

I've worked on projects in which both the front and end back end were written in the same language & those that are different. The former were more productive imho with developers working on both and with shared libraries & shared test platforms. The latter often end up getting silo'd with stuff passed over the fence. Yes many developers can do both, but its difficult to do both at the same time & even harder to hire for.

Here's my experience as a solo developer for all of my projects. When I have to do everything from marketing, SEO, domain/dns, server setup, to database design, interface design, and whatever else. Doing most of the actual programming in one language, rather than many, helps considerably in my workflow. The NPM ecosystem is also awesome.

Node.js let's you require() packages from npm. There, all the code you for ever need.

Instead of writing "a quick Python script" for personal use, I now write "a quick node script" because there's almost no thinking required on my part. Just require the packages and throw them together.

Not even Python has this package-completeness.

Depends who you ask really.

If you are a developer then you should invest your time and be able to learn and use the best tool for the job.

If however you are something like a Product manager then learning JS is much more valuable time investment. It is the one language that will, currently, run anywhere ... Backend, Frontend, Side end, whatever.

You can quickly get good at JS to the point of being able to prototype the full app stack and come up with something that works, goto market and fail. Should you find your self in the unlikely position that your product meets its success, then you can go ahead and hire a Go/Elxir/WebASM whatever guy to optimize this and needs larger throughput.

You have 24 hours in day, 6 to sleep, 3 to breath, 1 to eat. How do you want to spend the remaining 14 ? You get good at what you practice :)

IMHO, the core piece is that supporting a language is very, very expensive: tooling, CI, linting--especially standards. Many of things that ensure quality are not language agnostic. It's not about learning a language, it's about maintaining one.

If you are a web shop you have javascript. Using node.js allows you to eliminate one extra language.

Is it perfect? Definitely not. Is it best for everything? Probably not the best for anything. But, it's good enough for most stuff. It doesn't make sense to incur the burden of another language for a one off task.

>"more people know JavaScript so you don't have to learn a new language, which saves you time".

This is also an excuse for NIH ( never invent here ) where people try to shoehorn an OSS product even if it doesn't fit their needs .

I know Javascript well enough to avoid it when possible.

  class Shape {
      constructor (id, x, y) {
          this.id = id
          this.move(x, y)
      }

      move (x, y) {
          this.x = x
          this.y = y
      }

      fixed_offset(off_x,off_y) {
        return () => {
          console.log(`offsets x: ${off_x} y: ${off_y}`)
          return [this.x + off_x, this.y + off_y]
        };
      }
  }

  var Shape = function (id, x, y) {
      this.id = id;
      this.move(x, y);
  };
  Shape.prototype.move = function (x, y) {
      this.x = x;
      this.y = y;
  };
  Shape.prototype.fixed_offset(off_x,off_y) {
    var self = this;
    return function() {
      console.log("offsets x: " + off_x + " y: " + off_y`)
      return [self.x + off_x, self.y + off_y]
    }
  }

While I don't know node.js very well and can't speak to the "shared memory server", I do think it is valid to point out that this sort of redesign to fit the platform is frustrating. I've hit similar situations in Python where an async i/o framework is used and at some point there becomes a CPU bound task. The application was redesigned and new microservices were started in order to cope and the architecture became convoluted. This sort of question always seems to always show up in Python where limitations of the GIL influences the design of the software, the libraries used and deployment. It seems node.js, not surprisingly, has the same problems.

As the above comment clearly points out, there are workarounds to make things work. Still, when I think about the amount of time and effort that goes into debugging systems when they hit limits like the author mentioned, I imagine most of the the benefits gained by using a language like Python or JavaScript go away.

NodeJS is a multi-threaded process. You can verify it with top or ps command. Async methods to decode JSON: https://github.com/nodejs/node-v0.x-archive/issues/7543

The issue isn't that it takes a long time to parse the JSON. It's that the server can't do anything else while it's parsing. In Java, for example, you could parse the JSON on a background thread without affecting your ability to serve requests.

Similarly, the memory issue isn't so much that a single copy of the table takes a lot of space, but rather that they need to store 4 copies of the table -- because they're running 4 different processes in order to utilize multiple cores.

Both of these issues are specific to nodejs.

I thought the same or even the same 4 cpus for proxies and a shared 1 for the cache service.

There's always streaming json parsers[1] that will help you when parsing large json data sets.

[1]: https://github.com/dominictarr/JSONStream

Node.js isn't great for CPU bound tasks in general.