31–40 of 110 posts
Good article. I never get why people of one language bash another language. No language is perfect for every task. Use what is good for you and works. Don't bash others because you don't use it.
Geeks love to debate technical stuffs.
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 that wears skinny jeans and shemagh scarves.
Then, just to set things straight, people have to come along and write reasonable posts (like this one) in response.
Keep the anger to yourself, so the rest of us can get on with it and use whatever tools are right for our job.
Just wanted to point out the apples to oranges comparison being made: The article argues that node's sweet-spot is: "to enable real-time propagation of events and state-changes between clients. You could do the same thing with long-polling ajax or even frequent polling, but those both come with the cost of tying up unnecessary worker threads on the server and dealing with extra requests." yes we all know that, that i…
Twisted's website, on the other hand, fills the front page to use verbose, boilerplate-heavy code examples. They mention an "event-driven web server" but don't say why I'd want that. If I'm still interested and click through to their example's I see stuff like "pbsimple.py - simplest possible PB server" or "ampserver.py - do math using AMP". Thrilling.
Earlier quoted context omitted.
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-…
I'm also a bit puzzled by your statement that there are people working on the problem but not talking about it. Do you have some inside information? :) I do agree that it is a solvable problem, however.
I like the smartness of today's blogger: write something that attack another popular internet rant. You'll get instant pageviews.
Languages 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?
Earlier quoted context omitted.
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 ...
Also, even if one opposes the idea of co-routines due to the problem of not knowing which function will yield, there's no denying that they provide one of the best current solutions to the flow control issues with a clean upgrade path to generators when those become available in V8 in 18 months or so.
Languages 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?