5 ms·

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.

maxloh 4y ago
Navigations within the same repo are powered by client side routings (e.g. from "Code" tab to "Issue" tab).
- msbarnett 4y ago
  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.
  - maxloh 4y ago
    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.
    - msbarnett 4y ago
      Ah, AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax 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.
      - semiquaver 4y ago
        > AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax Check out https://api.github.com/users/defunkt https://api.github.com/users/defunkt: > "id": 2 pjax was written by a GitHub founder for use in github.com.
        msbarnett 4y ago
        huh, TIL
  - dmix 4y ago
    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/ 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 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/ https://anycable.io/
    - msbarnett 4y ago
      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.
      - dmix 4y ago
        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-steroids 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.
    - eyelidlessness 4y ago
      > 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.

maxloh 4y ago

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

msbarnett 4y ago
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.
- maxloh 4y ago
  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.
  - msbarnett 4y ago
    Ah, AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax 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.
    - semiquaver 4y ago
      > AFAIK that's not actually theirs but: https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax Check out https://api.github.com/users/defunkt https://api.github.com/users/defunkt: > "id": 2 pjax was written by a GitHub founder for use in github.com.
      - msbarnett 4y ago
        huh, TIL
- dmix 4y ago
  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/ 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 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/ https://anycable.io/
  - msbarnett 4y ago
    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.
    - dmix 4y ago
      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-steroids 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.
  - eyelidlessness 4y ago
    > 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.