Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So very much this.

I never really learnt Rails, to be honest. I dabbled, but never got fully into it. The thing is, the way I'm writing web apps now (nice API's over straight classes, composable libraries, and a routing layer over the top to give it a REST interface) doesn't fit my mental model of how Rails works.

Similarly, I've somewhat abandoned "MVC" for web-apps. Nice API's with the ability to have any front-end, not kicking out HTML from my framework, and the like -- that's what I'm doing now.

Don't get me wrong -- I know that Rails (especially 4) can do all this as well. Heck, there's not much stopping me from doing what I'm doing here with straight Ruby, a couple of libraries and Sinatra (I have a good friend who does exactly that). But for some reason, I've instead written off ruby entirely for that use-case.

I'm merely the n=1 here though, and as a non-ruby programmer, my opinion doesn't mean much I guess. But I find it curious how I ended up skipping it.



Interesting, as that's very much how my mental model of how Rails works:

1. The routing layer is all about declaring a resource which gives you all 7 major REST operations, and

2. there's a nice facility for responding_to any data format (html, json, js, text, etc) you want.

With rails scaffolding, you can pretty much get all boilerplate code written for you, and have it very simply implement a REST backend for a more "heavyweight" javascript framework (angular, ember, etc).

I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?

I think the article gets it right in that Ruby needs better concurrency primitives (promises are a nice idea), and esp better performance. If Javascript can be as fast as it is with V8, there should be nothing stopping Ruby from achieving similar levels of performance.


I think its not an issue of anyone thinking that rails can't do those things. Its just that there are other things out there that are not as thick, which can also do restful routing. Unless you're already entrenched in Rails, there isn't much benefit to using it over sinatra or express, which allow you to modularize the other components that you need, while also having a lower barrier to entry.

I don't think many Rails developers are abandoning the platform though, so dying probably isn't the right word for it.


> I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?

I don't think I got it across in my post correctly, but that's basically what I was trying to say, yeah! I even _know_ that I have that cognitive bias, and yet it remains. I even tried to pick up Rails 4 last week, and put it back down rather quickly again.


As someone who programs when the urge hits, rather than as a day job, I ended up playing catch up with Rails. Each time I went to start a project, there's be some new changes/features in Rails for me to learn.

These days, I'm happy coding away in Padrino, which seems to sit between Sinatra and Rails in terms of features and functionality.

For me, Rails just became too big to keep up with. It's more fun and productive with a lighter-weight framework that can get you 90% of the way there. For a newcomer to Ruby, it doesn't seem to be the old "watch me write a blog engine in 5 minutes!" anymore. That might be why the other popular frameworks are getting the attention...


So what do you use for the front-end? How is it communicating with your API?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: