5 ms·

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, includi

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.
  - aantix 10y ago
    "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.
    - AnneOminous 10y ago
      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.

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.
- aantix 10y ago
  "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.
  - AnneOminous 10y ago
    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.