Pulldash: Fast, filterable GitHub PR review. Entirely client-side

12 points by kylecarbs

the instant i open https://pulldash.com/ghostty-org/ghostty/pull/9803 on my browser, i see:

Anonymous users are limited to 60 requests per hour. Sign in with GitHub for 5,000 requests per hour.

and signing in with github requires:

This application will be able to read and write all public and private repository data. This includes the following:

Code

Issues

Pull requests

Wikis

Settings

Webhooks and services

Deploy keys

Collaboration invites

kylecarbs

I'll check up on the anon rate-limit thing, thanks for reporting.

Signing in with GitHub unfortunately requires all of these perms. For OAuth apps, GitHub does not allow scoping tighter than repo for PR reviews.
- osa1
  
  I understand that this can be GitHub limitation, but I can imagine this being a deal breaker for many of the users. It certainly is a deal breaker for me.
  
  It looks a great project and I passionately hate GitHub's PR pages. It's unfortuante I have to give full access to my account to a third-party app to be able to use it.
  - kylecarbs
    
    If you download the desktop app, there is no token ever sent externally, nor does it give permissions to Pulldash.
    
    The app itself makes calls directly to GitHub, never proxied through a backend - the token is truly client-side, no GitHub App has permissions to access your repositories - even if we wanted to.
    
    Would a PAT be better for you?
    
    osa1
    
    I hadn't even realized that there's a desktop app. I think you should mention it and link to it in the "rate limit reached" overlay and also in the home page.
    
    kylecarbs
    
    Good idea - will do! Thank you.
    
    matklad
    
    Diffs ... only render visible rows.
    
    Could you explain why this is faster? Feels counter-intuitive. I would expect the user to view every single line of a diff, so the browser will have to render any dom node anyway, and it feels like adding JS dom tracking on top would be just pure latency&throughput overhead?
    
    That part of the question which is more a comment than a question:
    
    I'd make two assumptions here:
    
    Eventually a user will view every diff line/comments, etc
    
    Network round-trips are slow
    
    which I think suggest the architecture where we try to do everything as fast as possible, while trying to mask latency. Something like this:
    
    The first thing we show is the "cover letter" & CI status
    
    While the user looks at those, we load&render every single file
    
    It might be the case that the user came back just to give a quick LGTM, so it's worthwhile to cache HTTP responses in local storage, and do a quick preflight "has anything changed" check.
    
    So, on the first view of the PR we mask latency because the user is busy with the cover letter, and on the subsequent views we work from local storage
    
    For outgoing network trips (leaving a comment), it makes sense to first persist the comment into a local storage, upload it in background and show a small "uploading..." icon/status to inform the user when all the data is on GitHub.
    
    kylecarbs
    
    You're right that for most PRs, a user will view every line. But that's actually not where virtualization helps - it's about avoiding the initial render cost and interaction jank.
    
    Consider a 5,000-line diff. Without virtualization:
    
    Browser must create ~15k DOM nodes upfront (line numbers, content, gutters, buttons)
    
    Initial paint is blocked until all nodes exist
    
    Each line has hover states, selection handlers, and comment affordances - all wired up for invisible rows
    
    Scrolling triggers layout recalculations across all nodes
    
    With virtualization (20 rows visible, 100 in overscan), we:
    
    Render ~120 rows initially for an immediate first paint
    
    The user can start reading while the rest "exists" virtually
    
    Scrolling is smooth because we're repositioning ~200 nodes max, not 15k
    
    On the architecture you suggest, we actually do a lot of this already:
    
    API responses are cached to localStorage with SWR semantics (show stale, revalidate in background)
    
    When viewing file N, we prefetch files N-2 through N+5 in the background with full syntax highlighting
    
    Comments are saved to localStorage immediately, so you won't lose them if you refresh
    
    antonmedv
    
    Just remove code highlighting from diff =) This is what I did for https://github.com/antonmedv/gitmal
    
    And prowser for sure can render huge amound of DOM nodes. I checked Gitmal on some enormous commits - it works.
    
    fanf
    
    Scrolling triggers layout recalculations across all nodes
    
    I thought page layout is unaffected by scrolling?
    
    Each line has hover states, selection handlers, and comment affordances - all wired up for invisible rows
    
    Can’t you attach the handlers to just the enclosing element and use event.target to work out which line was clicked?
    
    Have you benchmarked a 5000 line diff?
    
    kylecarbs
    
    I'll be doing benchmarks (I'm not a fan of the arbitrary feeling either).
    
    Once I do we can have certainty, but on my feeling, it's a lot faster than GitHub.
    
    GitHub: https://github.com/oven-sh/bun/pull/25168/files#diff-137a4c938da19206288b38e59a0b777e92dd9046c456169de216f13230a457c8
    
    Pulldash: https://pulldash.com/oven-sh/bun/pull/25168#file=test%2Fjs%2Fweb%2Furlpattern%2Furlpatterntestdata.json
    
    fanf
    
    GitHub is infamous for being incredibly slow, so surely you can set yourself a better target such as Forgejo or cgit, eg https://cgit.freebsd.org/src/commit/?id=1c7c36f67f4670a5e3c256a3a8cea7b4857b8b69