
Rails 5.0.0.beta1: Action Cable, API Mode, Rails Command - aaronbrethorst
http://weblog.rubyonrails.org/2015/12/18/Rails-5-0-beta1/
======
shimonamit
An interesting tweet by Sam Saffron:

"@dhh this is just a bit too much
[https://github.com/rails/rails/blob/master/rails.gemspec#L28](https://github.com/rails/rails/blob/master/rails.gemspec#L28)
… now every Rails install requires redis, eventmacine, celluloid and faye"

[https://twitter.com/samsaffron/status/678701348297158657](https://twitter.com/samsaffron/status/678701348297158657)

~~~
inopinatus
Rails 5 is a bloat too far for my liking as well. ActionCable's dependency on
redis is too fat a pill to swallow, especially given that some of the existing
ActiveRecord backends have pub/sub capabilities.

The result is that I'm learning Elixir/Phoenix and having the same reaction
Dave Thomas describes in his new book, that is, finding anew the joy of
programming.

~~~
mbrain
Do you see a future in Elixer/Phoenix? And how do you like it?

~~~
chippy
I often do a word count of languages and technologies in the monthly "Who's
hiring" posts here. Elixir/Phoenix gets less mentions than Erlang - often
there would be at least one position that says they use Elixir, sometimes
none.

~~~
awinder
Small point: this is how all popular languages once started. Much like the
stock market, there's value in being balanced on the forefront of a technology
along with a solid footing in an established technology. Having no balance in
either direction is the only "risky" career move.

------
ralmidani
While I prefer Django to Rails, I'm glad to see both teams taking support for
real-time applications seriously.

Some will note that Node has had real-time for years, but with all due respect
to the Node ecosystem, nothing in it (edit: I'm referring to server-side
frameworks; I love Ember-CLI) is as nice for developer happiness and
productivity as Django and Rails. The best practices that have taken years to
be baked into these frameworks make it more difficult to bring in new
functionality, but I feel more confident that when new features are
implemented, they will be done right.

~~~
geebee
I have a feeling there are a lot of people looking at this from a similar
angle.

I feel that we are in a very transitional time for web development right now.
This is a field with a pretty high rate of change in general, but every now
and then, things change dramatically even by web programming standards, and we
go through a period of technological uncertainty. The last time I remember
feeling this way was the rise of object relational mappers, dependency
injection, model view controller frameworks, and various tag libraries on the
front end[1] in javaland. I remember from a previous HN discussion that there
is a web counter measuring the number of days since the last javascript
framework was released. I remember feeling the same way about struts, struts2,
spring MVC, tiles, tapestry, JPA, hibernate, ibatis, spring DI, pico, guice,
and so forth…

Interestingly, much of this didn't so much get resolved as swept aside - Ruby
and Rails, Django, and a few other technologies "appeared" [1, again] at this
moment. I do remember feeling extremely grateful for ruby and rails, because I
had started to hate programming. It wasn't the Java verbosity that I objected-
I rather enjoyed programming with servlets/jsp and jdbc + the java web
cookbook, and I never minded data structures and algorithms in Java - it was
the churn and incredible amount of complexity just to do simple things that
made me unhappy. Rails got some bloat here and there, expand and consolidate,
but I feel that it did accomplish its main goal, at least for me, which was
that I felt happy and productive programming again.

Now, with the disruption of SPAs, we are clearly back in framework churn, and
I'm not loving the model of writing the back end in rails-api and using a
javascript front end. I may warm up to this as my knowledge of javascript
increases (and I certainly never minded going outside rails and writing sql,
so I can't really say I object to more than one language). I've done a bit of
ember, and it seems heavy to me, I have to duplicate so much routing, model,
persistence, data tier work (I'm a noob, I may be doing it wrong, fully
possible). I don't like looking at javascript as much as I like looking at
ruby. I also do remember feeling a bit frustrated with Rails in the beginning,
before I understood it well enough to do an end-run around conventions, so
like I said, I may really warm up to javascript frameworks. But I really like
Ruby, and I'm very satisfied with Rails (and if not rails, sinatra or
something like that would be fine too).

Like I said earlier, I studied a lot of java-based MVC/DI/ORM approaches and
ended up going with something that I hadn't even considered (Rails). I do
think that in these highly transitional periods, this tends to happen - that
you are surprised by the solution that ends up working for you. At this point,
it's getting so speculative that I'm not highly confident in predicting
things, but I wouldn't be too surprised if the "isometric" transpiled
languages (like ruby and opal) end up changing things dramatically (ie., just
as I didn't end up "picking" a java-based MVC/DI/ORM approach, I may not end
up picking a javascript framework, I may end up surprised by a new and
different approach).

[1] I understand these weren't really "new" ideas, many of them (like a lot of
CS) go back to the 1970s, but they hit the scene in that they became an issue
in day to day development for ordinarliy up-to-date but not cutting edge web
developers, the people who just wanted to get things done.

~~~
steveklabnik

      >  I've done a bit of ember, and it seems heavy to me, 
    

One thing about Ember: it's specifically for "ambitious" applications. The
idea is that you're going to be building something which needs all those
things, so it's better to have them in the framework, where best practices can
be shared across projects. Once you've built out those features yourself,
you've built a custom framework anyway.

An interesting point about frameworks, generally: they have a constant
overhead. So for smaller projects, the framework dominates the application,
but as the application grows, the application will dominate the framework.

~~~
sandstrom
We're using Rails (in 'API-mode') with Ember. It's a great combination in my
view. Thrilled to see Rails 5 providing even better support for this
combination.

@steveklabnik Thanks for spearheading Rails-api! :)

Re: Ember being heavy; yes, it is a bit heavy but that has huge payoffs as
your application grows.

~~~
steveklabnik
Any time. It's been a few years, but it's finally in. Frankly, I had very
little to do with it becoming eventually included, I believe that was Dan
Gebhardt's work.

------
pmontra
The new Attributes API is interesting.
[https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab...](https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab1e9d0142c4041e58/activerecord/lib/active_record/attributes.rb)

Basically it's a type system for models with the ability of defining new
types. I wonder if it can be used also for plain Ruby objects but given the
existence of tableless ActiveRecord gems, why not?
[https://github.com/softace/activerecord-
tableless/](https://github.com/softace/activerecord-tableless/)

~~~
tomphoolery
That's pretty cool. Basically including the best parts of ActiveAttr into
ActiveRecord. :)

Maybe someday we won't have to write migrations anymore. Rails could maybe
just diff the attributes and types given, and figure out the schema itself.

~~~
thirdsun
Oh yes, I always though it would make more sense to setup columns in the model
itself, without migrations. Also, no more need for the annotate gem.

~~~
pmontra
I see your point but the implementation must be very well designed.

There are migrations that can take hours to complete in production. Examples:
adding an index to a very large table or adding an element to an enum (I
remember a customer of mine had this problem on a MySQL db a couple of years
ago.) A DSL that makes clear you are modifying the db is a safeguard against
those surprises. Just adding something like indexed: true to an attribute
declaration would be dangerous. Furthermore rake migrate:up/down are more
convenient than reverting a change to a model by checking out an older
version. I believe that it's not impossible to do it, but it must be designed
very carefully.

Maybe because of those reasons Phoenix, the Rails like web framework for
Elixir, has migrations even if models declare the attributes of the tables in
the database.

------
kawsper
DHH made a Action Cable demo where he builds a chat-application:
[https://www.youtube.com/watch?v=n0WUjGkDFS0](https://www.youtube.com/watch?v=n0WUjGkDFS0)

------
gloves
How DHH manages between Ruby, Basecamp, Family and Racecars I don't know.

~~~
pibefision
+1 for an AMA about this.

~~~
gloves
He actually held an AMA with Business of Software the other day -
[http://businessofsoftware.org/2015/11/should-you-rewrite-
you...](http://businessofsoftware.org/2015/11/should-you-rewrite-your-
software-yes-david-heinemeier-hansson-ama-recap-basecamp-3/)

Full disclosure: I help produce the events - but you did ask.

[edit: it's only touched upon about his lifestyle - it's far more about his
recent talk about rewriting software from scratch]

~~~
pchm
One suggestion for future recordings: please mute all people, except the one
talking - the touchpad clicks and constant noises in the background are making
it really difficult to listen to what's being said... I gave up after a couple
of minutes.

~~~
gloves
Feedback much appreciated - I'll make sure that's followed up and implemented.
Thank you :)

------
dexcs
I love the "One Rails command to rule them all" streamlined bin/rails command.
Wondered always why there are different commands. Thanks guys!

~~~
davidpdrsn
I figure its because its quite annoying to pass arguments to rake tasks. So
all the commands the required arguments lived in the rails command, the rest
in rake.

------
resca79
I like the concept to use a single web socket with multiplexing/demultiplexing
mode. It's very simple concept but rails yet give to its developers the 'right
way', to set under control the number of connection of web sockets. Now each
connection will use the same web sockets and every connections on the web page
pass by it. This means that each service send message like: (service_A:
requests)->(multiplexing) -> Web Socket -> (demultiplexing) -> Server

~~~
gkop
They pretty much just stole the best parts of Phoenix Channels and phoenix.js
right?

------
RawData
And check out the guide for upgrading Rails...

[http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...](http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html)

~~~
frostmatthew
That page covers a number of upgrade scenarios, the section for upgrading from
4.2 to 5.0 only has three entries[1], one of which is optional.

[1]
[http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...](http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-
from-rails-4-2-to-rails-5-0)

------
sandstrom
Great, both Action Cable and the api-capabilities are really useful. Great to
see that Rails is keeping itself up to date.

------
dschiptsov
Any new dependencies, besides NodeJS? .Net portable runtime? Swift? Rust for
safety?

~~~
aaronem
I'm told[1] that Node isn't a _new_ dependency...

[1]
[https://news.ycombinator.com/item?id=10770732](https://news.ycombinator.com/item?id=10770732)

~~~
FooBarWidget
Rails doesn't even depend on Node.js exclusively. Rails depends on _some_
JavaScript runtime so that it can minify JavaScript. You may choose to install
Rhino, or some V8-based gem, or whatever.

------
cdnsteve
What will the upgrade path from 4.2x be like to 5x? Do you have to re-write
your apps or is it upgradable?

~~~
dasil003
My company's main app (~50k LOC acording to rake stats) has been upgraded
continuously from 1.2 up to 4.2. The most painful upgrade was 2.3 to 3.0,
followed closely by 3.0 to 3.1 (which was incidentally painful because of a
performance regression affecting ruby 1.8, so we had to simultaneously do the
1.9 upgrade at the same time which was the most painful ruby upgrade of recent
memory). Since then the upgrades have been easier.

From what I've seen 5.0 should be on par with the 4.x upgrades, which is to
say, not bad. YMMV of course.

~~~
jon-wood
That's pretty impressive - we've basically stalled at 2.3 because of the Ruby
1.8 upgrade making it near impossible to bump everything we'd need to at this
point.

~~~
dasil003
My understanding is this also happened to GitHub and they stayed on 2.3 for
years, even maintaining their own fork to handle security issues once official
support lapsed. I also understand they eventually realized this wasn't viable
long term and made the massive effort to get over the hump.

FWIW, the memory and instrumentation improvements in Ruby 2.x alone are worth
the massive effort to upgrade. Good luck!

~~~
sandstrom
If you want to read up on how Github transitioned, this post is useful:
[http://shayfrendt.com/posts/upgrading-github-to-
rails-3-with...](http://shayfrendt.com/posts/upgrading-github-to-rails-3-with-
zero-downtime/)

Getting stuck on 2.3 isn't desirable.

------
dmerrick
I wonder if Ruby 2.3 will be released on Christmas Day this year (a Ruby
tradition).

~~~
InAnEmergency
Yes: [https://bugs.ruby-lang.org/projects/ruby-
trunk/wiki/ReleaseE...](https://bugs.ruby-lang.org/projects/ruby-
trunk/wiki/ReleaseEngineering23)

------
lephyrius
So does this mean that this pull request isn't accepted?
[https://github.com/rails/rails/pull/19272](https://github.com/rails/rails/pull/19272)

Why release a beta if it's just an alpha? All the features isn't there. Why
have this [temp] milestone?
[https://github.com/rails/rails/milestones/5.0.0%20%5Btemp%5D](https://github.com/rails/rails/milestones/5.0.0%20%5Btemp%5D)

~~~
nygrenh
Hi, I'm the author of the pull request. The pull request got stuck due to an
issue with dynamic injection of local variables into view templates.
(Explained more in the Aaron Patterson's RailsConf keynote[1]). We were
planning to solve this issue before (potentially) merging the feature.

At the moment, it looks like the issue is solvable, and I have code that seems
to solve it but still needs some refinement before I can submit a pull request
about it.

I don't know what the Rails core team is planning about the feature, but
considering how complex the whole thing is and how much there's still left to
do, I'd guess that it won't make it to 5.0.

[1]:
[https://www.youtube.com/watch?v=B3gYklsN9uc&feature=youtu.be...](https://www.youtube.com/watch?v=B3gYklsN9uc&feature=youtu.be&t=1052)

~~~
lephyrius
I see that it's an issue. But the places you use locals in a template is
small. Majority of the templates would still benefit. Like the main layout and
so on.

------
reitoei
[https://github.com/rails/rails/tree/master/actioncable](https://github.com/rails/rails/tree/master/actioncable)

Just looking at the client examples for action cable; is CoffeeScript now the
standard way of doing JavaScript in Rails?

~~~
epidemian
Using CoffeeScript for generators has been the default for a long time (Rails
4 for sure, but probably even from Rails 3), but you can use JavaScript as
well (to the asset pipeline it makes no difference if the files are .js or
.coffee, they get processed and concatenated/minified the same way), or change
the default so generators generate JS files.

------
grandalf
There are a number of perverse incentives going on here:

\- Rails needs something opinionated and "new" every so often to remain
relevant.

\- Workers, consultants, etc., benefit from being familiar with the latest
rails, so many projects are upgraded that don't need to be.

\- New versions break lots of gems and useful online tutorials, increasing the
value of experience relative to aptitude.

So now, across the world, lots of teams will remove perfectly good code and
divert lots of attention to upgrading to Rails 5 for no apparent reason or
simply that a higher number is viewed as better.

Contrast this with the node ecosystem where libraries tend to be smaller and
significant version bumps typically take an hour or so to accommodate at most.

The worst part is that if you engineered an alternative to action cable (for
example) into your app, Rails 5 makes your approach seem outdated for no
reason.

~~~
ch4s3
\- If you upgrade a project "just because" then you're doing it wrong. That
isn't the fault of the rails team. \- New versions don't break that many
things that aren't tied directly to how rails works. Most general gems will
work just fine, and a lot of tutorials from 3.2 are still more or less usable
with minimal googling. Generators work the same, active record's api hasn't
changed much, action view works the same way.

And don't get me started on the mess that a node dependency graph can become.

~~~
nirvdrum
While upgrading "just because" should be avoided (and indeed, DHH stated as
much in a keynote at one of the RailsConfs), that's exactly the approach the
Ruby community/ecosystem have adopted as a whole. Most Rails plugins don't
maintain compatibility with multiple versions. And if you use something that
overlaps with Rails's dependency graph, you're going to have to deal with that
in one way or another.

In Ruby and Rails, you basically have to keep updating regardless of the
changelog simply to amortize your costs. If you fall too far behind then when
you invariably do need to upgrade a dependency, you're going to have to pay
all that cost in one swoop and the complexity of that amps up considerably.

~~~
gkop
I missed the keynote, but according to the OP the release of Rails 5 means
"4.1.x and below will essentially be unsupported".

My advice is always to upgrade 3-6 months after a major or minor release.
After 3 months so that other people have exhaustively documented their
troubles and resolved incompatibilities in the libraries they maintain. And
before 6 so that Google results for common issues are still fresh.

So I think putting it in terms of "just because" is not really very helpful.
In a sense my upgrading in the 3-6 month interval is "just because", but doing
it this way keeps the overall maintenance burden to a minimum, since I do have
to upgrade sooner or later in order to receive security updates.

~~~
nirvdrum
Obviously everyone has different situations. But if all you need are security
updates, the Rails team has historically been very good about providing
patches even for unsupported releases. If they don't, porting is often fairly
trivial anyway. I often see ronin [1] implementations of exploits very soon
after a CVE so you can even test against your own app.

Unfortunately, my point was more that you can't just not upgrade Rails.
Eventually everything else you use will require newer Rails and upgrading at
that point becomes extraordinarily difficult. E.g., ActiveRecord plugins often
just monkeypatch the internals, which are naturally free to change from
release to release. However, most gem authors don't want to test against
multiple versions, so the latest becomes the only supported one and you have
to upgrade "just because."

[1] -- [https://github.com/ronin-ruby/ronin/](https://github.com/ronin-
ruby/ronin/)

~~~
ch4s3
That's all totally fair. I really wish people weren't so quick to monkey patch
things, especially when it comes activerecord.

"Eventually everything else you use will require newer 'x'", I think this is a
problem even with non-frameworks. Imagine any core to your functionality lib
getting far out of date. Dependency graphs are hard to manage over time.

~~~
nirvdrum
Agreed. It just seems far more pronounced in the Ruby ecosystem. My experience
with Python and Java is that both communities are okay with maintaining
multiple versions of a library. And when you commit to that, you adopt
practices like separate namespaces between major versions, which can make
upgrading substantially easier. With a bit of trickery, you could even load
two different versions of the same lib as long as their namespaces don't
conflict. Ruby gems, on the whole, hardly ever employ namespacing so that
option isn't even available.

I don't see it so much as a technical limitation of Ruby, but simply the way
the community has evolved. With other ecosystems, the emphasis is often on
stability by sticking what's known to work. Abstractly they have the same
dependency graph problems, but in practice their problems and solutions are
quite different.

