Node.js isn't a silver bullet, but it's still a bullet. • Hacker News Board

Re: Node.js isn't a silver bullet, but it's still a bullet.

#91

Post by freshhawk » Sat, Feb 04, 2012, 5:32 AM UTC

crgwbr wrote: post #40

wmf wrote: post #27

Earlier quoted context omitted.

But what if Node isn't the right tool for any job? What if everything Node does well has already been done even better and years earlier by Erlang?

That's clearly not the case. Sure, other event-based web frameworks exist, but Node definitely makes it easier than ever to write event-based apps. Additionally, being able to share code between the server and client is a very interesting and useful feature. Finally, Javascript is unlike really any other language in existence. It has many of the benefits of a functional language, without being nearly as intimidating…

Ease of novice development is definitely a worthy goal and a valuable niche to carve out (like PHP).

But there will be backlash if too many of those novice supporters go overboard in their enthusiasm without any experience to put it in context.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#92

Post by kylebrown » Sat, Feb 04, 2012, 5:58 AM UTC

the-cakeboss wrote: post #76

kylebrown wrote: post #69

Earlier quoted context omitted.

There's other reasons to like node besides the non-blocking IO. For me, its being able to reuse code on the client and the server. Not sure why the node bashers seem to overlook that one.

Serious question: What might you want to reuse on the client side?

The model. For example, including a backbone.js collection/model definition in the server-side node environment and serving the same model code to the client. The controller-y stuff will be different on each: on the node server the model is persisted by overwriting backbone.sync backbone-redis, and the client could choose to do local caching by extending the sync function with a localstorage plug-in.

For the client-server communication, by default backbone.sync on the client uses restful cruddy urls (for rails), which would need to be handled in a node.js router. There's a lot of boilerplate-type stuff out there to help handle routing those urls, building on e.g. express.js. It seems to be more straightforward on rails which already established conventions.

That's probably why a lot of the backbone/node demos and tutorials forego the restful server interface. Its simpler to just do client-server communication using a real-time pipe like socket.io (which itself is shared code on the server the client). not restful but comes with an added wow factor.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#93

Post by tensor » Sat, Feb 04, 2012, 7:13 AM UTC

GnarlinBrando wrote: post #89

tensor wrote: post #87

Earlier quoted context omitted.

I guess the take home here is that Node.j is not new technology. It is old technology reimplemented in a new language. In that sense, rather than fumble through the same mistakes and rediscover the same limitations others have, why not read a book on event driven programming instead?

That is sort of like saying a smart phone is not new technology. In a sense it is not. It is the combination of two already existing technologies, but isn't that pretty much what all new technologies are? On top of that it is a new language and each language is going to be better or worse at doing certain tasks. It is also frequently more beneficial to actually learn something for yourself. As for your second point,…

No, there are sometimes genuinely new technologies: ideas or frameworks that have not been previously explored. Google's PageRank algorithm is a good example. It's not often that you see genuinely new ideas in programming languages, although it does happen occasionally. Javascript as a language doesn't push any boundaries, although it's an alright language overall.

I don't know what books would be best to learn event driven programming. That would be a good question to have an answer to. My point in suggesting a book is that it's the concepts here that matter, not that you are using a Javascript, Python, Ruby, or C# implementation, or a language built around the idea like Erlang. Once you know the concepts, you can quickly and easily pick up or even build a framework in any language.

I don't think anyone is suggesting that Node and the community isn't doing well. It's just that many of us are quite confused by the massive hype around it. Javascript might be a fine choice in some situations, but in general, on the server side you have many different languages to choose from and many (most?) of them also have competent event driven frameworks available. It would surprise me if most development shops didn't have server side developers who work daily with a language other than Javascript.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#94

Post by lmkg » Sat, Feb 04, 2012, 8:49 AM UTC

InclinedPlane wrote: post #79

apgwoz wrote: post #47

Earlier quoted context omitted.

Calling JavaScript a functional language on the pure basis that it has first class functions and closures is sort of stupid. Aside from that, what other properties does JS enforce that are deemed functional? I'll save you some time: none.

Provide a concise, objective definition for functional languages which Lisp, Scala, Haskell, and Lua satisfy but Javascript does not.

The language uses functions as the primary mechanism for implementing core language design features, such as abstraction, modularity, code re-use, and configurable behavior. Lisp, Scala, and Haskell use functions as their go-to tool, supported by macros and/or types. JavaScript uses objects and its object system as its primary tool, with functions in a supporting role.

I will concede that JavaScript supports programming in a functional style. However, if one uses that as the definition of a functional language, the term becomes nearly useless, basically excluding only Java.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#95

Post by InclinedPlane » Sat, Feb 04, 2012, 9:38 AM UTC

ISeemToBeAVerb wrote: post #34

So far, everyone seems to agree that every project has unique problems and solutions, and that node.js has a place. The real argument here seems to be that people are tired of "node hipsters" and "hype". Get over it. What's the point in wasting time being angry about what other developers are thinking or doing? If they're wrong, they'll figure it out eventually. It's the online equivalent of bitching about everyone t…

To be honest, in the case of node.js I don't think there's an overabundance of hype. There is some hype, to be sure, but mostly there's just a lot of buzz from people who are using node and enjoying it.

As long as things stay out of the snake oil zone I think it's ok. And that applies to NoSQL, "cloud" computing, mobile apps, etc.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#96

Post by democracy » Sat, Feb 04, 2012, 10:28 AM UTC

moe wrote: post #80

jeremymcanally wrote: post #7

Earlier quoted context omitted.

If you've spent any appreciable amount of time on Hacker News, you'd know that there has been pretty big hype behind Node.js. If you don't see it, you're not paying attention. Anecdotally, I work with a lot of fairly inexperienced developers with my clients, and I honestly can't tell you how many times they've suggested we "rewrite (x) in Node.js because it's faster" or "let's switch this to Redis" with no real reaso…

or "let's switch this to Redis" Don't throw node and redis in the same bucket please.

And why not? Both are trying to solve a problem 99% of developers do not have.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#97

Post by democracy » Sat, Feb 04, 2012, 10:37 AM UTC

randomdata wrote: post #23

jerf wrote: post #4

The problem was the hype. It was hyped as a silver bullet, and we even have issues like people who have drunk too much Node Kool-Aid thinking that Node has the absolute best multithreading solution, and anything else that doesn't work exactly like Node is therefore worse, when Node in fact merely has a polished-but-old-school approach to the problem. If people are upset that Node isn't a silver bullet, it's because t…

You cannot build hype out of nothing. The reason Node saw the hype it did was because it attacked and reasonably solved real problems that people were having. What you seem to be pointing out here is that there are still unsolved problems out there. Problems where Node tried and failed to deliver. We used to write web applications completely in C, and that was shown to not work either. It doesn't mean those people we…

"You cannot build hype out of nothing. "

Yes you can. There was no hype around asyn java libs (netty , grizzly, mina), however the chance of java folks having these problems is way higher than for javascript front end devs (the main audience of node).

Re: Node.js isn't a silver bullet, but it's still a bullet.

#98

Post by democracy » Sat, Feb 04, 2012, 10:41 AM UTC

maratd wrote: post #12

The problem with Node.js is that it's very good at it's original purpose and terrible at everything else. Node.js is excellent for building network services. It is terrible at general server-side computing. If you need a server that consumes websocket connections, it's great. If you need to build a CLI script that installs and upgrades various software packages, not so much. If you need a chat server, it's great. If…

Thanks dude, that's probably the best introduction to Node, I would put it to Node's front page ,really.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#99

Post by paramaggarwal » Sat, Feb 04, 2012, 12:18 PM UTC

Each language fills a void, a different way of doing something, just because it can be done. Because it is possible. And there are always uses for every way something can be done.

Node.js is nothing different, it has its pros and cons. You simply cannot tag it as 'good' or 'bad'. You are smart if you use it where it suits you. You are silly if you just try to trash it.

Re: Node.js isn't a silver bullet, but it's still a bullet.

#100

Post by apgwoz » Sat, Feb 04, 2012, 12:42 PM UTC

lmkg wrote: post #94

InclinedPlane wrote: post #79

Earlier quoted context omitted.

Provide a concise, objective definition for functional languages which Lisp, Scala, Haskell, and Lua satisfy but Javascript does not.

The language uses functions as the primary mechanism for implementing core language design features, such as abstraction, modularity, code re-use, and configurable behavior. Lisp, Scala, and Haskell use functions as their go-to tool, supported by macros and/or types. JavaScript uses objects and its object system as its primary tool, with functions in a supporting role. I will concede that JavaScript supports programm…

You might add that Lisp (well Scheme and some Common Lisps), Scala, and Haskell provide mechanisms to make recursion equivalent to iteration without explicit looping constructs that require mutation (tail recursion).