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?
The article seems to be refuting assertions that Node is no good for enterprise, but without calling out specific articles that do so. So it's a little difficult to get.
It's also a response that says "Node is no good for enterprise because enterprise development is broken", which isn't wrong, but doesn't necessarily help much. Changing the coding practises of every developer you have is not a small problem.
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.
It's awfully rambling. I think the high-level idea is that you can't build large monolithic applications in Node, but that's not actually a problem because building large monolithic applications doesn't work very well in any language, and Node is unusually good at building modular applications.
Get your coffee and read it again. He explains his point rather well, and it's about the difficulty of bulding large codebases with big teams in JS and some ways to overcome it.
I believe the point is in the conclusion and the content leads to the conclusion: If you change your mind, you may start to see the advantages of Node, that is not possible if you continue to think with older models in mind.
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.
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.
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,
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.
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.
> 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
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.
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.
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?
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.
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?
22 comments
[ 4.1 ms ] story [ 78.3 ms ] threadIt's also a response that says "Node is no good for enterprise because enterprise development is broken", which isn't wrong, but doesn't necessarily help much. Changing the coding practises of every developer you have is not a small problem.
I don't know that I agree, per se, but that piece of the argument is interesting.
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.
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.
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.
> 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
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.
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?