[hkarthik]

Basecamp and Harvest were both written in Rails. For standing up simple SaaS, Rails is a great choice.

However, for a complex SaaS (any SaaS can get here really), you will need to make some sane choices around modularity and building separate, loosely coupled services before things get out of hand. Node.js (or any of its lightweight frameworks on top) is probably a little stronger than Rails in this regard.

This service-based approach is more difficult with Rails as the community hasn't blessed any consistent conventions around doing it. Any custom convention you create to integrate multiple Rails applications will likely break compatibility with future Rails framework upgrades. There are many companies that are paralyzed and stuck on older versions of Rails because they ran into this problem.

All that being said, Java is still a great choice if you make some modern choices and will help you move forward without being slowed down by learning a new framework. Check out the Modern Java Series here: http://blog.paralleluniverse.co/2014/05/01/modern-java/

[digitalzombie]

... you can just architecture it to be SOA or with tons of microservices.

I think Node.js is hype right now and you'll be betting on a technology that may or may not have a good market share.

RoR is better and have tons of documentations and blogs.

Node.js right now just got forked. Javascript isn't a particular pretty language compare to Python or Ruby. Loosely type and dynamic makes it kinda bad.

I have yet to see any body mastered Javascript as a language and Javascript 6 or ECMA or whatever is coming out. So there is even more stuff to learn. The dev pools for javascript for backend is sparse and their language mastery, from my experiences, for javascript is very low. With that in mind hey you didn't learn prototype OOP yet but guess what we're going to add more to the language and hope that those dev catch up to all of the changes?

yeah... That's a con to be at least. And also Ruby while they're changing with every version it's small iteration, most of the stuff is mostly in place.

Javascript is missing a few construct to build large code base, namely module which they will have a standard soon, and going to add promise construct cause node.js callback hell is bleh. So the language wasn't multi purpose in mind so it's playing catchup.

You can argue that you can do anything with a turing complete language. Sure you can, but how easy it is should be a factor.

Erlang got primitives for spawning process and such. It makes it damn easy.

Javascript got little construct for building large code base. THere are tons of libraries to fix this but still.

I think Node.js ss better as a middleware technology and even then Go would be a better choice with better toolings.

[rubiquity]

> However, for a complex SaaS (any SaaS can get here really), you will need to make some sane choices around modularity and building separate, loosely coupled services before things get out of hand. Node.js (or any of its lightweight frameworks on top) is probably a little stronger than Rails in this regard.

Huh? This is a load of crap. Frameworks, and even languages, have nothing to do with modularity and building services. You can do this in any language and any framework. Modularity and loose coupling are decided by the developer(s) writing the code and if you think a particular tool will solve this for you then you have a grave future.

[bnb]

I don't think it's right for you to call what he said crap without backing it up with any evidence. Node.js is essentially the modern poster child of modularity. JavaScript doesn't have inherent modularity--but the devs of Node have made some choices that make it possible to have an extensive module ecosystem for Node. npm is probably one of the best package managers for development right now, as it comes with one of the most popular platforms and is inherently flexible.

[rubiquity]

Package managers have nothing to do with modularity. You're confusing modules, a thing, with modularity, a property. How you write and design your systems is how you get (and don't get) modularity, not by having a service you upload and download packaged code to.

Again, modularity has nothing to do with the quality of your package manager.

[hkarthik]

> Frameworks, and even languages, have nothing to do with modularity and building services.

I respectfully disagree with this statement. Many frameworks actively encourage a monolithic architecture through conventions, all to increase productivity during the initial construction phase of a project. If you're sprinting to launch a project, modularity and loose coupling matter a lot less than sheer productivity to churn out as many features as quickly as possible. Rails was designed with this mindset and it excels in it more than any other framework out there.

Refactoring to modularity and loose coupling down the road after choosing something like Rails is non-trivial, especially when compared to the rapid pace the development team enjoys in the early stages of using the framework. So one needs to be aware of that before diving in.

Other lightweight tools like Node.js front load the cost of modularity by forcing you to design on your own conventions early on. If you know the product is likely going to get complex very quickly, it maybe worth taking on the front-loaded cost of these tools.