Ask HN: What do you want to see in Rails 4.1?
62 points| steveklabnik | 12 years ago | reply
What can Rails add or change that will help your startup be even more great? How can we make Rails development more productive?
62 points| steveklabnik | 12 years ago | reply
What can Rails add or change that will help your startup be even more great? How can we make Rails development more productive?
[+] [-] tilsammans|12 years ago|reply
* Streamline the command line. Why rake to migrate, but rails to generate a migration? I know, I know. But new folks to Rails do not know. And it would be better if there was just one tool that does it all.
* Get rid of the global magic functions. users_path is nice and sweet, but where is it defined? Object? Kernel? Why can't I just call a method on my app. Sort of like how engines work: main_app.users_path is IMO better than users_path.
* I guess instance variables in views are a given forever, but I still don't like them. Why can't these be simple methods on objects as well? Simplify, simplify, simplify. Also, deprecate helpers. (Hey, I can dream!)
* I would help if my app was defined as a (singleton) class that I can see and use somewhere. It would be better if this were always a Gem, without me doing anything special. Then I could make all kinds of gem dependencies explicit.
* Fix mailers to allow them to work with async delivery out of the box. (Bringing back queues? Yes please!)
* Make mailers work with Markdown and friends to produce multipart emails out of the box. Write a pretty(ish) plaintext mail, and get HTML formatted for free. (There are gems for this, it would be nice if it were standard)
* Get rid of all hardcoded tokens in source code. Especially the session secret. Require dotenv gem and move all config into ENV. Including the database configuration!
* Fix the log file format. One line per event would be nice. Proper timestamps would be nice. Use standard Ruby loggers with a good format that the rest of the industry understands.
[+] [-] steveklabnik|12 years ago|reply
* Making apps no longer a singleton has been happening on master already, so expect to see a bunch of that.
* I like multipart emails too, since I prefer plaintext emails.
* Working on the tokens issue, I already commented about it elsewhere in this thread.
* As of Rails 4, you can slip in your own Logger, so this is pretty easy to customize if we don't change anything.
* Queues were explicitly brought back to 4.1, that's a feature that we (and I, maintaining Resque) really want to get in.
Thanks! <3
[+] [-] mtarnovan|12 years ago|reply
Better yet, make it as 12factor compliant as possible, out of the box.
[+] [-] meerita|12 years ago|reply
[+] [-] sytse|12 years ago|reply
[+] [-] tibbon|12 years ago|reply
[+] [-] ekidd|12 years ago|reply
I'm seeing more organizations learning towards frameworks like Ember.js and Angular.js. I'm also hearing lots of things like, "When I update the data in this browser, I want the changes to automatically propagate to other browsers."
Among other things, this means I need robust plugins like ember-rails that integrate into the asset pipeline and provide appropriate generators. I also need libraries similar to Socket.io that can notify the browsers when the model changes.
I don't necessarily want these features to be in the Rails 4.1 core. But I suspect that I'll be building more and more apps like this over the next two years, and I'd love to see Rails be a strong competitor on the back end.
[+] [-] steveklabnik|12 years ago|reply
[+] [-] xatnys|12 years ago|reply
[+] [-] terabytest|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] nXqd|12 years ago|reply
[+] [-] sytse|12 years ago|reply
[+] [-] gary4gar|12 years ago|reply
* Improvement in performance in regarding to JSON generation or other thing is always welcome. following benchmarks can be taken as reference where rails stands currently. Any improvement in the above stats would be awesome http://www.techempower.com/benchmarks/#section=data-r6
[+] [-] jordanthoms|12 years ago|reply
[+] [-] jph|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
As for JSON generation, there's an open ticket for it already: https://github.com/rails/rails/issues/9212
[+] [-] cheald|12 years ago|reply
[+] [-] cheald|12 years ago|reply
[deleted]
[+] [-] anonyfox|12 years ago|reply
[+] [-] thepumpkin1979|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
As for getting it into core Rails, well, considering it was originally pulled out, I wouldn't hold your breath, as much as I'd prefer that personally.
[+] [-] mateuszf|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
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.
[+] [-] dasil003|12 years ago|reply
In essence, the idea there should be an object that knows how to render a form based on an internal object state paired with a deserializer that knows how to read the form in and convert it to an internal object state. This way, by default, the form only recognizes the params that were defined and the risk of leaky params causing security issues is reduced by orders of magnitude.
I'm not sure how you retrofit something like this into Rails since it would be a huge architectural shift, but man it would be sweet to see something official along those lines.
[+] [-] steveklabnik|12 years ago|reply
With features like this, the usual answer is 'if a gem gets popular enough, we'll consider it.'
[+] [-] phamilton|12 years ago|reply
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.
[+] [-] steveklabnik|12 years ago|reply
[+] [-] wasd|12 years ago|reply
https://github.com/ngauthier/tubesock is pretty close but it needs better support for channels. Basically, I want websocket-rails style auxiliary functions minus the custom controller part.
[+] [-] rarestblog|12 years ago|reply
[+] [-] purephase|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] jbverschoor|12 years ago|reply
Some defaults for: queueing background jobs timers
Will come back at this tomorrow.
[+] [-] sytse|12 years ago|reply
[+] [-] IanChiles|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
I'm personally very interested in the secret_token issue, and so is the rest of the team, but it's tricky to get the balance right. Working on it!
[+] [-] grey-area|12 years ago|reply
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 by default.
Also, I know this has been a really thorny issue in the past, but the thing I add first to every single app I make is authorisation and authentication. Usually I use devise and cancan, but it'd be great to just have default rails generators for this - they could be very basic, just covering the most basic use-cases, and would obviously have to be optional. Not everyone would use them, but it would at least help a lot of beginners avoid mistakes like this:
https://www.computerworld.com/s/article/9186579/Facebook_wan...
and it would also provide guidelines for people on how to approach those topics - at present they'll tend to google a solution. That would help to emphasise that you need both of these things separately, and give us a baseline from which more complex bespoke solutions could easily be built.
[+] [-] tibbon|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
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.
[+] [-] purephase|12 years ago|reply
For me, my wish list would be:
- Down with helpers. Or, at least the ability to arbitrarily set them. Maybe push presenter as alternatives?
- Some native performance tuning/testing/reporting would be awesome. Gems like rack-mini-profiler and ruby-prof are great, but a near-native tool, opinionated at that, would be awesome.
- I personally love the decorator pattern that gems like Spree use. Unfortunately (and maybe this is my own failing), eval'ing filters/callbacks is a big pain.
- As mentioned in another comment, the env specific configuration provided by figaro is awesome and should be native in Rails. Specifically, it might be a welcome alternative to the secret_token issue.
- Most deployment tools (Capistrano/Mina) enforce a different folder structure. It might be helpful to include some of them by default, or provide configurable options/symlinks that will work out of the box.
I have a lot more items on my list but those are the top items that I can think of at the moment.
[+] [-] steveklabnik|12 years ago|reply
I'm sure you know that I'm a big fan of presenters, maintaining one of the most popular gems that implements them, but they've generally been deemed a bit too heavy of a pattern in the past. What do you mean by 'arbitrarily set them'?
There were performance tests, but nobody used them, so we pulled them out to a gem in 4.0.
Can you give me an example of the eval problem? Not familliar with it.
[+] [-] peteforde|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
That said, other than increased usage, I don't think being included in core would actually do anything that we can't already do ourselves outside of core.
[+] [-] triskweline|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] rarestblog|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] artur_roszczyk|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] rartichoke|12 years ago|reply
- Something like spring ( https://github.com/jonleighton/spring ) built in because I use a low end machine and it still takes 5-6 seconds just to see a page refresh with live reloading enabled in my browser with nearly an empty project in terms of complexity. It would be nice to have it somehow work for tests and near instant code reloads for development.
Random question on queues: Will they be just as good (easy to use / efficient) as resque?