6 ms·

Github is one of the few webapps where I can feel daily that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by

Github is one of the few webapps where I can feel daily that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by refreshing the page.

hakre 4y ago
Yes, just seen it yesterday. However, this is perhaps not of Github origins. Even when you use the recommended interface to git - the command line - it's only as up-to date as you've entered the last command for - or pressing F5 in gitk.
Gasp0de 4y ago
If anything that's a fault in the Frontend though, which is not what the article is about, right?
amrocha 4y ago
Very true, but that's a frontend problem, not a rails problem.
- jeremyjh 4y ago
  These problems are always more common in server-rendered apps though, because front-end state is always a patchwork. And the Rails developers and community have a strong preference for this architecture.
  - VWWHFSfQ 4y ago
    I observe the exact opposite. Server rendered UIs are far more often times up to date than client rendered apps.
    - amrocha 4y ago
      I can't think of a single website that's real time and server rendered
      - UlisesAC4 4y ago
        I do not have examples with me. But anything built with Elixir Liveview will be server rendered and will also be real time, with some gotchas though. https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view
        jeremyjh 4y ago
        Its not exactly server rendered, though. After the first page view all the server is rendering are json graphs of dom diffs to be applied by the client application. If you use the routing features then technically its an SPA.
  - gls2ro 4y ago
    Mind you some parts of Github FE are React https://twitter.com/rauchg/status/1591464351990697984?s=46&t=MBvUO3Qs3QEK_GU1anYaZQ https://twitter.com/rauchg/status/1591464351990697984?s=46&t...
  - int_19h 4y ago
    The upside is that you can link just about anything in GitHub, and those links work consistently and point at the exact right content. This is much less common with SPAs.
    - amrocha 4y ago
      SPA =\= client rendering
    - jeremyjh 4y ago
      I agree its a valid criticism of parts of the ecosystem, but a lot of people these days are using next.js, nuxt.js or sveltkit and those give you easy patterns to follow so that all those things work, basically for free. SPAs are better now than they were just a few years ago.
yurishimo 4y ago
Is that a fault of Rails though or Github's architecture as a whole? In my opinion, Github is the result of hundreds (thousands?) of devs working on one product with little discussion across the entire project. Their HTML patching solution works great in isolation for one team shipping features to their island of the product. But we as users see it fall short at scale. Like you mentioned, things getting out of sync is a real pain point that doesn't have an obvious fix when you have so many people touching the product daily.
Cthulhu_ 4y ago
I feel the same with Gitlab, with e.g. build pipeline status not updating when it's done - it feels pull- instead of push-based. I mean it may be working just fine, but I don't see it - and the success rate of refreshing a page to see an update is so high that it doesn't instill confidence. These tools should be more reactive, I think, with live progress indicators and the like.
- peheje 4y ago
  Nothing wrong with pull based. Actually I feel like push connections are more often less reliable as they are lost and not reconnected.
ativzzz 4y ago
I think it's a tradeoff - rails makes live frontend updating challenging because you need to maintain a separate system to manage that, especially when you have a large app. JS frameworks have this built in, but their backend is lacking compared to rails IMO
- doodlesdev 4y ago
  GitHub could've used Hotwire [0] but instead they decided to grow a buggy immature in-house solution. [0]: https://hotwired.dev/ https://hotwired.dev/
  - mscccc 4y ago
    Even with my kindest interpretation, I cannot find how this comment adds anything to the conversation. It’s also incorrect. Hotwire was released after GitHub’s internal UI framework (which is quite impressive!) was created. Attributing some UI bugs with their choice of framework is a massive oversimplification of the problem.
    - 0xblinq 4y ago
      > Hotwire was released after GitHub’s internal UI framework Any source for this? My understanding is that it was extracted for building Hey from the use cases the 37signals people had on other products such as basecamp, etc.
      - mscccc 4y ago
        Yes that’s correct. I was saying it came after, meaning GitHub could not have used it since it didn’t exist. :)

Github is one of the few webapps where I can feel daily that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by refreshing the page.

hakre 4y ago

Yes, just seen it yesterday. However, this is perhaps not of Github origins. Even when you use the recommended interface to git - the command line - it's only as up-to date as you've entered the last command for - or pressing F5 in gitk.

Gasp0de 4y ago

If anything that's a fault in the Frontend though, which is not what the article is about, right?

amrocha 4y ago

Very true, but that's a frontend problem, not a rails problem.

jeremyjh 4y ago
These problems are always more common in server-rendered apps though, because front-end state is always a patchwork. And the Rails developers and community have a strong preference for this architecture.
- VWWHFSfQ 4y ago
  I observe the exact opposite. Server rendered UIs are far more often times up to date than client rendered apps.
  - amrocha 4y ago
    I can't think of a single website that's real time and server rendered
    - UlisesAC4 4y ago
      I do not have examples with me. But anything built with Elixir Liveview will be server rendered and will also be real time, with some gotchas though. https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view
      - jeremyjh 4y ago
        Its not exactly server rendered, though. After the first page view all the server is rendering are json graphs of dom diffs to be applied by the client application. If you use the routing features then technically its an SPA.
- gls2ro 4y ago
  Mind you some parts of Github FE are React https://twitter.com/rauchg/status/1591464351990697984?s=46&t=MBvUO3Qs3QEK_GU1anYaZQ https://twitter.com/rauchg/status/1591464351990697984?s=46&t...
- int_19h 4y ago
  The upside is that you can link just about anything in GitHub, and those links work consistently and point at the exact right content. This is much less common with SPAs.
  - amrocha 4y ago
    SPA =\= client rendering
  - jeremyjh 4y ago
    I agree its a valid criticism of parts of the ecosystem, but a lot of people these days are using next.js, nuxt.js or sveltkit and those give you easy patterns to follow so that all those things work, basically for free. SPAs are better now than they were just a few years ago.

yurishimo 4y ago

Is that a fault of Rails though or Github's architecture as a whole? In my opinion, Github is the result of hundreds (thousands?) of devs working on one product with little discussion across the entire project. Their HTML patching solution works great in isolation for one team shipping features to their island of the product. But we as users see it fall short at scale. Like you mentioned, things getting out of sync is a real pain point that doesn't have an obvious fix when you have so many people touching the product daily.

Cthulhu_ 4y ago

I feel the same with Gitlab, with e.g. build pipeline status not updating when it's done - it feels pull- instead of push-based. I mean it may be working just fine, but I don't see it - and the success rate of refreshing a page to see an update is so high that it doesn't instill confidence. These tools should be more reactive, I think, with live progress indicators and the like.

peheje 4y ago
Nothing wrong with pull based. Actually I feel like push connections are more often less reliable as they are lost and not reconnected.

ativzzz 4y ago

I think it's a tradeoff - rails makes live frontend updating challenging because you need to maintain a separate system to manage that, especially when you have a large app. JS frameworks have this built in, but their backend is lacking compared to rails IMO

doodlesdev 4y ago
GitHub could've used Hotwire [0] but instead they decided to grow a buggy immature in-house solution. [0]: https://hotwired.dev/ https://hotwired.dev/
- mscccc 4y ago
  Even with my kindest interpretation, I cannot find how this comment adds anything to the conversation. It’s also incorrect. Hotwire was released after GitHub’s internal UI framework (which is quite impressive!) was created. Attributing some UI bugs with their choice of framework is a massive oversimplification of the problem.
  - 0xblinq 4y ago
    > Hotwire was released after GitHub’s internal UI framework Any source for this? My understanding is that it was extracted for building Hey from the use cases the 37signals people had on other products such as basecamp, etc.
    - mscccc 4y ago
      Yes that’s correct. I was saying it came after, meaning GitHub could not have used it since it didn’t exist. :)