Hacker News new | past | comments | ask | show | jobs | submit login

I don't know about its popularity, but from what I've seen it doesn't seem to be on the hype train anymore. No technology stays on the hype train forever. Of course this is just based on observing trends, it shouldn't dampen your enthusiasm if you've found something that works for you.



Rails still solves all the problems it solved last year or two years ago. I'm always astonished when teams give into the hype train and replace the two things Rails excels at, templating and database access, with a 10MB frontend JS blob and microservices running in a JVM language.

Just use Rails, it scales just fine. Your hand-coded DB layer for your microservice will never be as good as ActiveRecord if you aren't Facebook.


Why do you say that Rails excels at templating? Ignoring for the moment the obvious differences between server-rendered HTML and JS frontends, the Rails templating doesn't strike me as one of the most prominent solutions Rails provides. The templating is fine, but other than a few niceties (like layout hierarchies and resource-based forms) it's not much more than a thin syntax to embed Ruby eval inside HTML.

If I had to pick the top things that Rails excels at, I'd point to ActiveModel and resourceful routing. I know REST isn't the hotness any more, but it sure is great for CRUD web sites or APIs, and Rails makes setting up database models, associations, and REST routes a breeze.


I also don't think Rails templating is anything special but it's well designed.

One strong point is that it's full Ruby, so there is no need to learn another language. This means that one could write the application in the views (just like vanilla PHP) but in my experience nobody does it.

Another nice feature is that every instance variable of the controller is available in the view. No need to waste time to declare them and get an extra chance to add some bug (I'm looking at you, Django.) I still remember how good it felt coming from Java Struts in 2005.


I'd go so far as to not only agree with your assertions of the best points of Rails, but to also extend your skepticism of the excellence of Rails' templating to calling that the worst part of Rails. Of course, one can use Rails as an API only service and it's quite adept at that.


I don't know if I would call Rails templating excellent, but it is acceptable. The nature of HTML allows for quite a lot of flexibility. However, I have to disagree with your view of Rails in API usage. Maintaining a client contract for fields and value types is far more difficult in Rails, at least out of the box, than similar offerings.

If you send the wrong HTML tag, the content just might look a little funny to the end user. If you send the wrong datatype to an API client, it generally won't be able to do anything with it, and may not fail gracefully at that. Constructs to ensure you cannot make that mistake are invaluable in API design.


It's a bit late for this reply, but check out [shameless plug] the ClassyHash gem.


>"Just use Rails"

I wasn't looking for advice about web frameworks, but since you offered it, do you believe developers using other web frameworks are misguided in doing so? It's not like Rails is the only game in town, comparable solutions exist.


I'm talking about teams that use Rails as router, microservices as ORM, and a heavyweight React behemoth on the front, just for simple CRUD. Those projects would almost always be better off using straight Rails.




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

Search: