It is great to see another milestone is almost done and stable version will be released soon.
Highlights for me will be:
- Actioncable (real-time communication over websockets)
- Rails-API is merged into core.
- Min ruby version is 2.2 (performance improvements via Garbage Collector)
- Little bit of code cleanup (less code to run)
- Turbolinks 3 (single-page applications)
- Evented file system monitor (faster development environment)
I think they have done a great job with the release. Especially removing Celluloid, Redis, and EventMachine as a dependency for ActionCable part.
I only have one small concern about the Turbolinks part. It hasn't been my choice until now for the projects because of the compatibility issues with other libraries. It always felt like the Quicktime player on Mac OS. Sure you can use it but you better off with something else.
But I really want it to be something i can use out of box this time. Partial rendering is not there yet but lets wait and see how it turns ut.
You're wrongfully trivializing Turbolinks 5. The whole point of using it is so that you get an incredibly responsive experience without having to resort to bolting on a front end framework and maintaining essentially two application states. This is a huge productivity boost.
Furthermore, the optimizations that TL v5 provides means that you can use your webviews for mobile and get an incredibly responsive experience. That is what they are doing with Basecamp and they're able to provide a first class mobile experience on iOS, Android, a desktop app, all with a team of 12 developers (https://m.signalvnoise.com/the-majestic-monolith-29166d02222...). That's fucking impressive. On top of that, they've release the generic iOS and Android wrappers so that you can roll your own mobile applications with Rails and Turbolinks.
There's no other framework out there that remotely comes close to providing that value to the end developer.
The market demands that your app be present on multiple platforms, which is usually a fucking nightmare if you're a small dev team. These Turbolink additions now give you a fighting chance.
Turbolinks is great for some use-cases (like Basecamp for example). But it is not for everybody. It absolutely sucks for other use-cases.
Among other things, since its inception it has messed with the CSS heirarchy, resulting in the fact that by default it loads all the CSS and JavaScript for all pages, in an order you probably don't want. (Note: there is a reason the "C" in CSS stands for "Cascading". It wasn't designed to all be loaded at once.)
If you DO want "one page apps", then fine. If you don't, and you have a significant site with more than a couple of dissimilar pages, it will probably be more performant if you disable Turbolinks and load only the JavaScript and CSS necessary for a given page, i.e., the conventional approach.
"will probably be more performant"..? How much more performant?
"sucks for other use cases"? Which use cases have you use TurboLinks where it wasn't a good fit?
Basecamp isn't a trivial one page app; it has over 200+ screens.
For page changes, CSS is generally scoped by controller action classes. Quick look up by the browser, penalty negligible.
All of the JS is loaded, but again, you can invoke the needed js for the page by looking at the body/action selector. Again, a few if checks on the "page:change" callback.
Weighed against the traditional: a full request to the server which includes a download of relevant CSS for the page, a download of relevant javascript for the page, parsing of that css, parsing of js, and then execution of that js.
1) The use-cases in which not all JavaScript or CSS is (or should be) loaded up front. There are many such. You should be able to think of several just off-hand. I can.
2) "Basecamp isn't a trivial one page app; it has over 200+ screens." I didn't say it was. Read again. However, Basecamp IS written in such a way as to heavily rely on Turbolinks.
3) "For page changes, CSS is generally scoped by controller action classes. Quick look up by the browser, penalty negligible." Not in our tests with Rails 4.2.
4) "All of the JS is loaded." Yep. The rest of your sentence is not relevant to my point.
You seem to think my objection was that there is some kind of difficulty accessing specific CSS/JavaScript under Turbolinks. Nothing of the sort. Rather the opposite, really: it was that there is too much loaded, specifically in ways that disrupt standard CSS hierarchy.
Obviously that can be compensated for by scoping. That wasn't my point. The point was that IT WORKS DIFFERENTLY THAN THE STANDARD CSS HIERARCHY. Understand?
"Weighed against the traditional: a full request to the server which includes a download of relevant CSS for the page, a download of relevant javascript for the page, parsing of that css, parsing of js, and then execution of that js."
There are times when that is desirable over having that CSS and JS always loaded. I get that you don't seem to be able to think of any, but we've encountered many.
I'm not going to get into an argument with you here about which is "better". Which you seem to want. I simply said there are use cases that are appropriate to each.
Turbolinks 3 (now known as Turbolinks Classic) is old news. Rails 5 will ship with Turbolinks 5 and 5 has no support for partial rendering.
I tried partial rendering in TL3 and liked what it did. I then moved to TL5 and couldn't figure out how to migrate my code that made use of the partial rendering feature. It'd be nice if they provided a better upgrade guide on how to accomplish similar tasks between TL3 and 5 to make the transition easier.
I got stuck in the same situation but caught onto the issue tracker before I got in too deep. You should check out turbograft from Shopift which is what inspired partial rendering in the first place.
How long has it been since you've used Turbolinks? I've been using the Turbolinks 5 beta with not a lot of issues. Of course, I used this from the get go with a new application.
You should try it again. It's gotten quite good at automatic reloading. I use it with Rspec and as long as you've got spring-commands-rspec[0] installed, it's never a hassle.
Agreed. I've been using spring for about 1.5 years now and it has saved me huge amounts of time. The only time it hasn't picked up changes was on initializers and the router, which is understandable. I can't imagine developing without spring. I would be restarting rails hundreds of times per day.
Same here. AFAIAC, the default Rails setup has been leaning more and more toward a Basecamp-specific kind of use case, rather than the generalized tool it started out to be.
Turbolinks messes A LOT with conventional design. Unless you really want the "one page" approach, or have a small, simple app or site -- or even if you just want to design a site using normal CSS conventions -- then Turbolinks gets disabled right away.
Fortunately, we can still do that. I can legitimately question the decisions made regarding default settings, but at least those settings can be changed.
40 points and no comments... Can we please discuss this?
I would like to know if this makes Rails worth learning for someone who knows Ruby but doesn't know rails. I have found my ruby knowledge to be less than marketable, and I want to step my game up. What do yall think?
I'm a big Python evangelist for reasons lost to history, but even I would recommend learning Ruby on Rails if you want to make yourself marketable. I'm not sure how much of a market there is out there right now for people with Rails experience, but it never hurts to learn something new.
Besides, whether you chose to use Rails, or Sinatra, or move to some other language, as long as you are doing web development you'll be able to apply the concepts learned. So I say go for it!
I've noticed there seem to be a lot more remote Rails jobs than anything else (other than Javascript). I know some Ruby and am also thinking about Rails, despite my preference for Python- there just so few Python or Django remote jobs unfortunately I need to broaden my horizons.
The problem is that the maturity of the Rails market means that most Rails positions require X number of years experience - I can certainly pick up Rails but those years of experience have to come from somewhere.
EDIT: not entirely true, as there are a lot of PHP jobs. However these include bottom-feeder Wordpress gigs and generally pay much lower salaries than other languages, right or wrong.
I know a few other languages, they just aren't nearly as marketable as Ruby. I've learned Lua, Scheme, I know a little bit of Julia but most of the stdlib is over my head mathematically. I've fallen in love with Ruby because it seems to be how I 'think' about problems. I just never really had the motivation to learn Rails, I always hear people complaining about it, I've never needed a website or anything, I don't know. It just never happened.
Like the parent commenter, I'm also a huge fan of Python. I've recently started my journey learning web dev using Scala. It's a pretty hot language right now, what with the rise of big data and ML (see Spark for example). It allows you to use existing Java libraries, yet there still is a considerable number of high-quality libraries written in Scala. The stack I've chosen is Scala + Play + Slick, but there are several popular options.
We've begun to use Elixir and Phoenix at work, and it's far nicer to work with than Rails - there's far less magic going on, and being functional, there is much less mutable state to keep in your head. That said, I still miss a rich type system. Typespecs can get you some of the way, but they're unreliable, and there's no support for parametrically polymorphic functions so far as I can see, which limits the usefulness of protocols for typechecking purposes.
Static typing is not a single issue. It is several.
From a high-level-language standpoint, static typing is a crutch. It isn't necessary, but it forces you to do things "the right way"... according to some definitions of the right way. It is possible to make mistakes without static typing that you would not make with it... but if you're careful you can also do some good things without it that you can't do with it. It all depends on whether you feel more comfortable with taking control or you feel the need for some restrictions to keep you "in line".
From a purely performance standpoint, there is no question: static typing compiles/interprets to faster code.
> From a high-level-language standpoint, static typing is a crutch
I see types as a high-level design tool. They allow me to reason about a domain, and figure out how to structure things at a high level before delving into the implementation. Yes, performance is a great side-benefit, but it is not always the driving factor.
As someone who used to do (still do a bit) C and Ruby for embedded stuff but now does RoR for an ecommerce site, webdev can be a soul-crushing mind-numbing bore, but there are jobs and it pays. Rails is decent, especially if you are working on a site where server costs are not a significant factor in site costs. It is worth learning.
Germany is mostly Java or heavy embedded stuff.
I mean one of the biggest shop is probably Zalando which uses Java/Scala/Python.
And as far as I know otto.de is on the JVM, too.
I find interesting how some countries (or rather, the industries in those countries) seem to specialize in certain stacks. Back when I lived in Brazil, Delphi used to be huge there, even though it had already kind of died everywhere else. Argentina seemed to be doing mostly Java. I guess it has to do with the kind of consulting companies that hire the bulk of the software engineers in the country.
It'd be great to get something like the TIOBE index, but split by country, although I guess I'd try to bias it a bit heavier towards commercially developed LOCs.
It not only teaches you Rails, it teaches Github and Heroku and gets your first first web app deployed at the end of the first chapter. And, it's free!
There is also enormous hiring market for Rails developers.
I'm not sure about that. Search Indeed.co.uk's API (which removes duplicates) for - "Ruby" title:(Rails or RoR) - and you'll find 101 jobs listed in London. Repeat the search for United Kingdom and there are only 158. So 64% of Rails jobs are in London. Compare that with PHP - 2102 jobs in the UK, 672 of them in London and you find a more even distribution and a much higher number of jobs. Rails is still a niche framework and has never come anywhere near matching PHP's adoption despite all the hype.
I almost want to say thay this is an unfair comparison but that would also be unfair.
Nothing matches PHP adoption. It started 10 years before than Ruby and Python web frameworks and its runtime model is ideal for free hosting. That gave it mindshare and market share. It's still one of the ugliest languages even if it's slowly getting a face lift.
At the time its competitors where Java and Perl. Perl could have the same runtime model and was the first language for the web thanks to CGI.pm. PHP won because its simplicity and the commands embedded in the HTML page. Java is another world and only suited to corporate developers especially because there could be hardly a free Java hosting. Any of them now, not counting the AWS Lambda free tier?
How well paid are PHP jobs compared to Rails? I know the UK has abysmal salaries for developers (especially outside London) but the average salary for a PHP developer [1] is in a class of its own, much less than Ruby [2].
Yeah, but what percentage of those PHP jobs involve customizing a Wordpress site? I personally wouldn't touch any of those with a ten foot pole.
Besides, PHP codebases are notorious for being incredibly messy. PHP as a language used to suck big time, so you'd be taking over lots and lots of legacy code that would make you cry. That's nowhere as big of a problem with Rails: it's newer and Ruby is a joy to work with.
If you have strong opinions on how things should be done with a web framework, I would suggest, for the sake of sanity, to purposefully learn Rails with an open mind and just let it do what it wants to do. When you learn it that way, it doesn't take long to figure out.
throwing shit together is insanely fast. i mean insanely. once i had a friend who was asking me for a time estimate on building a backend for his iOS app (mostly crud with a couple search routes) and i just did it for him in thirty minutes.
Yeah that's the incredible thing about Rails. It's just so fricking fast to set up a project. I kinda feel like it's going out of fashion - being eclipsed by Node mostly -and that sucks because I've never found another framework that is as simple and quick to work with.
Rails is nice, at least in the beginning. It's easy to pick it up and build something trivial, but it's pretty hard to solve some non-trivial issues -- you have to learn the framework internals. While, "frontend" side in Rails is pretty easy to grasp, internals are much harder, in my opinion (due to a very large codebase and Ruby's flexibility).
It is definitely a convenient tool, designed with programmer happiness in mind -- so there're a lot of things which will make your life easier. Although, sometimes this UX-centric model backfires and we get such things as RSpec.
Finally, it depends on what you are trying to achieve. If you are into money-side of the question, then maybe JavaScript ecosystem might be more worthwhile. Although, I believe that it is possible to bootstrap demand around tools that you are passionate about if you convince others to think the same way. My point being, that maybe you should look at the technologies that you love instead of following the market hype, but this is more harder and also means more time investment, but it pays off in the future.
The most important lesson I've learned from Rails is that you always have to learn the framework internals. If you're doing anything non-trivial, there will always be very helpful undocumented features, a much, much easier way to do things, and you can know how to build out entirely new functionality and keep it consistent with the core system so future developers don't have to learn every detail of your solution.
I'll bite. If you know Ruby, I'd definitely recommend taking the next step and learning Rails. I started with Plain Old Ruby first as well by writing small scripts and then slowly graduated to Sinatra and ultimately Rails. Unless you are using Ruby for DevOps you can almost never go without having to interact with Rails or it's components in some way.
To be fair if you know other programming language like php and have used mvc of php you don't really need to specifically learn ruby before starting using rails, you can pretty much learn it on the go I think, at least that worked for me
As long as people go into that realising they are learning Rails and not Ruby. So many Rails developers get totally lost if they're asked to do something in plain Ruby because they don't know what the differences are.
I know a little about a lot of things, but I know least of all about web development. I worked my way through some Sinatra tutorials and through the Cuba.rb book, but I just never got into it.
Are there any books that you'd recommend or anything?
Personally I find the most effective way to quickly pickup something is by using it in a project. I'd recommend some of these starter projects that you can download and start hacking: http://railsapps.github.io/
For learning RoR, I can't really recommend enough Agile Web Development with Rails 4 (although you might want to wait for a revised v5 version to pop up).
It takes you through building a simple site with a shopping cart from scratch, and lets you encounter enough real-world style situations to give you a really good grounding.
If you understand Rails, you'll have a better grasp of a lot of the other web frameworks out there that have been inspired by it. So even if you don't use it in the future, learning it may be helpful.
Rails will be useful regardless. Even when I am not working on a Rails project, I still use rails in some manner or another. Be it stubbing out a temp api for an Angular front or sculpting out a Schematic during planning. Over the years it's been an invaluable tool.
I get plenty of contract to hire jobs for rails to my inbox from linked in. Pay rates are usually $70k+, sometimes going above 100k for sr positions (for Austin and Dallas areas). So I'd say if you like ruby, then go for it. I don't really like ruby though, or rails.
Or course you should also learn some front end stuff too and be more full stack worthy, especially with ajax powered
APIs.
Are there anyone that can chime in on the current long-time support story for rails? How much commitment could one expect from the Rails community towards long time software life-cycle? To clarify, if I want to implement a solution (say a web/service portal) now, that I have a reasonable dev budget for, and a commitment to maintain with security updates (and bug fixes) for, say the next 10 years -- is rails 5 likely to be a viable solution?
I always had the impression (possibly false) that the Rails community was very focused on rapid development, but that it had a tendency to leave dead projects on the road-side to fend for themselves -- and that maintaining a project that was a few years old sort of implied massive forward-porting if you wanted to have a semblance of security updates?
Is my impression way off? Is there a "safe path" if one sticks with the Rails core?
Rails has really stepped up their game after Rails 3; really nailing down the API and conventions. Upgrades are much easier now (Moved from Rails 4.2 to Rails 5 in an short afternoon).
Just definitely keep up with the minor releases; but the major releases will stay in good standing for a while too! Lock down all your gem versions and only update as needed; so if they ever break on a move to the next major version - you can act accordingly.
At RailsConf this week Jeremy Daer specifically mentioned that Basecamp (formerly 37signals) was maintaining projects deliberately on older versions of Rails.
According to wikipedia, Hacker News Launched February 19, 2007; 9 years ago.
[ed: Other things off the top of my head, AFAIK both from the 90s: slashdot.org, webhostingtalk.com, twitter is from 2006 (obviously twitter and slashdot have been pretty much rewritten, not sure about wht.]
Rewritten is not the same thing as having to upgrade a library. Even most enterprise apps upgrade the big libraries within 4 or 5 years due to the CVEs that pile up (see struts 1)
Super excited to see Rails 5 hitting stability. I've recently built a production Rails API on 5 (the beta -- it's been shockingly stable) including ActionCable, with a React + React-Router frontend, handling a pretty good-sized production load on Heroku + Passenger. AMA if you want a developer's/user's perspective on Rails 5 :)
Thus far, peak at about 3000 REST requests per minute and 400 simultaneous ActionCable (websocket) connections. We're still scaling up the app, as we just launched it about a week ago, but we haven't yet hit the limits of the platform.
Actually just 1 Performance-M dyno. With Sidekiq for external/resource-intensive requests, and a pretty large pool configured in Passenger.
ETA: It doesn't get as much press, but ActiveJob is one of my favorite parts of Rails 5. It's an agnostic implementation of background jobs -- ActiveRecord : (Postgres, Mysql, etc) :: ActiveJob : (Sidekiq, Resque, etc). Very nice, flexible syntax and it helps make your application platform-agnostic.
Second ETA: As rapind pointed out, ActiveJob has actually been available since Rails 4.2.
For those on the fence about learning Rails it's one of the most in demand frameworks out there. I don't just mean in terms of sheer numbers node but in terms of awesome jobs associated with it.
I don't know about where you live but in the UK job market, as measured by Indeed.co.uk, PHP:Rails is 13:1 with only 158 Rails jobs in total, 2/3 of which are in London. That's hardly "one of the most in demand". I say this as someone who dislikes PHP intensely. It's just so frustrating when you've invested so much in learning Ruby & Rails to then find jobs are very thin on the ground.
I don't think job sites are really the best metric for Rails jobs - in my experience no one bothers posting them there because the people who know Rails well aren't trawling job sites for work.
When I was looking for a new job recently I was mostly looking at places like Stack Overflow jobs, along with the London Ruby User Group mailing list which tends to get three or four job postings a week - I haven't looked at a mainstream job site since about 2008.
If you want a better sense of how much work there is add a few years of Rails experience to a Linked In profile and watch the recruiters start circling.
There have been points in the last few years when the volume got to the point of people asking to have a list specifically for job postings to prevent other stuff being drowned out.
I once posted my resume on resumerabbit.com (at the time with a mere 1 years experience with rails) and I was harassed by recruiters for nearly half a decade. (US)
Aside from the latter having a smaller dev environment and community, what's the status of Rails vs Phoenix (Elixir)? Not trying to start a war (I like both)—just wondering if this release changes things.
I've been enjoying just thinking about problems differently. I know it doesn't sound like much but elixir has been my first foray into functional programming and it's been really fascinating to digest.
I'm looking forward to wrapping my mind around Phoenix and already planning to do a small subscription app with it where it happens to be a perfect fit.
My guess is that you'll see people who were hitting the limitations of Go end up moving to Phoenix. For Rails users coming to it there are still too many "library x for Phoenix" questions out there.
Elixir is great but it's still not ruby. Much like Go, it's not something you can fully appreciate until you've seen the limitations of other approaches first hand. There are so many things that Phoenix and Elixir do that solve major long term problems and ruby's biggest selling point is usually the short term.
I've been developing for Rails since around the 1.2 days. For me, ActionCable seems to excite a lot of Rails developers, but it's no Elixir.
2015 is a watershed year for the Elixir ecosystem. It was like this back in the Rails 1.2 days. Back then, people said the same thing about Ruby. "Ruby is great, but it's still not X."
The idea that Rails is very fast for doing quick development is, at this point, a myth. It takes thoughtfulness to write good code, regardless of the language. There's this idea that you can put together a prototype quickly, but in the wild, it ends up being a repository of sloppy code resulting from fuzzy, superficial thinking.
Another situation I have seen is this the "perpetual MVP". That is, sacrificing code quality because you don't know if the product is even something that people want. However, when your MVP has users and it starts getting traction, it's not an MVP anymore. The fragility that comes from sloppy coding comes back to bite you. I think developers confuse Ruby's agility with their own sloppiness.
I think Elixir is interesting not just because it solves those long term problems, but it is also as agile in the short term -- provided that you are not a sloppy coder.
I can't disagree with any of that. The biggest thing around prototyping for Rails at least is how close it comes to aspect oriented program thanks to the ability to pull in libraries that inject themselves across multiple points of your application, like Devise for example.
That and the ability to monkey patch something from a 3rd party library without breaking your upgrade path, having to fork it or needing to adjust the entire inheritance chain. It's not good practice to do too much but knowing you can make using all those gems a lot easier.
This is my main issue with Rails; this feeling that every project that I'm working on is a rolling protptype. It's so, so easy to build out the initial functionality, then it becomes a slog, and I guess that's very much down to how monolithic Rails is
"you'll see people who were hitting the limitations of Go end up moving to Phoenix"
This is oranges and apples. First, you're comparing a language to a framework. Second, use cases for these two barely overlap. I'm a huge fan of Go and I started using Phoenix for web development and I can't really think of a scenario where I'd have to think which one to choose for a particular job.
Elixir and Phoenix with the underlying Erlang oecosystem is a different world in a positive sense. With Rails you will never get there. If you have the freedom, go the Phoenix way, it will enable you to do much larger things.
Any insight on pros and cons of Rails + ActionCable vs. Rails + your own socket.io based node server? I've been getting by with the latter whenever the need arose.
ActionCable is super simple to setup since you can keep the same style as the rest of your Rails application. The only downside at the moment is the support/documentation: the real time messaging app, I'm working on is starting, to get more complex and it would be better to get more support. But hey, it's still in beta... so better wait if you don't want to get your hands dirty ;)
While I love Rails, I've stepped away from it over the past couple years in favour of smaller frameworks. While it's nice to have a kitchen sink approach when it applies, for SPA's, I found I was using very little of the sink, and the sink often got in the way. Is Rails 5 doing a better job of letting you pick what parts you want, or is it still predominantly focused on an all or nothing approach?
I built a production app recently, Rails 5 (beta -- surprisingly stable) + Heroku + Passenger, separate React + react-router frontend. It's been fantastic so far -- has handled a decently sized production load, including some pretty heavy ActionCable usage, with no problems. There's a few tricks to getting it working on Heroku though; I've been meaning to write a blog post about it but haven't found the time.
I've been running it in production since the first days of the year with a small new application. No problems whatsoever writing, testing, deploying and running it. I don't expect particular problems upgrading Rails 4.2 applications.
I didn't use ActionCable because my application doesn't need it. I experimented with it since the first version, which I plugged into Rails 4.2. It had some quirks that were fixed. It works well. There is obviously code to write in the client to handle the websocket but it's pretty much standard boilerplate. I expect some gem will appear implementing it in some clever helper, except the code we really have to write.
While I haven't moved into production yet; nothing broke when I migrated my Rails 4.2 application - just had to tweak the few things to new conventions.
I'm actually currently running a production Rails 5 (beta) app in Heroku using ActionCable, in-process. It's an API only application (React + react-router frontend) but it's handled a decently sized production load without any trouble. Feel free to ask if you need tips getting it working :)
sorry. I wrote it too quickly like I was just chatting with a friend. I mean no disrepect to rails. I just recently learned golang after working for years in rails. The API thing made me go, wow, if didn't need to worry about erb stuff and it was 100% json, I think I'd rather do it in go. But you are right. My comment was just being silly. There's no place for that on hacker news.
For what it's worth I thought it was amusing, in a slightly trolly way ;)
Just to remain slightly on topic, you can't really compare an entire application stack like Rails with a language like Go. Maybe you could do with something lighter like Sinatra.
For me Rails big win isn't that it's high performance (although done right it can handle a decent volume of traffic), but the fact it's configured out of the box. You can be productive on day one, rather than wiring together low level libraries for database access and the like.
Finally having said all that I'm having a really good time with Pliny, Heroku's Ruby API stack, which feels like I imagine Rails might have done if it were built specifically for REST APIs rather than full applications with a UI.
> You can be productive on day one, rather than wiring together low level libraries for database access and the like.
One of my big gripes with Rails is defaulting to ActiveRecord, compared to pretty every alternative (my favourite is Sequel). This is the problem with Rails: You can be productive if you can be productive with its default choices.
But in every project where Rails has been involved that I've worked on, sooner or later people start fighting one of the Rails default choices, and the problem with that is that so many parts are expected to be there by other components they bring in, so even things that are in theory replaceable are in practice tightly coupled.
Does using Sequel instead of ActiveRecord cause problems? I understood it can be used pretty much as a drop-in replacement, but I gather that's not quite the case?
I believe it has gotten easier. But the problem is not so much Rails itself - Rails has gotten steadily better at reducing coupling. The problem is that Rails on its own is not that interesting - what makes Rails is the ecosystem around it. And a lot of the Rails philosophy (convention over configuration etc.) contributes to an environment where people make a lot of assumptions. Active Record is often one of them.
Highlights for me will be:
- Actioncable (real-time communication over websockets)
- Rails-API is merged into core.
- Min ruby version is 2.2 (performance improvements via Garbage Collector)
- Little bit of code cleanup (less code to run)
- Turbolinks 3 (single-page applications)
- Evented file system monitor (faster development environment)
I think they have done a great job with the release. Especially removing Celluloid, Redis, and EventMachine as a dependency for ActionCable part.
I only have one small concern about the Turbolinks part. It hasn't been my choice until now for the projects because of the compatibility issues with other libraries. It always felt like the Quicktime player on Mac OS. Sure you can use it but you better off with something else.
But I really want it to be something i can use out of box this time. Partial rendering is not there yet but lets wait and see how it turns ut.