8 ms·

Honestly github always felt snappy and intuitive to me, more so than many "cool" react fronts I've seen. It would be great if they wrote an article about this

Honestly github always felt snappy and intuitive to me, more so than many "cool" react fronts I've seen. It would be great if they wrote an article about this switch to understand some of the challenges they were facing. I would also be curious if they considered other approaches and stacks.

ronnier 4y ago
I don't have any data to back this up, just my opinion, but I prefer backend rendered sites with Javascript augmentation for the parts that need it. Just feels faster. These JavaScript UIs feel clunky and slow IMO. Maybe it's the (sometimes) dozens of calls the UI make back to the server to get data whereas if it was all rendered in the backend the round trip time would be a lot faster since the server is closer to the data, but my browser needs to make a call across the internet to the server and then to the database or whatever. Also for tools websites at companies I work at, as a backend dev, building those tools in react is huge overhead. Webpack and react and redux etc. It's a lot to deal with for some simple tool. I'm wondering how much internal tool websites built in react slow down the development process at corps.
- deleted 4y ago
  [deleted]
- 323 4y ago
  In theory React websites should transfer less data since you just send a JSON model instead of one annotated in full HTML markup. The React runtime would be cached after the first visit.
  - coffeefirst 4y ago
    That’s the theory, but every time I measure it the combined data and JS needed to render it wind up being more than plain HTML both in bytes transferred and milliseconds to render. There will be exceptions of course, but I haven’t found them.
  - martinald 4y ago
    The problem isn't the amount of data but the number of round trips required to get it. Imagine you need to do the following calls to get the page rendered with the various information different parts of the page has: 1. Get user information 2. Get projects for user 3. Get the selected project Now, if this was all server side rendered, it might take 1ms to go to the database and get the various bits of info, or 3ms for 3 sequential requests. With a react app and say 250ms of latency to the database, you're looking at 750ms of overhead - 200x slower. Of course you can architect all your APIs to always return everything the user needs so they don't have to do multiple requests, but that has its own drawbacks and honestly is very difficult to do and plan ahead for, especially at scale with multiple consumers of various APIs.
    - lomereiter 4y ago
      What you describe is solved with GraphQL, which is a very mature technology by now.
      - ronnier 4y ago
        Now we are in the world of graphql, react (and all the other stuff that comes to react), plus the backend server and language. It's a complicated world and I'm not sure we really need that much complexity. There are times when it is needed but I think we've over done it in some cases where we can just have a golang or ruby backend server that renders the page server side. I recently did this and it's a very good feeling just sticking to my server side language that I use daily + html.
        lomereiter 4y ago
        Who are these 'we'? It's all up to personal preference in the end. As Github demonstrates by postponing SPA framework adoption, there are enough companies out there that share your desire to keep things simple.
        ronnier 4y ago
        We is our industry.
- throw_m239339 4y ago
  > These JavaScript UIs feel clunky and slow IMO They don't feel slow, they are slow, even more so on mobile, but developers have stopped caring about mobile web performance a long time ago. So much for "flash is killing my battery", now it's Javascript.
paxys 4y ago
Snappy and intuitive while loading static pages of text, sure, but their code browsing and search experience needs massive improvement. I'd love to not have to clone a repo and pull up an IDE just to be able to understand the code.
- thegginthesky 4y ago
  Trur, when I need to browse code I just use codespaces, which you can access by using github.dev/owner/repo, or pressing dot ( . ) when inside the repo
- gw98 4y ago
  Actions is also a broken pile of shit. The UI falls to bits constantly.
  - diarrhea 4y ago
    I work with it on a daily basis and am still confused by most pages in Actions.
    - brightball 4y ago
      Gitlab ftw on the CI front
- williamdclt 4y ago
  GH Codesearch is in beta, it seems to improve exactly that
- diarrhea 4y ago
  It’s not impossible to imagine Web IDEs surpassing desktop ones, but it’s not happening anytime soon. Until then desktop IDEs will remain superior, so this experience won’t change anytime soon. For every new feature a web IDE adds, we’ll end up missing desktop features still.
adamredwoods 4y ago
Interesting, they use html content templates for code re-usability, which is more difficult to use than React. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...
papito 4y ago
One thing they did at Github years ago was get closer to the metal by ditching JQuery. You can do the same things - and more - with ES6 and updated browser support pretty much across the board. Nowadays you don't even need a transpiler. https://github.blog/2018-09-06-removing-jquery-from-github-frontend/ https://github.blog/2018-09-06-removing-jquery-from-github-f...
noahtallen 4y ago
I actually disagree — GitHub has been relatively slow for me when it comes to page transitions. For example, switching between a PR’s various tabs would probably be a lot faster with client rendering. Of course, performance will come down to how well the team builds the site and optimizes it. It is very easy to make a site slow in so many different ways. You always have to be looking at and optimizing it for improvements, both on the client and server. React isn’t immune to this, just as various server frameworks aren’t immune to it either.
- hardwaregeek 4y ago
  Agreed. I'm rather surprised at people in this thread saying they prefer GitHub's server rendered setup. I use GitHub a lot in my job and it feels rather slow/clunky.
  - Aeolun 4y ago
    All the people that were used to Bitbucket’s 20s page loads think Github is heaven.
- cntainer 4y ago
  I'm curious what relatively slow means for you. As an example I just made a quick test from my Firefox mobile browser in desktop mode and the switch between PR tabs is not instant but close enough to not be bothered by it.

ronnier 4y ago

I don't have any data to back this up, just my opinion, but I prefer backend rendered sites with Javascript augmentation for the parts that need it. Just feels faster. These JavaScript UIs feel clunky and slow IMO. Maybe it's the (sometimes) dozens of calls the UI make back to the server to get data whereas if it was all rendered in the backend the round trip time would be a lot faster since the server is closer to the data, but my browser needs to make a call across the internet to the server and then to the database or whatever. Also for tools websites at companies I work at, as a backend dev, building those tools in react is huge overhead. Webpack and react and redux etc. It's a lot to deal with for some simple tool. I'm wondering how much internal tool websites built in react slow down the development process at corps.

deleted 4y ago
[deleted]
323 4y ago
In theory React websites should transfer less data since you just send a JSON model instead of one annotated in full HTML markup. The React runtime would be cached after the first visit.
- coffeefirst 4y ago
  That’s the theory, but every time I measure it the combined data and JS needed to render it wind up being more than plain HTML both in bytes transferred and milliseconds to render. There will be exceptions of course, but I haven’t found them.
- martinald 4y ago
  The problem isn't the amount of data but the number of round trips required to get it. Imagine you need to do the following calls to get the page rendered with the various information different parts of the page has: 1. Get user information 2. Get projects for user 3. Get the selected project Now, if this was all server side rendered, it might take 1ms to go to the database and get the various bits of info, or 3ms for 3 sequential requests. With a react app and say 250ms of latency to the database, you're looking at 750ms of overhead - 200x slower. Of course you can architect all your APIs to always return everything the user needs so they don't have to do multiple requests, but that has its own drawbacks and honestly is very difficult to do and plan ahead for, especially at scale with multiple consumers of various APIs.
  - lomereiter 4y ago
    What you describe is solved with GraphQL, which is a very mature technology by now.
    - ronnier 4y ago
      Now we are in the world of graphql, react (and all the other stuff that comes to react), plus the backend server and language. It's a complicated world and I'm not sure we really need that much complexity. There are times when it is needed but I think we've over done it in some cases where we can just have a golang or ruby backend server that renders the page server side. I recently did this and it's a very good feeling just sticking to my server side language that I use daily + html.
      - lomereiter 4y ago
        Who are these 'we'? It's all up to personal preference in the end. As Github demonstrates by postponing SPA framework adoption, there are enough companies out there that share your desire to keep things simple.
        ronnier 4y ago
        We is our industry.
throw_m239339 4y ago
> These JavaScript UIs feel clunky and slow IMO They don't feel slow, they are slow, even more so on mobile, but developers have stopped caring about mobile web performance a long time ago. So much for "flash is killing my battery", now it's Javascript.

paxys 4y ago

Snappy and intuitive while loading static pages of text, sure, but their code browsing and search experience needs massive improvement. I'd love to not have to clone a repo and pull up an IDE just to be able to understand the code.

thegginthesky 4y ago
Trur, when I need to browse code I just use codespaces, which you can access by using github.dev/owner/repo, or pressing dot ( . ) when inside the repo
gw98 4y ago
Actions is also a broken pile of shit. The UI falls to bits constantly.
- diarrhea 4y ago
  I work with it on a daily basis and am still confused by most pages in Actions.
  - brightball 4y ago
    Gitlab ftw on the CI front
williamdclt 4y ago
GH Codesearch is in beta, it seems to improve exactly that
diarrhea 4y ago
It’s not impossible to imagine Web IDEs surpassing desktop ones, but it’s not happening anytime soon. Until then desktop IDEs will remain superior, so this experience won’t change anytime soon. For every new feature a web IDE adds, we’ll end up missing desktop features still.

adamredwoods 4y ago

Interesting, they use html content templates for code re-usability, which is more difficult to use than React. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template https://developer.mozilla.org/en-US/docs/Web/HTML/Element/te...

papito 4y ago

One thing they did at Github years ago was get closer to the metal by ditching JQuery. You can do the same things - and more - with ES6 and updated browser support pretty much across the board. Nowadays you don't even need a transpiler. https://github.blog/2018-09-06-removing-jquery-from-github-frontend/ https://github.blog/2018-09-06-removing-jquery-from-github-f...

noahtallen 4y ago

I actually disagree — GitHub has been relatively slow for me when it comes to page transitions. For example, switching between a PR’s various tabs would probably be a lot faster with client rendering. Of course, performance will come down to how well the team builds the site and optimizes it. It is very easy to make a site slow in so many different ways. You always have to be looking at and optimizing it for improvements, both on the client and server. React isn’t immune to this, just as various server frameworks aren’t immune to it either.

hardwaregeek 4y ago
Agreed. I'm rather surprised at people in this thread saying they prefer GitHub's server rendered setup. I use GitHub a lot in my job and it feels rather slow/clunky.
- Aeolun 4y ago
  All the people that were used to Bitbucket’s 20s page loads think Github is heaven.
cntainer 4y ago
I'm curious what relatively slow means for you. As an example I just made a quick test from my Firefox mobile browser in desktop mode and the switch between PR tabs is not instant but close enough to not be bothered by it.