5 ms·

The problem with node is it decreases your productivity tremendously. The most important thing about the choice of programming tools is productivity. Node.JS d

• karterk 15y ago
  You may see some very nice libraries/tools coming out around node.js, like jade, coffeescript, and stylus. These are all nice and good, and they do increase your productivity, but, only on the client side. I disagree. Firstly, CoffeScript is not confined to the client-side. Besides, there are some modules like socket.io for which you will hardly find any substitues in other eco-systems. You're also discounting the effects of context shifts between two separate languages - one on the client side, and the other on the server side. Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.
  • hasenj 15y ago
    The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write. I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires. > Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node. Not having to write everything asynchronously? I haven't actually used go, but the way goroutines communicate (and synchronize) with channels suggests to me (from what I've read/seen) that this callback spaghetti problem is non-existent in Go.
    • guelo 15y ago
      It cracks me up that you haven't tried Go but you're still recommending it, is there a web framework? Edit: Found web.go. Screw it it's a long weekend, I'll give learning Go a go.
      • hasenj 15y ago
        I haven't had a pressing need for using it, and I'm considering it as something I want to learn on the side for now. As for frameworks, it seems the http package comes builtin with a server and a url router. Also, Google's AppEngine supports Go.
      • chrisbroadfoot 15y ago
        You don't really need a web framework with go. net/http is just fine for most use cases.
      • Jare 15y ago
        web.go is still not compliant with the recently released Go1. I'd recommend anyone interested in Go but not in a hurry to wait a month or two until the Go1 dust settles.
    • bobz 15y ago
      > I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires. This is a sign of a not-fully-adopted paradigm shift. Like, when someone first learns a new (spoken) language, they translate it to their native language in their head. Fluent speakers don't translate, they simply understand. Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural. That said, it does take some getting used to, which is a real cost that needs to be considered when choosing Node.
      • irtopiste 15y ago
        > Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural. A minor remark from my experience with functional programming, continuation-passing style is actually something I prefer to avoid.
  • Animus7 15y ago
    > The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write. I know exactly what you mean, because that's what I thought a year ago. I was going on and on about this to everyone. Mea culpa. Then I actually tried node and learned the functional side of JavaScript (I don't mean the semantics, which are very simple; I mean powerful LISPish design patterns). Now I don't think about callbacks anymore, because I have a functional toolkit that mostly hides them. You say asynchronous coding makes simple algorithms annoying to write. So let's have an example. Read two files -- in parallel -- trap I/O errors and warn about them, otherwise merge and sort the files by line, write the result to a third file, and warn about I/O errors there as well. Simple enough? My solution is 8 lines, formatted. It was very pleasant to write. fork( ['lines.txt', 'lines2.txt'].map(function(name) { return fs.readFile.bind(fs, name); }), check(console.warn.bind(console), function(a) { fs.writeFile('linesOut.txt', a.sum().split('\n').sort().join('\n'), check(console.warn.bind(console))); }) ) If you've seen enough JS to deduce what the lib definitions for fork() and check() might be, then this code will seem obvious -- almost trivial. Otherwise, you will probably claim shenanigans or 'spaghetti' because it doesn't look like insert favorite programming language/framework here. So it saddens me to hear people whining about this aspect of node -- partly because it recalls my own naivety, and partly because I know from experience that they're missing out on something great.
    • ericflo 15y ago
      So your point is that it's hard until you spend a year working with callback-based JavaScript, and then it becomes easy and intuitive? A year of investment may as well be an eternity for most.
      • downx3 15y ago
        That's good to know though. As it's pretty easy to waste a year learning framework X.
      • karterk 15y ago
        To be fair, the OP did not exactly say that it took 1 year to learn it. I personally took less than a few days. Every framework has a learning curve.
• mcav 15y ago
  Red herring. Node can increase productivity as well. It's all about your requirements and workflow.
• pepve 15y ago
  > The problem with node is it decreases your productivity tremendously. People say this over and over, complaining about nested callbacks and what not. I can tell you from experience that it is not true. I've been working on a Node application for a few weeks now. It is our first server side Javascript endeavour as a company, I had only tinkered with it in my own time before this. And the experience is pretty good. Writing in a more functional style makes me more productive and makes quite some problems more straightforward to describe (implement).
• Peaker 15y ago
  Or Haskell, Erlang or various other languages that have better solutions for non-blocking I/O.
  • trimbo 15y ago
    Or C, C++, Java, Python or Ruby. Every language has solutions for non-blocking I/O, even the boring ones.
    • Peaker 15y ago
      C doesn't have a good solution for non-blocking IO. Managing callbacks and their lexical scopes manually is quite painstaking. User-level threads are non-standard, and ordinary threads are too heavy. All forms of threads lose much of C's benefit due to the relatively heavy stack allocation per thread.
• ryan_f 15y ago
  I very much agree on the drop in productivity. I was just contracted to help with a Node project and just getting up to speed has been difficult. This is not all node's fault since the callbacks and such could have been handled differently. The better examples will be in a few years when programmers have more experience with Node and the projects' code reflect that. I won't be returning back to Node after the project though because it reminds me of earlier days writing XML with Spring.
• VeejayRampay 15y ago
  If "This is a revolution" hadn't been patented by Apple years ago, I'd be using it right now. Hell, Node invented / brought us: - The Reactor Pattern, a never-been-before paradigm. - V8 and its mind-blowing speed. - Evented I/O, a game changer. - It also allows you to program all that with the best language known to man, Javascript, ON - THE - EFFIN - SERVER (zomg). Hats off to the Node community though, they're getting good at emulating Rails' PR tactics of buzzwords, fluff and overblown hype.