[deleted]
Node.js isn't a silver bullet, but it's still a bullet.
21–30 of 110 posts
Re: Node.js isn't a silver bullet, but it's still a bullet.
#22To extend the metaphor, Node is a silver bullet.
Silver's way more expensive than lead and offers little or no improvement unless you're shooting at werewolves.
Re: Node.js isn't a silver bullet, but it's still a bullet.
#23The 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 were wrong to try using C. It just was proven, by actually trying it, that it is not the right tool for the job.
It's not really a shortcoming of Node or its hype, it's simply the process we use to eventually find what does work. If you don't try, you'll never know.
Re: Node.js isn't a silver bullet, but it's still a bullet.
#24The 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…
I've found the traditional synchronous approach I am familiar with from Ringo (http://ringojs.org) a better fit for general purpose server side work, so I've made it possible on Node with the help of node-fibers.
Common Node (https://github.com/olegp/common-node/) gives you the best of both worlds: it's easy to develop in & debug just like Ringo yet has low memory usage and is easy to integrate with existing Node libraries.
Here's a very simple CMS I wrote in it: https://github.com/olegp/mcms
Here's a canonical blog example that also shows the use of the synchronous Mongo driver: https://github.com/olegp/notes
Re: Node.js isn't a silver bullet, but it's still a bullet.
#25The 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…
What hype? Whose hype? I think it's a strawman. There is a certain class of problem that often appears on the web presentation layer -- the interaction between the browser and a cornucopia of back-end sources and systems -- where nodejs is often a very good fit, and it is almost always what enthusiasts of the platform are speaking of. That's it. Nothing more. I've seen various angry retorts that opine that become it…
If you do not already think it has been hyped, I am at a loss as to how to prove it to you.
Let me put it this way: Why do we hear so much about Node when it's just another event-based single-threaded "asynchronous" execution environment running on a dynamic language, like half-a-dozen others that preceded it? Basically, it won the hype lottery. Whatever nice things you may have to say about it apply reasonably well to the half-dozen predecessors, too.
Re: Node.js isn't a silver bullet, but it's still a bullet.
#26The 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…
I'm not sure why it is bad for building a CMS. Admittedly, node isn't all that mature so doing so might be a little lower level right now than doing the same with, say, Rails. But it has one huge advantage which is that any modern CMS is going to have a good chunk of client side code, and there are immense advantages to having the same language on the client and server.
The majority of services out there are self-sufficient. Take a very simple http server. It needs to talk to the local filesystem and serve the content requested. The only thing in that equation that might block is the filesystem. Node provides you the tools to deal with that and more. Building an http server in node is enjoyable, easy, and the end result performs well.
The majority of software like a CMS is not self-sufficient. It needs a database, a filesystem, it talks to the http server, it might talk to a dozen other services (generate thumbnails, upload some files to a CDN, scan for viruses in an upload, etc. etc.). You get the idea.
Each external dependency is a blocking dependency. You need to handle it and it isn't easy. Node provides you the tools, but unlike in our first example, where the only thing that blocks is the filesystem, here you have dozens of services that block, with hundreds of pain points. Writing code becomes a chore that is very unpleasant.
That's not the worst of it.
If you miss a blocking operation and don't handle it properly in node, which is very easy, your entire server will go down. In a thread-based or multi-process server-side language mistakes are painful, but not fatal. In node, missing a blocking operation is fatal.
The node guys get this. That's why they're busy trying to cook up a solution around this problem. But they don't talk about it or advertise it.
As of right now, node is definitely not a general purpose solution. It is, however, an excellent solution where you don't have a lot of dependencies that block.
Re: Node.js isn't a silver bullet, but it's still a bullet.
#27Languages are tools. Good carpenters use the right tool for the right job. Can you use sand paper to sand a door down to fit the space? Sure...but there is a reason the plane was invented.
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?
Re: Node.js isn't a silver bullet, but it's still a bullet.
#28People love new things and the story of the new guy overtaking the evil status quo. Node and JS in general seems very hyped right now. Every day there is a new blog about accomplishing something in these technologies that was entirely possible with alternatives for the last many years. But its new and exciting and blogged about. Because it is so new, there are not really any accounts of what a Node architecture does to your maintenance, refactoring, upkeep on a 5 year old application that no one cares about anymore (and the team that built it left).
Maybe it's a sign that the hipsters are rising as the neckbeads retire.
Re: Node.js isn't a silver bullet, but it's still a bullet.
#29Earlier quoted context omitted.
What hype? Whose hype? I think it's a strawman. There is a certain class of problem that often appears on the web presentation layer -- the interaction between the browser and a cornucopia of back-end sources and systems -- where nodejs is often a very good fit, and it is almost always what enthusiasts of the platform are speaking of. That's it. Nothing more. I've seen various angry retorts that opine that become it…
If you do not already think it has been hyped, I am at a loss as to how to prove it to you. Let me put it this way: Why do we hear so much about Node when it's just another event-based single-threaded "asynchronous" execution environment running on a dynamic language, like half-a-dozen others that preceded it? Basically, it won the hype lottery. Whatever nice things you may have to say about it apply reasonably well…
All else isn't the same. For one, this event-based, single-threaded "asynchronous" execution environment running on a dynamic language uses javascript, which is a surprisingly powerful functional language that just happens to run on the other side of the web server conversation in the context that we are discussing.
Being able to standardize and coalesce the two sides of the web pipeline -- regardless of what magic happened at the other layers -- has obvious merits.
Re: Node.js isn't a silver bullet, but it's still a bullet.
#30The 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…
I've found the traditional synchronous approach I am familiar with from Ringo ( http://ringojs.org ) a better fit for general purpose server side work, so I've made it possible on Node with the help of node-fibers. Common Node ( https://github.com/olegp/common-node/ ) gives you the best of both worlds: it's easy to develop in & debug just like Ringo yet has low memory usage and is easy to integrate with existing Node…
> I've made it possible on Node with the help of node-fibers
Cheating! It's not in core. Yes, it largely solves the problem at hand, but we're not talking about node + fibers or even the node + features they're currently working on. We're talking about node. Node doesn't have fibers. Although I wish it did! Fibers really don't belong in the user-space ...