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.

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

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

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.

I observe the exact opposite. Server rendered UIs are far more often times up to date than client rendered apps.

I can't think of a single website that's real time and server rendered

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

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.

Mind you some parts of Github FE are React https://twitter.com/rauchg/status/1591464351990697984?s=46&t...

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.

SPA =\= client rendering

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.

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.

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.

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

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

GitHub could've used Hotwire [0] but instead they decided to grow a buggy immature in-house solution.

[0]: https://hotwired.dev/

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.

> 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.

Yes that’s correct.

I was saying it came after, meaning GitHub could not have used it since it didn’t exist. :)