8 ms·

“Start Rails 5 development”

109 points by peeyushagarwal 12y ago

bherms 12y ago
Is there a good summary of the main goals of taking Rails from 4 to 5?
- dejv 12y ago
  http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#maintenance-consequences-and-rails-5-0 http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#mai...
- diminish 12y ago
  > Rails 5.0 is in most likelihood going to target Ruby 2.2. There's a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected. I'm looking forward for Rails 5 and Ruby 2.2 and the expected performance improvements.
ragecore 12y ago
I think it's shipping with its own background processor, Active Jobs. Sounds good!
- bherms 12y ago
  ActiveJob is in 4.2 http://edgeguides.rubyonrails.org/4_2_release_notes.html#active-job http://edgeguides.rubyonrails.org/4_2_release_notes.html#act... http://edgeguides.rubyonrails.org/active_job_basics.html http://edgeguides.rubyonrails.org/active_job_basics.html
- r-s 12y ago
  Active Jobs, at least how implemented in 4.2 is not its own background processor. Its just a common api for using the background processor of your choice (Sidekiq, Resque, Delayed job etc).
  - bherms 12y ago
    ActievJob actually does default to :inline, which uses the Rails process to execute the job, so in a way, it kind of is it's own background processor, but you can easily swap out, as it implements an API for creating and scheduling jobs.
ragecore 12y ago
I think it's shipping with its own background processor, Active Jobs. Sounds good!
echoless 12y ago
I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.
- bdcravens 12y ago
  I really don't think SPAs are very common, though following news of what's hot wouldn't suggest that. Honestly, I'd bet 95% of all web apps being built every day are traditional full request/response apps.
- Ben-G 12y ago
  I think you really need to differentiate between web applications and websites. Websites still are a lot better off with primarily static websites in terms of SEO and performance (caching static pages is easier). For web applications a SPA approach definitely has advantages; for the biggest part in usability. Given that a vast majority of content on the web are pretty plain websites I'm sure Rails will stay relevant for quite a while longer.
- aikah 12y ago
  > Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times. It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. > I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Why would you need a different framework for a "rest-backend" and a website that displays html? I dont understand.I pretty sure Rails has a "content negociation" like feature when it comes to json,xml,or html content types.
  - echoless 12y ago
    > It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs. > Why would you need a different framework for a "rest-backend" and a website that displays html? A full-stack framework is overkill as a backend for SPAs.
deleted 12y ago
[deleted]
cpursley 12y ago
I've moved on to Napa by Bellycard. It takes Grape and brings it together with things we all love from Rails like ActiveRecord, Rake and generators that make for a productive framework. https://github.com/bellycard/napa https://github.com/bellycard/napa

109 points by peeyushagarwal 12y ago

bherms 12y ago

Is there a good summary of the main goals of taking Rails from 4 to 5?

dejv 12y ago
http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#maintenance-consequences-and-rails-5-0 http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#mai...
diminish 12y ago
> Rails 5.0 is in most likelihood going to target Ruby 2.2. There's a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected. I'm looking forward for Rails 5 and Ruby 2.2 and the expected performance improvements.

ragecore 12y ago

I think it's shipping with its own background processor, Active Jobs. Sounds good!

bherms 12y ago
ActiveJob is in 4.2 http://edgeguides.rubyonrails.org/4_2_release_notes.html#active-job http://edgeguides.rubyonrails.org/4_2_release_notes.html#act... http://edgeguides.rubyonrails.org/active_job_basics.html http://edgeguides.rubyonrails.org/active_job_basics.html
r-s 12y ago
Active Jobs, at least how implemented in 4.2 is not its own background processor. Its just a common api for using the background processor of your choice (Sidekiq, Resque, Delayed job etc).
- bherms 12y ago
  ActievJob actually does default to :inline, which uses the Rails process to execute the job, so in a way, it kind of is it's own background processor, but you can easily swap out, as it implements an API for creating and scheduling jobs.

ragecore 12y ago

I think it's shipping with its own background processor, Active Jobs. Sounds good!

echoless 12y ago

I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.

bdcravens 12y ago
I really don't think SPAs are very common, though following news of what's hot wouldn't suggest that. Honestly, I'd bet 95% of all web apps being built every day are traditional full request/response apps.
Ben-G 12y ago
I think you really need to differentiate between web applications and websites. Websites still are a lot better off with primarily static websites in terms of SEO and performance (caching static pages is easier). For web applications a SPA approach definitely has advantages; for the biggest part in usability. Given that a vast majority of content on the web are pretty plain websites I'm sure Rails will stay relevant for quite a while longer.
aikah 12y ago
> Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times. It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. > I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Why would you need a different framework for a "rest-backend" and a website that displays html? I dont understand.I pretty sure Rails has a "content negociation" like feature when it comes to json,xml,or html content types.
- echoless 12y ago
  > It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs. > Why would you need a different framework for a "rest-backend" and a website that displays html? A full-stack framework is overkill as a backend for SPAs.

deleted 12y ago

[deleted]

cpursley 12y ago

I've moved on to Napa by Bellycard. It takes Grape and brings it together with things we all love from Rails like ActiveRecord, Rake and generators that make for a productive framework. https://github.com/bellycard/napa https://github.com/bellycard/napa