Here’s my list of why I’m moving everything to Node.js that I run.
- Between the enhancements Google gave to JavaScript and the ease of use in writing with the language, it provides the least resistance of any framework and language stack out there.
- Node.js + Express.js or Bricks.js + Jade + Every DB Choice on Earth really is a convincing reason too.
- The developer community, if it isn’t now, is ridiculously close to the biggest development community on Earth. The JavaScript community goes into every corner of development too and crosses over easily into Ruby on Rails, .NET, and Java. Nobody is left untouched by JavaScript. This provides more avenues of joining up for projects than any other platform in existence.
- Hiring for startups, mid- or enterprise business to build node.js and Javascript apps is 10x easier than hiring for anyone else right now. Which still makes it almost impossible. But that means it is “almost impossible” vs. “impossible” as it is with the other stacks!
- Node.js is fast enough, and easy enough to distribute and less resource intensive than almost anything on the market. All that and it requires almost nothing to configure and setup compared to Apache, IIS, and a bunch of those other solutions.
- The PaaS Solutions out there, thanks in large part to Nodejitsu, Nodester, and even the Windows Azure Node.js team have made deploying Node.js apps the easiest stack to deploy around – hands down – no contest.
- Node.js uses JavaScript (if you haven’t noticed) and most of the NoSQL solutions already speak the common language, JSON or BSON which makes layering more transparent in your architectures.
- I could go on… but you get the idea. Node.js + JavaScript makes life EASIER and gives me more time to do other things. Other stacks typically have me tweaking and tinkering (which I do find fun) for hours more at a time per project than a Node.js Project. Generally though, I like to get a beer at some point, and Node.js get me there earlier!
Sure, I’m sticking to being polyglot. I’m even headed to the Polyglot Conference in Vancouver BC this evening. But nothing is as approachable as Node.js + JavaScript. Looking forward to a lot of PaaS discussion around Node.js and getting interoperability against .NET, Java, Rails and other frameworks.
So expect to see a lot more Node.js and JavaScript bits on the blog! 🙂 Cheers!
(Cross-posted @ Composite Code)
My (albeit limited) experience with it has been somewhat different:
– “Every DB Choice” – try using SQL Server – 🙂 – I’ve spoken with the author of a plugin but the project is dormant now and I have yet to find a solution for this
– Debugging is still VERY difficult – it is hard to know why problems are occurring when there are no good IDE’s available for debugging your “new framework” code
– The resumes I see coming in weekly have less experience with Node.js than with other “more traditional” stacks
– I find that it takes a “new mindset” to work in this type of environment, as opposed to what I have been doing previously, so that’s a curve to be navigated
I agree with your other positive points though, but with any new technology, I always find there are trade-offs either way.
SQL Server… yeah, that one is an issue. Here’s my simple fix. Wrap it with Web API Services, do simple CRUD on it and, or manage it however you’d like. If you have to have SQL Server might as well do this. Personally I’ve generally tossed SQL Server since Postgresql, Mysql, etc have all proven to be just as good or better.
Then of course the other crux is, I’ve been primarily in a lot of the newer databases that are superior for prototyping and large data subsets used for business intelligence. This alleviates (actually requires in some situations) not using something like SQL Server.
I’d love to hear what others are doing to wrap or fix this parity mismatch with SQL Server and RDBMSes in general. I’ve spent years dealing with RDBMSes only to finally use them in rare occasions and other systems (Document, Object, Graph, etc) much more frequently now.
Debugging does require a strong BDD/TDD Approach to keep it under control. Traditional methods of hack code and throw it over the wall are horrible with these types of languages. Discipline is the key, otherwise things get real nasty. If you need some awesome debugging though, check out WebStorm. It’s got some pretty cool capabilities and provides an easier way for non-BDDers/TDDers to step into JavaScript Development without as much debugging pain. 🙂
Resumes. I tend to hire directly from my network, resumes are a dirge and not very effective. I’d highly advise, if it is possible, to drop the traditional resume and resume + recruiter hiring practice. Grow the network, hire from the network. I promise better candidates and vastly greater returns!
New mindset? Of course. JavaScript first off is naturally asynchronous, it is inherently a “web language” in that regard. Many others are not. The mindset is more natural to the system in which the web works. It is, indeed a “new mindset” for many, but for those just getting into the industry and they’ve only known web dev, it appears obvious to them many times. Where as the more static, synchronous languages are a broken mindset. So really it all depends on the approach and where you’re at in development.
I started with C++ and Pascal (in years I won’t mention), so getting all the way to Node.js and getting comfortable with JavaScript hasn’t been the easiest ride, but it is absolutely worth it!
Thanks for reading and commenting Kevin!
…and I do agree, there are always trade-offs. Overall though, for my personal and many of my professional apps and development efforts, Node.js just gets me to the taproom sooner than most other development stacks. 🙂
I usually for server-side developing use erlang.
Unfortunately, I see very, very few web developers around that manage to use JS in an object-oriented and elegant way – most still use just global JS functions and global variables, and never heard of namespaces or how to define an object in JS, most don’t know that there are debuggers for JavaScript, or if there are or not refactoring tools for JavaScript.
Tudor -> I see this too, however I rarely see much effective or elegant use of patterns or OOP in most shops anyway. Especially in enterprises. There is an extensive amount of hack and slash “get it done at all costs” type of development that is done. Which of course ends up costing an inordinate amount of money and general damage to the industry. Just because JavaScript has X abilities doesn’t mean anything more than people will mess it up just like they do so many other languages.
At any cost… I’m OOPing it well, and determining best practices as I go. So not everybody is just hacking and slashing their projects to completion. 😉
Adron,
I agree with you mostly (sorry Kevin :-)). However, i would like to highlight the sudden jump in the complexity for Node.js applications primarily due to the async nature. It is as easy as dropping a pencil to get a server running, but throw in mongo/ db, and little complex collections, you are in for steep curve!
Having said that, I would ditch MVC3 or any older stacks completely for Node.js.
Yup. My exact sentiments.