“Start Rails 5 development”

https://github.com/rails/rails/commit/f25ad07f5ade46eb978fa82658463232d0247c65

by peeyushagarwal • 12 years ago

109 62 12 years ago

github.com

bherms3• 12 years ago

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

dejv• 12 years ago

http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#mai...

diminish• 12 years 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• 12 years ago

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

bherms3• 12 years ago

ActiveJob is in 4.2

http://edgeguides.rubyonrails.org/4_2_release_notes.html#act...

http://edgeguides.rubyonrails.org/active_job_basics.html

r-s• 12 years 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).

bherms3• 12 years 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.

echoless3• 12 years 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• 12 years 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• 12 years 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.

aikah4• 12 years 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.

echoless3• 12 years 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.

nileshtrivedi• 12 years ago

I think Javascript frameworks (like Meteor) will grow in prominence given the promise of code sharing between client and server, better integration with single-page applcation and better libraries for server-side processing.

jedisct1• 12 years ago

Or that compiles to Javascript for the client-side, like Volt (which I have been very impressed by): http://voltframework.com/

adamonduty• 12 years ago

Rails works quite nicely as a REST backend. Its also much faster in my experience to render json than HTML templates. Rails is great as a general starting point, letting you choose SPA at the start or later.

josephagoss• 12 years ago

I was always under the impression that these server based frameworks are better for two reasons, the code is safe, so you're leaking less of your code, and that the size of the website on the client is reduced allowing for faster downloads.

I could be very wrong, but I feel more comfortable keeping as much code on the server as possible.

juliangregorian• 12 years ago

You guys need to learn how turbolinks works. Rails already is basically an SPA framework.

echoless3• 12 years ago

Turbolinks wipes off the entire DOM and replaces it with the new request's html on link navigation. So no, it is not an adequate replacement for SPAs.

digitalzombie2• 12 years ago

I've been doing web dev for 6 years, full stack, back and front, mostly somewhere in the middle and front end.

From what I've seen, backend rendering ain't going no where.

This SPA trends is still wild west. Angular 1 is kind slowing down imo cause of the drastic changes in Angular 2. Ember is bloat. The javascript eco system is meh right now.

NodeJS people probably will argue against this. But seriously, javascript needs a module system. RequireJS kinda suck with grunt, it doesn't work so well other grunt modules. Most of the frontend people I've met barely even use Bower. Sure maybe one that it'll be the future but right now it's unclear whose the winner and if people are willing to invest in something that can be obsolete in 1 or 2 years. Seeing how angular 2 is going to come out eventually a year or two, why learn angular 1?

Oh there's the react library and other stuff going on too. I haven't use that but it's getting traction...

Grunt and Glup are duking it out. In general it's just meh. I wouldn't bet on Angular or Ember anymore. Rails and Django or whatnot at least they're stable enough and have tons of people using it.

I'm kinda sick of it and moving toward backend really. It'll be fun architecturing stuff mesos, dockers, etc..

tinco4• 12 years ago

Not to one-up you, just since apparently it's worth mentioning, I've been doing webdev for about 9 years, and at least from my perspective backend rendering is definitely going out the window.

I started as a Rails dev in 2008, did ASP.Net before that, and last year I've moved from Rails to a pimped up Grape, which is a framework suited more for developing API's. Maybe it's just the sort of apps I'm building (basically SaaS) but I don't see any backend rendering in my feature, if I'm building it, it's going to be either a SPA, or a static site. (I built my sisters' band a single page static site, very nice).

Latest project is using Polymer, and no Javascript framework at all. I think you're right, Angular is extremely ugly, and Ember seems to do too much. But plain Javascript has become very powerful and HTML5+CSS3 reduce the need for UI toolkits.

Maybe I'm crazy, but I don't see a super hard need for modules either, I define all dependencies at a single location, and just bind everything to window. The not binding things to window rule is only for library/component developers, if you're an app developer you should own window, make it your home and have everything as you expect it to be.

Anyway, what I'm hoping is that new Rails editions focus more on the SPA experience, they have been reluctant to. I use Grape, but I immediately pimped it out with all the niceties Rails has, including ActiveSupport and ActiveRecord, but also a console and decent logging.

What I do worry about is the amount of people embracing Node.JS over Ruby. It's crazy people would chose Javascript over any language at all in an environment they're not absolutely forced to. My fear is one day I'll be seeking a job, and all there is is shops building webapps in vanilla Javascript, wouldn't that just be a plain horror story?

uptown• 12 years ago

Take a look at PJAX. I've found it to be a nice model for rendering pages with a good balance of severe rendering speed and page updating flexibility.

dgregd3• 12 years ago

Ruby on Rails is still the most productive why to build web apps. Turbolinks prolonged Rails life cycle, as the best web framework, by two or three years.

However SPA are the future. Maybe Angular 2 will be good enough to switch. Maybe something build after Angular 2.

dgregd3• 12 years ago

Would you please explain why my comment have been down-voted?

mratzloff2• 12 years ago

For over a decade I've heard that SPA and server-side JavaScript is the future. I always believed JavaScript would carve out a place on the server side, but I've always been skeptical about SPA given the often terrible UX and SEO. And besides that, most sites are better off being served statically from a cache.

tl;dr Wake me up when even 5% of sites are SPA.

bshimmin2• 12 years ago

Where on earth were you hearing about SPAs and server-side JavaScript in 2004? Was "SPA" even a term before about 2010?

alan82• 12 years ago

Wake me up when even 5% of sites are SPA.

5% of all web apps or new build apps?

sandstrom• 12 years ago

I think Rails is great for API-only backends too.

I'd say it's quite common to have clients in JS/iOS/Android, and still use a Rails-backend.

megaman821• 12 years ago

The browser is becoming more of a platform to deploy to like Android or iOS, instead of a document viewer. I think it is still the wild wild west on the client side for now, but once winners emerge there will be a much larger group of developers creating SPA's. It seems Angular 2.0, Ember 2.0, and React 1.0 are all headed in similar directions with their emphasis on components, so a winning concept might emerge some time soon. That said, development trends on the web slowly play out over years. I expect Rails and Django to have a massive user base for 5+ years at least.

meesterdude• 12 years ago

Rails isn't going away, as there are plenty of sites on the internet that use it. Everything I build is in rails, and i like it that way. And it makes my life pretty awesome, and is enjoyable to work with. I really can't complain.

Single page is an option for some people, and there are several ways to get you there as well. But that's the great thing about the web: we have all kinds of ways to deliver an end product.

That doesn't make other rendering methods go away, though. Flash is still around, for example. And there's really no reason to project that rails will suffer some terrible fate in a few years time. It's been around for several years now and has done nothing but grow, so as long as it solves a problem and people go to it, it and other frameworks will hang around.

tomchristie• 12 years ago

Personally I think they're going to remain strong. More single page apps? Fine, but they still need to be backed by an API and, in most cases, a relational database. Yes there will be more frontend templating, and yes more mature fuller stack JS alternatives will emerge, but those role those frameworks fulfill is still needed, backend template rendering or not.

dec0dedab0de• 12 years ago

just want to point out that Django is pretty good at making REST backends.

cpursley2• 12 years 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

“Start Rails 5 development”

Related Stories