Live data from Hacker News

Ask HN: What do you want to see in Rails 4.1?

news.ycombinator.com

61–70 of 94 posts

Re: Ask HN: What do you want to see in Rails 4.1?

#61
One of the things I've struggled with on large Rails projects is helping developers understand that they can and should write code is neither model, view, controller, helper or lib. Instead a model ends up with a ton of class methods that are only somewhat related to fetching and storing records. A controller ends up with some crazy query that joins three tables and generates statistics. I would like to see some guidance from Rails on how and where to put these types of things. When I advocate for a service object, I get asked what the parent class would be and where the code would live. Saying no parent class and app/service_objects gets me some questionable looks like I'm not doing it right. Opinionated frameworks are great but I feel like people assume a lack of opinion to mean don't do it.

I'm not sure what concrete steps rails can take, but maybe app/lib for application specific code and lib/ for more generic libraries. Or maybe something less confusing.

Re: Ask HN: What do you want to see in Rails 4.1?

#62

I'm not a Rails developer, I have only done some simple webapps with it, so I have a question. Does Rails support websockets natively? If not then why? I haven't seen any request for integrating them in this thread.

Rails does not have built-in support for WebSockets, though there are gems.

The simplest answer is 'because nobody has written a pull request,' I don't believe anyone on the team actually uses websockets for anything, though I could be wrong.

Re: Ask HN: What do you want to see in Rails 4.1?

#63
post #59

Perhaps this HTML/JS/URI/XML/HREF escaping C extension speedup by GitHub: https://github.com/blog/1475-escape-velocity (Improved render time by 20% in their tests)

We don't currently have any C extensions distributed with Rails proper for maximum portability. For example, if this were included by default, Rails would no longer work on JRuby, and a _lot_ of people use Rails with JRuby.

Re: Ask HN: What do you want to see in Rails 4.1?

#64

Thanks for asking! Are queues ready for prime-time yet? Another vote for async mailers please - also sending more than one mail at once would be nice. Sorting out secret_token.rb would be good - not sure what would work, ENV variable, auto-generating a file in production if not there, but there must be a better solution which lets you work both on Heroku and let's people avoid having secrets stored in version control…

Queues are not ready yet, but it's something that's being worked on. Of course, async mailers are tied up in that as well. The secret_token issue is one I'm personally interested in, we've been talking about the best way to fix it. Yeah, we already have has_secure_password, which helps with authentication, but you still end up adding gems for authorization. I'll give this some thought, thanks.

Rather than a gem for both, what I'd personally prefer is generators, because it makes all the code explicit - I always end up customising them to some extent (particularly devise, usually I use their generator then customise), and it'd be nice to expose things like the mailers that devise sets up for password reset etc (again something almost every app requires). Will be interested to see what the Rails team comes up with though.

Re: Ask HN: What do you want to see in Rails 4.1?

#65

One of the things I've struggled with on large Rails projects is helping developers understand that they can and should write code is neither model, view, controller, helper or lib. Instead a model ends up with a ton of class methods that are only somewhat related to fetching and storing records. A controller ends up with some crazy query that joins three tables and generates statistics. I would like to see some guid…

With 4.0 we included app/concerns, so that should help open up your conversations a bit.

Re: Ask HN: What do you want to see in Rails 4.1?

#66

Thanks for asking! Are queues ready for prime-time yet? Another vote for async mailers please - also sending more than one mail at once would be nice. Sorting out secret_token.rb would be good - not sure what would work, ENV variable, auto-generating a file in production if not there, but there must be a better solution which lets you work both on Heroku and let's people avoid having secrets stored in version control…

I concur that something needs to happen on queues/background jobs. Right now I've always gotta go setup Resque/Redis to make basic background stuff happen and keep the app snappy. Its not a huge pain, but it seems best-practice for lots of types of tasks.

Re: Ask HN: What do you want to see in Rails 4.1?

#67
I haven't used Rails 4.0 much yet, but I know that I really dislike the default HTML generated with the Rails 3.2 scaffolding generators. The markup is kinda ugly, too verbose and the use of form_for just bothers me. I always use simple_form myself and form_for just feels old and like a bad default.

Re: Ask HN: What do you want to see in Rails 4.1?

#69

One of the things I've struggled with on large Rails projects is helping developers understand that they can and should write code is neither model, view, controller, helper or lib. Instead a model ends up with a ton of class methods that are only somewhat related to fetching and storing records. A controller ends up with some crazy query that joins three tables and generates statistics. I would like to see some guid…

With 4.0 we included app/concerns, so that should help open up your conversations a bit.

Concerns are just geography, they do nothing to encourage single responsibility or domain design.

[edit: rereading the parent, your reply was to where to put the code, and app/concerns is as good a place as any I guess, but I stand by the idea that concerns themselves are a bad idea.]

Re: Ask HN: What do you want to see in Rails 4.1?

#70

Earlier quoted context omitted.

With 4.0 we included app/concerns, so that should help open up your conversations a bit.

Concerns are just geography, they do nothing to encourage single responsibility or domain design. [edit: rereading the parent, your reply was to where to put the code, and app/concerns is as good a place as any I guess, but I stand by the idea that concerns themselves are a bad idea.]

I have publicly blogged about my dislike of them as well. But they do at least demonstrate there's more to an app than MVC, and that those directories go in app.
Post reply on HN