

“Start Rails 5 development”  - peeyushagarwal
https://github.com/rails/rails/commit/f25ad07f5ade46eb978fa82658463232d0247c65

======
echoless
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.

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

~~~
tinco
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?

~~~
jonnii
When you say "Ember seems to do too much", can you give me an example? I'm
interested in understanding why it has this reputation of being bloated.

~~~
mixonic
Ember, more strongly than any of the other solutions mentioned, pushes you to
a browser application (or SPA) architecture. Usually developers who complain
about bloat aren't thinking of web development in that context.

The number of challenges a framework should help a developer manage for a
long-lived client-side JavaScript application is not trivial. It is absolutely
true that Ember is heavier than other frameworks, but it has a specific style
of development in mind. If someone chooses to build their app with an
alternative, they often end up with a similar amount of code in other
dependencies and application code.

And though we aren't there yet, we're working on ideas for modular loading of
application code (via the pods patterns) and of Ember itself via tree shaking.
This latter strategy leverages the fact that Ember's code and much app code is
written in ES6, and thus we can identify and drop un-referenced code.

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

~~~
dejv
[http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#mai...](http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#maintenance-
consequences-and-rails-5-0)

------
cpursley
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)

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

~~~
r-s
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
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.

