nbslabs/difflense

1. Project type and hosting

- DiffLens is a static, client-side-only web app designed to run entirely in the browser.

- It is structured for GitHub Pages deployment: no backend, no database, no server-side rendering, and no analytics/tracking layer.

2. Top-level page layout

- The repository is mostly a small set of HTML entry points:

- index.html for the landing/home experience

- diff-view.html for the actual diff viewer

- about.html, contact.html, and contribute.html for supporting content

- This makes the site more like a static product site plus a dedicated app page than a traditional SPA.

3. Core application boundary

- The main functional boundary is the diff viewer page.

- That page appears to load the JavaScript modules in assets/js/ and the shared styling in assets/css/main.css.

- The rest of the HTML pages are informational and do not appear to participate in diff processing.

4. Diff processing pipeline

- The app follows a straightforward flow:

- user pastes raw git diff text or uploads a diff file

- the diff is parsed in-browser

- the parsed representation is rendered into a structured diff view

- The key architectural principle from the README is that all parsing and rendering happen locally, so the diff content never leaves the browser.

5. Parsing subsystem

- assets/js/diff-parser.js is the likely core of the domain logic.

- Its role is to convert raw diff text into a structured model of files, hunks, additions, deletions, and metadata that the UI can consume.

- This is the main “business logic” layer of the repository.

6. Rendering and interaction subsystem

- assets/js/diff-viewer.js appears to own the UI rendering of parsed diffs.

- It likely handles:

- unified vs side-by-side display modes

- collapsible file sections

- file statistics such as additions/deletions

- navigation between files in multi-file diffs

- This is the main presentation/controller layer for the app.

7. GitHub-related integration

- assets/js/github-integration.js is a separate concern from parsing/rendering and likely handles GitHub-specific input or linking behavior.

- In architecture terms, this is an integration boundary for GitHub-oriented workflows, distinct from the core diff viewer logic.

- It is not a backend integration in the server sense; it remains browser-side.

8. State and persistence

- The README mentions settings such as expanded/collapsed file state being saved in browser local storage.

- That means the app uses lightweight client-side persistence for preferences, not for the diff data itself.

- This is an important boundary: preferences persist locally, diff content is transient.

9. Navigation and multi-page structure

- The site uses ordinary HTML navigation rather than a heavy client-side router.

- The home page and auxiliary pages are separate documents, while the diff viewer is the interactive app surface.

- This is relevant for diagramming because there is no central application server or route controller.

10. Styling and presentation layer

- assets/css/main.css is the shared styling layer and likely defines the clean visual system described in the README.

- The README’s mention of TailwindCSS suggests the design may be utility-driven, but from the file tree the important architectural point is that styling is centralized in a single shared CSS asset.

- The UI emphasis is on readability, responsive layout, and diff-specific visual cues like line numbers and highlights.

11. User input boundaries

- There are two primary input paths: paste text and file upload.

- Both are handled locally, then normalized into the same parsing/rendering pipeline.

- This keeps the architecture simple: multiple input sources, one internal diff model.

12. Deployment and operational model

- Because the app is static, deployment is effectively asset hosting rather than application hosting.

- CNAME indicates a custom domain setup, reinforcing that the production runtime is just browser + static files.

- No queues, APIs, authentication services, or external compute services are part of the core architecture.