jigar-sable/portfolio-website

1. This repository is a static personal portfolio site, not a server-backed application. The runtime is the browser; deployment is likely a static host such as Netlify, as indicated by the README.

2. The site is split into multiple entry pages rather than a single SPA:

- index.html for the main portfolio landing page

- experience/index.html for work/history content

- projects/index.html for project listings

- 404.html for the custom error page

3. Shared presentation lives under assets/:

- assets/css/style.css for global styling

- assets/js/app.js and assets/js/script.js for shared client-side behavior

- assets/images/ for reusable media, organized into educat, projects, and skills

4. Each section/page also has its own local CSS and JS:

- experience/style.css and experience/script.js

- projects/style.css and projects/script.js

- assets/css/404.css and assets/js/404.js

This suggests a clear boundary between global site behavior and page-specific interactions.

5. Data-driven content is stored in JSON rather than hardcoded in HTML:

- projects/projects.json likely feeds the projects page

- skills.json likely feeds the skills section on the main page

The JS files are probably responsible for fetching these files, parsing them, and rendering DOM elements.

6. The main page is the most feature-rich integration point. Based on the README, it likely combines:

- animated intro text via Typed.js

- visual effects via Particle.js

- reveal-on-scroll behavior via ScrollReveal

- card/image tilt effects via Tilt.js

- iconography via Font Awesome

- embedded live chat via Tawk.to

7. jQuery is part of the client stack, so some DOM manipulation and event handling are probably written with jQuery rather than plain vanilla JS. That matters for understanding how page scripts interact with the DOM and external plugins.

8. The architecture is purely front-end and componentized by page/section. There is no evidence of an API layer, database, build pipeline, or backend service. Data flow is mostly:

static HTML shell -> page JS -> JSON/assets -> rendered DOM.

9. The projects area is a self-contained sub-application of sorts: its own HTML, CSS, JS, and data file. That separation makes it the clearest example of a content module with its own rendering pipeline.

10. The custom 404 page is also isolated, which means even error handling is handled client-side at the static hosting layer rather than by application routing.

11. In diagram terms, the key boundaries are:

- shared assets vs. page-specific assets

- static content vs. JSON-driven content

- browser-only UI logic vs. external third-party widgets/libraries

12. Overall, the repository is a modular static portfolio site where each page loads a small set of local assets, optionally fetches JSON for dynamic rendering, and enhances the experience with a handful of browser-side libraries.