4 ms·

Key is that zero development effort need be poured into making a native version of the github website, because it already works. The web is good enough on deskt

Key is that zero development effort need be poured into making a native version of the github website, because it already works. The web is good enough on desktop. You want notifications, it could do them! You want to jump to an editor, no reason why the web couldn't do that (although you might have to switch branches!). Slack is different because when you're chatting, you don't really need tabs, but on GH I will usually have 10-15 open from a few different repos that stay mixed in with other pages for context. You're throwing away all the good things about browsers if you make it all native. And then you remember that every social feature comes at the cost of executing a git client really well. I'm personally very happy with GitUp.app not being clogged up with GitHub API calls to fetch comments, and showing alerts that when clicked will pull me away from the commit diff I was viewing. It works exactly as Git does offline. If you address all those things, congrats, you've still barely reached par, and what do you have to show for it? Maybe a cool new look? This is why it's a waste, and an ongoing cost as GitHub.com evolves.

robenkleene 7y ago
> Key is that zero development effort need be poured into making a native version of the github website, because it already works. This is true of every web app that also has a desktop app, e.g., Slack, Trello, Notion, and Figma. So yes, that trade off always exists. I'd just prefer GitHub make the decision differently, like those apps I listed do, and choose to have a desktop app. > You want notifications, it could do them! Notifications are worse in the browser. E.g., they cannot provide a badge on the app icon, and I cannot easily switch to the app that's the source of the notification like I can with a desktop app. I want the same communication workflow that I use with email and Slack, i.e., I get a notification that someone has commented on my code, and a badge icon as a reminder to address it. Then I can click the app icon when I'm ready to address it (and open the relevant source files directly in my editor if I need to). > You want to jump to an editor, no reason why the web couldn't do that (although you might have to switch branches!). Can you walk me through how a web app would implement that feature? E.g., the browsers sandboxing model prohibits access to the file system? And how would a website even know where the repo was checked out? > Slack is different because when you're chatting, you don't really need tabs, but on GH I will usually have 10-15 open from a few different repos that stay mixed in with other pages for context. You're throwing away all the good things about browsers if you make it all native. Again, all of that is true of every app that has a desktop app and a web app. Also many desktop apps also support tabs? E.g., VS Code. In fact, tabs are built-in at the window manager level on macOS. And you wouldn't have to choose between the desktop app and the web, just like with those other apps you could use the solution that best fits the situation. > And then you remember that every social feature comes at the cost of executing a git client really well. I'm personally very happy with GitUp.app not being clogged up with GitHub API calls to fetch comments, and showing alerts that when clicked will pull me away from the commit diff I was viewing. It works exactly as Git does offline. If you address all those things, congrats, you've still barely reached par, and what do you have to show for it? Maybe a cool new look? This is why it's a waste, and an ongoing cost as GitHub.com evolves. I'm not really following this paragraph, e.g., "showing alerts that when clicked", what's the referring to? But let me give a counter perspective: The GitHub client I'm envisioning would not be a git client, it would be GitHub client. E.g., you would not be able to stage commits in it. In my experience, the number of developers that use a GUI git client is vanishingly small (personally I think GUI git clients are great, but anecdotally they're very rare among my colleagues). Therefore, I think making a git client is a silly market for a company of GitHub's size to be involved in. Whereas as their social features, and the level of integration they could do between a checked out repo and comments/issues, those would be true differentiating features that would keep developers from switching to other hosts like GitLab.
- cormacrelf 7y ago
  > Can you walk me through how a web app would implement that feature? Same way you open a URL in the App Store? Not hard to let VSCode manage repo URL => workspace path mappings. > Also many desktop apps also support tabs Read again: "10-15 open from a few different repos that stay mixed in with other pages for context". Can't do that. You need a pretty huge value proposition for me to be willing to drop contextual tabbing to switch to your native app. > I'm not really following this paragraph, e.g. "showing alerts that when clicked" That's on you man, you brought up notifications. You also clearly understood when you replied on-point, no need for dramatically hand-waving an entire paragraph as incomprehensible. > In my experience, the number of developers that use a GUI git client is vanishingly small This tells me that GitHub.com is doing the everything-except-staging-commits job just fine for most people. AFAIK you add little value extending GH's analysis to live checkouts, and to gain what little there is, you'd have to bring some of that analysis online, compiled into the app, instead of cloud job queues. Pretty obvious why they wouldn't want to do that!

robenkleene 7y ago

> Key is that zero development effort need be poured into making a native version of the github website, because it already works. This is true of every web app that also has a desktop app, e.g., Slack, Trello, Notion, and Figma. So yes, that trade off always exists. I'd just prefer GitHub make the decision differently, like those apps I listed do, and choose to have a desktop app. > You want notifications, it could do them! Notifications are worse in the browser. E.g., they cannot provide a badge on the app icon, and I cannot easily switch to the app that's the source of the notification like I can with a desktop app. I want the same communication workflow that I use with email and Slack, i.e., I get a notification that someone has commented on my code, and a badge icon as a reminder to address it. Then I can click the app icon when I'm ready to address it (and open the relevant source files directly in my editor if I need to). > You want to jump to an editor, no reason why the web couldn't do that (although you might have to switch branches!). Can you walk me through how a web app would implement that feature? E.g., the browsers sandboxing model prohibits access to the file system? And how would a website even know where the repo was checked out? > Slack is different because when you're chatting, you don't really need tabs, but on GH I will usually have 10-15 open from a few different repos that stay mixed in with other pages for context. You're throwing away all the good things about browsers if you make it all native. Again, all of that is true of every app that has a desktop app and a web app. Also many desktop apps also support tabs? E.g., VS Code. In fact, tabs are built-in at the window manager level on macOS. And you wouldn't have to choose between the desktop app and the web, just like with those other apps you could use the solution that best fits the situation. > And then you remember that every social feature comes at the cost of executing a git client really well. I'm personally very happy with GitUp.app not being clogged up with GitHub API calls to fetch comments, and showing alerts that when clicked will pull me away from the commit diff I was viewing. It works exactly as Git does offline. If you address all those things, congrats, you've still barely reached par, and what do you have to show for it? Maybe a cool new look? This is why it's a waste, and an ongoing cost as GitHub.com evolves. I'm not really following this paragraph, e.g., "showing alerts that when clicked", what's the referring to? But let me give a counter perspective: The GitHub client I'm envisioning would not be a git client, it would be GitHub client. E.g., you would not be able to stage commits in it. In my experience, the number of developers that use a GUI git client is vanishingly small (personally I think GUI git clients are great, but anecdotally they're very rare among my colleagues). Therefore, I think making a git client is a silly market for a company of GitHub's size to be involved in. Whereas as their social features, and the level of integration they could do between a checked out repo and comments/issues, those would be true differentiating features that would keep developers from switching to other hosts like GitLab.

cormacrelf 7y ago
> Can you walk me through how a web app would implement that feature? Same way you open a URL in the App Store? Not hard to let VSCode manage repo URL => workspace path mappings. > Also many desktop apps also support tabs Read again: "10-15 open from a few different repos that stay mixed in with other pages for context". Can't do that. You need a pretty huge value proposition for me to be willing to drop contextual tabbing to switch to your native app. > I'm not really following this paragraph, e.g. "showing alerts that when clicked" That's on you man, you brought up notifications. You also clearly understood when you replied on-point, no need for dramatically hand-waving an entire paragraph as incomprehensible. > In my experience, the number of developers that use a GUI git client is vanishingly small This tells me that GitHub.com is doing the everything-except-staging-commits job just fine for most people. AFAIK you add little value extending GH's analysis to live checkouts, and to gain what little there is, you'd have to bring some of that analysis online, compiled into the app, instead of cloud job queues. Pretty obvious why they wouldn't want to do that!