8 ms·

If you're using Node.js, you're doing life wrong

139 points by fogus 15y ago

EhevuTov 15y ago
Certain tools are used for certain jobs. Node.js is a different tool and I welcome it. I don't curse a hammer because it is not a screwdriver.
deleted 15y ago
[deleted]
davidw 15y ago
I don't really have a dog in this fight, but I see node.js as being "disruptive": * It's "not as good" as languages/environments like Erlang. * But it's good enough, and significantly simpler, as an approach to tackle a certain class of problems. This, combined with widespread knowledge of Javascript, will probably make it fairly widely used.
- padobson 15y ago
  I was waiting for the disruptive argument in this thread. The fact of the matter is that Javascript is currently (and for the forseeable future) client side language that runs without a plugin. If you want your entire stack to run on Javascript, then server side programming is the only way. Projects like CoffeeScript are the earmarks of disruptive technology - getting something that doesn't fit most peoples needs to grow up quickly, fit everyone's needs, and destroy its competition before the competition even realized it was there.
- cube13 15y ago
  I disagree about it being that "disruptive". The concepts that it uses aren't new. They've existed in POSIX environments for decades. At a very basic level, Node.js is a callback-based API that's based around some(probably select) notifier loop. That's not particularly new.
  - karterk 15y ago
    The disruption is not about whether the paradigm is old or new. The fact is - today if you are building a small app and need some form of real-time features, your best bet is Node.js. Right from etherpad lite to socket.io you have the tools you need to be up and running and to support a few thousand concurrent users out of the box. Of course, scaling it past that will be a problem with Node being single threaded and so on - but I believe that these are problems that Node.js will eventually address.
  - deleted 15y ago
    [deleted]
  - davidw 15y ago
    Sure - Tcl has had an event loop since sometime in the 90ies, and you could always do stuff in C. However, Node is written from head to toe to take advantage of that style of coding, whereas Tcl never had the assumption that everything had to be async, so many calls block. Same thing with Python and Ruby, except that they're relative latecomers to the embedded "select loop" game (sure, modern systems have moved on from select, but it still conveys the idea). Erlang has been around for a while, and does async beautifully, but for every person who knows Erlang there are 10,000 who know Javascript.
indutny 15y ago
You're just using it wrong
tmitchel2 15y ago
Best thing I've read all day. lol. Node looks great for insanely high connection count / non blocking messaging apps but for nearly everything else it looks like a square peg in a round hole.
mustardamus 15y ago
If you're using [your fav framework], you're doing life right. Just use it and see if it works out for you.
deleted 15y ago
[deleted]
lightblade 15y ago
All the points that OP mentioned, whether they are correct or not, are irrelavent. The only factor that drives technology success is the people, aka the community. There are a lot of people on board of nodejs. This just creates more gravity and pulls more people toward it. Together, the community will carry the momentum that drives its success. If v8 is not server technology like OP said, there are enough open source developers to make its on fork.
sktrdie 15y ago
It seems to me like the author overly cares about languages, when the power of Node is the community and its simplicity of use - there's very little boilerplate even for complex things like network programming. Who cares about the language. Use JS if you want, or use Scala. At the end of the day is the maintainability of the product you're developing that matters. I feel, for example, that NPM is much easier and simpler to use than something like Maven. If it makes my life easier, I'll stick with it.
dhconnelly 15y ago
different tools for different jobs
jim-greer 15y ago
If you get really angry about the choices other people make for their own work, you're doing life wrong.
- zobzu 15y ago
  if its your company's people choice, and thus that impacts you directly, you're actually doing life right.
- mjwalshe 15y ago
  Amen - I quickly learnt node.js to build http handler for the callback element of a tool I am building using authority labs - for what we need its the dogs nuts.
  - fennecfoxen 15y ago
    Yeah; maybe if you're using it to build a Big Fancy Webapp it's actually a stupid idea, like if you use a Swiss Army Knife to do carpentry and build a home, you're probably doing it wrong. I'm using node for a small tool to analyze network traffic. The author of this drivel can cope. :P
- zzzeek 15y ago
  Approaches that become popular and highly publicized definitely impact everyone else's work in that field. Teams decide to migrate to those approaches, discarding others, based on perceived popularity, shallow impressions, small amounts of experimentation. Often, this is all we have to go on. But team members who have an intuition that the approach may have more problems than are first visible now have a choice, to either silently go along with the new decision, or to document their reservations. The anger is an issue though. It's a product of when you perceive a waterfall of hype crashing over your own perception of better judgment (please note: perception. subjective viewpoint). It's worth it to try adjusting those perceptions since anger doesn't really get you anywhere.
  - bunderbunder 15y ago
    Couldn't agree more. We're all aware of the Internet Hype Machine. We've all been duped by it before. Heck, my big project today consists of frantic backpedaling from an overly hasty decision, prompted by the IHM, to use SQLite in a project that had no business being based on SQLite. We should all be open to hearing criticism about choices to use X or Y technology. -But- if you start by saying, "You're so stupid," then the person you're talking to will start by thinking, "You're such a jerk." And nobody really pays much attention to the opinions of people they think are jerks.
robinduckett 15y ago
I have to agree with the rest of the commenters here. You make a blanket statement about something you've obviously never used. You're leveraging hearsay and third party complaints against a framework and language that you don't appear to be overly familiar with.
nathanwdavis 15y ago
Wow, this guy seems like a very angry person.
aiscott 15y ago
From the article: "The hype around Node.js on this issue makes me want to punch faces." "But the kind of misunderstanding going on in this video clip seems to pervade the Node.js hype and gives me rageface." This seems like a really over-the-top response to people that have a differing opinion. I can't take the rest of his post seriously after reading these parts. This certainly isn't the sort of thing you read in an informed opinion piece.
- Zancarius 15y ago
  That's also what I took away from it. Aggressive writing, insults, and condescending tone isn't a way to win friends and influence people--except, possibly, those who already agree (judging by the HN comments). He seems to have some valid criticism, but I can't say it's anything I've heard before. If anything, the article itself is flamebait and at least partly intended to troll. After browsing through the comments here on HN, I think he succeeded. But then, everyone likes a good flame war once in a while...
irahul 15y ago
The Ruby and Python communities are just now, many years after the hype has faded, learning that stuff like dependency injection and proper modularization are actually good things that help you maintain code over time. This remark is off the mark. Dependency injection, as in injection by parameters and injection by constructors are so obvious people do it sub-consciously. A fluff word isn't needed for it. As far as IoC containers are concerned, I don't see Ruby/Python communities using it, mainly because half of it is fighting static typing. And people are learning proper modularization now? Seriously? Python/Ruby has proper namespaces(ruby doesn't have it), modules, classes et al. Like any other languages, Python/Ruby has it's share of programmers who write spaghetti code, and programmers who don't. Again, if he writes AbstractConnectionDepenencyInjectioManagerAbstractFactory and calls it proper modularization, I am happy Python/Ruby isn't picking it up.
- Daishiman 15y ago
  Seriously, at least as far as Python goes it has always donde modules and namespaces better than C++ or Java or Scala.
- bri3d 15y ago
  Agreed entirely - I find that this is an old debate between people who "love Java" and those who don't. I posted some commentary on the same topic last time Nick Kallen's infamous "I love everything you hate about Java" blog got posted : http://news.ycombinator.com/item?id=3287777 http://news.ycombinator.com/item?id=3287777 . What it boils down to is that Java likes invoking the names of design patterns with all sorts of pomp and ceremony (look, ma, it's an AbstractFactoryFactory!) while many more modern languages make similar design patterns natural. Whether or not to like the ritual is up to the programmer, but I entirely agree that claiming that Ruby and Python are "just starting" or "don't" support patterns like dependency injection is absolutely baseless.
- rimantas 15y ago
  > As far as IoC containers are concerned, I don't see > Ruby/Python communities using it, mainly because half of > it is fighting static typing. Exactly. Jim Weirich gave a presentation on DI 2005 http://onestepback.org/articles/depinj/index.html http://onestepback.org/articles/depinj/index.html also see a nice writeup by the Jamis Buck—the author of a couple of DI frameworks: http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-pro... http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-pro...
substack 15y ago
> JavaScript has very little support for any of those nice things: it doesn't even have namespaces, for chrissakes. Why would I want to repeat these same mistakes over and over again in a new language? Javascript doesn't have this (by itself) but node has a very nice require() system that is really excellent for long-term maintainability. When you bump a dependency in a node project that change will only affect the code near it because of how node_modules are resolved to the most local copy. You can bump dependencies without worrying how this will affect other packages. Plus, require() just returns an object. It doesn't puke a bunch of objects into the current scope. This is massively useful for readability. I've sunk a lot of time on other systems tracking down unqualified exports to figure out which package's documentation to consult. I've got nothing against scala and am sure it's a useful language but I wonder if the author has even used node.
- josephcooney 15y ago
  How can we even be talking about node and long-term maintainability when it is about 2 years old? And require is younger than that?
virmundi 15y ago
I guess it depends on what I how I want to do my life. If I want to live my life by learning new ideas and using those ideas for something tangible, Node's a pretty good choice. If I want to live my life as a person with a particular language/architectual ideology, then anything that is not in that world view is wrong. I like node for system level scripting. I find bash annoying and non portable to windows. I really don't want to have to learn batch scripting for dos on windows. But I can use JavaScript with node to script in both environments. On the server I think that node might be helpful for certain network level tasks. But I haven't used it for much. But honestly what type of person would I be if I don't even consider it? The OP seems to be making an emotional decision rather than a technical one. Interestingly he's using Scala. There are many similar posts about Scala being the wrong way to do life. I just can't agree with any of those views. Finally I wonder what the value is for these rage posts. They just seem to further divide people. I do see the value in the posts about I've used node for X months, here's my thoughts or here's why I'm going back to X paradigm. But just a rant where faces should be punched seems out of place for HN.
- brunoc 15y ago
  If you like Node for system level scripting, you're gonna love this: http://www.jsdb.org/ http://www.jsdb.org/ Don't let the name fool you, it's not only for databases. I would say that it's probably more suitable for general purpose scripts than Node, though some of the APIs are a bit clumsy. It's not open source, but it's free and cross platform and actually pretty good for a lot of general purpose scripting. Seems that it is developed by a single guy. I found out about it a few years ago and used it to get some things quickly done.
eliaskg 15y ago
What's the problem if someone creates great stuff with it?
libria 15y ago
I haven't used node.js before, but I see 2 main points being made about it, by proponents and detractors respectively: * It uses non-blocking evented IO so it can scale well. * It is single threaded so it can't scale well. Someone teach me: which of these statements is true?
- tabbyjabby 15y ago
  I think largely non-blocking I/O is a means to an end. Non-blocking I/O allows one to implement a single-threaded event loop, which allows one to skip all the overhead associated with multithreaded systems. It's not the non-blocking I/O which necessarily makes it more scalable, it's the fact that you avoid the heavy cost of context-switching and the memory and CPU complexity of thread creation.
- ender7 15y ago
  Neither are true. Non-blocking evented IO is mostly attractive from a usability point of view: it's much easier to write programs that aren't multi-threaded. It can also use much less memory than a threaded model in certain situations. Non-blocking, evented systems tend to be single-threaded. Single-threaded systems don't automatically scale across multiple cores. To scale, you spawn a separate process for each core (for example, this is the suggested practice for node). You must then find some way for the different processes to communicate with each other, which is usually through a database (or some crazy pub-sub thing). Node can scale just fine if you design your program to do so. It just scales in a different way.
  - marshray 15y ago
    Personally I love it, but some programmers find non-blocking evented "async" IO completely counter-intuitive. So it's debatable on the usability. Async IO is an absolute win from the scalability perspective because it allows you to service a great many clients with many fewer threads. OS thread context switches are relatively expensive. Ideally you would have exactly one OS thread per physical core and they would never need to block on exclusive access to any shared resources. Now that we have a system where the user code inside the async handler doesn't need to manage exclusive access to anything, from the usability perspective it can has some of the simplicity of code that is fully single-threaded. But that's subtly different from saying ASIO makes it easy. My guess is that many of the same programmers who aren't comfortable writing multithreaded code aren't going to find it completely intuitive to rethread their stack around an ASIO model.
bunderbunder 15y ago
I've got my doubts about Node.js, since it seems like rather a one-trick pony. But it is a good trick. Node.js deserves credit for calling attention to an underappreciated design pattern that has a lot to offer in certain circumstances. (Personally I think the .NET team hit the nail more squarely on the head with TPL, a pony that can do that trick as well as many others. But .NET doesn't have the sex appeal it takes to be a spokesmodel so meh.) Javascript isn't my favorite language, or the most performant one. But as a "Lisp with C syntax", on a semantic level it's much better suited to the higher-order programming techniques that the pattern requires than most other popular Web languages are. Ruby also has the right features, but it isn't exactly the poster child for high-performance computing either. Might as well flip a coin, because either way opinionated folks with blood pressure conditions will call you an idiot.
andrewvc 15y ago
I'm really pretty anti-node, but this article isn't very good. The concerns here are mixed up and not very thorough. All these points need graphs, charts, something solid to anchor them to. This is the sort of article that polarizes, but doesn't add to the discussion. It starts off strong talking about a high bug count, but never gets into specifics there. As far as scaling across cores goes, it's disingenuous to suggest that node can't do this, there are a number of options here. Message passing, for instance, does indeed work. As far as nested callbacks sucking, I totally agree. But a walk through why would add a lot more substance here as well.
- nephics 15y ago
  Unfortunately, this way of stating unqualified arguments as basis for reasoning is quite prevalent on the Internet. Keeping it to node.js bashing, this guy takes the discussion to a slightly lower level: http://youtube.com/watch?v=1e1zzna-dNw http://youtube.com/watch?v=1e1zzna-dNw
  - highace 15y ago
    Ha, I liked that. But slagging aside, are the points he makes baseless?
  - AdrianRossouw 15y ago
    How is that lower level ? He tries to discredit node by taking apart the copy on the front page of nodejs.org. It's all conjecture and ad hominem.
- mnutt 15y ago
  I don't think it even starts off strong with the bug counts. That wasn't node, but using Chrome/v8 directly to parse web pages for their web crawler. I'm not the least bit surprised that parsing unfiltered HTML from the internet dominates their bug count. I also won't be surprised if their rewritten scala HTML parser also dominates the bug counts.
hamidpalo 15y ago
The spaghetti code of node.js callbacks is really a problem of Javascript lacking monads, and in this case something like the Async monad from F#. TameJS is a step in the right direction by adding a C#-style await.
jdelsman 15y ago
His comment about node.js only being able to use a single core is bullshit, and has been for a while: * Before native support: https://github.com/learnboost/cluster https://github.com/learnboost/cluster * Now, native: http://nodejs.org/docs/latest/api/cluster.html http://nodejs.org/docs/latest/api/cluster.html
rdouble 15y ago
I recently evaluated Node and Scala for a presence server for an iOS app. With my naive understanding of both platforms, it was way easier to do this with Node. It would be interesting to hear more detail about how Scala was used and why it was better.
tingletech 15y ago
Node is not for every use case, This tech talk on node is pretty interesting http://sna-projects.com/blog/2011/08/nodejs/ http://sna-projects.com/blog/2011/08/nodejs/ I watched it last weekend, and from what I understood/remember from the talk the reason the node people picked javascript was not because they liked javascript. It was because they wanted to do async programming, and they found other languages had too much synchronous baggage. In javascript, node.js could start from a clean slate and build a pure async culture and environment.
tingletech 15y ago
Node is not for every use case, This tech talk on node is pretty interesting http://sna-projects.com/blog/2011/08/nodejs/ http://sna-projects.com/blog/2011/08/nodejs/ I watched it last weekend, and from what I understood/remember from the talk the reason the node people picked javascript was not because they liked javascript. It was because they wanted to do async programming, and they found other languages had too much synchronous baggage. In javascript, node.js could start from a clean slate and build a pure async cultural and environment.
Kilimanjaro 15y ago
Node solves a problem I don't have in a so convoluted way that if I ever have that kind of problem I won't be using node for sure. Is there a need for webstackers to go play at the server side? YES! but node is not THE solution, it is just ONE solution. I venture to say, as javascript evolves more towards a coffeescript flavor, then a coffeescript flavor on the server is what is needed. And I'll support something along these lines.
bryanh 15y ago
Nonsense. Perhaps your choice to use Node.js is suboptimal? That isn't an indication of Node.js's quality, it's an indication of your inability to choose the right tech. People choose tools that make it easier to do something, Node.js accomplishes that for a wide range of tasks. I just spun up a IM API we needed in an evening thanks to Node.js and community contributed packages. It's humming along great, I even wrote up a piece about it: http://news.ycombinator.com/item?id=3547664 http://news.ycombinator.com/item?id=3547664
chrismealy 15y ago
"The Ruby and Python communities are just now, many years after the hype has faded, learning that stuff like dependency injection and proper modularization are actually good things" WTF?!
crazygringo 15y ago
Programming with Node's async model makes it extremely powerful and fast to run database queries and file functions in parallel, but the downside is the potential for huge callback spaghetti indeed. But the callback spaghetti problem can be largely solved by dropping in, for example, the IcedCoffeeScript fork: http://maxtaco.github.com/coffee-script/ http://maxtaco.github.com/coffee-script/ Or the previous JavaScript TAME functionality: http://tamejs.org/ http://tamejs.org/ There are of course many other async helper solutions as well, and if you're doing serious Node development, it's kind of insane not to use one of these.
- MatthewPhillips 15y ago
  If you expect a lot of callback it makes more sense to design that functionality as an object rather than as a single function. That way you can spread callbacks over many functionality and still maintain modularity.
  - crazygringo 15y ago
    Not necessarily -- the issue is not so much code modularity as much as control-flow issues, which separating out functions (mandatory) doesn't necessarily help with (because of all the flags of what function should call what other function afterwards, etc.).
steele 15y ago
Never take life advice from someone who responds to hype with a compulsion to "punch faces" while donning "rageface". To be fair though, I bet this is just a casual blog entry that the guy didn't know would hit HN. http://meyerweb.com/bkkt/okaythen.gif http://meyerweb.com/bkkt/okaythen.gif
karterk 15y ago
Ok, as someone who has been actually building apps on Node for about 1 year AND working with a largish Scala codebase for the last six months: > Not to mention the fact that its balls-ass slower than some straight un-optimized Scala. I don't see the point of comparison here. Slower/faster is meaningless without the context. Apples to Oranges. And, Scala has it's own issues. Yeah, the JVM's performance is there, but bringing your team onto a Scala codebase is not easy either. > It provides the least amount of aid and comfort to the programmer and its nigh-on-impossible to follow the code 6 months later. Anyone who has developed more than a Hello World in Node will know that the problem of callback sphaghetti can be circumvented using events, promises and async libraries. Yes, until the language itself offers an async construct, this will be an issue, but frankly there are ways to get around it. > JavaScript has very little support for any of those nice things: it doesn't even have namespaces, for chrissakes. Client side JS has no module system. But Node.js has. At this point, I really wonder if the OP has actually worked at all with Node. > It seems to me that people who are really crazy about Node.js are people who only knew JavaScript to begin with and to whom none of the above would ever even occur. Another baseless claim. I urge you to go see the GitHub profiles of Node core committers. Seriously.
- rgarcia 15y ago
  Nit: Client side JS has no module system. Check out requirejs: http://requirejs.org/ http://requirejs.org/ I've used it to handle both server-side (node) and client-side module systems, and it's been great.
  - karterk 15y ago
    Yes, I am aware of requirejs. I was talking about native module support.
    - MatthewPhillips 15y ago
      Native module support is a feature of Harmony and,it's pretty fantastic. I hope Node adopts this method of module loading as an alternative to require in the future. edit: phone keyboard typos
deleted 15y ago
[deleted]
alexchamberlain 15y ago
Glad to see someone has been brave enough to come out against this. I too don't like Node; JavaScript was never designed to take on this sort of load.
funkah 15y ago
Node seems unnecessarily complicated and faddish, but if you really want to mire yourself in callback soup then go ahead. I'll just be over here, not tearing my hear out.
brianshumate 15y ago
The problem I see with all these kinds of negative posts concerning Node.js is that they essentially boil down to "this is so radically different and uncomfortable to me that it cannot possibly be good for anyone else." and do not provide any concrete business examples of why it should be avoided. Until I see an actual example of how "Node.js crashed my business, cost us N dollars, and here's exactly how...", I will continue to look at such posts as developers complaining about having to learn to do things a new way — something that has been going on since there were developers.
antrover 15y ago
It's posts like this that make me embarrassed to be a programmer. The author basically states, "Node.js is not a good fit for my company, therefor everyone using node.js is wasting their time." It's generalizations like this that just blow my mind. I don't go around saying, "Snickers is the worst candybar, therefor anyone who eats a Snickers is wasting their time." I bet the author is not a pleasant person to work with.
IsaacSchlueter 15y ago
This is hilarious.
jessedhillon 15y ago
Here's my problem and why I don't care to use it: It's a community built around an implementation of a language which they do not control. Who is Guido or Matz in node.js? Ryan Dahl I suppose; does he take requests or hold discussions concerning the future evolution of the language? Does he issue any rationale documents concerning his language design philosophy? Could he add multithreading to V8 and if so, why hasn't this happened? It's a community built around someone else's tool, and Google develops it for entirely different reasons. Case in point, someone posted IcedCoffee, which adds an "await" keyword to CoffeeScript -- you have to implement a compiled language on top of Javascript to have the language features you need! Finally, to preempt questions about my being concerned about other people's language choices -- other people are choosing, inexpertly in my opinion, the technologies with with I will contend in the future. Future employers may value and demand experience in node, and future employees may have to be disabused of bad habits accumulated during the learning of it.
- chc 15y ago
  This comment is just wildly off the mark. You're comparing a framework to a language. DHH can't add features to MRI Ruby any more than Ryan Dahl can add features to V8 JavaScript.
  - jessedhillon 15y ago
    Off the mark? Perhaps. Wildly so? Unlikely. But if that's so, then simply view this as an explanation for why I don't use server-side Javascript. And Node is still a tool built around a language implementation which is going in a different direction from where a server side environment/general-purpose language needs to go.
    - chc 15y ago
      You're welcome to use whatever you like, of course — I'm just saying that you haven't really raised any specific objections that couldn't be (and haven't been) leveled against most other languages. Ignoring the confusion of a language and a framework, so far, your concrete objections seem to be: • Node.js is a framework built by people other than the language's core maintainers (which is true of most frameworks) • If you want to add fundamental language features, you can't just force it into the core implementation, but will have to implement your own offshoot (which is true of most languages, including, for example, Clojure) If you're really concerned about other people's language choices, you're going to need concrete reasons, not just generalities, vague insinuations and your own personal preferences. (Edited a bit to clarify and because the original phrasing sounded more combative than I intended.)
didip 15y ago
Everybody is angry if bugs keep punching them in the face. I get that. But this post needs more info to be informative: * If I read correctly, OP is using Chrome/V8 directly. I don't see if the bug list is on V8 itself or his bindings? * "Callback Spaghetti". To each his/her own. I happened to read callbacks easier than other solutions. And this is coming from Python programmer, not JS programmer. * The last 2 points are also information-less rants. What happened to HN?
hello_moto 15y ago
Article like this needs to be sliced-n-diced in different ways: 1) If you don't know technology X and use it due to hype, you deserve to get burned Let that be a lesson for anybody. 2) There's no silver bullet Choosing node.js over web-framework just because you want the front-end and the back-end to use the same code-base is to trade one feature for another: Ruby and Rails still have better tools than Node.js while you get JS all over the place (assuming you're good with JS). 3) Complaining about the language is a sign that you have no clue I used to think that Java is better than some of the hype dynamic languages out there but I was wrong: Java is better for ME because I _KNOW_ Java Better. If I know Ruby more than I know Java then Ruby is better than Java FOR ME. 4) Don't program using another language's idioms This is documented left and right already. If you use technology X, find best-practices for technology X. Don't just apply best-practices from technology Y. http://dirtsimple.org/2004/12/python-is-not-java.html http://dirtsimple.org/2004/12/python-is-not-java.html Or some of the comments here about Dependency Injection (which is quite common in Java but not so in Python/Ruby). In the past, I had one instructor that noticed that my QBasic code looked like Fortran. He asked me if I knew Fortran beforehand and I told him that I've taken Fortran before this class. People see and notice.
skrebbel 15y ago
I love articles like this. All the dry analyses, the subtle counter-counter-arguments, that the usual tech opinion articles on HN have make me nuts. The little layer of emotion and drama added here gets the point across much better, IMHO. Of course it doesn't do anything but preaching to the choir (hi there), and not convincing anyone not already in the choir, but it's a great read! (and so is this thread). In other news, if you're voluntarily using a dynamically typed language and an editor without an integrated debugger, you're not fit for programming!
jconley 15y ago
Node enforces a programming model that puts you down the path to extreme vertical scalability, you know, actually using all the hardware you are paying for. CPUs and the kernels that manage them are good at running code. They suck at waiting for things to happen. Out of the box the callback model can be difficult to wrap your head around. But if you are serious about writing a vertically scalable IO-bound service, it is currently the only option. There are some add-ons to make the code less ugly, but you still have to have the mental model down. It's a lot like multi-threaded programming, or functional programming. It's a matter being able to visualize the flow and pass context around. This takes time to change the way you think. If you approach problems in Node like you'd approach a problem in a functional language the spaghetti of callbacks becomes much less of a burden. For the async haters out there operating at scale. How many of you have farms of machines with idle CPU's, maxed out memory, and practically idle network interfaces? Yeah, I thought so.
Lazare 15y ago
Okay, let's play a little game. I'm going to describe a scenario (using Python; feel free to substitute the equivalent Ruby terms if that makes it more relevant for you). You're a pretty good Python developer. You know, and feel comfortable with, not just Python, but the entire ecosystem. Virtualenv, pip, the whole nine yards. And now you're working on a really nifty Django app, maybe a CRM or something, when you realize... ...damn. This app really needs a lot of functionality ripped out and shoved in the browser. I'm losing my marbles writing spaghetti jQuery code, but what I really need is some client side templates. So you poke at it, and think about it, and you realize that the proper design of your app is really a bunch of client-side code using Backbone, and a server that just handles authentication and is otherwise a thin RESTful wrapper around your database. Great! But at this point, most of the actual code you will be writing is Javascript. Your server could be written in, practically, anything. And there's some compelling reasons to leave it in Python. On the other hand, if you switch to node.js it means all your code is in the same language (which is nice). It also opens the door to being able to use the same code on both the client and the server - which is really good. Client-side templates are nice, but being able to render them on the server when you need to is practically a requirement. And Python's support for rendering Javascript templates is very limited. And if you're a Python coder, you'll probably want to be writing your client in CoffeeScript anyhow, which requires having node.js installed, so, at least for development, just have the whole damn stack in node.js. You can always hack together a little RESTful server in Python later if you decide that node.js isn't right for production. Seems simple enough, right? And as you can probably guess, I just went through this process. And so now we have this blogpost, which is saying...well, it's not really clear what it's saying. That I should be using Scala, I guess. This is, frankly, so wrong it's embarrassing. 1) Even if the JVM was just so amazing and awesome, I'm not a JVM developer. The ecosystem is radically different. As a Python developer, I'm able to install, configure, and be productive with node.js very quickly. npm, nvm, coffeescript, and we're away. My IDE of choice (PyCharm) even supports CoffeeScript. There is very low impedence. Switching to Scala...where would I even begin? 2) I'm doing this because I need to write a client side app. That must be written in Javascript, or something that compiles to Javascript. Scala is neither. And while there are JVM language that do, there are some major concerns with their suitability, maturity, and tooling. Clojurescript looks great, but it's not something you pick because you think coffeescript is too new and little used! 3) The rant would be more compelling if the author came across as someone who actually knew anything about Python, Javascript, or node.js. Contrary to his assertions: Javascript does have namespaces. Python and Python developers have ALWAYS been convinced that modularity is good. And Python developers are still quite aware that dependency injection is a way to solve problems with the design of Java which aren't even relevant to their language of choice. 4) Also, if you don't grok callbacks, it doesn't mean you are a bad programmer. But it might be worth keeping in mind that there are plenty of programmers who do, and they're going to laugh at you when you reveal you don't. Not to mention that there are plenty of ways of programming in node.js WITHOUT callback spaghetti, and revealing that you have no clue about the framework your slagging is not going to improve your credibility. 5) To continue the theme, insulting a framework for not scaling well may work better if you don't reveal that you don't know how it scales in the same paragraph.
mnot 15y ago
Wow, seriously? This is just as bad as the fanboy "you'll use X for EVERYTHING!" posts. Please.
gumbo 15y ago
Please give me a break. This guy made some points: spaghetti code, .... He state it in the wrong way, however one should admit that node.js is not mature enougth for many use cases. I'm still learning but, haven't seen how just by using node.js you get a scalable server.

139 points by fogus 15y ago

Certain tools are used for certain jobs. Node.js is a different tool and I welcome it. I don't curse a hammer because it is not a screwdriver.

deleted 15y ago

[deleted]

davidw 15y ago

I don't really have a dog in this fight, but I see node.js as being "disruptive": * It's "not as good" as languages/environments like Erlang. * But it's good enough, and significantly simpler, as an approach to tackle a certain class of problems. This, combined with widespread knowledge of Javascript, will probably make it fairly widely used.

padobson 15y ago
I was waiting for the disruptive argument in this thread. The fact of the matter is that Javascript is currently (and for the forseeable future) client side language that runs without a plugin. If you want your entire stack to run on Javascript, then server side programming is the only way. Projects like CoffeeScript are the earmarks of disruptive technology - getting something that doesn't fit most peoples needs to grow up quickly, fit everyone's needs, and destroy its competition before the competition even realized it was there.
cube13 15y ago
I disagree about it being that "disruptive". The concepts that it uses aren't new. They've existed in POSIX environments for decades. At a very basic level, Node.js is a callback-based API that's based around some(probably select) notifier loop. That's not particularly new.
- karterk 15y ago
  The disruption is not about whether the paradigm is old or new. The fact is - today if you are building a small app and need some form of real-time features, your best bet is Node.js. Right from etherpad lite to socket.io you have the tools you need to be up and running and to support a few thousand concurrent users out of the box. Of course, scaling it past that will be a problem with Node being single threaded and so on - but I believe that these are problems that Node.js will eventually address.
- deleted 15y ago
  [deleted]
- davidw 15y ago
  Sure - Tcl has had an event loop since sometime in the 90ies, and you could always do stuff in C. However, Node is written from head to toe to take advantage of that style of coding, whereas Tcl never had the assumption that everything had to be async, so many calls block. Same thing with Python and Ruby, except that they're relative latecomers to the embedded "select loop" game (sure, modern systems have moved on from select, but it still conveys the idea). Erlang has been around for a while, and does async beautifully, but for every person who knows Erlang there are 10,000 who know Javascript.

indutny 15y ago

You're just using it wrong

tmitchel2 15y ago

Best thing I've read all day. lol. Node looks great for insanely high connection count / non blocking messaging apps but for nearly everything else it looks like a square peg in a round hole.

mustardamus 15y ago

If you're using [your fav framework], you're doing life right. Just use it and see if it works out for you.

deleted 15y ago

[deleted]

lightblade 15y ago

All the points that OP mentioned, whether they are correct or not, are irrelavent. The only factor that drives technology success is the people, aka the community. There are a lot of people on board of nodejs. This just creates more gravity and pulls more people toward it. Together, the community will carry the momentum that drives its success. If v8 is not server technology like OP said, there are enough open source developers to make its on fork.

sktrdie 15y ago

It seems to me like the author overly cares about languages, when the power of Node is the community and its simplicity of use - there's very little boilerplate even for complex things like network programming. Who cares about the language. Use JS if you want, or use Scala. At the end of the day is the maintainability of the product you're developing that matters. I feel, for example, that NPM is much easier and simpler to use than something like Maven. If it makes my life easier, I'll stick with it.

dhconnelly 15y ago

different tools for different jobs

jim-greer 15y ago

If you get really angry about the choices other people make for their own work, you're doing life wrong.

zobzu 15y ago
if its your company's people choice, and thus that impacts you directly, you're actually doing life right.
mjwalshe 15y ago
Amen - I quickly learnt node.js to build http handler for the callback element of a tool I am building using authority labs - for what we need its the dogs nuts.
- fennecfoxen 15y ago
  Yeah; maybe if you're using it to build a Big Fancy Webapp it's actually a stupid idea, like if you use a Swiss Army Knife to do carpentry and build a home, you're probably doing it wrong. I'm using node for a small tool to analyze network traffic. The author of this drivel can cope. :P
zzzeek 15y ago
Approaches that become popular and highly publicized definitely impact everyone else's work in that field. Teams decide to migrate to those approaches, discarding others, based on perceived popularity, shallow impressions, small amounts of experimentation. Often, this is all we have to go on. But team members who have an intuition that the approach may have more problems than are first visible now have a choice, to either silently go along with the new decision, or to document their reservations. The anger is an issue though. It's a product of when you perceive a waterfall of hype crashing over your own perception of better judgment (please note: perception. subjective viewpoint). It's worth it to try adjusting those perceptions since anger doesn't really get you anywhere.
- bunderbunder 15y ago
  Couldn't agree more. We're all aware of the Internet Hype Machine. We've all been duped by it before. Heck, my big project today consists of frantic backpedaling from an overly hasty decision, prompted by the IHM, to use SQLite in a project that had no business being based on SQLite. We should all be open to hearing criticism about choices to use X or Y technology. -But- if you start by saying, "You're so stupid," then the person you're talking to will start by thinking, "You're such a jerk." And nobody really pays much attention to the opinions of people they think are jerks.

robinduckett 15y ago

I have to agree with the rest of the commenters here. You make a blanket statement about something you've obviously never used. You're leveraging hearsay and third party complaints against a framework and language that you don't appear to be overly familiar with.

nathanwdavis 15y ago

Wow, this guy seems like a very angry person.

aiscott 15y ago

From the article: "The hype around Node.js on this issue makes me want to punch faces." "But the kind of misunderstanding going on in this video clip seems to pervade the Node.js hype and gives me rageface." This seems like a really over-the-top response to people that have a differing opinion. I can't take the rest of his post seriously after reading these parts. This certainly isn't the sort of thing you read in an informed opinion piece.

Zancarius 15y ago
That's also what I took away from it. Aggressive writing, insults, and condescending tone isn't a way to win friends and influence people--except, possibly, those who already agree (judging by the HN comments). He seems to have some valid criticism, but I can't say it's anything I've heard before. If anything, the article itself is flamebait and at least partly intended to troll. After browsing through the comments here on HN, I think he succeeded. But then, everyone likes a good flame war once in a while...

irahul 15y ago

The Ruby and Python communities are just now, many years after the hype has faded, learning that stuff like dependency injection and proper modularization are actually good things that help you maintain code over time. This remark is off the mark. Dependency injection, as in injection by parameters and injection by constructors are so obvious people do it sub-consciously. A fluff word isn't needed for it. As far as IoC containers are concerned, I don't see Ruby/Python communities using it, mainly because half of it is fighting static typing. And people are learning proper modularization now? Seriously? Python/Ruby has proper namespaces(ruby doesn't have it), modules, classes et al. Like any other languages, Python/Ruby has it's share of programmers who write spaghetti code, and programmers who don't. Again, if he writes AbstractConnectionDepenencyInjectioManagerAbstractFactory and calls it proper modularization, I am happy Python/Ruby isn't picking it up.

Daishiman 15y ago
Seriously, at least as far as Python goes it has always donde modules and namespaces better than C++ or Java or Scala.
bri3d 15y ago
Agreed entirely - I find that this is an old debate between people who "love Java" and those who don't. I posted some commentary on the same topic last time Nick Kallen's infamous "I love everything you hate about Java" blog got posted : http://news.ycombinator.com/item?id=3287777 http://news.ycombinator.com/item?id=3287777 . What it boils down to is that Java likes invoking the names of design patterns with all sorts of pomp and ceremony (look, ma, it's an AbstractFactoryFactory!) while many more modern languages make similar design patterns natural. Whether or not to like the ritual is up to the programmer, but I entirely agree that claiming that Ruby and Python are "just starting" or "don't" support patterns like dependency injection is absolutely baseless.
rimantas 15y ago
> As far as IoC containers are concerned, I don't see > Ruby/Python communities using it, mainly because half of > it is fighting static typing. Exactly. Jim Weirich gave a presentation on DI 2005 http://onestepback.org/articles/depinj/index.html http://onestepback.org/articles/depinj/index.html also see a nice writeup by the Jamis Buck—the author of a couple of DI frameworks: http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-pro... http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-pro...

substack 15y ago

> JavaScript has very little support for any of those nice things: it doesn't even have namespaces, for chrissakes. Why would I want to repeat these same mistakes over and over again in a new language? Javascript doesn't have this (by itself) but node has a very nice require() system that is really excellent for long-term maintainability. When you bump a dependency in a node project that change will only affect the code near it because of how node_modules are resolved to the most local copy. You can bump dependencies without worrying how this will affect other packages. Plus, require() just returns an object. It doesn't puke a bunch of objects into the current scope. This is massively useful for readability. I've sunk a lot of time on other systems tracking down unqualified exports to figure out which package's documentation to consult. I've got nothing against scala and am sure it's a useful language but I wonder if the author has even used node.

josephcooney 15y ago
How can we even be talking about node and long-term maintainability when it is about 2 years old? And require is younger than that?

virmundi 15y ago

I guess it depends on what I how I want to do my life. If I want to live my life by learning new ideas and using those ideas for something tangible, Node's a pretty good choice. If I want to live my life as a person with a particular language/architectual ideology, then anything that is not in that world view is wrong. I like node for system level scripting. I find bash annoying and non portable to windows. I really don't want to have to learn batch scripting for dos on windows. But I can use JavaScript with node to script in both environments. On the server I think that node might be helpful for certain network level tasks. But I haven't used it for much. But honestly what type of person would I be if I don't even consider it? The OP seems to be making an emotional decision rather than a technical one. Interestingly he's using Scala. There are many similar posts about Scala being the wrong way to do life. I just can't agree with any of those views. Finally I wonder what the value is for these rage posts. They just seem to further divide people. I do see the value in the posts about I've used node for X months, here's my thoughts or here's why I'm going back to X paradigm. But just a rant where faces should be punched seems out of place for HN.

brunoc 15y ago
If you like Node for system level scripting, you're gonna love this: http://www.jsdb.org/ http://www.jsdb.org/ Don't let the name fool you, it's not only for databases. I would say that it's probably more suitable for general purpose scripts than Node, though some of the APIs are a bit clumsy. It's not open source, but it's free and cross platform and actually pretty good for a lot of general purpose scripting. Seems that it is developed by a single guy. I found out about it a few years ago and used it to get some things quickly done.

eliaskg 15y ago

What's the problem if someone creates great stuff with it?

libria 15y ago

I haven't used node.js before, but I see 2 main points being made about it, by proponents and detractors respectively: * It uses non-blocking evented IO so it can scale well. * It is single threaded so it can't scale well. Someone teach me: which of these statements is true?

tabbyjabby 15y ago
I think largely non-blocking I/O is a means to an end. Non-blocking I/O allows one to implement a single-threaded event loop, which allows one to skip all the overhead associated with multithreaded systems. It's not the non-blocking I/O which necessarily makes it more scalable, it's the fact that you avoid the heavy cost of context-switching and the memory and CPU complexity of thread creation.
ender7 15y ago
Neither are true. Non-blocking evented IO is mostly attractive from a usability point of view: it's much easier to write programs that aren't multi-threaded. It can also use much less memory than a threaded model in certain situations. Non-blocking, evented systems tend to be single-threaded. Single-threaded systems don't automatically scale across multiple cores. To scale, you spawn a separate process for each core (for example, this is the suggested practice for node). You must then find some way for the different processes to communicate with each other, which is usually through a database (or some crazy pub-sub thing). Node can scale just fine if you design your program to do so. It just scales in a different way.
- marshray 15y ago
  Personally I love it, but some programmers find non-blocking evented "async" IO completely counter-intuitive. So it's debatable on the usability. Async IO is an absolute win from the scalability perspective because it allows you to service a great many clients with many fewer threads. OS thread context switches are relatively expensive. Ideally you would have exactly one OS thread per physical core and they would never need to block on exclusive access to any shared resources. Now that we have a system where the user code inside the async handler doesn't need to manage exclusive access to anything, from the usability perspective it can has some of the simplicity of code that is fully single-threaded. But that's subtly different from saying ASIO makes it easy. My guess is that many of the same programmers who aren't comfortable writing multithreaded code aren't going to find it completely intuitive to rethread their stack around an ASIO model.

bunderbunder 15y ago

I've got my doubts about Node.js, since it seems like rather a one-trick pony. But it is a good trick. Node.js deserves credit for calling attention to an underappreciated design pattern that has a lot to offer in certain circumstances. (Personally I think the .NET team hit the nail more squarely on the head with TPL, a pony that can do that trick as well as many others. But .NET doesn't have the sex appeal it takes to be a spokesmodel so meh.) Javascript isn't my favorite language, or the most performant one. But as a "Lisp with C syntax", on a semantic level it's much better suited to the higher-order programming techniques that the pattern requires than most other popular Web languages are. Ruby also has the right features, but it isn't exactly the poster child for high-performance computing either. Might as well flip a coin, because either way opinionated folks with blood pressure conditions will call you an idiot.

andrewvc 15y ago

I'm really pretty anti-node, but this article isn't very good. The concerns here are mixed up and not very thorough. All these points need graphs, charts, something solid to anchor them to. This is the sort of article that polarizes, but doesn't add to the discussion. It starts off strong talking about a high bug count, but never gets into specifics there. As far as scaling across cores goes, it's disingenuous to suggest that node can't do this, there are a number of options here. Message passing, for instance, does indeed work. As far as nested callbacks sucking, I totally agree. But a walk through why would add a lot more substance here as well.

nephics 15y ago
Unfortunately, this way of stating unqualified arguments as basis for reasoning is quite prevalent on the Internet. Keeping it to node.js bashing, this guy takes the discussion to a slightly lower level: http://youtube.com/watch?v=1e1zzna-dNw http://youtube.com/watch?v=1e1zzna-dNw
- highace 15y ago
  Ha, I liked that. But slagging aside, are the points he makes baseless?
- AdrianRossouw 15y ago
  How is that lower level ? He tries to discredit node by taking apart the copy on the front page of nodejs.org. It's all conjecture and ad hominem.
mnutt 15y ago
I don't think it even starts off strong with the bug counts. That wasn't node, but using Chrome/v8 directly to parse web pages for their web crawler. I'm not the least bit surprised that parsing unfiltered HTML from the internet dominates their bug count. I also won't be surprised if their rewritten scala HTML parser also dominates the bug counts.

hamidpalo 15y ago

The spaghetti code of node.js callbacks is really a problem of Javascript lacking monads, and in this case something like the Async monad from F#. TameJS is a step in the right direction by adding a C#-style await.

jdelsman 15y ago

His comment about node.js only being able to use a single core is bullshit, and has been for a while: * Before native support: https://github.com/learnboost/cluster https://github.com/learnboost/cluster * Now, native: http://nodejs.org/docs/latest/api/cluster.html http://nodejs.org/docs/latest/api/cluster.html

rdouble 15y ago

I recently evaluated Node and Scala for a presence server for an iOS app. With my naive understanding of both platforms, it was way easier to do this with Node. It would be interesting to hear more detail about how Scala was used and why it was better.

tingletech 15y ago

Node is not for every use case, This tech talk on node is pretty interesting http://sna-projects.com/blog/2011/08/nodejs/ http://sna-projects.com/blog/2011/08/nodejs/ I watched it last weekend, and from what I understood/remember from the talk the reason the node people picked javascript was not because they liked javascript. It was because they wanted to do async programming, and they found other languages had too much synchronous baggage. In javascript, node.js could start from a clean slate and build a pure async culture and environment.

tingletech 15y ago

Kilimanjaro 15y ago

Node solves a problem I don't have in a so convoluted way that if I ever have that kind of problem I won't be using node for sure. Is there a need for webstackers to go play at the server side? YES! but node is not THE solution, it is just ONE solution. I venture to say, as javascript evolves more towards a coffeescript flavor, then a coffeescript flavor on the server is what is needed. And I'll support something along these lines.

bryanh 15y ago

Nonsense. Perhaps your choice to use Node.js is suboptimal? That isn't an indication of Node.js's quality, it's an indication of your inability to choose the right tech. People choose tools that make it easier to do something, Node.js accomplishes that for a wide range of tasks. I just spun up a IM API we needed in an evening thanks to Node.js and community contributed packages. It's humming along great, I even wrote up a piece about it: http://news.ycombinator.com/item?id=3547664 http://news.ycombinator.com/item?id=3547664

chrismealy 15y ago

"The Ruby and Python communities are just now, many years after the hype has faded, learning that stuff like dependency injection and proper modularization are actually good things" WTF?!

crazygringo 15y ago

Programming with Node's async model makes it extremely powerful and fast to run database queries and file functions in parallel, but the downside is the potential for huge callback spaghetti indeed. But the callback spaghetti problem can be largely solved by dropping in, for example, the IcedCoffeeScript fork: http://maxtaco.github.com/coffee-script/ http://maxtaco.github.com/coffee-script/ Or the previous JavaScript TAME functionality: http://tamejs.org/ http://tamejs.org/ There are of course many other async helper solutions as well, and if you're doing serious Node development, it's kind of insane not to use one of these.

MatthewPhillips 15y ago
If you expect a lot of callback it makes more sense to design that functionality as an object rather than as a single function. That way you can spread callbacks over many functionality and still maintain modularity.
- crazygringo 15y ago
  Not necessarily -- the issue is not so much code modularity as much as control-flow issues, which separating out functions (mandatory) doesn't necessarily help with (because of all the flags of what function should call what other function afterwards, etc.).

steele 15y ago

Never take life advice from someone who responds to hype with a compulsion to "punch faces" while donning "rageface". To be fair though, I bet this is just a casual blog entry that the guy didn't know would hit HN. http://meyerweb.com/bkkt/okaythen.gif http://meyerweb.com/bkkt/okaythen.gif

karterk 15y ago

Ok, as someone who has been actually building apps on Node for about 1 year AND working with a largish Scala codebase for the last six months: > Not to mention the fact that its balls-ass slower than some straight un-optimized Scala. I don't see the point of comparison here. Slower/faster is meaningless without the context. Apples to Oranges. And, Scala has it's own issues. Yeah, the JVM's performance is there, but bringing your team onto a Scala codebase is not easy either. > It provides the least amount of aid and comfort to the programmer and its nigh-on-impossible to follow the code 6 months later. Anyone who has developed more than a Hello World in Node will know that the problem of callback sphaghetti can be circumvented using events, promises and async libraries. Yes, until the language itself offers an async construct, this will be an issue, but frankly there are ways to get around it. > JavaScript has very little support for any of those nice things: it doesn't even have namespaces, for chrissakes. Client side JS has no module system. But Node.js has. At this point, I really wonder if the OP has actually worked at all with Node. > It seems to me that people who are really crazy about Node.js are people who only knew JavaScript to begin with and to whom none of the above would ever even occur. Another baseless claim. I urge you to go see the GitHub profiles of Node core committers. Seriously.

rgarcia 15y ago
Nit: Client side JS has no module system. Check out requirejs: http://requirejs.org/ http://requirejs.org/ I've used it to handle both server-side (node) and client-side module systems, and it's been great.
- karterk 15y ago
  Yes, I am aware of requirejs. I was talking about native module support.
  - MatthewPhillips 15y ago
    Native module support is a feature of Harmony and,it's pretty fantastic. I hope Node adopts this method of module loading as an alternative to require in the future. edit: phone keyboard typos

deleted 15y ago

[deleted]

alexchamberlain 15y ago

Glad to see someone has been brave enough to come out against this. I too don't like Node; JavaScript was never designed to take on this sort of load.

funkah 15y ago

Node seems unnecessarily complicated and faddish, but if you really want to mire yourself in callback soup then go ahead. I'll just be over here, not tearing my hear out.

brianshumate 15y ago

The problem I see with all these kinds of negative posts concerning Node.js is that they essentially boil down to "this is so radically different and uncomfortable to me that it cannot possibly be good for anyone else." and do not provide any concrete business examples of why it should be avoided. Until I see an actual example of how "Node.js crashed my business, cost us N dollars, and here's exactly how...", I will continue to look at such posts as developers complaining about having to learn to do things a new way — something that has been going on since there were developers.

antrover 15y ago

It's posts like this that make me embarrassed to be a programmer. The author basically states, "Node.js is not a good fit for my company, therefor everyone using node.js is wasting their time." It's generalizations like this that just blow my mind. I don't go around saying, "Snickers is the worst candybar, therefor anyone who eats a Snickers is wasting their time." I bet the author is not a pleasant person to work with.

IsaacSchlueter 15y ago

This is hilarious.

jessedhillon 15y ago

Here's my problem and why I don't care to use it: It's a community built around an implementation of a language which they do not control. Who is Guido or Matz in node.js? Ryan Dahl I suppose; does he take requests or hold discussions concerning the future evolution of the language? Does he issue any rationale documents concerning his language design philosophy? Could he add multithreading to V8 and if so, why hasn't this happened? It's a community built around someone else's tool, and Google develops it for entirely different reasons. Case in point, someone posted IcedCoffee, which adds an "await" keyword to CoffeeScript -- you have to implement a compiled language on top of Javascript to have the language features you need! Finally, to preempt questions about my being concerned about other people's language choices -- other people are choosing, inexpertly in my opinion, the technologies with with I will contend in the future. Future employers may value and demand experience in node, and future employees may have to be disabused of bad habits accumulated during the learning of it.

chc 15y ago
This comment is just wildly off the mark. You're comparing a framework to a language. DHH can't add features to MRI Ruby any more than Ryan Dahl can add features to V8 JavaScript.
- jessedhillon 15y ago
  Off the mark? Perhaps. Wildly so? Unlikely. But if that's so, then simply view this as an explanation for why I don't use server-side Javascript. And Node is still a tool built around a language implementation which is going in a different direction from where a server side environment/general-purpose language needs to go.
  - chc 15y ago
    You're welcome to use whatever you like, of course — I'm just saying that you haven't really raised any specific objections that couldn't be (and haven't been) leveled against most other languages. Ignoring the confusion of a language and a framework, so far, your concrete objections seem to be: • Node.js is a framework built by people other than the language's core maintainers (which is true of most frameworks) • If you want to add fundamental language features, you can't just force it into the core implementation, but will have to implement your own offshoot (which is true of most languages, including, for example, Clojure) If you're really concerned about other people's language choices, you're going to need concrete reasons, not just generalities, vague insinuations and your own personal preferences. (Edited a bit to clarify and because the original phrasing sounded more combative than I intended.)

didip 15y ago

Everybody is angry if bugs keep punching them in the face. I get that. But this post needs more info to be informative: * If I read correctly, OP is using Chrome/V8 directly. I don't see if the bug list is on V8 itself or his bindings? * "Callback Spaghetti". To each his/her own. I happened to read callbacks easier than other solutions. And this is coming from Python programmer, not JS programmer. * The last 2 points are also information-less rants. What happened to HN?

hello_moto 15y ago

Article like this needs to be sliced-n-diced in different ways: 1) If you don't know technology X and use it due to hype, you deserve to get burned Let that be a lesson for anybody. 2) There's no silver bullet Choosing node.js over web-framework just because you want the front-end and the back-end to use the same code-base is to trade one feature for another: Ruby and Rails still have better tools than Node.js while you get JS all over the place (assuming you're good with JS). 3) Complaining about the language is a sign that you have no clue I used to think that Java is better than some of the hype dynamic languages out there but I was wrong: Java is better for ME because I _KNOW_ Java Better. If I know Ruby more than I know Java then Ruby is better than Java FOR ME. 4) Don't program using another language's idioms This is documented left and right already. If you use technology X, find best-practices for technology X. Don't just apply best-practices from technology Y. http://dirtsimple.org/2004/12/python-is-not-java.html http://dirtsimple.org/2004/12/python-is-not-java.html Or some of the comments here about Dependency Injection (which is quite common in Java but not so in Python/Ruby). In the past, I had one instructor that noticed that my QBasic code looked like Fortran. He asked me if I knew Fortran beforehand and I told him that I've taken Fortran before this class. People see and notice.

skrebbel 15y ago

I love articles like this. All the dry analyses, the subtle counter-counter-arguments, that the usual tech opinion articles on HN have make me nuts. The little layer of emotion and drama added here gets the point across much better, IMHO. Of course it doesn't do anything but preaching to the choir (hi there), and not convincing anyone not already in the choir, but it's a great read! (and so is this thread). In other news, if you're voluntarily using a dynamically typed language and an editor without an integrated debugger, you're not fit for programming!

jconley 15y ago

Node enforces a programming model that puts you down the path to extreme vertical scalability, you know, actually using all the hardware you are paying for. CPUs and the kernels that manage them are good at running code. They suck at waiting for things to happen. Out of the box the callback model can be difficult to wrap your head around. But if you are serious about writing a vertically scalable IO-bound service, it is currently the only option. There are some add-ons to make the code less ugly, but you still have to have the mental model down. It's a lot like multi-threaded programming, or functional programming. It's a matter being able to visualize the flow and pass context around. This takes time to change the way you think. If you approach problems in Node like you'd approach a problem in a functional language the spaghetti of callbacks becomes much less of a burden. For the async haters out there operating at scale. How many of you have farms of machines with idle CPU's, maxed out memory, and practically idle network interfaces? Yeah, I thought so.

Lazare 15y ago

Okay, let's play a little game. I'm going to describe a scenario (using Python; feel free to substitute the equivalent Ruby terms if that makes it more relevant for you). You're a pretty good Python developer. You know, and feel comfortable with, not just Python, but the entire ecosystem. Virtualenv, pip, the whole nine yards. And now you're working on a really nifty Django app, maybe a CRM or something, when you realize... ...damn. This app really needs a lot of functionality ripped out and shoved in the browser. I'm losing my marbles writing spaghetti jQuery code, but what I really need is some client side templates. So you poke at it, and think about it, and you realize that the proper design of your app is really a bunch of client-side code using Backbone, and a server that just handles authentication and is otherwise a thin RESTful wrapper around your database. Great! But at this point, most of the actual code you will be writing is Javascript. Your server could be written in, practically, anything. And there's some compelling reasons to leave it in Python. On the other hand, if you switch to node.js it means all your code is in the same language (which is nice). It also opens the door to being able to use the same code on both the client and the server - which is really good. Client-side templates are nice, but being able to render them on the server when you need to is practically a requirement. And Python's support for rendering Javascript templates is very limited. And if you're a Python coder, you'll probably want to be writing your client in CoffeeScript anyhow, which requires having node.js installed, so, at least for development, just have the whole damn stack in node.js. You can always hack together a little RESTful server in Python later if you decide that node.js isn't right for production. Seems simple enough, right? And as you can probably guess, I just went through this process. And so now we have this blogpost, which is saying...well, it's not really clear what it's saying. That I should be using Scala, I guess. This is, frankly, so wrong it's embarrassing. 1) Even if the JVM was just so amazing and awesome, I'm not a JVM developer. The ecosystem is radically different. As a Python developer, I'm able to install, configure, and be productive with node.js very quickly. npm, nvm, coffeescript, and we're away. My IDE of choice (PyCharm) even supports CoffeeScript. There is very low impedence. Switching to Scala...where would I even begin? 2) I'm doing this because I need to write a client side app. That must be written in Javascript, or something that compiles to Javascript. Scala is neither. And while there are JVM language that do, there are some major concerns with their suitability, maturity, and tooling. Clojurescript looks great, but it's not something you pick because you think coffeescript is too new and little used! 3) The rant would be more compelling if the author came across as someone who actually knew anything about Python, Javascript, or node.js. Contrary to his assertions: Javascript does have namespaces. Python and Python developers have ALWAYS been convinced that modularity is good. And Python developers are still quite aware that dependency injection is a way to solve problems with the design of Java which aren't even relevant to their language of choice. 4) Also, if you don't grok callbacks, it doesn't mean you are a bad programmer. But it might be worth keeping in mind that there are plenty of programmers who do, and they're going to laugh at you when you reveal you don't. Not to mention that there are plenty of ways of programming in node.js WITHOUT callback spaghetti, and revealing that you have no clue about the framework your slagging is not going to improve your credibility. 5) To continue the theme, insulting a framework for not scaling well may work better if you don't reveal that you don't know how it scales in the same paragraph.

mnot 15y ago

Wow, seriously? This is just as bad as the fanboy "you'll use X for EVERYTHING!" posts. Please.

gumbo 15y ago

Please give me a break. This guy made some points: spaghetti code, .... He state it in the wrong way, however one should admit that node.js is not mature enougth for many use cases. I'm still learning but, haven't seen how just by using node.js you get a scalable server.