3 ms·

Were they using vanilla js? That's impressive if yes.

by chistev 1y ago

bapak 1y ago
Most of the UI is React now, especially the most commonly used areas.
- Imustaskforhelp 1y ago
  The parent comment actually asks what they were doing before using React... No worries, you may have misunderstood them and that's okay!
  - deleted 1y ago
    [deleted]
LoganDark 1y ago
Pretty sure it used to be more server rendered?
- princevegeta89 1y ago
  Most of it still is server rendered.
  - arp242 1y ago
    I believe most stuff gets loaded via a JSON API now, and HTML rendered in JS via Rect. Maybe even all of it? For example the file overview has 14(!) requests (/recently-touched-branches, /latest-commit, /overview-files/{branch}, etc.). The issues list uses 5(!) requests to the GraphQL API. Didn't look in to why it needs five requests.
radlad 1y ago
Github was originally written in Ruby on Rails back in 2008. React was released to the public in 2013 (though it was in use at Facebook prior to that.) If we inspect the source for Github back in 2010 on the Wayback Machine[0], we can see that they were using jQuery like most sites of that time period. [0] https://web.archive.org/web/20100115102310/http://github.com/ https://web.archive.org/web/20100115102310/http://github.com... (interestingly, elan/plex shows up as a recently updated repo!)
spankalee 1y ago
They were, and still very much are, using web components. But they hired a team to do experiments to imagine the future of GitHub UI, and that team built everything in React. Now that team's work is being ported to the production UI.
- koakuma-chan 1y ago
  Just use that thing that renders React 1000x faster, million JS or something
  - Dlanv 1y ago
    it has some limitations: https://old.million.dev/docs/manual-mode/block#breaking-rules-of-blocks https://old.million.dev/docs/manual-mode/block#breaking-rule... and it isn't a silver bullet on its own
- deleted 1y ago
  [deleted]
- mdhb 1y ago
  Also as a part of their bullshit React rewrite in addition to making everything much much slower they also managed to break basic functionality like the back and forth buttons on Safari that only got fixed quite recently but for a good 9-12 month period it was impossible to use on iOS. Genuinely whoever was a part of pushing this rewrite should have been fired.
  - jdlshore 1y ago
    I know you’re just expressing your frustration, but the “the person who did this should be fired” meme you’re propagating is pretty toxic. Decisions like this are never the work of one person, and even when they are, any problems you’re perceiving were traded off against other problems you’re not perceiving. And even if it was an unadulterated mistake, it’s just that… a mistake. Should you get fired for the mistakes you make? I guess what I’m really saying is that the internet would be a better place if you and others like you dialed down the rhetoric, dialed down the outrage, and dialed up the empathy. Thanks for listening.
simonw 1y ago
They used mostly vanilla JS for over a decade. They were early proponents of a technique they called PJAX which is actually pretty similar to how HTMX works: https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax My hunch is that over time it became harder and harder for them to hire new frontend developers who didn't insist on building everything new in React and eventually they gave up.
- spankalee 1y ago
  I think it was two things: 1) The original web components proponents[1] there were very heavily into "vanilla" web components. Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API. 2) The GitHub Next team built their work in React because they required the ergonomics to move fast and they were operating independently from the production app teams. I think the first thing of theirs to be integrated was Projects, and they could probably show that their components had much better DX. Starting from the ergonomics argument, the hiring argument would take hold. I've seen this happen a few times where web components teams believe that the whole point of them is to not have to use dependencies, hamstring themselves by not using a helper library on that principle, and then get web components as a whole replaced for a proprietary framework in search of ergonomics. If they had used an ergonomic web component helper library, they could have stuck with them. The irony is that these transitions are usually way easier than a framework-to-framework migration because of web component's inherent interoperability. I still consider that a plus for web components: morally and pratically, technologies should be as easy as possible to migrate away from. [1] GitHub was so into web components that they regularly sent representatives to W3C meetings to work on them, but a lot of the original team has left the company over the last 10 years.
  - jauntywundrkind 1y ago
    > Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API. GitHub did have their own declarative semi-reactice webcomponent framework. It's pretty nice! https://github.github.io/catalyst/ https://github.github.io/catalyst/ It not at all coincidentally bears some resemblance to the (thinner, simpler) Invoker Commands API that has shipped in HTML (they share a main author): https://open-ui.org/components/invokers.explainer/ https://open-ui.org/components/invokers.explainer/
deleted 1y ago
[deleted]

Were they using vanilla js? That's impressive if yes.

bapak 1y ago

Most of the UI is React now, especially the most commonly used areas.

Imustaskforhelp 1y ago
The parent comment actually asks what they were doing before using React... No worries, you may have misunderstood them and that's okay!
- deleted 1y ago
  [deleted]

LoganDark 1y ago

Pretty sure it used to be more server rendered?

princevegeta89 1y ago
Most of it still is server rendered.
- arp242 1y ago
  I believe most stuff gets loaded via a JSON API now, and HTML rendered in JS via Rect. Maybe even all of it? For example the file overview has 14(!) requests (/recently-touched-branches, /latest-commit, /overview-files/{branch}, etc.). The issues list uses 5(!) requests to the GraphQL API. Didn't look in to why it needs five requests.

radlad 1y ago

Github was originally written in Ruby on Rails back in 2008. React was released to the public in 2013 (though it was in use at Facebook prior to that.) If we inspect the source for Github back in 2010 on the Wayback Machine[0], we can see that they were using jQuery like most sites of that time period. [0] https://web.archive.org/web/20100115102310/http://github.com/ https://web.archive.org/web/20100115102310/http://github.com... (interestingly, elan/plex shows up as a recently updated repo!)

spankalee 1y ago

They were, and still very much are, using web components. But they hired a team to do experiments to imagine the future of GitHub UI, and that team built everything in React. Now that team's work is being ported to the production UI.

koakuma-chan 1y ago
Just use that thing that renders React 1000x faster, million JS or something
- Dlanv 1y ago
  it has some limitations: https://old.million.dev/docs/manual-mode/block#breaking-rules-of-blocks https://old.million.dev/docs/manual-mode/block#breaking-rule... and it isn't a silver bullet on its own
deleted 1y ago
[deleted]
mdhb 1y ago
Also as a part of their bullshit React rewrite in addition to making everything much much slower they also managed to break basic functionality like the back and forth buttons on Safari that only got fixed quite recently but for a good 9-12 month period it was impossible to use on iOS. Genuinely whoever was a part of pushing this rewrite should have been fired.
- jdlshore 1y ago
  I know you’re just expressing your frustration, but the “the person who did this should be fired” meme you’re propagating is pretty toxic. Decisions like this are never the work of one person, and even when they are, any problems you’re perceiving were traded off against other problems you’re not perceiving. And even if it was an unadulterated mistake, it’s just that… a mistake. Should you get fired for the mistakes you make? I guess what I’m really saying is that the internet would be a better place if you and others like you dialed down the rhetoric, dialed down the outrage, and dialed up the empathy. Thanks for listening.

simonw 1y ago

They used mostly vanilla JS for over a decade. They were early proponents of a technique they called PJAX which is actually pretty similar to how HTMX works: https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax My hunch is that over time it became harder and harder for them to hire new frontend developers who didn't insist on building everything new in React and eventually they gave up.

spankalee 1y ago
I think it was two things: 1) The original web components proponents[1] there were very heavily into "vanilla" web components. Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API. 2) The GitHub Next team built their work in React because they required the ergonomics to move fast and they were operating independently from the production app teams. I think the first thing of theirs to be integrated was Projects, and they could probably show that their components had much better DX. Starting from the ergonomics argument, the hiring argument would take hold. I've seen this happen a few times where web components teams believe that the whole point of them is to not have to use dependencies, hamstring themselves by not using a helper library on that principle, and then get web components as a whole replaced for a proprietary framework in search of ergonomics. If they had used an ergonomic web component helper library, they could have stuck with them. The irony is that these transitions are usually way easier than a framework-to-framework migration because of web component's inherent interoperability. I still consider that a plus for web components: morally and pratically, technologies should be as easy as possible to migrate away from. [1] GitHub was so into web components that they regularly sent representatives to W3C meetings to work on them, but a lot of the original team has left the company over the last 10 years.
- jauntywundrkind 1y ago
  > Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API. GitHub did have their own declarative semi-reactice webcomponent framework. It's pretty nice! https://github.github.io/catalyst/ https://github.github.io/catalyst/ It not at all coincidentally bears some resemblance to the (thinner, simpler) Invoker Commands API that has shipped in HTML (they share a main author): https://open-ui.org/components/invokers.explainer/ https://open-ui.org/components/invokers.explainer/

deleted 1y ago

[deleted]