[steveklabnik]

In the recent discussions about Discourse, it was said that on slower connections, it feels way snappier than a server-side solution would be.

Frankly, I'm a server-side guy, so I prefer that kind of development, but there are advantages to SPAs, and like any good engineer, you should use the right tool for the job. Rails is modular enough that you can do whatever you want, Turbolinks is just a gem, so if you don't want to use it, you can just pull it out of the Gemfile.

If be willing to bet that the less dynamic interaction per page, the less an SPA makes sense. ;)

That said, I can also see how something like Ember gives you a nice way to do API-first development, so even if your site is more static, it could make sense.

As always: It Depends. Don't believe anyone who tells you they have a silver bullet.

[ksec]

I agree. I would love to see some article on What TurboLinks actually breaks and How to avoid it. As much as the world love JS and Client Side Rendering. My Experience is that most of these people are either designing it with Chrome in Mind ( And hell yes they are ) or People using other browsers with a single tab at a time. ( Tell me if any single developer test their website in a Multi Tab environment )

Having JS heavy web page will slow down the browsers. That even includes Chrome, you just need a larger number of tabs. On Firefox a few JS heavy site with a slow computer will make your site experience sucks.

Although not a single user would blame the site ( It is always the browsers' fault. ) but to me, most of the time, the less JS the better.

Discourse is pretty fast, but to say 300K zipped JS file is peanuts just doesn't cut it for me ( How about 100K? That is peanuts. ) And again, slow JS execution and loading is something i have zero control of.

[steveklabnik]

> I would love to see some article on What TurboLinks actually breaks and How to avoid it.

The big change is that instead of getting a clean slate every request, you now have one, long-running JavaScript environment. That's where Turbolinks derives its speed from, but it's the biggest change, and this difference in assumption has been where the issues have popped up.

Honestly, I have not followed turbolinks' development very much, so I'd look through the Issues if I were you to get a better idea of what kinds of things have cropped up so far.

> Discourse is pretty fast, but to say 300K zipped JS file is peanuts just doesn't cut it for me

Sure. I think you'd be surprised how quickly you can get up to 300k of assets in a site, though. Plus, you're only fetching it once, it's all cached afterwards. Regardless, as far as I'm concerned, the practice beats the theory. Turbolinks and Ember have both been show to speed up web sites in practice.