My new/current job is 100% JavaScript and I have been thinking to choose NodeJS and either React/EmberJS/AngularJS for my newbside project (a typical CRUD app) that I will have to maintain for a very long time. I almost chose Sails because Express is too low level/too simple.
Lately I've been reconsidering my options ever since there were a few HN posts related to my choice of stack that seem to conflict with my requirements: side project (meaning little effort) and long term maintenance (meaning stability, documentation should still exist for perhaps prior versions, relevant articles, examples from the Internet). Real time isn't a requirement, REST API isn't a requirements (yet), so I guess that minimize the need of NodeJS. I also haven't found a good case/example of code sharing between client and server side neither I heard people reaping tons of benefit from the principle since most front end framework forces the user to subscribe to their model/paradigm that may not work well with the back end code.
I quickly realized that perhaps Rails or the good old Java (with SpringMVC) seem to satisfy the requirement.
It's built on top of express.js and offers some of the more "Railsy" features that express lacks. Also supports this idea of shared models between the client and server (going for that whole code reuse thing you're talking about).
The company was also bought by IBM so I'm feeling pretty confident that it's going to keep getting regular updates and long-term support. They offer a bunch of enterprise-type features for the paid version, but the free one will be enough for your needs.
For me, it's personal preference. Node.js is used and loved by many, but to me it's just an asynchronous event loop running on a single threaded process with a JavaScript API. I've written performant Node.js code and maybe for smaller web services it's great. But for a backend server, I worry about human error in large, evolving projects (especially when it comes time to scale).
Other issues faced by myself and colleagues more experienced than me include callback hell, race conditions, NPM errors and debugging code (in hindsight, something like node-inspector would have come in handy [1]).
Why Elixir? Well, for me OTP makes writing async code much easier. Message passing between GenServers or other processes is effortless. Fault-tolerance is built into the platform, as processes can be supervised and respawned when they die. It is based on Erlang, released 30 years ago and used by many large companies and projects [2]. Also, writing it makes me genuinely happy. :)
I would consider Ruby mostly because I've had my hands in Rails apps and can make my way around them. I've also been blown away by many brilliant people I've met and worked with in the Ruby community.
I'm with you on this one (except the Elixir part, never tried, can't comment).
Many past NodeJS stories/use-cases from the big name companies like LinkedIN, eBay, Wal-mart seemed to use NodeJS as a front-end server. The back-end code is still something else (or perhaps even legacy code). I know someone who works for another big name company that uses NodeJS for their new project doing exactly this as well: a front-end server that communicates with multiple/many services behind the scenes. Those services are written in Java/C#/C++.
Meanwhile, a few other NodeJS based commercial apps (e.g. Trello) does not look too complicated when they begin the project...
Lately I've been reconsidering my options ever since there were a few HN posts related to my choice of stack that seem to conflict with my requirements: side project (meaning little effort) and long term maintenance (meaning stability, documentation should still exist for perhaps prior versions, relevant articles, examples from the Internet). Real time isn't a requirement, REST API isn't a requirements (yet), so I guess that minimize the need of NodeJS. I also haven't found a good case/example of code sharing between client and server side neither I heard people reaping tons of benefit from the principle since most front end framework forces the user to subscribe to their model/paradigm that may not work well with the back end code.
I quickly realized that perhaps Rails or the good old Java (with SpringMVC) seem to satisfy the requirement.