Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery

The center of gravity in advanced interactive web work has moved decisively away from the old Bootstrap-plus-jQuery pattern and toward three families of systems: platform-first approaches built on native browser APIs...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/files/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-bd337b79/
Source reference	raw/system-archives/protocol5/report-preservation/2026-05-02/agent-file-handoff/Archive/Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery.md
File type	md
Content category	memory-file
Last fetched	2026-05-03T02:48:13.1276041Z
Last changed	2026-05-02T22:34:38.8925068Z
Content hash	sha256:bd337b799f5494c5acbe29542d8b2f88013a1dd322532b249a5daa714deb2159
Import status	unchanged
Raw source layer	data/sources/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-handoff-archive-cutting-bd337b799f54.md
Normalized source layer	data/normalized/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-handoff-archive-cutting-bd337b799f54.txt

Current File Content

Structure Preview

• Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery
• Executive summary
• Protocol5 under the microscope
• Observed Protocol5 traits
• Modern tooling for rich interactivity without Bootstrap or jQuery
• Comparative view of the major options
• Standout case studies
• Architecture patterns, performance tradeoffs, SEO, and accessibility
• Recommended stacks by project goal
• Primary sources and limitations
• Prioritized primary sources
• Open questions and limitations

Raw Version

# Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery

## Executive summary

The center of gravity in advanced interactive web work has moved decisively away from the old Bootstrap-plus-jQuery pattern and toward three families of systems: platform-first approaches built on native browser APIs and Web Components; compiler/reactivity frameworks such as Svelte and Solid that minimize runtime work; and graphics/motion stacks built around Three.js, WebGL/WebGPU, Motion, GSAP, and related tools. Astro’s islands architecture adds a fourth, especially practical pattern: keep most of the page static HTML, then hydrate only the small zones that truly need interactivity. That combination usually gives a better performance, accessibility, and SEO envelope than the legacy “ship a big JS app everywhere” model. citeturn40search1turn17search2turn15search4turn12search3turn10search5turn14search0turn11search4turn13search0

Protocol5 is unusual within this landscape. It is not a motion-heavy, award-site-style showcase. Instead, its novelty lies in what it calls a “protocol surface”: static human-readable routes, a Blazor-hosted calculator shell for the computational tools, and machine-readable JSON route contracts, mirrors, registries, schemas, and package artifacts exposed as first-class public assets. In other words, its most original move is treating the website itself as both documentation and inspectable interface, not just presentation. citeturn1view0turn2view0turn2view1turn20view0

For greenfield projects that explicitly avoid Bootstrap and jQuery, the strongest default recommendations are: Astro for marketing and editorial experiences with selective interactivity; SvelteKit or SolidStart for highly interactive UI with tight responsiveness; Lit or vanilla Web Components when components must be framework-agnostic and embeddable; and Three.js plus either Theatre.js or GSAP for immersive 3D or cinematic storytelling. Motion is especially compelling when you want modern animation with a much lighter surface area than a full GSAP-driven build. citeturn40search1turn38search5turn15search4turn43search2turn10search5turn38search0turn13search0turn11search4turn15search1

## Protocol5 under the microscope

Protocol5’s current homepage describes itself as “a public interface for exact mathematics, dense symbolic media, and the official UAI .NET implementation path,” and explicitly says the page is meant to behave like a “protocol surface: readable, inspectable, and alive under the pointer.” The information architecture is intentionally split into sibling domains for Mathematics and the UAI .NET Hub, with About, Links, Contact, downloads, schemas, registries, and compatibility routes kept as shared infrastructure. That is a deliberate IA choice: it avoids collapsing everything into a single marketing shell and instead foregrounds boundaries, authority, and route stability. citeturn1view0turn24search0turn20view0

The clearest architectural signal is the public route contract. Protocol5 publishes a JSON contract that enumerates modern human routes, compatibility aliases, stable machine assets, stable download assets, and frozen generated route families. It explicitly marks `/mathematics/calculator`, `/mathematics/converter`, and `/mathematics/encryption` as being served by an “NS12.Calculator Blazor shell,” while most editorial routes resolve to static HTML files. That split strongly suggests a static-first public site with a more dynamic .NET/Blazor island for computational tools. citeturn2view0turn20view0

The site’s machine-readable surface is not cosmetic. Its public JSON assets include a route contract, UAI discovery JSON, registry mirrors, schema mirrors, and downloadable package artifacts. The UAI discovery file also documents a separation of responsibilities: UAIX is the canonical standards authority, while Protocol5 distributes implementation packages, compatibility mirrors, ZIP bundles, and NuGet artifacts. This is a rigorous “authority boundary” pattern that most interactive sites do not attempt. citeturn2view0turn2view1turn9view2

### Observed Protocol5 traits

| Aspect | Evidence from the live site | Assessment |
|---|---|---|
| Information architecture | Homepage and Mathematics/UAI pages repeatedly emphasize sibling sections, explicit authority boundaries, and separate human/machine routes. citeturn1view0turn9view0turn9view2 | Strong, unusually disciplined IA. Better than many visually richer sites at making scope and ownership legible. |
| Interactive features | Publicly exposed interactive tools include Calculator, Converter, Encryption Tool, Workbench, plus a “Copy install command” control on the homepage. citeturn9view0turn9view2turn1view0 | Interactivity is functional rather than theatrical. Tool-first, not animation-first. |
| Client/server stack | Route contract shows Blazor shells for calculator/converter/encryption; About page says the current version “hosts a Blazor calculator shell.” Older site materials referenced Azure, C#, and TypeScript. citeturn2view0turn20view0turn25search1 | Likely hybrid architecture: static HTML for most routes, .NET/Blazor for the computational application surface. |
| Animations and motion | The crawlable pages expose little evidence of heavy animation; the site’s novelty is inspectability and layered route design, not cinematic motion. citeturn1view0turn9view0turn20view0 | Visually restrained. Compared with cutting-edge showcase sites, Protocol5 is closer to “procedural documentation” than to “immersive microsite.” |
| Accessibility | There is a visible “Skip to content” link on key pages, a consistent heading hierarchy, and readable link labels. However, at least one homepage graphic is exposed only as “Image” in the crawler output, which suggests non-descriptive alt/labeling for at least one asset. citeturn1view0turn9view0turn9view2 | Solid semantic baseline, but image labeling and dynamic tool accessibility warrant deeper manual audit. |
| Performance profile | Most modern human routes resolve to static HTML files, while a smaller tool surface is delegated to Blazor. citeturn2view0turn20view0 | Editorial routes should be favorable for FCP/LCP/CLS if assets stay light; the Blazor tool routes are the place where INP and bundle size risks will concentrate. Context on these metrics: Google’s current CWV set is LCP, INP, and CLS. citeturn49search2turn49search0turn49search3turn49search5 |
| Novel technique | “Machine-readable public surface” with human pages paired to route contracts, package downloads, mirrors, and explicit authority boundaries. citeturn1view0turn2view0turn2view1 | This is the most original part of the site. It points toward websites that are understandable to both humans and software agents. |

The key critique is that Protocol5 is “cutting-edge” in structure and inspectability more than in visual expressiveness. If your benchmark is a Bruno Simon or Lusion-style 3D showpiece, Protocol5 is comparatively austere. If your benchmark is rigorously machine-legible publishing, explicit standards boundary management, and mixed human/machine route design, it is quite forward-looking. citeturn34search0turn36search2turn1view0turn2view0

## Modern tooling for rich interactivity without Bootstrap or jQuery

The modern replacement for Bootstrap/jQuery is not a single stack. It is a toolkit decision: choose the minimum abstraction that gives you the interaction model you need. If the experience is primarily content with a few interactive islands, Astro is usually the best default. If the experience is a highly reactive application, SvelteKit or SolidStart is stronger. If you need interoperable components that can live in any host environment, Web Components and Lit are the cleanest path. If the experience itself is motion or 3D, move to Motion, GSAP, Three.js, WebGL, or WebGPU. citeturn40search1turn15search4turn38search5turn12search3turn43search2turn11search4turn13search0turn10search5turn14search0

### Comparative view of the major options

| Tool or approach | Size profile | Learning curve | SSR or SSG support | Interactivity capability | Best-fit use cases |
|---|---|---|---|---|---|
| Vanilla JS plus native APIs | Minimal; no framework runtime | Medium if you build patterns yourself | Natively works with any SSR/SSG stack | Medium to high for DOM/UI, lower for large app ergonomics | Small-to-medium sites, bespoke interactions, progressive enhancement |
| Web Components | Minimal platform runtime | Medium | Excellent when paired with static/SSR hosts | High for reusable widgets | Design systems, embeds, cross-framework component delivery |
| Lit | Very low; Lit says about 5 KB minified/compressed | Low to medium | Good with static/SSR hosts | High for componentized UI | Scalable Web Components, enterprise design systems |
| SvelteKit | Low; compiler-generated minimal browser work | Medium | Strong SSR, CSR, prerender, static export patterns | High | Product sites, apps, data-rich interactions |
| SolidStart | Low; Solid emphasizes fine-grained, real-DOM updates and tree shaking | Medium | Strong CSR, SSR, SSG | High, especially for responsiveness | Dashboards, reactive tools, complex stateful UI |
| Astro | Often near-zero client JS for Astro components; islands opt in as needed | Low to medium | Excellent SSG, SSR, server islands | Medium to high, selectively | Marketing sites, docs, commerce, editorial with islands |
| Motion | Very low to moderate; docs expose 2.3 KB mini and 18 KB hybrid modes | Low | Works with JS, React, Vue, any host page | High for DOM/SVG/gesture/scroll animation | UI motion, transitions, scroll effects, lightweight microsites |
| GSAP | Moderate to high, depending on plugins | Medium | Framework-agnostic, works in SSR/CSR projects with care | Very high for timelines and choreography | Hero scenes, complex timeline sequencing, scroll storytelling |
| Three.js | High relative to DOM libraries; assets dominate total footprint | High | Usually client-rendered, though can sit inside SSR shells | Very high for 3D/WebGL/WebGPU experiences | Portfolios, immersive storytelling, product visualization |
| WebGL and WebGPU | Browser-native APIs, but high application complexity | High to very high | Usually client-rendered modules | Very high | Custom renderers, compute-heavy visuals, advanced 3D |
| CSS Houdini | Browser-native, feature-dependent | High | Works anywhere CSS works | Niche but powerful | Paint worklets, typed custom properties, creative effects |

The size column above is intentionally comparative rather than pretending every option publishes directly comparable min+gzip numbers. The strongest high-confidence size signals from primary sources are: Astro components render to static HTML with no client runtime by default; Svelte shifts work into a compiler and aims for tiny bundles; Solid describes itself as small and tree-shakable; Lit says its footprint is around 5 KB compressed; Motion documents two sizes for `animate()` at 2.3 KB and 18 KB; Web Components, WebGL, WebGPU, and much of Houdini are native browser capabilities rather than framework runtimes. citeturn40search1turn17search2turn28search10turn43search2turn15search1turn12search3turn13search1turn14search0turn12search1

For platform-native front ends, the most important building blocks are not glamorous: `requestAnimationFrame` for frame-aligned animation; the Web Animations API for browser-native motion; `IntersectionObserver` and the `loading` attribute for lazy work; and `ResizeObserver` for layout-aware components. Those are the primitives that replaced much of what jQuery used to do indirectly. citeturn44search0turn46search0turn43search3turn43search4turn45search2turn45search0

## Standout case studies

The examples below were chosen because the official site, repo, or creator notes expose a credible modern stack centered on native APIs, compiler frameworks, graphics engines, or motion runtimes rather than Bootstrap/jQuery-era conventions.

| Site | Why it stands out | Technical breakdown | Official source |
|---|---|---|---|
| Protocol5 | Machine-readable “protocol surface” rather than conventional marketing shell | Static human routes, Blazor calculator shell, route contract JSON, schema/registry/package mirrors, explicit authority boundary to UAIX | citeturn1view0turn2view0turn2view1turn20view0 |
| Bruno Simon portfolio | One of the strongest examples of game-like 3D navigation on the public web | Three.js world, WebGPU/WebGL renderer selection, Rapier physics, Howler audio, public source code, in-site devlog transparency | citeturn34search0turn34search1 |
| Spline homepage | Production-grade interactive 3D site that also documents its own export path | Real-time collaborative 3D platform, states/events, timeline animation, physics/particles, exportable web component (`spline-viewer`) and framework integrations | citeturn35search1 |
| Rive homepage and editor | High-end interaction driven by stateful vector animation rather than DOM tweens | GPU-accelerated vector renderer, state machines, web runtime, editor-to-runtime pipeline, cross-platform runtimes | citeturn35search0turn35search6 |
| Lusion main site and Gemini experiment | Award-driven, real-time 3D studio work with explicit WebGL practice | Official studio expertise lists WebGL development; Gemini monthly experiment is a real-time car demo by named creators | citeturn36search2turn36search5 |
| Theatre.js site | Motion-design tooling site that demonstrates browser-native animation craft | Sequence editor, graph editor, stack-agnostic variable animation, official paths for THREE.js, React Three Fiber, and HTML/SVG | citeturn38search0turn38search4turn38search2 |
| Motion examples | Dense interaction examples for gestures, scroll, menus, and text animation | Low-footprint DOM/SVG animation APIs, extensive official examples for JS/React/Vue | citeturn11search4turn15search1turn38search1 |
| Three.js examples | The canonical 3D interaction laboratory on the web | Official examples expose cameras, shaders, loaders, post-processing, controls, WebXR, and WebGL/WebGPU capabilities | citeturn10search5turn39search3turn39search0 |
| WebGPU Samples | Best current reference for GPU-native web interaction patterns | Official sample set and source repo; TypeScript plus Rollup build; shows compute and rendering patterns beyond classic WebGL | citeturn39search2turn39search1turn14search0 |
| Astro docs and demos | A strong model for “mostly static, selectively interactive” sites | Islands architecture, server islands, component-level hydration directives, multi-framework support | citeturn40search1turn40search0 |
| Svelte site | Interactive learning/product site backed by compiler-driven UI | Svelte positions itself as a compiler that emits minimal browser work and concise component code | citeturn17search2 |
| SolidStart docs | Reactive doc site that demonstrates fine-grained updates and mixed rendering modes | Solid fine-grained reactivity plus SolidStart support for CSR, SSR, and SSG | citeturn15search4turn38search5 |

If you want a shortlist of “what to study first,” the highest-value references are Protocol5 for inspectable route design, Bruno Simon for immersive 3D interaction, Spline and Rive for production-ready design-to-runtime pipelines, Astro for selective hydration, and WebGPU Samples for next-generation browser graphics. citeturn2view0turn34search0turn35search1turn35search0turn40search1turn39search2

## Architecture patterns, performance tradeoffs, SEO, and accessibility

The most robust no-jQuery/no-Bootstrap architecture in 2026 is usually HTML-first, then interactive enhancement by layer: semantic HTML and CSS first, selective components second, motion third, and heavy canvas or GPU modules only where they add clear value. That framing is directly aligned with progressive enhancement and with Astro’s islands model, which renders most of the page to static HTML and hydrates only what actually needs client-side code. citeturn45search3turn40search1

```mermaid
flowchart LR
    A[Static HTML and CSS baseline] --> B[Selective interactivity]
    B --> C[Component layer]
    C --> D[Motion layer]
    D --> E[Heavy graphics layer]
    A --> F[SEO metadata and crawlable content]
    B --> G[Keyboard support and semantics]
    D --> H[Reduced-motion fallback]
    E --> I[Capability checks and lazy loading]

    B1[Astro islands or server islands] --> C
    B2[Lit or custom elements] --> C
    B3[SvelteKit or SolidStart routes] --> C
    D1[Motion or GSAP] --> D
    E1[Three.js on WebGL or WebGPU] --> E
```

This diagram reflects current best practice because large JavaScript payloads directly pressure Core Web Vitals. Google’s current Core Web Vitals are LCP for loading, INP for responsiveness, and CLS for visual stability, with thresholds of roughly 2.5 seconds, 200 milliseconds, and 0.1 respectively for a good experience. HTML-first delivery and selective hydration help LCP; avoiding long main-thread tasks helps INP; reserving media dimensions and controlling late DOM insertion helps CLS. citeturn49search2turn49search0turn49search3turn49search5

For SEO, server rendering, static rendering, and hydration are still the safer defaults than pure client-side rendering. Google Search can process JavaScript, but Search Central still recommends SSR, static rendering, or hydration over dynamic rendering, and characterizes dynamic rendering as a workaround rather than a long-term solution. Google’s own rendering guidance also notes that SSR is often favored because it delivers a “complete looking” experience to crawlers and users, while CSR requires more testing and operational care. citeturn48search2turn48search1turn48search4

Performance implementation patterns should stay close to browser primitives. Use `requestAnimationFrame` for custom animation loops, the Web Animations API when DOM animation can stay native, `IntersectionObserver` plus built-in lazy loading for offscreen work, and `ResizeObserver` for component responsiveness rather than polling. For many “fancy” sites, a surprising amount of polish comes from doing these simple things correctly. citeturn44search0turn46search0turn43search3turn45search2turn45search0turn43search4

Accessibility is where many interactive sites still fail. WAI guidance is clear that keyboard operation must exist for all functionality, moving interfaces need pause or control mechanisms, and carousels or motion-rich widgets need semantic structure, focus handling, and user control over animation. Reduced-motion handling is also not optional on serious interactive work: the `prefers-reduced-motion` media query exists specifically so teams can disable or soften non-essential motion for people who experience discomfort. citeturn47search7turn47search2turn47search8turn46search5

For canvas, WebGL, and WebGPU experiences, the accessibility rule is not “avoid them,” but “never make them your only interface.” Give keyboard equivalents for drag-dependent actions where feasible, keep important copy and metadata in real HTML outside the canvas, provide live-region or text alternatives for state changes, and offer reduced-motion or simplified-render modes for heavy scenes. WebGPU in particular remains a limited-availability API, so capability detection and graceful fallback to WebGL or DOM rendering is essential. citeturn14search0turn13search1turn45search3turn47search7

## Recommended stacks by project goal

The right stack is mostly a question of where you want your complexity to live: in content, in UI state, in motion choreography, or in graphics rendering.

| Project goal | Recommended stack | Why this is the best fit | Complexity | Resource profile |
|---|---|---|---|---|
| Portfolio | Astro + a small Svelte or Lit island layer + Motion; add Three.js only for one hero experience | Astro keeps the portfolio crawlable and fast; Motion gives polished transitions; a single focused 3D module can create differentiation without turning the entire site into a game | Medium | 1 creative front-end developer, 1 designer; roughly 4–8 weeks |
| Data visualization | SvelteKit or SolidStart + D3/Observable-style charting + server caching/API layer | Fine-grained reactivity is ideal for controls, filters, and live updates; SSR/SSG support preserves discoverability and fast initial paint | Medium to high | 1 front-end engineer, 1 data engineer or analyst; roughly 6–12 weeks |
| Immersive or 3D experience | Vite + Three.js + Theatre.js or GSAP + compressed asset pipeline; optional WebGPU path with WebGL fallback | Best when the experience itself is a scene, product model, simulation, or spatial story; Theatre.js is excellent for authored motion, GSAP for timeline control | High to very high | 1 creative developer, 1 3D artist, often 1 technical artist; roughly 8–20 weeks |
| Marketing microsite | Astro + Motion + optional GSAP for hero sections + server islands for personalization | Strongest performance/SEO balance for campaigns, launches, and content-rich pages with a few memorable interactive zones | Low to medium | 1 front-end developer, 1 designer, optional content producer; roughly 3–8 weeks |

If the project must ship components across many host environments or multiple product teams, add a fifth option: Lit plus Web Components. Lit is especially attractive when you want long-lived, framework-neutral interactive components with low payload and minimal lock-in. citeturn43search2turn12search3

If the goal is to emulate Protocol5 specifically, I would not copy its exact stack wholesale unless the site also needs a .NET package-distribution or standards-hub role. What is worth borrowing is its discipline: static-first editorial routes, dynamic tools isolated to their own surface, explicit machine-readable contracts, and strong authority boundaries between “what this site implements” and “what another site defines.” citeturn2view0turn2view1turn20view0

## Primary sources and limitations

### Prioritized primary sources

| Priority | Source | Why it matters |
|---|---|---|
| Highest | Protocol5 homepage, Mathematics/UAI pages, route contract, and UAI discovery JSON citeturn1view0turn9view0turn9view2turn2view0turn2view1 | Primary evidence for the Protocol5 review |
| Highest | Microsoft Blazor docs on render modes and interactivity citeturn37search0turn37search1 | Best source for interpreting the Blazor shell noted by Protocol5 |
| Highest | Astro islands and server-islands docs citeturn40search1turn40search0 | Core reference for selective hydration and static-first interactivity |
| Highest | Svelte homepage and Solid/SolidStart docs citeturn17search2turn15search4turn38search5 | Primary sources for compiler-driven and fine-grained reactive UI |
| Highest | Three.js docs and official examples; WebGPU Samples repo/site citeturn10search5turn39search2turn39search1 | Core references for immersive graphics systems |
| Highest | Motion docs and GSAP installation docs citeturn15search1turn11search4turn13search0 | Primary references for modern motion tooling |
| Highest | MDN and Lit docs for Web Components, WebGL, WebGPU, Houdini, WAAPI citeturn12search3turn43search2turn13search1turn14search0turn12search1turn46search0 | Best cross-browser technical references for platform-native interactivity |
| High | Google Search Central and web.dev rendering guidance citeturn48search2turn48search1turn48search4 | Best sources for SEO/rendering tradeoffs |
| High | web.dev Core Web Vitals documentation citeturn49search2turn49search0turn49search3turn49search5 | Ground truth for current performance metrics and thresholds |
| High | W3C WAI accessibility principles and carousel/animation guidance citeturn47search7turn47search2turn47search8 | Practical standards guidance for motion-heavy interactive UI |

### Open questions and limitations

I was not able to obtain a live Lighthouse or CrUX readout for Protocol5 through the available browsing tools, so the Protocol5 “performance metrics” discussion is architecture-based rather than a fresh synthetic or field audit. The dynamic calculator/converter routes also were not directly crawlable in this session, so the accessibility and interaction review of those tools should be treated as incomplete. Finally, for the case-study list, the absence of Bootstrap/jQuery is a high-confidence inference from the official stacks and creator documentation, but I did not perform packet-level dependency inspection on every live example.

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery; Executive summary; Protocol5 under the microscope; Observed Protocol5 traits; Modern tooling for rich interactivity without Bootstrap or jQuery; Comparative view of the major options; Standout case studies; Architecture patterns, performance tradeoffs, SEO, and accessibility. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Global File Index
• Reports

Provenance And History

• Current observation: 2026-05-03T02:48:13.1276041Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-360 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/files/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-bd337b79/",
    "source_reference":  "raw/system-archives/protocol5/report-preservation/2026-05-02/agent-file-handoff/Archive/Cutting-Edge Interactive Website Systems Without Bootstrap or jQuery.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:bd337b799f5494c5acbe29542d8b2f88013a1dd322532b249a5daa714deb2159",
    "last_fetched":  "2026-05-03T02:48:13.1276041Z",
    "last_changed":  "2026-05-02T22:34:38.8925068Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-360",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-05-03T02:48:13.1276041Z"
}