5 ms·

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 communicatio

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.

tarr11 10y ago
First thing I do when creating a new rails project is remove Turbolinks. It subtly breaks other gems all over the place in difficult to discover ways.
- dasil003 10y ago
  Do you mean Rails gems or 3rd party gems?
- dgobaud 10y ago
  and spring which causes all types of weird random bugs from old cached code in development
  - timdorr 10y ago
    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. [0] https://github.com/jonleighton/spring-commands-rspec https://github.com/jonleighton/spring-commands-rspec
    - rashkov 10y ago
      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.
- KurtMueller 10y ago
  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.
- AnneOminous 10y ago
  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.
  - heartbreak 10y ago
    Wasn't Rails originally a Basecamp-specific tool because they quite literally built it as Basecamp?
werdnapk 10y ago
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.
- rubiquity 10y ago
  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. https://github.com/Shopify/turbograft https://github.com/Shopify/turbograft
technion 10y ago
The huge trend towards React/Angular/etc on the front end, means that this list can be discussed as: - Rails-API is exciting. It means better defaults, including less bloat, for developers taking these options - Turbolinks is even less exciting than it wasn't a few years ago. - Several other changes boil down to "better performance". Let's hope that pans out.
- aantix 10y ago
  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-29166d022228#.bs8zilllr 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. https://github.com/turbolinks/turbolinks-ios https://github.com/turbolinks/turbolinks-ios https://github.com/turbolinks/turbolinks-android https://github.com/turbolinks/turbolinks-android 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.
  - desireco42 10y ago
    Thank you for explaining this.
  - AnneOminous 10y ago
    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.

tarr11 10y ago

First thing I do when creating a new rails project is remove Turbolinks. It subtly breaks other gems all over the place in difficult to discover ways.

dasil003 10y ago
Do you mean Rails gems or 3rd party gems?
dgobaud 10y ago
and spring which causes all types of weird random bugs from old cached code in development
- timdorr 10y ago
  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. [0] https://github.com/jonleighton/spring-commands-rspec https://github.com/jonleighton/spring-commands-rspec
  - rashkov 10y ago
    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.
KurtMueller 10y ago
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.
AnneOminous 10y ago
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.
- heartbreak 10y ago
  Wasn't Rails originally a Basecamp-specific tool because they quite literally built it as Basecamp?

werdnapk 10y ago

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.

rubiquity 10y ago
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. https://github.com/Shopify/turbograft https://github.com/Shopify/turbograft

technion 10y ago

The huge trend towards React/Angular/etc on the front end, means that this list can be discussed as: - Rails-API is exciting. It means better defaults, including less bloat, for developers taking these options - Turbolinks is even less exciting than it wasn't a few years ago. - Several other changes boil down to "better performance". Let's hope that pans out.

aantix 10y ago
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-29166d022228#.bs8zilllr 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. https://github.com/turbolinks/turbolinks-ios https://github.com/turbolinks/turbolinks-ios https://github.com/turbolinks/turbolinks-android https://github.com/turbolinks/turbolinks-android 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.
- desireco42 10y ago
  Thank you for explaining this.
- AnneOminous 10y ago
  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.