twerquie

I'm just conceding that these argument cannot be won. Tomes have been written and the argument becomes unproductive very quickly. It's like people who believe in God arguing with those who do not. It's not about JavaScript or Node, it's about your entire belief system.

They're both good, in both cases.

I've responded there, sorry for the noise.

I'm no zealot, and don't think these are absolute truths by any means but I've worked extensively on enterprise solutions in both C#/.Net and Node.js and can respond to your points below.

1. It turns out the reactor pattern is a good way to build network servers that scale reasonably well with minimal developer effort. In my experience developers tend to avoid writing threaded code in synchronous languages, and threads don't show up very often in run-of-the-mill solutions. To be sure, JavaScript's lack of threads is a blemish, but oddly it forced the community to focus heavily on distributed architectures, and as a result most of the tooling encourages distributed systems, which is a win for some common use cases.

2. Type safety is a hotly debated topic and I don't think you can find resolution on this one. For some people, "weakest of weak typing" is a benefit.

3. Static vs. dynamic, see #2.

4. Do you mean that everything must be enforced by convention instead of static code analysis, compile-time checks and type safety? If so, I think you're making the same point three times.

Erlang is a beautiful language and may be the most correct in some sense, but doesn't look nearly as attractive to the kinds of teams I work on when you start to consider developer availability, library ecosystem, tooling, ISP support, documentation and community.

Care to back up any of your assertions? If your main complaint is popularity, your argument comes off as elitist.

This pattern is commonly called "materialized path", if anyone is trying to search for it.

I really enjoy that trend. Tech is a dry topic with typically uninspiring presenters.

I agree with this. The surface area of most modules is small enough to be covered in a README.md, which is displayed prominently on npmjs.org, github.com and a copy of it is in your ./node_modules folder.

As said earlier, the core Node.js framework has great documentation, as do other frameworks such as Mongoose and Express.

If your application is largely fetching a bunch of external resources, say from something slow like a database or a web API, mashing them up and returning a response to a client, you need async.

Node has a very beginner-friendly primitive for doing this.

Or your needs are so insanely complex - as in project management - that modelling the problem in any detail leads to a million features and an inflexible solution.

Either I'm interpreting this too simplistically or they're doing a great deal better than I expected.

This is a broad social generalization so please take it with a grain of salt, but I do think there is an element of truth to the notion that Japanese people take good care of their elderly maintaining their dignity and keeping a healthy respect for their elders. The perception is that they age more gracefully. In western / european cultures, growing old is treated like a shameful disease. Hence the double standard.

I wonder it could be split up, and the necessary segment(s) could be dynamically loaded based on OS language preferences?

I was indeed.

I appreciate that the author distilled his thoughts about software down into porno terms we can all relate to.

You are fighting a losing battle.

For the same reasons you're writing in English.

What's wrong with just using Bower?

I used public transit, taxis and car sharing services exclusively until I started a family. At which point setting up the carseat every time became prohibitively cumbersome and I bought my own car. Children's car seats are very personal in terms of size and configuration and are required by law.

I think things like that will make people want their own self driving car. You want the one that fits your wife and two kids and your dog. Or you're rich and you want to be driven around in a really nice one that hasn't been used by other people.

The more I think about it, the more I imagine rich people increasing their car ownership due to self driving cars. Take your fleet with you to the cottage or across the country, why not?

I would argue that Google's job now includes executing javascript and evaluating dynamically loaded content.

Break the web.

I think my point is clear when you read what I wrote as a whole instead of dissecting parts. I'm allowed to editorialize a bit, am I not? I'm not a robot nor am I writing my thesis on the subject, we're just talking here.

It is true though that many js deficiencies have turned out to be factors contributing to node's popularity. A lack of namespaces, standard library and import/require come to mind.

I'm not interested in arguing about technical superiority, I'm sure node is no where close to ideal. But, like javascript itself, it's popular, interesting, useful, and here to stay. From my perspective, for better or worse, javascript is the most important programming language of the decade.

Different yes, conflicting no.

ES6 standard promises have landed in v8 (https://code.google.com/p/v8/source/browse/trunk/src/promise...) so it's only a short matter of time until the "batteries included" solution is available.

But that doesn't mean people will be forced to use them.

Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting

a) A small core API instead of a sprawling standard class library

b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1)

c) The fastest growing and soon to be largest community repository of packages (2)

d) asynchronous by default stack and ecosystem.

With those things in hand, "bolting on" is a virtue and not a disadvantage. That Node is general-purpose - you can build cross-platform desktop applications, streaming servers, web applications, console utilities, etc - and does not impose its package opinions are major factors in its success.

1) http://blog.izs.me/post/1675072029/10-cool-things-you-probab...

2) http://modulecounts.com/

The writing here is very nice. I wish my writing carried itself as well. Beyond the style and structure, the tone of the article is remarkable and lovely. Cynicism wrapped in love and hope and nostalgia.

Nice work.

It would be great if this was published as an npm module.

Sure, why not? See the "asshole vacuum" scene in HBO's Silicon Valley S01E02.

DHH does have a point, but he makes it in a manner that is hyperbolic, accusatory, narrow-minded, stubborn and often rude. I find him to be a negative voice in the community and a dangerous leader. I am happy to fight fire with fire where necessary, and agree with the tone of the article linked by the OP.

> I'd like to see someone form a well constructed argument for why that statement is inaccurate, over-stated, or otherwise unfair

Here's his statement again, rewritten without the Fox News-style editorialization:

"Test-first units lead to a graph of intermediary objects in order to avoid doing things that are outside the scope of your test. This practice isolates the piece of code you are testing, but as a side-effect means that you don't do unnecessarily slow work like hitting a database, filesystem or web browser. It has given rise to new patterns of application architecture such as a service and command layers."

Oops, I wrote all the same facts but stated them neutrally, and now it doesn't sound like a horror movie! How am I supposed to bully Rails devs into following my style?

> Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

This is DHH's central argument, he is once again defending his "there are only three places to put code" application design and the monolithic Rails architecture. We see him, time and time again, sniping at people who outgrow those patterns but still want to use Rails. People who do want fast and isolated unit tests, who want encapsulated, reusable service objects and people who are perhaps building something more complicated than a TODO list.

He goes as far as to subtly deprecate unit testing, something which is incredibly vital in a dynamic, loosely typed language such as Ruby, where monkey-patching other's code is more of a rule than an exception. In Ruby, unit tests stand in place of static compiler checks. I haven't heard a strong argument against them nor a replacement for them. The binary notion of "the whole application works" or "the whole application does not work" does nothing to quell the critics who say that Ruby and indeed Rails projects are brittle and difficult to refactor.

I love Rails and think it's a fine product, but I don't understand its leadership strategy, doggedly preserving web application design as it existed in 2004.

> "Rails 5 will be renamed to Basecamp. This will help to end confusion over which types of apps to build using Rails." @markbates

It is owned by a single corporate entity who is also its primary sponsor, Typesafe. This is similar to how Joyent owns node, and how they sponsor it's development, along with NodeJitsu, Microsoft, Heroku and others.