[noblethrasher]

Everything causes friction with respect to something. So you have to examine the merits of the argument.

I, for instance, loathe the prescription that the names of .NET interfaces begin with "I". This is because I realized that once you understand the difference between a “class” and a “type”, then it becomes obvious that everything is an interface (abstraction is just naming things). But, the .NET style guide hinders that understanding since it enjoins you to focus on the little things (classes and interfaces) instead of the big things (types)[1].

So, “code snobbery” is about figuring out what you really want, and then creating cognitive affordances (or eliminating cognitive hinderances) with respect to that.

[1] This is especially apparent when you consider how interfaces and classes are defined in F#.

[tracker1]

More often than not, Abstract Classes, and Interfaces in .Net are more for testability, or code generation than they are actually needed for a working system. I'm not saying they are bad, as I actually like WCF (using a DI framework with convention, not the XML config hell) as well as a lot of the Entity Framework bits.

That said, the more I work with components and smaller services in node.js, the more I enjoy it. It's nice to be able to write meaningful unit tests without several layers of indirection just to be able to write tests.