
Ask HN: What do you want to see in Rails 4.1? - steveklabnik
We&#x27;ve started planning out Rails 4.1: https:&#x2F;&#x2F;twitter.com&#x2F;rails&#x2F;status&#x2F;366620806064783361<p>What can Rails add or change that will help your startup be even more great? How can we make Rails development more productive?
======
tilsammans
Hey Steve, great of you to ask! Here are some suggestions:

* 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
* the tension between 'rails' and 'rake' has always been there, and I see it trip up beginners. There is a gem that sorta does this, I'll give this some thought.

* 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

~~~
grey-area
_Queues were explicitly brought back to 4.1_

Hurray!

------
ekidd
I consult for a number of startups, both at seed stage and with significant
revenue. Mostly I do web applications, as opposed to "sites."

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
Totally. I help out with rails-api for a reason. That said, I think Rails is
already pretty great at this, it's more marketing than ability.

------
terabytest
What do you think about integrating
[https://github.com/charliesome/better_errors](https://github.com/charliesome/better_errors)
directly into rails?

~~~
steveklabnik
It's a super neat gem. Improving error pages is always a good idea, I'm
actually really happy with the relatively minor changes we added in 4.0, so I
could totally see this or something like it, thanks.

~~~
ericb
I always wished Exceptions captured variable values so I could log them and
not have to reproduce a bug in order to see what happened. To that end, I made
[https://github.com/ericbeland/exception_details](https://github.com/ericbeland/exception_details).
Perhaps Rails exception logging could include logging variable values at
exception-time?

------
gary4gar
* Improved migration format: make it possible to create new initial migrations as a project evolves by rebasing. Meaning there's no need to keep or execute the whole migration history every time. On my current project running migrations from starch takes 30mins :(

* 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](http://www.techempower.com/benchmarks/#section=data-r6)

~~~
jph
+1 for this. My team "rolls up" migrations akin to spring cleaning, because
the migration files often have more important information that the db schema,
and are easier for team members to learn quickly. I'll contribute $50 if this
feature is accepted for Rails 4.1.

~~~
steveklabnik
> I'll contribute $50 if this feature is accepted for Rails 4.1.

Oh yeah? I wonder if others would also pay for bug bounties.

~~~
codeodor
I came across [https://www.bountysource.com/](https://www.bountysource.com/)
the other day.

------
anonyfox
I faced recently scaling/refactoring problems due to way too large models and
some kind of callback-hell baked in. instead of just "drag-n-drop" model code
to concerns/mixins/..., have a look at
[https://github.com/cypriss/mutations](https://github.com/cypriss/mutations)
to extract business logic in a clear way. This was just a life-saver for my
team, this should be preferred over "stuff any logic in your models", at least
from my point of view.

~~~
steveklabnik
I have not seen mutations, I'll check it out, thank you.

------
thepumpkin1979
Please finish [https://github.com/rails-
api/active_model_serializers](https://github.com/rails-
api/active_model_serializers) according to
[http://jsonapi.org/](http://jsonapi.org/) and distribute it officially with
Rails 4.1

~~~
steveklabnik
AMS is currently undergoing a major internal refactoring, possible even a near
re-write, but getting it in line with what's up at JSON-API is real important.
Also, ember-data is undergoing a major push this month, so while this is in
flux, it should improve soon.

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.

~~~
sytse
Thanks for commenting, good to hear Ember compatibility is also in scope.

------
mateuszf
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.

~~~
steveklabnik
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.

------
dasil003
I would love to see something like Django's Editing Views. Ever since George
Brocklehurst described this at Ruby Manor earlier this year I can't get the
idea out of my head. If you look at all the security issues and hand wringing
over params parsing, roles, attr_accessible and strong attributes, etc, etc, a
very large percentage of those issues are greatly improved or in some cases
completely nullified by Django's approach to forms. It's actually one of the
biggest Rails warts in my opinion.

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
There are a few gems that do this, but you're right, it'd be a huge shift. I
do like the approach, though I haven't tried it outside of toy examples
myself.

With features like this, the usual answer is 'if a gem gets popular enough,
we'll consider it.'

------
phamilton
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.

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

~~~
karmajunkie
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.]

~~~
phamilton
app/concerns is a perfect example of the problem I'm trying to communicate. If
I want to extract code out into a concern, everyone is perfectly ok with it
because Rails has "blessed" the concern pattern by providing a parent object
to inherit from and a directory where concerns should be placed. As soon as
Rails weighs in with an opinion, everyone is onboard.

I think the message I would like to see communicated is that we as developers
are free to create app/foo if we feel like foo is a good idea. Technically
there's nothing stopping it. Culturally, it's almost unheard of.

I brought up lib/ because structurally it is a free for all. Nobody looks
twice if I create lib/foo and add some code there. The problem is that I don't
want to put app specific code into lib. I'm not sure if app/lib is a good
idea, but I feel like it would communicate the idea that it is OK to write app
specific code that doesn't fit into anything Rails has approved.

Anyway, I realize my concern is very much a culture issue. That culture has
its pros and cons, and if we didn't have the strong opinion to stick to MVC,
we would probably end up with a ton of spaghetti code in app/lib. I just wish
we could strike the right balance.

------
wasd
Out of the box support for websockets that's hopefully not based on event
machine.

[https://github.com/ngauthier/tubesock](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
I'm really missing deployment-specific settings, like `figaro` gem, especially
for database.yml

~~~
purephase
Another vote for this. The figaro gem is awesome and it should be default
Rails.

------
jbverschoor
I'd love to see a move away from the activerecord model, towards a datamapper
/ mongoid / declared format. It just makes more sense in multiple ways

Some defaults for: queueing background jobs timers

Will come back at this tomorrow.

~~~
steveklabnik
Background jobs are something we explicitly punted from 4.0 with the intention
of 4.1, so hopefully this will happen.

Thanks!

------
sytse
Thanks for asking Steve! I think Rails is already very complete. I would like
to see an included state machine, rails-api integration, commands (baby-zeus)
integration and GitLab secret storage
([https://github.com/gitlabhq/gitlabhq/pull/4040](https://github.com/gitlabhq/gitlabhq/pull/4040)).
But I realize these are all very controversial. The most important thing is
the core-team stays happy, so no problem if these can't make it.

~~~
steveklabnik
What is baby-zeus?

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!

~~~
sytse
With baby-zeus I mean
[https://github.com/rails/commands](https://github.com/rails/commands). The
secret_token is indeed hard, other people proposed the dotEnv gem which makes
sense as well. Or maybe link a whole directory to a shared dir?

------
grey-area
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 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...](https://www.computerworld.com/s/article/9186579/Facebook_wannabe_Diaspora_hit_on_security_issues)

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.

~~~
steveklabnik
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.

~~~
grey-area
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.

------
purephase
Thanks for putting this together Steve. Your work, and those of the Rails
contributors is amazing stuff. I know this past year has been a pain from a
security perspective but as a framework matures and adds n+ features, it is an
inevitable outcome.

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
Thanks!

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.

~~~
purephase
Steve, thanks for following-up.

For point one, I mean that developers have free range with helper definitions
and that they eventually find their way into controllers.

Interesting news about performance tests in <4\. I didn't realize that, I'll
check them out.

The eval problem is as follows (typically if you have to eval something in a
gem):

    
    
        class Foo < ActiveRecord::Base
          before_save :bar
          ..
        end
    
        Foo.class_eval do
          # I want to remove before_save callback here without having to redefine it.
    
          before_save :bar
          ...
          def bar
            return
          end
        end
    

It's not a big deal, just adds clutter. Thanks again!

------
peteforde
I would love to see rails-api become a first-class player in the Rails
ecosystem.

~~~
steveklabnik
Given that I help maintain it, you can imagine that I'm a bit biased here. ;)

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.

~~~
gcao
IMHO, built-in support of api-only application is very good. Here are the
reasons I can think of right now:

1\. unify people who are looking for a standard approach to create api in
Rails

2\. clear separation between lower level http support and higher level
html/js/css processing

3\. performance improvement against using regular Rails for api

4\. easier upgrade for app developers

------
triskweline
I wish there was some way to call the asset pipeline with parameters. E.g.
"render that stylesheet with the dark theme".

~~~
steveklabnik
How would this be an improvement over setting environment variables?

------
rarestblog
Maybe moving out secret key to .gitignored file, so that you can't (by
default) commit it?

~~~
steveklabnik
I commented on this elsewhere in the thread, but I'm working on it, thanks!

------
artur_roszczyk
rails package - dockerization of app, but this rather goes beyond of
responsibilities of Rails and I should complain at capistrano guys ;-)

~~~
steveklabnik
True, that's sorta outside of the scope of the framework.

------
rartichoke
I'm still new to rails but I would really like to see:

\- Something like spring (
[https://github.com/jonleighton/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?

~~~
steveklabnik
Spring was made by a core member, there is also rails/commands. You might see
this feature or not...

Queues will be an interface for things like Resque to implement, not an
implementation itself. I maintain Resque too, it'll be a good story to use the
two together.

~~~
rartichoke
Nice, sounds good.

I vaguely remember reading about a downside when using the console to run
tests, maybe I should give it a second look.

All I care about is being able to run tests on file save from my editor and
seeing feedback in a terminal window. Speedier the better of course.

------
timmillwood
Unicorns, ponies and rainbows please.

~~~
steveklabnik
Simply adding `gem 'unicorn'` or `gem 'rainbows'` to your Gemfile will give
you unicorns or rainbows, I'll investigate ponies, thanks.

~~~
tibbon
This is true- but at least for Heroku deployment I always find myself digging
around for the "unicorn-killer" stuff. But perhaps that's Heroku specific.

------
tibbon
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.

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

~~~
steveklabnik
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.

------
tylerdavis
Replace turbolinks with pjax.

~~~
steveklabnik
Considering dhh created Turbolinks specifically to improve upon PJAX, I think
we both know how likely that idea is. Thanks for the suggestion though!

~~~
byroot
More realistically, commenting it by default would be IHMO a good idea. A
friend of mine who currently learn rails and angular by himself got bitten by
it. And angular is definitely not the only JavaScript framework / plugin that
don't work well with Turbolinks.

It's a very nice gem for some use cases but a terrible default.

~~~
mtarnovan
I'd have to agree, having it on by default doesn't seem like such a good idea,
omakase or not. There are tons of situations where using turbolinks spells
trouble.

------
jph
Minitest 5. I'm getting great results with Minitest Spec.

~~~
steveklabnik
[https://github.com/rails/rails/blob/master/activesupport/act...](https://github.com/rails/rails/blob/master/activesupport/activesupport.gemspec#L26)

<3

------
joneslee85
1) Support minitest/spec with ActiveSupport::TestCase 2) Make rails
indenpendent of testing framework, why should I case about minitst if I prefer
rspec?

~~~
steveklabnik
1) was specifically reverted by David, so that won't be happening.

2) How is it not agnostic now? What's the problem with just using rspec?

~~~
joneslee85
Regarding point 2), I don't think it is very agnostic though.

Because ActiveSupport::Testcase is extension of Minitest. Thus, rspec won't be
able to use all helpers of AS. I am fully aware of there are rspec-rails with
equivalent matchers.

Sadly, majority of commercial companies are now using rspec/rspec-rails for
the dev job, this makes AS::TS a second-class citizen. So if we could not
abstractify AS::TS, my vote is to extract it to a separate gem and let user
choose the test framework they want.

------
meerita
I would love a sort of annotate-gem built in. As well if you change the model
with a migration, the comments on the model would be updated would be nice.

------
jacke
Updated welcome page.

~~~
jacke
Because most major framework has excellent welcome pages, like these one
[http://blog.japila.pl/wp-content/uploads/2013/03/wlp-play-
we...](http://blog.japila.pl/wp-content/uploads/2013/03/wlp-play-welcome-page-
dev-env.png)

