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

51–60 of 90 posts

Re: Node.js is Backwards

#51

Post by evgen »

Volpe wrote: post #41
sausagefeet wrote: post #31

Earlier quoted context omitted.

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.

> Seems like you write a few little functions... Seriously? A very common problem in web apps is validation logic is usually duplicated in JS and Server side language. Node allows the same logic to be used in both cases. These are not a 'few little functions'. Validation is a central part of most business applications. Given the potential to template html with javascript, and to code exclusively in javascript. You co…

Validation is not a central part of most biz applications. Validation on the client side is a UX convenience, but not strictly necessary because anyone with two brian cells to rub together is going to ignore any client side validation and run the real input validation on the server.

Re: Node.js is Backwards

#52

Post by mattking »

> Node.js appeals to people who already know Javascript and don’t want to learn a new language

This is a blanket statement that perhaps displays the author's opinion on Javascript as a language itself.

Re: Node.js is Backwards

#53

Post by otterley »

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

Like what? I hear this argument all the time, but it's always unsubstantiated.

In my experience, the choice of language is less important than the programmer's understanding of facts that have little to do with the language itself.

If you are developing client-side browser code, for instance, then you have little choice but to use Javascript.

But learning JavaScript is not the hard part: mainstream programming languages, in and of themselves, are rarely difficult to master.

On the contrary, the skill that separates the superior engineers from the inferior ones is the mastery of the environment that the program operates in.

For front-end developers, it is an intricate understanding of how browsers work (i.e., the DOM and supported events) and some good understanding of how to optimize requests back to the server. (There is probably much more they know than this, but I'm not a front-end developer.)

Similarly, back-end developers have much to learn about how to efficiently and reliably serve (hopefully) many thousands of requests per second. They need to understand the limitations of their servers, how to manage memory and storage effectively, and build reliable, operable services.

For both types, these skills often take many years to master, and they are hardly interchangeable. Consider that developers themselves often describe themselves as "front-end" and "back-end" people. The fact that you can now use JavaScript on the server side does little to disturb this reality; and things wouldn't change much if you could run Perl or Python or Ruby in the browser tomorrow.

Re: Node.js is Backwards

#55

Post by cwp »

m0th87 wrote: post #17
cwp wrote: post #14

What a bunch of gobbledygook. People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency. Not that you'd get this from the article.

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

Well, that's debatable. I suppose if you squint a bit, you mentally perform a reverse CPS transform on a Node program and end up with a set of tasks that are executing concurrently. In that case, I'll rephrase: Erlang as parallelism (on adequate hardware) but no shared state; Node has shared state but no parallelism.

Still, given the way Node forces programmers to manually unravel tasks and write everything as callbacks, I'm not inclined to call it "concurrency" even if eg. the processing of a group of web requests overlap in wall-clock time.

Re: Node.js is Backwards

#56

Post by akdubya »

alnayyir wrote: post #32
m0th87 wrote: post #11

Earlier quoted context omitted.

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.

I'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.

Re: Node.js is Backwards

#57

Post by cwp »

edtechre wrote: post #19
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...

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.

I used the word "gobbledygook" because the article is poorly written, not because I think he's wrong to criticize Node. Reread the paragraph on Node and tell me it doesn't meet the Wikipedia definition: "text containing jargon or especially convoluted English that results in it being excessively hard to understand."

Re: Node.js is Backwards

#58

Post by BasDirks »

SeoxyS wrote: post #9

Speaking of concurrent programming and parallelism. If you're not into functional programming, check out Apple's Grand Central Dispatch[1] and Objective-C Blocks[2]. Unless you write your own Objective-C http server and run it on Mac OS X Server (it's not that hard, I've done it), this isn't very useful for Web programming. However, if you're comparing the languages / frameworks themselves (you can use all three to c…

Node is very nice for command line tools!

Re: Node.js is Backwards

#59

Post by IsaacSchlueter »

ajessup wrote: post #42
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.

Since the early days of node there has been a proposal to dispatch tasks via the WebWorker API, with a callback - as is currently done for calls to OS subsystems. Sounds like that would be a great way of dispatching CPU intensive tasks without breaking the semantics of Node. What happened to this?

Since the early days of node?

Node's first commit:

    commit 9d7895c567e8f38abfff35da1b6d6d6a0a06f9aa
    Author: Ryan 
    Date:   Mon Feb 16 01:02:00 2009 +0100
    
        add dependencies
How old is Erlang? 25 years or so?

> What happened to this?

There's been some preliminary stuff on giving spawned node processes a more slick API, with the intent of then being able to optimize them in some way.

Whether or not it'll end up at the WebWorker API is yet to be seen, but that'd certainly fit with node's "don't reinvent BOM conventions where they fit" pattern.

Re: Node.js is Backwards

#60

Post by IsaacSchlueter »

otterley wrote: post #53
m0th87 wrote: post #11

Earlier quoted context omitted.

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 Like what? I hear this argument all the time, but it's always unsubstantiated. In my experience, the choice of language is less important than the programmer's understanding of facts that have little to do with the language itself. If you are developing client-side browser code, for instance, then you have little choice but to use J…

> Like what? I hear this argument all the time, but it's always unsubstantiated.

Have you ever done it? It's very comfortable. It reduces one element of friction in the daily thought-work of the programmer.

By the same token, a comfortable chair or nice text editor won't turn an amateur into an all-star programmer in the absence the other important stuff (smarts, work, etc.) It can be a huge waste of time to fret over your editor or your chair adjustments. But that's not going to make me less likely to sit in a nice ergonomic chair and use vim rather than notepad.

Comfort isn't everything, but it's certainly not nothing.

Post reply on HN