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

Node.js is Backwards

blog.ankurgoyal.com

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Node.js is Backwards

#31

Post by sausagefeet »

chromic wrote: post #18
jessedhillon wrote: post #15

Earlier quoted context omitted.

> Using the same language at both the client and server end has some serious benefits. What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)

Off the top of my head benefits: -No mental context switch when working on both ends -Easier serialization (though JSON is pretty portable...) -Sharing code They aren't exclusive to Node and JS, but browsers run JS and will continue to for the foreseeable future. Since the front end can't budge its language at the moment, the back end has to.

I see the "sharing code" claim a lot but I haven't really seen it substantiated. Seems like you write a few little functions but it's not like you sharing the same framework which would be the real benefit.

Re: Node.js is Backwards

#32

Post by alnayyir »

m0th87 wrote: post #11
alnayyir wrote: post #4

I've been saying this about Erlang and Node for awhile, and I don't know anybody who knows both Erlang and JS that takes Node seriously.

I know both and I take Node seriously. Using the same language at both the client and server end has some serious benefits. And web servers are mostly shared-none, so not having first-class support for communication between Node processes is not that big of a deal. Node has its niche.

>Using the same language at both the client and server end has some serious benefits.

The functionality implemented is mutually exclusive. This canard needs to die.

Re: Node.js is Backwards

#33

Post by ankrgyl »

jrockway wrote: post #27
edtechre wrote: post #19

Earlier quoted context omitted.

The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server. NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.

NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. Well, you do with node what you do with anything: if you have 4 CPU cores, run 4 copies of your app. Problem solved.

That works really well for handling requests for HTML pages, because they tend to render independently of one other. However, you run into trouble when you to make "Nodes" communicate, and the comment that the article is addressing specifically mentions interprocess communication.

Re: Node.js is Backwards

#34

Post by seoguru »

jessedhillon wrote: post #28
m0th87 wrote: post #16

Earlier quoted context omitted.

Here's a case study: an open source project I made with node.js; https://github.com/node-bus/node-bus It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance. Technically there are tools that will convert, say, Haskell to Javascript so that you…

I looked through your shared/util.js and, while I don't want to take anything away from your project, it doesn't seem to me that there is much of a case for significant and useful code sharing in Node. When I think of code sharing, I expect something like Luna, from Asana http://asana.com/luna/ Instead, the examples of shared code in Node are always simple utility functions, validators and the like. While it helps no…

have a look at dnode: https://github.com/substack/dnode bidirectional remote method invocation. Oh, and a complimentary robot free of charge: http://substack.net/browse/2010-11-08%2022:16:39 :-)

Re: Node.js is Backwards

#35

Post by weixiyen »

nzoschke wrote: post #24
alnayyir wrote: post #4

I've been saying this about Erlang and Node for awhile, and I don't know anybody who knows both Erlang and JS that takes Node seriously.

I love Node for many things, but I agree with this sentiment. At work, every time we undertake a project in Node, it just doesn't work at scale, and it has to get re-implemented in Erlang. A lot of this is for personnel reasons. To all of us Node is a neat new toy, where a few engineers are Erlang wizards. If Node crashes we don't have any experience debugging it. If it locks up there's little intuition why. Can peop…

plurk

Re: Node.js is Backwards

#36

Post by m0th87 »

jessedhillon wrote: post #28
m0th87 wrote: post #16

Earlier quoted context omitted.

Here's a case study: an open source project I made with node.js; https://github.com/node-bus/node-bus It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance. Technically there are tools that will convert, say, Haskell to Javascript so that you…

I looked through your shared/util.js and, while I don't want to take anything away from your project, it doesn't seem to me that there is much of a case for significant and useful code sharing in Node. When I think of code sharing, I expect something like Luna, from Asana http://asana.com/luna/ Instead, the examples of shared code in Node are always simple utility functions, validators and the like. While it helps no…

The code itself might not be significant, but the implications are. It defines standard interfaces for interacting with the library. Thus people can write plugins on top that work at both the client and server end.

Re: Node.js is Backwards

#37

Post by mcantelon »

jrockway wrote: post #27
edtechre wrote: post #19

Earlier quoted context omitted.

The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server. NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.

NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. Well, you do with node what you do with anything: if you have 4 CPU cores, run 4 copies of your app. Problem solved.

With Node you have to manage the 4 cores if you're doing something where they need to communicate.

Re: Node.js is Backwards

#38

Post by toddh »

ajross wrote: post #20
m0th87 wrote: post #17

Earlier quoted context omitted.

Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...

That seems too nitpicky to me. You can use those definitions if you like, but it's not the common usage. To most programmers those terms are synonyms. In my experience, people trying to be precise about architectures like node.js use the term "asynchronous" and not "concurrent". Calling node.js concurrent obscures the important fact under discussion: namely that it won't scale beyond one CPU in a world where 8-core s…

Seems too fine a point for me too. The number of CPUs doesn't matter, that's up to the scheduler. What limits the the scheduler are coordinating shared resources. That includes CPU, locks, memory, disk, network, IO, etc. The multi-node issue doesn't seem that much of a problem in that you can start a node.js process per core. There's very good performance doing this for MySQL, for example.

Re: Node.js is Backwards

#39

Post by davidhollander »

> Node.js’s concurrency mechanisms are simply an approximation of Erlang’s.

Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.

Re: Node.js is Backwards

#40

Post by kragen »

m0th87 wrote: post #16
jessedhillon wrote: post #15

Earlier quoted context omitted.

> Using the same language at both the client and server end has some serious benefits. What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)

Here's a case study: an open source project I made with node.js; https://github.com/node-bus/node-bus It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance. Technically there are tools that will convert, say, Haskell to Javascript so that you…

That's cool! I was doing something like that at KnowNow in 2000 and 2001 (eventually open-sourced as mod_pubsub), but it never took off.

I agree that JS-on-server is a nicer way to share code than compiling other languages into JS.

Post reply on HN