It's not so much about "trusting" node (I trust it as much as min(how much I trust my browser, how much I trust some pretty switched-on hackers wrapping my browser's engine), which is quite a lot) as about understanding where node is stronger or weaker than the alternatives.
For anything webby it's fantastic. This is where node.js shines. Frameworks like *connect* and the higher-level *express* make it a joy to write the server side of web apps. (I rarely use express because there are so many great connect modules.) Mix in plates <https://github.com/flatiron/plates> for server-side CSS-based templating and you're off and running. If you like building apps by composing small modules that do one thing well, node.js is a winner there. In that regard it feels like it really captures the Unix philosophy <http://www.faqs.org/docs/artu/ch01s06.html>. However, as Mikeal and others are warning, node still very young and evolving rapidly so good practise this week can easily become "how we used to do it" the following week. I'm looking after an app we wrote about a year ago (circa node 0.2.x) that needed, well, quite a lot of love recently to bring it up to date. Having said that it's been rock solid in production for that year, which shows it was a good technology choice even then! One thing I'm noticing is that it seems to be evolving towards make-things-easier rather than include-the-kitchen-sink, which I hope continues, otherwise we'll just end up with the next Spring/Rails/J2EE monster. I also spend most of my time coding the solution to the problem I'm working on rather than fighting with the runtime infrastructure, which mostly seems to Just Work. Where it *isn't* a good fit yet is more about integration. Other technologies, in particular Python, Ruby and Perl, have great support for database integration for instance. Node's is coming along but I wouldn't do a hardcore SQL Server integration with it yet. (Although I might front the SQL Server database with a CRUD-over-HTTP endpoint and use that.) As another example a year ago there was precious little LDAP integration. In that time ldapjs <http://ldapjs.org/> has become robust enough for production use. Likewise IMAP integration was pretty patchy - I had to hack support on for Exchange-style headers - but it's getting there. So you need to be prepared to get your hands dirty if you are one of the early adopters of a particular protocol. The scare stories about a single heavy calculation pinning the VM don't really materialise in my experience. People just don't write node apps like that. If you're constrained by the amount of heavy machine calculations you can do, JavaScript is a pretty poor choice in the first place. You'd be better off with a mathematical or scientific vector language (one of the APL derivatives like Q). So I would say, in the first instance think about the integration points for your app, and check on the level of maturity for node integration with those. And in the second instance, decide how comfortable you are with a dynamic language like JavaScript with all its quirks, which has decent IDE support (the IntelliJ IDEs like PyCharm and WebStorm) and editor support in vim, emacs and textmate, but not nearly as powerful refactoring tooling as static languages like Java or C#. Pick a small-ish piece of work that seems to fit the node.js model and see how you get on. The folks on this list will be happy to help. Cheers, Dan On 5 March 2012 20:24, Baz <[email protected]> wrote: > I haven't used node yet, but am planning to. A question was asked in > another thread, along with many other great questions, that got lost in the > shuffle. I'd be really interested in hearing people's opinions on it. To > quote Luke: > > What kind of applications would you not trust on Node.js? Should someone > like Amazon trust Node to power their shopping cart knowing that having the > one thread fail could prematurely cut off thousands of in-progress > transactions? I'm sure Node.js isn't intended to be the "fit all" solution > for everything. But are there things you would say "you should never use > Node for X, but it would be great for Y"? > > Best, > Baz > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
