13 ms·

Rails 5.0.0.beta1: Action Cable, API Mode, Rails Command

395 points by aaronbrethorst 11y ago

gloves 11y ago
How DHH manages between Ruby, Basecamp, Family and Racecars I don't know.
- pibefision 11y ago
  +1 for an AMA about this.
  - gloves 11y ago
    He actually held an AMA with Business of Software the other day - http://businessofsoftware.org/2015/11/should-you-rewrite-your-software-yes-david-heinemeier-hansson-ama-recap-basecamp-3/ http://businessofsoftware.org/2015/11/should-you-rewrite-you... 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 11y ago
      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 11y ago
        Feedback much appreciated - I'll make sure that's followed up and implemented. Thank you :)
- tortilla 11y ago
  Don't forget Twitter! He's pretty active there too. :)
- tomphoolery 11y ago
  No kids? :)
  - dmerrick 11y ago
    He has a son named Colt, apparently: http://david.heinemeierhansson.com/#family http://david.heinemeierhansson.com/#family
dexcs 11y ago
I love the "One Rails command to rule them all" streamlined bin/rails command. Wondered always why there are different commands. Thanks guys!
- davidpdrsn 11y ago
  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.
kawsper 11y ago
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
shimonamit 11y ago
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
- VeejayRampay 11y ago
  I don't think there's even been a point in Rails history where you've been forced to install something. I think those are all ActionCable dependencies, which I'm pretty sure you can deactivate (not every app requires the capability it offers).
  - cristianbica 11y ago
    The only way to deactivate it is from your app's Gemfile (remove gem "rails" and add all the active/action gems individually). For new apps there's a flag "--skip-action-cable". In the future probably the faye/redis will probably be made adapter based (similar to ActiveRecord and ActiveJob) and exctracted in a gem. So if you want actioncable you'll have to add a "actioncable-faye-adapter" gem to your Gemfile.
- aaronem 11y ago
  Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s
  - aikah 11y ago
    > Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s AFAIK nodejs is already an optionial rails dependency for the asset pipeline.
    - Rafert 11y ago
sandstrom 11y ago
Great, both Action Cable and the api-capabilities are really useful. Great to see that Rails is keeping itself up to date.
pmontra 11y ago
The new Attributes API is interesting. https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab1e9d0142c4041e58/activerecord/lib/active_record/attributes.rb https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab... 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/
- ScotterC 11y ago
  Didn't know about ActiveRecord-tableless thanks! Glad to have an easier way to incorporate AR benefits without including one by one
- tomphoolery 11y ago
  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 11y ago
    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 11y ago
      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.
cdnsteve 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        If you want to read up on how Github transitioned, this post is useful: http://shayfrendt.com/posts/upgrading-github-to-rails-3-with-zero-downtime/ http://shayfrendt.com/posts/upgrading-github-to-rails-3-with... Getting stuck on 2.3 isn't desirable.
      - 11y ago
dschiptsov 11y ago
Any new dependencies, besides NodeJS? .Net portable runtime? Swift? Rust for safety?
- aaronem 11y ago
  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 11y ago
    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.
lephyrius 11y ago
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 11y ago
  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&t=1052 https://www.youtube.com/watch?v=B3gYklsN9uc&feature=youtu.be...
  - lephyrius 11y ago
    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.
RawData 11y ago
And check out the guide for upgrading Rails... http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...
- frostmatthew 11y ago
  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.html#upgrading-from-rails-4-2-to-rails-5-0 http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...
grandalf 11y ago
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 11y ago
  - 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 11y ago
    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.
    - 11y ago
dmerrick 11y ago
I wonder if Ruby 2.3 will be released on Christmas Day this year (a Ruby tradition).
- InAnEmergency 11y ago
  Yes: https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/ReleaseEngineering23 https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/ReleaseE...
- xjlin0 11y ago
  Welcome to try Ruby 2.3.0 preview 2 https://www.ruby-lang.org/en/news/2015/12/11/ruby-2-3-0-preview2-released/ https://www.ruby-lang.org/en/news/2015/12/11/ruby-2-3-0-prev...
reitoei 11y ago
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 11y ago
  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.
- sandstrom 11y ago
  I like (and currently use) CoffeeScript. But it seems like ES-Y and Babel is the future, so I think removing CoffeeScript as the default in Rails would be a good idea.
resca79 11y ago
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 11y ago
  They pretty much just stole the best parts of Phoenix Channels and phoenix.js right?
ralmidani 11y ago
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 11y ago
  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.

395 points by aaronbrethorst 11y ago

gloves 11y ago

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

pibefision 11y ago
+1 for an AMA about this.
- gloves 11y ago
  He actually held an AMA with Business of Software the other day - http://businessofsoftware.org/2015/11/should-you-rewrite-your-software-yes-david-heinemeier-hansson-ama-recap-basecamp-3/ http://businessofsoftware.org/2015/11/should-you-rewrite-you... 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 11y ago
    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 11y ago
      Feedback much appreciated - I'll make sure that's followed up and implemented. Thank you :)
tortilla 11y ago
Don't forget Twitter! He's pretty active there too. :)
tomphoolery 11y ago
No kids? :)
- dmerrick 11y ago
  He has a son named Colt, apparently: http://david.heinemeierhansson.com/#family http://david.heinemeierhansson.com/#family

dexcs 11y ago

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

davidpdrsn 11y ago
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.

kawsper 11y ago

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

shimonamit 11y ago

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

VeejayRampay 11y ago
I don't think there's even been a point in Rails history where you've been forced to install something. I think those are all ActionCable dependencies, which I'm pretty sure you can deactivate (not every app requires the capability it offers).
- cristianbica 11y ago
  The only way to deactivate it is from your app's Gemfile (remove gem "rails" and add all the active/action gems individually). For new apps there's a flag "--skip-action-cable". In the future probably the faye/redis will probably be made adapter based (similar to ActiveRecord and ActiveJob) and exctracted in a gem. So if you want actioncable you'll have to add a "actioncable-faye-adapter" gem to your Gemfile.
aaronem 11y ago
Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s
- aikah 11y ago
  > Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s AFAIK nodejs is already an optionial rails dependency for the asset pipeline.
  - Rafert 11y ago

sandstrom 11y ago

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

pmontra 11y ago

The new Attributes API is interesting. https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab1e9d0142c4041e58/activerecord/lib/active_record/attributes.rb https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab... 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/

ScotterC 11y ago
Didn't know about ActiveRecord-tableless thanks! Glad to have an easier way to incorporate AR benefits without including one by one
tomphoolery 11y ago
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 11y ago
  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 11y ago
    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.

cdnsteve 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      If you want to read up on how Github transitioned, this post is useful: http://shayfrendt.com/posts/upgrading-github-to-rails-3-with-zero-downtime/ http://shayfrendt.com/posts/upgrading-github-to-rails-3-with... Getting stuck on 2.3 isn't desirable.
    - 11y ago

dschiptsov 11y ago

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

aaronem 11y ago
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 11y ago
  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.

lephyrius 11y ago

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 11y ago
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&t=1052 https://www.youtube.com/watch?v=B3gYklsN9uc&feature=youtu.be...
- lephyrius 11y ago
  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.

RawData 11y ago

And check out the guide for upgrading Rails... http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

frostmatthew 11y ago
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.html#upgrading-from-rails-4-2-to-rails-5-0 http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

grandalf 11y ago

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 11y ago
- 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 11y ago
  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.
  - 11y ago

dmerrick 11y ago

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

InAnEmergency 11y ago
Yes: https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/ReleaseEngineering23 https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/ReleaseE...
xjlin0 11y ago
Welcome to try Ruby 2.3.0 preview 2 https://www.ruby-lang.org/en/news/2015/12/11/ruby-2-3-0-preview2-released/ https://www.ruby-lang.org/en/news/2015/12/11/ruby-2-3-0-prev...

reitoei 11y ago

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 11y ago
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.
sandstrom 11y ago
I like (and currently use) CoffeeScript. But it seems like ES-Y and Babel is the future, so I think removing CoffeeScript as the default in Rails would be a good idea.

resca79 11y ago

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 11y ago
They pretty much just stole the best parts of Phoenix Channels and phoenix.js right?

ralmidani 11y ago

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 11y ago
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.