4 ms·

In my opinion it’s gotten worse in favor of cost savings. Two biggest examples: if you leave more than 10 code review comments on a PR, it hides them under a “s

In my opinion it’s gotten worse in favor of cost savings. Two biggest examples: if you leave more than 10 code review comments on a PR, it hides them under a “show more” link. Time and time again my reviews get ignored, so I’ve started subconsciously picking my battles when doing a one. That might be good on small PRs so that you don’t go into the weeds nit-picking, but on a big gnarly one it’s an anti-feature. And in any case, I don’t want Microsoft’s cheap UI to inform the code review etiquette of my team. Second example: if a file in a PR has a large diff, it will not be loaded, you have another “show more” link. That file is probably the part of your PR most in need of review, but again, on my PRs my teammates often skip right past it because it’s hidden by default.

esperent 2y ago
That's a fair complaints. However, it's clearly a design decision, whereas the author is trying to imply that it's gotten generally worse because they switched to using a frontend framework.
- eloisius 2y ago
  I agree with her. I appreciate the new code navigation stuff a bit, but not at the cost it’s imposed on my workflow. A pull request used to be a regular web page. I could refresh it, search it with ctrl-f, reliably link to a specific line, etc. Now it’s a crapshoot. If you refresh there’s no guarantee you’ll land anywhere near where you were. Page loads take forever so I can’t easily open multiple tabs to cross-reference the code I’m reviewing. If you link to some code that was within a diff that you had to “show more” to open, well, who knows where the link will land you.
  - deleted 2y ago
    [deleted]
- johnnypangs 2y ago
  Doesn’t github use Rails and web components? They definitely gotten more frontend heavy though… https://github.blog/engineering/architecture-optimization/how-we-use-web-components-at-github/ https://github.blog/engineering/architecture-optimization/ho...
  - yen223 2y ago
    The Github frontend appears to be React now. That said, most (not all) of it still works with Javascript disabled
    - johnnypangs 2y ago
      I looked a bit into the JavaScript loaded when going to GitHub and my best guess as to what it’s using react for is the copilot chat. It’s still using turbo rails and doing full ssr reloads. Something very at odds with react router which it’s also loading. It’s still loading catalyst (their homebrew web component lib) which from what I understand doesn’t seem to offer react bindings. It even loads lit (another web component lib), which I couldn’t find the react bindings for. If it’s just for the copilot chat I’d still say GitHub is mainly rails based though would love to hear if anyone has any more / better insight.
- bryanrasmussen 2y ago
  some frontend frameworks - the React like ones - make that kind of design decision so easy to do that you might just do it without arguing if it was a good decision or not. Not that it is particularly difficult with Vanilla JS etc. but maybe slow enough you think, hey why are we doing this? React it's 5 seconds to do, you are done so quick with the actual code you might not consider the implications.

esperent 2y ago

That's a fair complaints. However, it's clearly a design decision, whereas the author is trying to imply that it's gotten generally worse because they switched to using a frontend framework.

eloisius 2y ago
I agree with her. I appreciate the new code navigation stuff a bit, but not at the cost it’s imposed on my workflow. A pull request used to be a regular web page. I could refresh it, search it with ctrl-f, reliably link to a specific line, etc. Now it’s a crapshoot. If you refresh there’s no guarantee you’ll land anywhere near where you were. Page loads take forever so I can’t easily open multiple tabs to cross-reference the code I’m reviewing. If you link to some code that was within a diff that you had to “show more” to open, well, who knows where the link will land you.
- deleted 2y ago
  [deleted]
johnnypangs 2y ago
Doesn’t github use Rails and web components? They definitely gotten more frontend heavy though… https://github.blog/engineering/architecture-optimization/how-we-use-web-components-at-github/ https://github.blog/engineering/architecture-optimization/ho...
- yen223 2y ago
  The Github frontend appears to be React now. That said, most (not all) of it still works with Javascript disabled
  - johnnypangs 2y ago
    I looked a bit into the JavaScript loaded when going to GitHub and my best guess as to what it’s using react for is the copilot chat. It’s still using turbo rails and doing full ssr reloads. Something very at odds with react router which it’s also loading. It’s still loading catalyst (their homebrew web component lib) which from what I understand doesn’t seem to offer react bindings. It even loads lit (another web component lib), which I couldn’t find the react bindings for. If it’s just for the copilot chat I’d still say GitHub is mainly rails based though would love to hear if anyone has any more / better insight.
bryanrasmussen 2y ago
some frontend frameworks - the React like ones - make that kind of design decision so easy to do that you might just do it without arguing if it was a good decision or not. Not that it is particularly difficult with Vanilla JS etc. but maybe slow enough you think, hey why are we doing this? React it's 5 seconds to do, you are done so quick with the actual code you might not consider the implications.