Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monolithic Node.js

richardrodger.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Monolithic Node.js

#11

Post by 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...).

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.

Re: Monolithic Node.js

#12

Post by 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). 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.

Re: Monolithic Node.js

#13

Post by al2o3cr »

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

Re: Monolithic Node.js

#14

Post by 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.

Re: Monolithic Node.js

#15

Post by shtylman »

oinksoft wrote: post #14

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…

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 :)

Re: Monolithic Node.js

#16

Post by oinksoft »

shtylman wrote: post #15
oinksoft wrote: post #14

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…

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 :)

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.

Re: Monolithic Node.js

#17

Post by 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?

Re: Monolithic Node.js

#18

Post by taeric »

msluyter wrote: post #17

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…

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.

Re: Monolithic Node.js

#19

Post by _random_ »

zzzeek wrote: post #11

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 patte…

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,

Re: Monolithic Node.js

#20

Post by j_s »

al2o3cr wrote: post #13

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

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

Post reply on HN