3 ms·
Startups usually try on a bunch of use-cases (features, ideas, workflows) before they gain traction or die. Your saying that startups should know all the use-ca
by dk8996 10y ago
Startups usually try on a bunch of use-cases (features, ideas, workflows) before they gain traction or die. Your saying that startups should know all the use-cases they plan on building before they even start -- that simply impossible. Maybe your point is that startups shouldn't use Rails and its more suited for dev projects with a clear spec.
- danenania 10y agoNot really. Rails is good for quickly hacking things together across a very wide range of the domains that startups usually play in, which makes it as good as anything out there when upfront productivity is the priority and you have rapidly evolving specs. The only really common startup use case it's decidedly bad at is realtime/sockets/streaming data, where Node takes its place as the hack-it-together tool of choice--at a significant productivity penalty compared to Rails. It's also, of course, pretty bad at all kinds of tasks unrelated to web development or REST apis. You wouldn't want to write machine learning algorithms or do statistical analysis in Rails, just like you wouldn't want to do 3d game development in Rails. And while you do occasionally see startups who have bolted some heavy data processing or pseudo-ML monstrosity onto their Rails apps, I've never seen anyone in the Rails community claim that was a good idea. The vanilla recommendation there is to keep your main server stack in Rails and then write services in something more appropriate for those needs.