GitHub is an MPA Rails app that uses turbolinks to make page transitions quicker, which is what you’re seeing stall. No routing is done client side.

Navigations within the same repo are powered by client side routings (e.g. from "Code" tab to "Issue" tab).

No? I'm looking at the request in webinspector right now. GitHub is kicking back the full partial for the issues tab, and turbolinks JS is then swapping out the relevant DIVs -- it's a bog-standard Rails MPA server side routed setup, I think you're just letting the turbolinks animation convince you there's more happening on the frontend than really is.

Github uses something called View Component to render 'partials' (aka components) which is a bit more sophisticated than just Turbolinks and IMO the future of complex web apps

https://viewcomponent.org/

It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds.

This is a really good talk about how we got here from Jquery->Backbone.js->SPAs + React/Vue->Stimulus/ViewComponent/ActionCable

https://www.youtube.com/watch?v=sIxvxp7E0xg

There's another similar project called AnyCable which combines websockets with an ActionCable style approach:

https://anycable.io/

> It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds.

This is similar to how React Server Components work, except that they work for arbitrary server-side rendering updates to the client as well as navigation. And it’s conceptually similar to how Qwik works, only the “partials” are typically client chunks. And again with Qwik, not tied to navigation, but that’s pretty much how I’d imagine a client routing solution for Qwik would (will?) look.

Eh, we use ViewComponents inhouse at work too, and they're great, but they're really just a better way of approaching partials instead of the normal "grab the Controller's ivars" free-for-all -- they don't move the needle any on the MPA front, and they change nothing w.r.t turbolinks (or any client side JS), since they're purely a server-side rendering time thing.

I'm more interested in the concept of ViewComponents than just the current library. It's really just starting with Rails adopting ActionCable and Phoenix using LiveView (which I see as both immature proto-concepts of the future of JS frontends).

This blog post (and my linked talk above) opened my eyes on the subject: https://evilmartians.com/chronicles/anycable-actioncable-on-...

Right now the complexity is a bit high on this approach^ and I personally just use a mix of Vue + Turbolinks/Rails at work for legacy/simplicity reasons. But I'm watching the space.

You are right. It wasn't client side routing.

But GitHub doesn't use turbolink. They wrote their own implementations that lies at app/assets/modules/github/behaviors/pjax.ts.

Ah, AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax (although I guess they rewrote it in TS, unless that's a different project floating around?), from which Turbolinks took its inspiration as a Rails-native built in solution. Presumably GitHub never saw any reason to rewrite for Turbolinks when the latter appeared.

> AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax

Check out https://api.github.com/users/defunkt:

> "id": 2

pjax was written by a GitHub founder for use in github.com.

huh, TIL

Github is a Rails app, and leverages Turbolinks which does partial page renders (but still keeps routing server-side)