3 ms·

> The spec lives in GitHub in a 7MB source file which is too large to view through the GitHub web interface It's a bit offtopic, but think about it: cannot vie

by zx8080 2y ago

> The spec lives in GitHub in a 7MB source file which is too large to view through the GitHub web interface It's a bit offtopic, but think about it: cannot view the doc despite its size is only 7Mb ~ about 0.04 percent of a typical computer's memory (16Gb). We can open and view PDFs much bigger and search there without an issue in browser. We can view movies worth half of the memory. But it's surprisingly not possible to view a 7Mb text file in the professional tool for working with textual source code called github. Shame. And sad.

ehutch79 2y ago
7mb is a LOT of text. More than most epic fantasy novels. While surely the text fits, it’s all the stuff around it like rendering and layout that take the memory.
sureIy 2y ago
The file is 142k lines line that GitHub would have to turn into HTML and the browser would have to render immediately. The browser is perfectly able to render the raw file (you can try it yourself) but everything that goes with it would be asking a bit much, particularly because the intent of the author was to blame the file, therefore adding yet more information/elements to the page. While browsers nor GitHub are beacons of performance, I don’t think it's fair in this case. PDFs can be rendered page by page and each page is self-contained. Same with videos, where you read the index and jump to the key frame you're onto, reading data in a highly optimized and parallelized way (often down to the chip). With HTML you must render every letter that comes before line 100000 before rendering line 100000
- kevmo314 2y ago
  You might be surprised to learn that VS Code renders its viewport with HTML and it has no issues displaying this file.
  - quintu5 2y ago
    Indeed. This is also one of the use-cases I built the Tachi Code browser extension for. It injects a monaco-based editor into the current page when it detects you're viewing a raw file (i.e., the page's rendered body contains nothing other than a <pre> tag). Tachi Code for Chrome: https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf https://chromewebstore.google.com/detail/tachi-code/acoecgia... Tachi Code for Firefox: https://addons.mozilla.org/en-US/firefox/addon/tachi-code/ https://addons.mozilla.org/en-US/firefox/addon/tachi-code/
  - sureIy 2y ago
    I'm not surprised to learn anything because I worked at GitHub before. GitHub is not VS Code. GitHub is a Ruby on Rails website with some React sprinkled on. You can't expect the same performance optimization from a website that a whole IDE has.
- koito17 2y ago
  > The file is 142k lines line that GitHub would have to turn into HTML and the browser would have to render immediately. GitHub's new, React-based code viewer aggressively virtualizes the rendered text. Only the lines visible in the viewport, together with 10-20 lines around the viewport, will be rendered. This is why search is broken when using the native browser search (not all text is rendered). As another comment pointed out, VS Code is capable of opening such large files with syntax highlighting, minimap, etc. VS Code is also employing some form of virtualization. It's unclear why GitHub's file viewer refuses to show files larger than a megabyte or so.
  - simonw 2y ago
    I'm sad that the No-React forces within GitHub (presumably) eventually lost that battle. There's React all over GitHub now and it's resulting in so many weird glitches like this.
    - koito17 2y ago
      The file viewer is especially strange. Scrolling is janky on iOS (presumably they are trying to control scroll position and this interferes with Safari's scroll bar). Last time I looked into the file viewer, I believe it was rendered as a web component with its own shadow DOM and a react root inside. Although off-topic for this thread, one minor annoyance is how the "improved" Issues interface no longer displays pagination controls until several megabytes of JavaScript finish loading. Meanwhile the Pull Request page, one of the oldest parts of the GitHub interface, is capable of displaying pagination controls before JavaScript loads, and it's interactive (i.e. clicking on pagination buttons will work as expected, even without JavaScript). Want to note that web-based UI doesn't have to be this way. In the case of rendering text with syntax highlighting, VS Code shows that it can be done in a performant manner. As for functionality without JavaScript, embracing standard web APIs, etc., that is exactly what frameworks like React Router (formerly Remix) are designed for.
  - Starlevel004 2y ago
    > GitHub's new, React-based code viewer aggressively virtualizes the rendered text. Only the lines visible in the viewport, together with 10-20 lines around the viewport, will be rendered. Then why is it so fucking slow all of the time?

by zx8080 2y ago

ehutch79 2y ago

7mb is a LOT of text. More than most epic fantasy novels. While surely the text fits, it’s all the stuff around it like rendering and layout that take the memory.

sureIy 2y ago

The file is 142k lines line that GitHub would have to turn into HTML and the browser would have to render immediately. The browser is perfectly able to render the raw file (you can try it yourself) but everything that goes with it would be asking a bit much, particularly because the intent of the author was to blame the file, therefore adding yet more information/elements to the page. While browsers nor GitHub are beacons of performance, I don’t think it's fair in this case. PDFs can be rendered page by page and each page is self-contained. Same with videos, where you read the index and jump to the key frame you're onto, reading data in a highly optimized and parallelized way (often down to the chip). With HTML you must render every letter that comes before line 100000 before rendering line 100000

kevmo314 2y ago
You might be surprised to learn that VS Code renders its viewport with HTML and it has no issues displaying this file.
- quintu5 2y ago
  Indeed. This is also one of the use-cases I built the Tachi Code browser extension for. It injects a monaco-based editor into the current page when it detects you're viewing a raw file (i.e., the page's rendered body contains nothing other than a <pre> tag). Tachi Code for Chrome: https://chromewebstore.google.com/detail/tachi-code/acoecgiamdjjkhmdodcfdfanfnagamjf https://chromewebstore.google.com/detail/tachi-code/acoecgia... Tachi Code for Firefox: https://addons.mozilla.org/en-US/firefox/addon/tachi-code/ https://addons.mozilla.org/en-US/firefox/addon/tachi-code/
- sureIy 2y ago
  I'm not surprised to learn anything because I worked at GitHub before. GitHub is not VS Code. GitHub is a Ruby on Rails website with some React sprinkled on. You can't expect the same performance optimization from a website that a whole IDE has.
koito17 2y ago
> The file is 142k lines line that GitHub would have to turn into HTML and the browser would have to render immediately. GitHub's new, React-based code viewer aggressively virtualizes the rendered text. Only the lines visible in the viewport, together with 10-20 lines around the viewport, will be rendered. This is why search is broken when using the native browser search (not all text is rendered). As another comment pointed out, VS Code is capable of opening such large files with syntax highlighting, minimap, etc. VS Code is also employing some form of virtualization. It's unclear why GitHub's file viewer refuses to show files larger than a megabyte or so.
- simonw 2y ago
  I'm sad that the No-React forces within GitHub (presumably) eventually lost that battle. There's React all over GitHub now and it's resulting in so many weird glitches like this.
  - koito17 2y ago
    The file viewer is especially strange. Scrolling is janky on iOS (presumably they are trying to control scroll position and this interferes with Safari's scroll bar). Last time I looked into the file viewer, I believe it was rendered as a web component with its own shadow DOM and a react root inside. Although off-topic for this thread, one minor annoyance is how the "improved" Issues interface no longer displays pagination controls until several megabytes of JavaScript finish loading. Meanwhile the Pull Request page, one of the oldest parts of the GitHub interface, is capable of displaying pagination controls before JavaScript loads, and it's interactive (i.e. clicking on pagination buttons will work as expected, even without JavaScript). Want to note that web-based UI doesn't have to be this way. In the case of rendering text with syntax highlighting, VS Code shows that it can be done in a performant manner. As for functionality without JavaScript, embracing standard web APIs, etc., that is exactly what frameworks like React Router (formerly Remix) are designed for.
- Starlevel004 2y ago
  > GitHub's new, React-based code viewer aggressively virtualizes the rendered text. Only the lines visible in the viewport, together with 10-20 lines around the viewport, will be rendered. Then why is it so fucking slow all of the time?