

Monolithic Node.js - medeu
http://www.richardrodger.com/monolithic-nodejs#.Uq70yXgazCS

======
zzzeek
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...](http://modernjavascript.blogspot.com/2013/09/promise-
patterns.html)).

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.

~~~
_random_
Many people don't want to care about types and correctness, they just want to
be able to hack quickly in dynamic/weak languages. Future maintenance is
someone else's responsibility,

~~~
collyw
You can write shitty unmaintainable code in a statically typed language, and
maintainable elegant code in a dynamically typed language.

------
rmrfrmrf
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?

~~~
ebiester
The point is that node.js is a classic case of "worse is better." That is,
because of its lack of namespacing, NPM came up with a great module system
that made modular programming the default, making code cleaner. Its
limitations forced smart architecture.

I don't know that I agree, per se, but that piece of the argument is
interesting.

------
msluyter
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?

~~~
taeric
I like how you are basically drawing this to the microkernel debate. I've
tried to make that comparison plenty of times at work, and I've yet to really
hear why it doesn't apply here. I can think of a few reasons, but none that
are satisfying to me.

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

LOL:
[https://github.com/bevry/watchr/issues/51](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.

~~~
j_s
[https://news.ycombinator.com/item?id=6896205](https://news.ycombinator.com/item?id=6896205)

> _They are constantly breaking backwards compatibility and committing to
> "stable" at this point seems unrealistic_

>> _the various node.js libraries that so many people depend upon are either
weekend fads that get abandoned, or moving at the same speeds and likewise
breaking compatibility_

>>> _The team claims to have turned the corner. relevant comment from
@isaacs:[https://www.youtube.com/watch?v=82hJbjqbIt4#t=120](https://www.youtube.com/watch?v=82hJbjqbIt4#t=120)
_

------
schmichael
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.

------
robbles
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](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.

------
oinksoft
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.

~~~
shtylman
You don't have to trust anything. If you want to NIH everything yourself,
nothing is stopping you. It is however more likely that many packages on NPM
are better than the ones you or your team can create if simply for the fact
that they may have been created by a person very versed in the particular
domain the package is for. Or maybe it will be shit but whatever :)

~~~
oinksoft
I have no such reservations about the NPM/CPAN style, but your assertion that
the only other choice is "NIH" isn't quite true. With Python for instance, you
can choose SQLAlchemy for your ORM. It has no depencencies. In JavaScript,
Mongoose (a good comparison) depends on "hooks, mongodb, ms, sliced, muri,
mpromise, mpath, regexp-clone, mquery". Who knows what those in turn depend
on. In a strict place, you need to get every one of those things approved, and
each represents a moving target if you want to upgrade Mongoose later. Those
shops begrudgingly let open source in as it is, so it's a tough sell.

------
Stwerner
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?

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

~~~
coldtea
Which tells us more about you than about the post.

~~~
secoif
huh?

