What's new in Rails 5?

http://blog.michelada.io/whats-new-in-rails-5

by dabit • 11 years ago

113 60 11 years ago

blog.michelada.io

happywolf2• 11 years ago

Minor clarification: what i meant below is I plan to build a portal with major feature being CMS, not planning to rewrite an CMS from scratch, instead I will source in Github for the module that can be ported/plugged in right away with some modification.

-----

Right now, the web frameworks that are on my radar are: Laravel(PHP), Phoenix(Elixir), React+Meteor(JS), and RoR(Ruby). This list is by no means exhaustive, just that recently they caught my attention and I am contemplating to choose one for an upcoming CMS project.

Would like to know if these frameworks each has its own segment or/and sweetspots, or they kind of compete against each other and the choice is mostly personal preference?

The goal is to hear what people like/dislike on a particular framework. Inputs from those who have worked with multiple frameworks will be awesome.

Thanks in advance.

porker2• 11 years ago

choose one for an upcoming CMS project.

Thing is, none are CMS's. If that's what you need, why would you start with a framework? Sure it's fun to build and I always think I can do better than the existing CMS's do, but it's never a good use of my time - or good for the client.

Please, if you need a CMS, use a CMS. If you need a Content Management Framework (CMF) one of the above could save time. If it's an application surrounded by managed content, your choices are different again. But please don't reinvent the wheel if you can avoid it.

ryantownsend• 11 years ago

I agree with the above. That said, even if you are doing something new, you don't need to reinvent the wheel – it may be worthwhile taking a look at https://www.contentful.com/ (not affiliated, just an interesting service) and utilising their API to build an application which purely delivers the added value.

Jgrubb4• 11 years ago

I actually disagree. There's a big difference between reinventing the wheel - which happens because you didn't know that somebody else had thought of this before and already solved the problem - and building your own wheel because none of the off-the-shelf wheels work that great for your needs.

If this is a small business website and will never be built on ever again, then absolutely ignore the hate and go Wordpress. If it's something that might be extended over the years into use cases beyond just a webform to post an article with a title and a body then it's worth evaluating if you might be able to custom tailor a better fit for your business.

mrmondo2• 11 years ago

As someone who's hosted and fixed a lot of CMS in recent years I'll say this: choose a solution that's fit for the individual purpose.

All CMS' suck, a bit like all OS' suck. As soon as you do anything non-standard their inherit flexibility becomes a burden. If you have skills in rails and need an off the shelf CMS find a popular one and use it you like but if you need to create a web 'application' look at Sinatra, rails or whatever but don't use a CMS as the foundation for an application.

Most of all, if my team and I have one take away: Stay far away from Drupal and people that preach its relevance. It is a world of hurt with an 'expert beginner' community. That has cost so many organisations more time and money than they ever anticipated.

Treat ever 'off he shelf' product with a degree of disposability - don't get locked in and never get into the trap that you've chosen 'the best'.

egeozcan• 11 years ago

I've worked with Drupal 6 years ago. I think it was awesome if all you need is a web site with custom workflows in the content creation. It made you suffer, however, if you started to turn the web site into an app for the public (anything more than custom filters for your lists and I think you are in this territory). The problem is a typical web site (even in those days) almost always turned into an app.

mattmanser• 11 years ago

It's CMSes and OSes. You're looking for the plurals, so you definitely don't need to use a possessive apostrophe there because there's no ownership in the sentence.

Also, because they're acronyms you pronounce by enunciating the words, my instinct would be to use OS's (as you would pronounce the 's, O-S-es). But that's up for debate.

For example:

The OS's kernel blew up (possessive apostrophe, the OS owns the kernel)

He had a wide range of OSes to choose from (pluralization, there are many OSes)

bigbento• 11 years ago

I haven't used Laravel, but PHP tends to be relatively easy to get a development environment running as well as deploying on shared host type environments. On the flip side, the application becomes ever intertwined with the host environment, and beyond that, PHP libraries and frameworks tend to lack a lot of discipline that you find in other languages (that is, you find yourself pondering things like, "what if I were running this across many boxes, oh it'd just break..."), so 12-factor readiness (which helps when you want to run your app on more than one machine) tends to be an afterthought.

I haven't worked with Phoenix or even Erlang/Beam that much (though I've used Rabbit quite a bit). I think the overall model of the runtime is brilliant, but I'm not sure you need to buy in to the whole ecosystem to benefit from the learnings of it. There are actor systems for a lot of languages (Celluloid and Akka come to mind). Celluloid works nicely for weird long running things. I'm not totally sure how much it matters for your typical web app that would work fine enough with a CGI model (though I guess it's not totally different).

I've only played with Meteor, but I've used Node and React pretty extensively. React in particular is brilliant. It provides a nice way of thinking about the UI of your app in a more functional way. Of course, the devil's in the details, but it works pretty well. I'm less keen on Node as a backend language. A lot of backend code is between the lines, waiting on the DB or dealing with crazy errors. Node and JavaScript aren't very good at those things today. ES7 Async functions have some promise (hah!), but interoperating between libraries can be a little confusing at first.

Rails is an old friend of mine. You can do a lot with Rails, and it's almost sacrilege to say these days, but a well written monolithic, non-javascript heavy Rails app can be a joy to work in. It's pretty good for CMS type content; I've used it a bit to build various web stores to good effect. Things can get hairy when you try and step outside of "the Rails way", but that's less of an issue these days. It can also be a little funky using the asset pipeline with newer frontend libs, but there's that nifty source that packages frontend libraries as gems (the name eludes me at the moment).

nithinbekal• 11 years ago

there's that nifty source that packages frontend libraries as gems (the name eludes me at the moment).

Are you thinking of Rails Assets?

https://rails-assets.org

girvo2• 11 years ago

PHP is shared-nothing, how is 12-factor readiness something of an afterthought? I've worked on numerous PHP applications and services that are scaled out horizontally with less issues than I've had (with that specific use-case, PHP as a whole still has other issues) in doing the same with Node at times. Basically, I'm curious what sort of libraries you're talking about where horizontal scaling breaks them?

grey-area• 11 years ago

If you need something complex and bespoke, build it yourself with something like Rails/Elixir/Whatever - your choice will depend mostly on your preference of tools/language/community as they are all quite flexible if you know them well.

Rails is suitable if you're greenfielding a complex new site (as would be Go or Elixir), Laravel probably if you like PHP (haven't used it), definitely not Drupal, Typo3, Wordpress etc if you are thinking of extending them in any significant way. Meteor doesn't strike me as particularly suitable for a CMS. Django might be worth looking at as it has built-in admin which is more CMS-like than others?

Since you mention building a CMS, my 2 cents on that:

If you need something very simple which is a good fit for a particular CMS and/or are on a very limited budget, just use a prebuilt CMS product and adjust some templates, otherwise you're reinventing a lot for not much gain. Doesn't sound like you want this option.

If you are producing a bespoke site consider writing most of what you need from scratch rather than trying to use modules/plugins etc. because the capability to use modules/plugins tends to invert authority in an app, and require you to do the things the framework way or not at all. Every bit of code you import from elsewhere comes with a significant cost in maintenance, security and complexity. So don't choose a framework in the hope you can just plug things other people have written together and make it all work.

Avoid CMS products which try to allow the end user to customise records (custom fields, nodes etc), install hundreds of badly written modules, and do a limited form of programming by manipulating records or templates in the database (I'm thinking of things like Drupal and to a lesser extent Wordpress). If you try to use them for something complex it will usually lead to an unmaintainable morass of poorly understood code.

girvo2• 11 years ago

I despise Wordpress, and have definitely shaved off too many years of my life struggling with its utter insanity that is its core/plugin ecosystem... However, check out Themosis. It's basically dragged Wordpress kicking and screaming into 2015, and considering clients will still sometimes demand the familiar Wordpress admin if you live in agency land, it's a worthy framework to have in your toolkit.

aikah• 11 years ago

Laravel(PHP), Phoenix(Elixir), React+Meteor(JS), and RoR(Ruby).

All solutions have trade-off. Obviously rails isn't adapted if an app is focused on websockets, Elixir gives you good primitives for distributed programming and PHP runs on cheap hosting. Rails is really like "ok , I have like 2 weeks I need to develop a complex CRM for a client" , something in my opinion that cannot be pulled off that quickly with other solutions.

But yeah , there is no silver-bullet. When I read articles like these I wonder if the author really believes it or if he is trolling :

https://www.linkedin.com/pulse/go-dominate-next-decade-ian-e...

Every solution has its share of problems,even Go.

happywolf2• 11 years ago

Thanks. Very insightful and informative. Great input.

Jgrubb4• 11 years ago

Currently working for a company that has all of it's websites in Drupal, so my team is versed in PHP. I've been working with Drupal for 7 straight years.

I have this dream of not having to work with Drupal ever again, so I often daydream about what I'd build if I were given the chance. In a sense I'm in the same position as you, except that it's probably never going to happen and that I've been thinking about this for years.

I'd go Rails, and here's why.

Rails is easy to learn - even if your team has never written Ruby it's an easy language to pick up with way fewer gotchas than either PHP or JS. I've evaluated Laravel, and it's probably the best PHP option out there right now, but knowing Rails, I often find myself hating how much code you have to write to accomplish the same thing in Laravel just by virtue of it being PHP. The resulting code feels clunky (though, that's surely just because I also suck at programming).

Rails is extremely mature - it's been around for over a decade. The upgrade from 2 to 3 was painful, the upgrade from 3 to 4 was much less so. I imagine the upgrade from 4 to 5 will be as well, and so on. The ecosystem is very filled out, the package mgmt story is there, the testing story is there. These are new developments on the wider PHP scene that will probably takes several more years to reach the level of adoption and familiarity that Ruby enjoys. I love writing JS, but the whole ecosystem over there is in this constant state of tectonic upheaval right down to the language (ES6), and unlearning the old gotchas so I can learn the new ones doesn't appeal to me right now.

Rails is exceptionally well documented in terms of blog posts, the Rails Guides, and the API docs. None of these other technologies even come close. This is especially true of Laravel, and I've only ever read 1 blog post about Phoenix, so good luck with that.

This was supposed to be short, sorry.

berkes3• 11 years ago

so I often daydream about what I'd build if I were given the chance. In a sense I'm in the same position as you, except that it's probably never going to happen and that I've been thinking about this for years.

This was me, until three years ago. I am freelancer, all my gigs, clients and my whole network was about Drupal. Hell, I still receive requests for Drupal work on a weekly basis: my name was established, so almost impossible to move out of Drupal.

So I wrote some op-eds on why Drupal was not always a good choice for projects (most notably: government projects) citing from my experience as rescue-consultant-for-failing-drupal-projects.

And then I wrote http://berk.es/2012/10/01/farewell-drupal/ and declined all work Drupal related.

It does not have to be Rails. It could be Opal, Django, Spring, Symphony, Yii, anything. But if you are really unhappy with Drupal, as you seem to be, cut the ties. There's more then enough work out there.

And working in an environment that is built for developers (instead of building a webapp by clicking checkboxes and clumsy html interfaces in the Drupal backend). Move to a community that encourages clean code, "craftmanship", designs, patterns and so on, you will become a better programmer. If that is what you want.

I'm now a happy Rails developer. Who learns new things every day. I like my job a lot; so much, that I can't imagine not coding for work (And already I am almost always that Old Guy on the job). In ten years it'll probably not be Rails anymore, but WhateverFancyFramework is the default then. And because within Rails I really learned coding, picking up new languages, frameworks and whatnots is not that hard at all, anymore.

bshimmin2• 11 years ago

This is a great summary, and there look to be some really interesting things coming in Rails 5. Two thoughts:

1) I hope ActionCable is as seamless to integrate and works as well as Rails features ought to; you can, of course, achieve web sockets right now using Faye or various other implementations, but it's quite complex to get right (though the faye-rails gem is pretty handy) - and realtime functionality is becoming more and more important.

2) I wish they'd just give up on Turbolinks. Maybe some people are using it and love it, but it's always the first thing I turn off when I start a new Rails project, and I know quite a few people who feel the same. For those of us who never thought it was a good idea in the first place, I'm not sure any number of improvements are going to change our minds.

giuseppeciuni• 11 years ago

I totally agree with your 2 point. I always turn off turbolink too when I start a new rails project!

skrebbel• 11 years ago

I didn't use rails since turbolinks appeared, but I really like the idea on paper. Why do you turn it off?

technion2• 11 years ago

2) I wish they'd just give up on Turbolinks

Ditto for Coffeescript. I realise you can't just remove it, but the whole dev community is raving about ES6 - there's a whole of JS devs who could be a lot more interested in Rails.

danmaz74• 11 years ago

Turbolinks can create problems even to those who don't use them explicitly, but Coffeescript can't: if you don't like it, just don't use it, and it's as if it wasn't there. How would removing it from the asset compiler help you in any way?

KurtMueller5• 11 years ago

You can choose to not use coffeescript in any Rails project.

As for ES6, there is the sprockets-es6 gem. According to their github gem, their goal is to get in es6 support into sprockets 4. This, obviously, is not a perfect solution - but I think this is going in the right direction.

rcaught2• 11 years ago

I used to disable Turbolinks as well, but I took the time recently to use Turbolinks 3 (off master) in a project and have been really impressed with what you can achieve.

The server-side partial replacement, for example, is wonderful.

headz• 11 years ago

2) Why? Have you ever tried it? I use it on all my projects and it works great.

ksec• 11 years ago

I thought DHH recently announce on Twitter there will be Basecamp 3, which is based on Rails 5.

And there will be Turobolink 5 too.

I was guessing they have some more things to announce soon.

rcaught2• 11 years ago

Turbolinks 3

littlewing2• 11 years ago

I'm a long-time Rails developer and unfortunately this release doesn't excite me, though I appreciate all the hard work by the core team/continued support from 37signals. The reason is this:

The intent of Rails is to make writing web applications easier, but that writing web applications actually got much more difficult for me as a Rails developer when Angular and Ember and then later React got popular. I love Ruby, but I respect the fact that the Javascript-client-side-heavy/"single-page" part of the app is where the magic is for at least a few years now- really several years.

Other than Rails helpers in the 2006-2008 timeframe being a big deal, Rails' has not ever really helped out a whole lot on the JS side, and you wouldn't expect it to. The asset pipeline is wonderful, and coffeescript support with in it is ok I guess, even though I don't use it. But, writing JS client-side is not any easier. To be a full-stack developer in today's world I have to accept the fact that Ruby, as much as I love it and would rather develop in it all day and night, is just not taking over in every facet of development. There is no Rubyscript on the client side taking over the world. There is ES6/Typescript- that is the future.

A substantial number of Ruby masters are jumping over to the Phoenix/Elixir bandwagon. I look at it, and want to like it, but I just haven't gotten into it yet. I know it is fast, but it just isn't as readable yet for me. And it won't solve the problem that the client still needs to be written primarily in Javascript.

And the answer is not Node either, because every serious Javascript developer I've talked to says, "Node is still not ready."

I just feel let down. I want to get excited about Rails again, but give me a path. I don't really like Ember a whole lot, because the community is just not where it is with Angular and React. Someone please take your favorite frameworks and show me how my life is supposed to get better by using them. Show me how it is fun. Bring back the magic, because right now it all just seems like more and more of a PITA as attention deficit has fully set in within the web application development community and there is no clear way ahead for the next few years.

kailuowang• 11 years ago

I think you can try solve the "rails no longer excites me" problem by finding a more exciting language than Ruby. There are more than plenty of them out there.

littlewing2• 11 years ago

Like what?

When considered as a whole of the combination of what is possible with the stdlib and all of the best gems available, Ruby can be written clearly and tersely. Those are the two first and most important things that I look for to do general web application development. From that perspective it beats Javascript, Python, Php, Java, C#, Go, Scala, Erlang, Haskell, OCaml, and every other language I've used.

I'm not saying Ruby is the best language ever. It has its flaws. In a few places in the stdlib, it doesn't make sense. There are languages, with maybe Smalltalk and Lisp at the top of the list, that beat Ruby from a simplicity and purity standpoint. But, Ruby is just great to use. I love reading it and love using it. It took a few years in the beginning of love and hate, but if I was stuck on a deserted island and had one programming language, Ruby would be it for me.

If it weren't for the Ruby core group being so exclusive and bitter towards others getting involved to make it even better, and if it weren't for the Rails core team just having too much to do and being unable to execute on support, documentation, performance, clarity, simplicity, and important features all at the same time, then maybe it would be the world's number one language and Rails would be the number one web framework.

Instead Javascript had emerged years ago as the language of choice in the browser, had plenty of attention spent on making it execute quickly, etc. though it was an uglier language than Ruby, and because of that attention, it is today's number one language for the web. But, I still like Ruby.

usethis• 11 years ago

I am excited about Rails API becoming an official part of the Rails ecosystem. I don't expect Rails to solve my client-side needs (templating was always slow, sprockets suboptimal), but I love to use it as an API and have a simple node server to proxy my website calls to that api. An additional benefit of this is that your client consumes the same API, as your other clients, so you don't have to worry about two api versions anymore and it improves your TDD.

ocean3• 11 years ago

Rails API and react-rails gem should be good combination.

michael_fine• 11 years ago

What's their rationale for saying That Node is not ready? I've found it to be stable and performant, and if it doesn't have quite the volume of useful libraries Ruby/Rails does, it's certainly fast approaching.

KurtMueller5• 11 years ago

Rails has always given me conventions to follow when creating/writing apps - except for javascript. Rails never really had any conventions for writing javascript. Hopefully, you and your coworkers had good habits when writing/organizing your js, but rails never really gave you any guidance except to throw it in your apps/assets/js folder.

There is ES6/Typescript- that is the future.

According to the sprockets-es6 github page, its goal is to have es6 functionality in sprockets 4 by default.

Node is still not ready.

I'm not quite sure what you mean by this statement. It's very ambiguous.

Anyways, you might want to look at MeteorJS. It's a rails-like framework in javascript. It's not ready yet if you want to use a database other than mongo.

I just feel let down. I want to get excited about Rails again, but give me a path.

One of the lessons that I've learned working with OSS is that we as individuals & developers are responsible to create these paths. The people who develop Rails & other awesome oss are just regular janes/joes like you and me.

I don't really like Ember a whole lot, because the community is just not where it is with Angular and React

The ember community is not as big as Angular's or React, but it definitely does exist & is very friendly helpful.

IMO, Ember (along with Ember-Data & Ember-CLI) is the Rails of the js frameworks, it follows strong conventions and comes with a lot of magic right out of the box. You should check out their guide - perhaps they could have an overview that actually states the features that come out of the box.

dakull• 11 years ago

Not really sure why you say that whilst TL3 tries to solve exactly that issue in a simpler, classical way [0]

I love the idea of being able to use the usual Rails helpers combined with JS in a React-kind of way and at first sight that's what TL3 could manage to do.

[0] by that I'm referring to the clean HTML that still looks semantic and has all the normal separation of views and styles whereas in React et al if one's inspects the code is just looks horrid.

Regarding SPAs the isomorphic approach seems really contrived at this point and for most web apps TL3 seems like an elegant solution whilst keeping the full power of Rails intact.

Sure there are cases with heavy UI apps that require components et al but for my use cases TL3 + Rails5 looks like a breath of fresh air, maybe a middle step to full SPA.

notNow2• 11 years ago

[0] by that I'm referring to the clean HTML that still looks semantic and has all the normal separation of views and styles whereas in React et al if one's inspects the code is just looks horrid.

Even though I'm a JS-first dev but I second that. ( HTML & CSS in JS ) is a bad idea and not considered to be progress from the messy yet working templating engines (JS in HTML).

Proponents love to argue that integrating HTML & CSS into JS makes it easier for testing since JS is amenable to thorough testing as opposed to HTML & CSS.

While this is partially true and template files are not straightforward to test esp when you throw app logic into the mix but it still manageable if you kept to a minimum to the view part only and don't go overboard with it.

Also and this is very important, It's a given that HTML & CSS are forgiving compared to JS when it comes to errors but that doesn't mean that it's unlikely for a developer to shoot himself in the foot or to introduce unwanted/unintended bugs in the app through them esp. CSS and these usually are harder to catch and fix.

uptown• 11 years ago

"That's the power and diversity of web programming! As long as it spits out HTML, you can power your server by steamboat, no one knows/cares."

https://twitter.com/dhh/status/576425023222755328

33degrees• 11 years ago

"And it won't solve the problem that the client still needs to be written primarily in Javascript." Nothing's going to solve that. But rails could definitely work on making working with Javascript front ends easier. As great as Sprockets is, it doesn't fit so will in modern JS workflows.

atwrkrmrm2• 11 years ago

I'm the opposite. This release excites me more than it did for Rails 4.

Turbolinks 3 sounds like it's going to be real nice. My biggest reason for using SPA's are not the components, or the data flow, or the states, etc. It's for the partial rendering and the nested views. With Turbolinks 3 coming out, if it is as advertised, then I will pretty much be reaching for Rails for most of my projects.

I've moved on from Rails to Node for websockets. For ActionCables, the real-time library for Rails, I have to admit that it does kind of sound like a PITA to have a second server running for it. Doesn't sound right. But I can't judge it before it comes out (nor do I really have any right to judge. It's so easy to be entitled as a FOSS user). But if it is a pleasure to use, just like the rest of the Action* family, then that's another nail in the coffin for my use case for anything else. But then again, my needs and your needs may be different. I usually build small to medium sized apps that will never hit 4 figures in terms of users.

It sounds like you're looking for that "magic" you've felt when you first got into Ruby and RoR. We all do! But things like Rails once comes once in a blue moon, so even though it may not be the new hotness, I just like to appreciate that it happened. I don't think you'll find any other tech that will give you that "this is it!" feeling like Rails did for a long while.

In the mean time, instead of stressing out about tools, just focus on writing good software.

LunaSea• 11 years ago

Is it more security vulnerabilities ?

issaria• 11 years ago

Without a doubt, it is time to prepare our applications for the upgrade; just because of the performance improvements are worth it. If you are on Rails 4.x, the upgrade is almost painless.

Shouldn't it be called Rails 4.3? That been said, you could get the performance improvement by just upgrading to ruby 2.2.2

ownedthx• 11 years ago

I'm not sure if this is baked into Rails 5, but you can get es6 support (via Babel) with the sprockets-es6 gem:

https://github.com/TannerRogalsky/sprockets-es6

Rails is still a second-class JS citizen due to the asset pipeline being opinionated and controlling compared to the node way of doing things, but it gets you closer to 'the new hotness'.

atwrkrmrm2• 11 years ago

What do you mean JS is still a second class citizen? I'm unfamiliar with Rails asset pipeline. Do you just mean that the asset pipeline doesn't really have as much features as other build tools like Grunt and Gulp? Or is there something about asset pipeline that prevents you from using JavaScript to its full potential? (Genuinely curious. Not familiar with the JS side of Rails)

What's new in Rails 5?

Related Stories