Monolithic Node.js

this post rolls out every OOP canard there is. OOP implies monolithic design; OOP models the world in a naive and impractical way (but functions and callbacks are clearly just fine, obviously); OOP implies you'll have to "roll out" GOF (implying GOF is a "cookbook"; anyone who read it and understood it knows that this is absolutely not what was intended); "design patterns" are a code smell; only OOP has "design patterns" (in which case what exactly is a "promise"? look at this link, it even has "pattern" in the fricking name! http://modernjavascript.blogspot.com/2013/09/promise-pattern...).

Really, node.js is clearly a great product, but the node.js community is often emanating that "smell" I got from the NoSQL movement a couple of years back; "we didn't understand how to use X correctly, therefore X sucked and that's why we use Y!"

edit: oh: "Node.js does require you to learn some new patterns, but they are few in number, and have broad application. " I see, node.js has patterns, but unlike GOF patterns, they don't suck. Got it. GOF was written decades ago and is all about C++ patterns as applied to GUI design in the early 90's (pre-Java); a modern app written in Python or Ruby would hardly exhibit much similarity to all but a few of the actual patterns in GOF book.

Maybe I need a refill of coffee, but I couldn't really grasp what the point of the article was. JavaScript is half-usable, object oriented programming is broken (he even goes into a bit about inheritance), Java and .Net are enterprise-ready languages...huh?

I found this article interesting and enjoyable, but I had some questions about this:

Let’s apply this to our software systems. Instead of building a monolithic 100 000 line codebase, build 100 small services, each 100 lines long. Fred George, (the inventor of programmer anarchy) one of the biggest proponents of this approach, calls these small programs micro-services.

a.) With this sort of system, how do you avoid a sort of high level version of spaghetti code (spaghetti services), where services depend on each other willy nilly, and

b.) where if one service goes down, it brings other large chunks of the system down.

c.) Finally, any concern that a bunch of services communicating with each other over http might be substantially slower than a monolithic system largely communicating with itself in memory?

"As a result, Node.js projects suffer very little dependency hell."

LOL: https://github.com/bevry/watchr/issues/51

The article above will be especially funny in 5 or 6 years when everybody's cussing about how crappy Node is and how FooBarLanguageThingy will suddenly make all the complexity disappear.

The section on why objects are bad is awful. It appears the author is describing C++/Java/C#'s class based object orientation, which is definitely open to critique, but it's so poorly worded and vague I end up feeling the author doesn't know what he's talking about.

I think there's a lot of good thoughts here, but also a bit of re-inventing the wheel. This is NOT a new, innovative way of developing large systems - it's called a Service Oriented Architecture (http://en.wikipedia.org/wiki/Service-oriented_architecture). It's actually pretty common in enterprise apps (from hearsay alone).

I think this kind of thinking is great, but there does need to be some referencing of past work and existing techniques for solving these problems. Otherwise we'll be stuck in an endless cycle of discarding "old, stupid ideas thought up by enterprisey developers" in favor of "new, shiny ideas by intelligent hackers" without realizing the substantial overlap.

From the author's discussion of Node's "enterprise" popularity:

  > The visceral rejection of Node.js that you see from some quarters is often
  > the spidey-sense of an experienced enterprise developer zapping them between
  > the eyes. JavaScript? No!

The author shouldn't be so quick to chalk this uneasiness up to discomfort with JavaScript itself but rather with the perceived instability of the NPM ecosystem. While NPM is filled with high-quality libraries, each has a bird's nest of dependencies like what you see with CPAN packages. To use Node, you need to use NPM. To trust NPM, you need to trust Open Source. Until the enterprise really trusts open source, Node will never be very popular there, regardless of how heavily it is used elsewhere. PHP overcame this hurdle because you can use PHP productively with no third-party packages.

The second problem for Node to overcome is that its design requires asynchronous I/O for good performance, and you need decent developers to write good asynchronous code. While this is a real problem, I'm not sure that many decision-makers are aware of this (or would care about it) because so much "enterprise" software is dog slow and resource hungry.

The seneca toolkit that the post leads into and links to is super interesting. It seems like a pretty straightforward way to build with an SOA from the beginning. Does anyone have any experience using this for a sizable project that can comment on it?

This is the longest blog post I've ever read.