Currently, the highlighter uses a simple keyword heuristic (line.includes('error')). It produces false positives (e.g., "no error found"). I plan to add regex-based custom highlighting to fix this.
I treat the file like a video stream. Since the browser doesn't know the total line count of a 10GB file without reading it all (which defeats the purpose), a traditional scrollbar is hard to implement perfectly. The slider acts as a "seek bar". I'll consider adding Prev/Next Chunk buttons for finer control. The "~20MB" claim refers to the file buffer/chunk size held in memory by the FileReader, not the entire browser process footprint (React + DOM + V8 overhead). You are right that the baseline for a React app is higher (60MB+), but the key value proposition is that opening a 10GB file won't spike usage to 10GB—it stays flat relative to the baseline.
Why are some lines red? and scrolling through the file with a slider was not a good experience.
> Reads 10GB+ files instantly (constant memory usage ~20MB).
I loaded a 21MB file and it uses 174MB. If I don't even open a file it still uses 60MB
Currently, the highlighter uses a simple keyword heuristic (line.includes('error')). It produces false positives (e.g., "no error found"). I plan to add regex-based custom highlighting to fix this. I treat the file like a video stream. Since the browser doesn't know the total line count of a 10GB file without reading it all (which defeats the purpose), a traditional scrollbar is hard to implement perfectly. The slider acts as a "seek bar". I'll consider adding Prev/Next Chunk buttons for finer control. The "~20MB" claim refers to the file buffer/chunk size held in memory by the FileReader, not the entire browser process footprint (React + DOM + V8 overhead). You are right that the baseline for a React app is higher (60MB+), but the key value proposition is that opening a 10GB file won't spike usage to 10GB—it stays flat relative to the baseline.
I appreciate you testing it out!