Desktop Emulation Architecture and Engineering Roadmap

Full report

On this page

1. Executive Summary

The transition of a traditional browser-based historical archive into a deeply interactive, late-1990s desktop-computer emulation represents a critical paradigm shift in digital preservation and consumption. This master planning document details the architectural pathway, technical constraints, and phased engineering roadmap required to realize this environment using exclusively vanilla JavaScript, PHP, HyperText Markup Language (HTML), and Cascading Style Sheets (CSS). Adhering to a strict zero-dependency mandate—eschewing third-party frameworks, external application programming interfaces (APIs), content delivery networks (CDNs), and external runtime dependencies—the architecture relies heavily on advanced browser-native capabilities. By leveraging IndexedDB for virtual filesystems, the Web Audio API for procedural sound synthesis, and Service Workers for offline persistence, the system will achieve native-like performance and deep historical immersion1. The resulting product will transform a flat research portal into a spatial, temporal environment where users can genuinely explore historical data for prolonged 30 to 60-minute sessions. By managing Document Object Model (DOM) mutations surgically, employing strict Content Security Policy (CSP) guidelines, and overriding traditional web accessibility paradigms in favor of desktop-class interactions, the system delivers an authentic retrospective computing experience4. This report reconciles multiple technical disciplines into a cohesive blueprint for subsequent development phases, ensuring that the historical content is inseparable from the historical interface.

2. Product Vision

The vision for this platform is to anchor historical research within the temporal context of its original digital consumption. Rather than presenting late-twentieth-century digital artifacts within a sterile, modern web layout, the platform encapsulates the data within a highly tactile, period-accurate desktop operating system simulation. Users will navigate a simulated Windows-era desktop environment to access the Research Explorer, Cognitive Atlas, and Book Archive, fundamentally altering their cognitive relationship with the material. The objective is to sustain long-form research sessions characterized by deep, uninterrupted exploration. To achieve this, the environment must react instantaneously to user inputs, maintaining the unbreakable illusion of a native operating system executing locally on era-appropriate hardware. The platform relies heavily on the user's spatial memory. By empowering users to organize their own overlapping windows, place shortcuts strategically on the desktop, and utilize a persistent taskbar to manage complex, multi-threaded research workflows, the system offloads cognitive burden to the spatial environment. Nostalgia within this architecture is utilized not merely as an aesthetic veneer, but as a highly functional cognitive framework. The interface serves as a time machine, establishing a symbiotic relationship between the archival materials and the graphical user interface. When researchers manipulate data through period-accurate constraints—such as aliased typography, strict hierarchical file systems, and discrete application boundaries—they develop profound historical empathy, experiencing the digital past exactly as it was originally encountered.

3. Principles for Deciding OS Behavior Implementation

To prevent feature creep and maintain strict adherence to the zero-dependency architecture, the decision to implement any emulated operating system behavior must be evaluated against four primary architectural principles. These principles serve as the filtering mechanism for all engineering proposals. The first principle requires strict research utility validation. The proposed feature must demonstrably aid in the organization, discovery, or consumption of archival material. For instance, implementing a "Recent Documents" menu directly accelerates research retrieval and supports session continuity. Conversely, simulating a disk defragmenter or a purely decorative screensaver offers only empty novelty, consumes valuable processing cycles, and must be rejected. The emulation serves the archive, not the other way around. The second principle mandates performance viability under the constraints of direct DOM manipulation. Because the system relies entirely on vanilla JavaScript without the safety net of virtual DOM diffing engines, any behavior requiring continuous, high-frequency DOM repaints must be heavily scrutinized7. Features like complex drag-and-drop window snapping or animated window resizing are acceptable only if executed via optimized requestAnimationFrame loops and hardware-accelerated CSS transforms. The browser must never drop below a sixty frames-per-second rendering threshold during interaction4. The third principle dictates unwavering period authenticity. The interaction paradigms must align perfectly with the computing standards of the mid-to-late 1990s. This heavily restricts modern browser behaviors. Features such as smooth kinetic scrolling, elastic overscroll, swipe gestures, and soft drop-shadows break the immersion instantly. The visual language must rely on specific CSS implementations to recreate four-pixel hard bevels rather than modern rounded corners, and interactions must feel discrete and mechanical10. The fourth principle is strict zero-dependency compliance. If a feature intrinsically requires an external library, it cannot be built. For example, parsing complex external legacy file formats that would normally require a massive WebAssembly port or an external SaaS processing API violates the core engineering mandate. Such features must be simplified, simulated via native web APIs, or discarded entirely to preserve the system's longevity, security, and offline capabilities.

4. Feature Inventory

The current system architecture already establishes a highly functional baseline. It features a Windows-era desktop, Start menu, taskbar, movable and resizable windows, an Internet Explorer-style archive viewer, the Research Explorer, a read-only research console, the Cognitive Atlas, the Ethics Workbench, the Book Archive, System Properties, canonical-versus-derived provenance rules, clean PHP routing, local persistence, and deep-link support. To evolve this baseline into a mature, immersive operating system emulation, the feature inventory has been categorized into distinct logical domains. The following table details the comprehensive inventory of features slated for evaluation and implementation.

5. Impact-Versus-Cost Analysis

To prioritize engineering resources, every proposed feature must be evaluated based on its strategic impact on user immersion and research utility relative to the architectural cost of implementing it within a zero-dependency vanilla JavaScript framework. The analysis below quantifies these trade-offs to guide the phased roadmap.

The analysis clearly indicates that structural features like the Virtual Filesystem and the Window Manager offer the highest return on investment, forming the prerequisite base for high-impact user features like Saved Sessions and Source-Safe Annotations. Sensory elements like Procedural OS Audio offer high immersion value for a moderate cost, provided the mathematics of sound synthesis are properly managed.

6. Technical-Risk Analysis

Operating strictly within the boundaries of browser-native APIs and vanilla JavaScript introduces several substantial architectural risks. Without the guardrails provided by modern frameworks, the engineering team must manually implement design patterns to mitigate memory leaks, layout thrashing, and asynchronous race conditions. The most critical risk involves DOM mutation bottlenecks. Without the benefit of a virtual DOM to intelligently batch updates, direct DOM manipulation can rapidly trigger excessive layout recalculations, commonly known as layout thrashing9. When a user drags a window across the simulated desktop, updating the top and left CSS properties forces the browser to recalculate the geometry of the entire page layout for every pixel moved. The mitigation strategy requires the window manager to temporarily promote the active window to its own composite layer using the CSS will-change: transform property. By manipulating transform: translate(x, y) instead of layout properties, the movement is offloaded to the Graphics Processing Unit (GPU), maintaining a strict sixty frames-per-second rendering cycle9. Furthermore, for bulk DOM insertions, the system must utilize DocumentFragment to batch additions in memory before a single insertion into the live DOM4. Memory management presents a secondary, equally severe risk. The simulated desktop will feature hundreds of interactive elements, including desktop icons, file list items, and context menus. Attaching individual event listeners to every element will inevitably bloat memory consumption and degrade performance over time7. The architecture will mitigate this via global event delegation. A single event listener placed on the root desktop container will capture bubbling events, determining the target via event.target.closest(). Additionally, to prevent memory leaks when simulated windows are closed, the architecture will leverage modern ECMAScript WeakRef patterns, ensuring that detached DOM nodes are properly identified and collected by the browser's garbage collector8. Asynchronous filesystem locking poses a risk to data integrity. IndexedDB handles transactions asynchronously to prevent blocking the main thread2. However, in a multi-window emulation where several simulated applications attempt to read or write to the virtual filesystem concurrently, race conditions can easily corrupt data11. The mitigation strategy mandates the creation of a centralized state manager—a vanilla JavaScript Publish/Subscribe (PubSub) message bus—that queues all IndexedDB transactions. This ensures atomic writes and prevents partial data corruption when saving complex desktop states or large document annotations. Finally, Service Worker cache traps represent a significant deployment risk. Implementing offline-first capabilities carries the danger of users becoming trapped on an aggressive local cache, permanently preventing them from receiving critical updates to the core PHP and JavaScript logic17. The Service Worker must employ a meticulously designed cache-busting strategy. During the activate event, the Service Worker must aggressively iterate through caches.keys() and delete outdated cache versions18. The application shell must update silently in the background and utilize clients.claim() alongside UI prompts urging the user to refresh the simulated OS session when a new version is verified1.

7. Immersion-Value Analysis

Immersion in a simulated desktop environment is fragile; it is easily broken by modern browser behaviors leaking through the interface. The engineering roadmap prioritizes features that establish and protect a cohesive psychological space. Visual authenticity and auditory fidelity are the two primary pillars of this immersion. Visual authenticity requires strict adherence to historical rendering constraints. Standard CSS declarations like border-style: outset fail to replicate the exact sub-pixel rendering of 1990s graphical interfaces, appearing flat and unconvincing10. True immersion requires bespoke box-shadow configurations. The architecture will compose bevels by layering multiple light and dark pixel offsets—specifically defining inset box-shadows assigned to CSS variables (e.g., \--rd-raise and \--rd-sink)10. This technique accurately draws the four distinct one-pixel lines required to achieve the distinctive, raised appearance of era-appropriate buttons and window frames. By swapping these variables dynamically upon the :active pseudo-class, the buttons will depress with mechanical authenticity10. Furthermore, typography will be constrained to crisp, aliased, monospaced or bitmap-style fonts, avoiding the modern anti-aliasing that betrays the browser environment19. Auditory feedback solidifies the physical presence of the emulation. Relying on network-fetched audio files introduces latency that destroys the illusion of local hardware13. By utilizing the native Web Audio API, the system can procedurally synthesize sound mathematically with zero latency3. The system will rely heavily on the OscillatorNode object, assigning specific waveforms to represent distinct system actions: square waves for error chimes, sine waves for gentle notifications, and sawtooth waves for aggressive system alerts13. A known risk of procedural audio is the generation of loud, jarring clicks and crackles when an oscillator is abruptly started or stopped21. To prevent this audio clipping, the architecture will apply Envelope Generators based on the Attack-Decay-Sustain-Release (ADSR) model23. By routing the oscillator through a GainNode and utilizing the exponentialRampToValueAtTime method, the system will mathematically shape the volume over time21. The decay curve is modeled as: [Figure omitted from source export] where [Figure omitted from source export] is the volume at time [Figure omitted from source export], and [Figure omitted from source export] is the time constant governing the fade. This mathematical smoothing ensures that the simulated retro hardware sounds deliberate and engineered, rather than glitchy or broken.

8. Accessibility Impact

Emulating an operating system within a web document intrinsically overrides default browser accessibility paradigms, presenting a severe risk to users relying on assistive technologies. A traditional screen reader expects a linear, semantic document flow; presenting it with a two-dimensional grid of movable, overlapping windows creates immediate and severe disorientation. To resolve this conflict, the architecture will aggressively and accurately utilize Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) roles. The root desktop container will be designated with role="application". This specific role instructs assistive technologies to abandon standard document reading modes (such as virtual cursor navigation) and pass raw keystrokes directly to the JavaScript environment, treating the web page exactly as it would a native desktop application24. Simulated windows will be strictly governed by role="dialog" or role="alertdialog"24. When a window gains active focus in the z-index stack, the window manager will dynamically update the aria-activedescendant property, ensuring that screen readers announce the window's title and immediately constrain the user's focus within its logical boundaries27. Menus, such as the Start Menu, will utilize the menubar, menu, and menuitem roles, establishing the expected hierarchical relationships for screen readers26. Furthermore, true desktop immersion demands keyboard-first operation. Users must be able to navigate the desktop icon grid and complex nested menus entirely without a mouse. Relying on the browser's default Tab sequence is insufficient for a two-dimensional spatial grid. Therefore, the architecture will implement a robust "roving tabindex" pattern28. The system will actively manage focus by maintaining tabindex="0" exclusively on the currently focused element, while dynamically setting tabindex="-1" on all adjacent interactive elements29. A custom keyboard event listener will capture directional arrow keys, calculate the spatial relationship of the icons on the grid, and programmatically move focus to the appropriate adjacent element, updating the tabindex values accordingly28. This ensures that both visual users and screen reader users navigate the desktop using the exact same spatial logic expected of a 1990s operating system.

9. Security Impact

Security must be enforced rigorously, particularly because the system processes dynamic historical archival data—which may contain un-sanitized historic HTML—and relies heavily on local persistence mechanisms. While the strict zero-dependency mandate naturally reduces supply-chain attack vectors (by eliminating vulnerable third-party NPM packages), rendering historical web data inside the simulated Internet Explorer poses significant Cross-Site Scripting (XSS) risks. To protect the host environment, a stringent Content Security Policy (CSP) will be implemented via HTTP response headers6. The foundational policy will define default-src 'none', explicitly blocking all external resource loading unless specifically authorized. Crucially, the policy will strictly prohibit unsafe-eval and limit unsafe-inline scripts, aggressively mitigating the risk of malicious execution if archival data contains embedded, historic JavaScript30. To safely render untrusted historic HTML within the Research Explorer without breaking the application, the system will utilize an advanced double-iframe sandbox strategy32. The outer iframe acts as a secure coordinator, communicating with the core OS environment via postMessage. The inner rendering iframe—where the historical content is actually injected—is locked down extensively using the HTML5 sandbox attribute. It will permit allow-scripts to run basic historical interactive elements, but it will specifically omit the allow-same-origin token31. By omitting allow-same-origin, the browser is forced to treat the inner iframe as an opaque, unique origin. Consequently, the Same-Origin Policy explicitly denies any JavaScript executing within the historical archive access to the parent application's IndexedDB stores, local storage, or global DOM scope31. This cryptographic-level isolation guarantees that researchers can explore potentially compromised historical data without any risk of data exfiltration or host system corruption.

10. Performance Impact

Achieving a consistent sixty frames-per-second rendering rate during complex, multi-window manipulations is essential for sustaining the target 30-to-60-minute session length. Any perceived lag shatters the illusion of native software. The performance architecture is dictated entirely by disciplined DOM management. The core window manager will explicitly avoid the use of innerHTML string parsing for dynamic content creation. Browser engines must halt the main thread to parse and compile string-based HTML. Instead, the architecture relies exclusively on programmatic DOM construction using document.createElement(), append(), and replaceChildren()4. This allows the JavaScript engine to interact directly with the DOM tree structure, eliminating parse-time blocking. When users interact with the window manager to minimize windows, bring them to the foreground, or switch application views, the system will employ a strict "hide over destroy" pattern. Modifying the DOM by setting display: none or toggling a hidden attribute on an inactive application window is exponentially faster than removing the node entirely and forcing the browser to rebuild it upon restoration5. Furthermore, the integration with IndexedDB for the Virtual Filesystem guarantees that read/write operations never block the user interface. Because the IndexedDB API is entirely asynchronous and Promise-based, massive historical datasets can be queried, filtered, and saved in the background while the user continues to interact fluidly with the desktop environment2. Memory profiling utilizing Chrome DevTools heap snapshots will be continuously integrated into the development cycle to verify that the combination of WeakRef patterns and event delegation prevents any linear memory growth over extended research sessions5.

11. Recommended Architecture Dependencies Between Features

A highly modular architecture is required to sequence feature development effectively. Features cannot be constructed in isolation; they must adhere to a strict dependency graph to prevent costly refactoring loops and ensure that lower-level systems are stable before higher-level features rely upon them. The recommended dependency hierarchy is as follows:

12. Phased Roadmap

The engineering implementation is structured strictly across six sequential phases. Each phase builds upon the structural and architectural integrity established by its predecessor, ensuring continuous delivery of testable, robust increments.

Phase 1: Shell Foundation

This phase establishes the non-negotiable user interface architecture, ensuring that the browser can handle robust, multi-window desktop interactions without suffering from DOM degradation or event pollution.

Phase 2: Filesystem

This phase constructs the underlying database architecture required to transform the web page from a stateless viewer into a stateful machine capable of retaining complex user data over time.

Phase 3: Application Interoperability

This phase elevates the environment from a collection of isolated widgets into a cohesive operating system where applications communicate and share data seamlessly.

Phase 4: Research Tooling

With the OS infrastructure secured, this phase focuses exclusively on enhancing the primary utility of the archive, deploying advanced, cross-linked research modules that benefit directly from the desktop environment.

Phase 5: Sensory Polish

This phase applies the final layers of psychological immersion, ensuring the environment sounds and feels indistinguishable from historical hardware.

Phase 6: Advanced Desktop Behaviors

The final phase locks the platform as a standalone, resilient entity. It transitions the product from a web application into a progressive, offline-capable research environment.

13. Proposed Release Sequence

The feature roadmap translates into six distinct user-facing releases. Each release is structured to incrementally deliver high-impact value to the research community while masking the underlying architectural complexity.

1. Release 1: "The Workspace" (Mapping to Phase 1). This release delivers the robust window manager and the complete visual UI overhaul. It provides immediate, tangible quality-of-life improvements for researchers who struggle with managing multiple simultaneous documents in standard browser tabs.

2. Release 2: "The Archive Drive" (Mapping to Phase 2). Introduces local persistence. Users can now "save" their customized layout and frequently accessed documents to a local virtual drive. The system survives browser restarts, establishing the concept of digital ownership over the research space.

3. Release 3: "The Ecosystem" (Mapping to Phase 3). Transforms the flat tools into a cohesive OS. Double-clicking files triggers appropriate viewers. This release fundamentally changes how users navigate the data, shifting from web-link clicking to application routing.

4. Release 4: "The Analyst" (Mapping to Phase 4). Deploys the heavy research tools. The introduction of the global Find dialog and cross-linking capabilities directly accelerates archival synthesis, proving the research utility of the desktop metaphor.

5. Release 5: "The Immersion" (Mapping to Phase 5). Adds the sensory layer. Procedural audio cues, authentic boot sequences, and user themes launch simultaneously, cementing the psychological environment and deepening historical empathy.

6. Release 6: "The Standalone" (Mapping to Phase 6). The platform becomes fully offline-capable. Users experience a true application lifecycle, capable of conducting deep research on trains, in archival basements, or in areas with intermittent connectivity, completely independent of the server.

14. "Do Not Build" List

To ensure project feasibility, prevent scope creep, and maintain strict architectural purity, the following features are explicitly forbidden from the engineering roadmap. Any proposal advocating for these features must be rejected. First, full hardware emulation (e.g., integrating v86 or DOSBox ports) is prohibited. Running actual legacy operating system binaries via WebAssembly violates the vanilla JavaScript requirement, adds massive payload sizes, and obfuscates the core archival content behind a black-box emulator. The goal is to emulate the interface to serve the archive, not to build a virtual machine. Second, remote, real-time multiplayer cursors or shared desktops are rejected. Maintaining server-side socket synchronization is computationally expensive and directly detracts from the solitary, deep-focus nature of historical archival research. The environment is designed for individual synthesis. Third, complex 3D WebGL Screensavers (e.g., the classic 3D Pipes) are excluded. While nostalgically accurate, the engineering overhead, required physics mathematics, and the high potential for battery drain and performance degradation far outweigh the momentary visual novelty. Fourth, rich-text word processors will not be built. Rebuilding a fully featured word processor comparable to Microsoft Word 97 is an excessively complex undertaking that would consume the entire development budget. Text inputs must be restricted to simple .txt format handling via standard, semantic \<textarea\> elements. Finally, third-party analytics integrations (e.g., Google Analytics, Hotjar) are strictly forbidden. The inclusion of external tracking scripts violates the zero-dependency mandate, introduces uncontrollable external variables into the CSP, and violates the privacy expectations inherent in a secure, locally-persisted research environment.

15. 100-Point Desktop-Emulation Quality Rubric

To objectively evaluate the success and stability of the emulation prior to any release, the system will be graded against a 100-point rubric. The rubric is divided evenly across five critical disciplines. A minimum score of 90 is required for production deployment.

16. Usability Testing Plan

Usability testing for a simulated operating system requires distinct methodologies compared to standard web design. Research clearly indicates that standard web users initially experience cognitive friction when navigating web archives, as they attempt to apply modern web interaction paradigms to historical contexts37. Testing will rely on qualitative, task-based observation utilizing the think-aloud protocol. Participants will be provided a specific, multi-step scenario (e.g., "Locate the 1998 archive of the Cognitive Atlas, extract a specific paragraph, annotate it in the text editor, and save it to a new folder on your desktop"). Observers will record the exact "time-to-completion" and meticulously note any instances where users default to standard browser behaviors—such as attempting to use the browser's native back button or URL bar—instead of relying on the emulated OS controls. Testing must be conducted across varying devices (laptops, touch-enabled tablets) to uncover unforeseen interaction issues, such as touch-target size failures on simulated 1990s menus36. A minimum effectiveness rate of 90% task completion without facilitator intervention, alongside an 80% user satisfaction score on post-test questionnaires, is the mandatory target benchmark before general release36.

17. Period-Authenticity Testing Plan

Authenticity testing ensures the visual and auditory emulation does not accidentally slip into modern anachronism, which destroys the psychological environment. Visual analysis will be rigorous. The rendered interface will be subjected to side-by-side pixel comparisons against canonical, verified screenshots of late-1990s operating systems. Quality assurance teams will verify that border highlights, shadow drops, and title bar gradients match historical constraints exactly, ensuring that no accidental modern smooth-radii or transparent anti-aliasing bleeds through the CSS constraints. Auditory analysis will be conducted systematically. The output of the Web Audio API oscillators will be captured and passed through a digital spectrum analyzer. The analysis must verify the mathematical shape of the waveforms (e.g., confirming a true square wave is generated without unintended harmonic distortion) and ensure frequencies align precisely with the capabilities of historical sound cards.

18. Performance-Testing Plan

Given the severe constraints of vanilla JavaScript and manual DOM updates, performance profiling must be a continuous, automated process rather than an afterthought. Engineers will utilize Chrome DevTools to monitor DOM reflows continuously. Specifically, tracking the "Layout" and "Recalculate Style" metrics during induced stress events—such as rapidly dragging a complex window across several other open windows. The objective is to absolutely eliminate forced synchronous layouts (layout thrashing)9. Memory profiling will utilize controlled heap snapshots. A snapshot will be taken at the beginning of a simulated 30-minute high-intensity research session, and another at the conclusion. The differential analysis must explicitly verify that detached DOM nodes representing closed windows are successfully garbage-collected by the browser, confirming that WeakRef patterns and event listener teardowns are functioning correctly, preventing progressive UI lockups5.

19. Security-Testing Plan

Security testing will focus aggressively on the boundaries between the host shell and the historical archival content, ensuring the zero-dependency architecture remains impenetrable. Automated Content Security Policy validation tests will run during every build. These tests will attempt to execute inline scripts and monitor network requests, verifying that the CSP headers strictly block all external payloads and throw fatal errors upon encountering eval() statements30. Sandbox penetration testing is mandatory. Security personnel will actively inject known XSS payloads into the archive's historical HTML documents to attempt to break out of the double-iframe sandbox. Success is defined entirely by the inability of the payload to access the window.parent object, interface with the IndexedDB instances, or read local storage32. If the historical iframe is capable of executing code outside its opaque origin, the build must be failed immediately.

20. Final Recommended Top-Ten Feature Priority

To maximize immediate strategic value and establish the necessary architectural foundations without requiring future refactoring, engineering development must proceed strictly according to the following prioritized list.

Works cited

1. Using Service Workers \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/Service\_Worker\_API/Using\_Service\_Workers

2. Introduction to IndexedDB: A Powerful Browser Storage Solution, https://javascript.plainenglish.io/introduction-to-indexeddb-a-powerful-browser-storage-solution-b908293b31df

3. Introduction to the Web Audio API \- Fireship, https://fireship.dev/web-audio-api

4. Building Modern Web Apps with Vanilla JavaScript \- DEV Community, https://dev.to/abanoubkerols/you-might-not-need-a-framework-building-modern-web-apps-with-vanilla-javascript-37dd

5. Patterns for Memory Efficient DOM Manipulation with Modern Vanilla, https://blog.master.dev/patterns-for-memory-efficient-dom-manipulation/

6. Content-Security-Policy (CSP) header \- HTTP \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy

7. Vanilla JavaScript Patterns for Modern Browsers \- Library, https://www.grizzlypeaksoftware.com/library/vanilla-javascript-patterns-for-modern-browsers-9jkhhape

8. I built a vanilla JS framework focused on DX, performance and zero, https://www.reddit.com/r/javascript/comments/1u19ztm/i\_built\_a\_vanilla\_js\_framework\_focused\_on\_dx/

9. Performance Optimization in DOM Manipulation | by Carlos A. Rojas, https://blog.carlosrojas.dev/performance-optimization-in-dom-manipulation-6669ae153847

10. A retro desktop shell theme in the windows 95 aesthetic: beveled, https://github.com/rampstackco/retro-desktop-theme

11. IndexedDB \- The Modern JavaScript Tutorial, https://javascript.info/indexeddb

12. IndexedDB in Practice: Large-File Storage and… | Tools Ku, https://www.toolsku.com/en/blog/indexeddb-browser-storage/

13. Optimizing Web Audio API Oscillators for Retro Arcade Sound, https://gamecentral.blog/optimizing-web-audio-api-oscillators-retro-sound-synthesis/

14. Making your web app work offline, with Service Workers and, https://medium.com/@adamrackis/making-your-web-app-work-offline-with-service-workers-and-indexeddb-6ce9c538c48

15. Vanilla Javascript & Dom Performance \- Stack Overflow, https://stackoverflow.com/questions/32768966/vanilla-javascript-dom-performance

16. Optimizing Performance with Event Delegation in Vanilla JS, https://utinfrancis.hashnode.dev/beginners-guide-optimizing-performance-with-event-delegation-in-vanilla-js

17. Service Workers With Vanilla JavaScript | by Sumit Mukhija \- Medium, https://medium.com/better-programming/service-workers-with-vanilla-javascript-49b63224a4fb

18. Service Workers: Build Offline-First Web Apps That Actually Work, https://javascriptbit.com/javascript-service-workers-offline-first/

19. Retro and brutalist UI design: a 2026 field guide | Setproduct Blog, https://www.setproduct.com/blog/retro-brutalist-ui-design-2026

20. Synthesising Sounds with Web Audio API \-, https://sonoport.github.io/synthesising-sounds-webaudio.html

21. Web audio api "clicks" "crackles" "pops" & distortion noise, https://stackoverflow.com/questions/71460284/web-audio-api-clicks-crackles-pops-distortion-noise-elimination-can-i-d

22. Weird crackling during audio playback \- web audio api, https://dsp.stackexchange.com/questions/80993/weird-crackling-during-audio-playback-web-audio-api

23. Web Audio API: Building a Moog-style Modular Synthesizer in, https://a80.it/blog/web-audio-api-building-a-moog-style-modular-synthesizer-in-javascript

24. WAI-ARIA Roles \- Accessibility, https://udn.realityripple.com/docs/Web/Accessibility/ARIA/Roles

25. ARIA Roles Explained: A Practical Guide for Web Developers, https://www.levelaccess.com/blog/aria-roles-explained-a-practical-guide-for-web-developers/

26. WAI-ARIA: Role=Menubar \- DigitalA11Y, https://www.digitala11y.com/menubar-role/

27. ARIA: menu role \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/menu\_role

28. Roving tabindex, https://jakelazaroff.github.io/roving-tabindex/

29. A Guide To Keyboard Accessibility: JavaScript (Part 2), https://www.smashingmagazine.com/2022/11/guide-keyboard-accessibility-javascript-part2/

30. "Content Security Policy of your site blocks the use of 'eval' in, https://stackoverflow.com/questions/65445255/content-security-policy-of-your-site-blocks-the-use-of-eval-in-javascript-wa

31. HTML CSS JS Playground: Instant Live Preview, No Login \- ToolSura, https://www.toolsura.com/tools/html-css-playground-live-preview/

32. PaulKinlan/generate-html-element \- GitHub, https://github.com/PaulKinlan/generate-html-element/

33. mcp-mcp-apps-kit | Skills Marketplace \- LobeHub, https://lobehub.com/skills/andurilcode-mcp-apps-kit-mcp-apps-builder

34. Building an offline web app using Service Workers \- thedeployguy, https://thedeployguy.com/2020-01-12-building-an-offline-web-app-using-service-workers/

35. Using IndexedDB \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB\_API/Using\_IndexedDB

36. Is my web archive usable? \- IIPC Blog, https://netpreserveblog.wordpress.com/2016/10/18/is-my-web-archive-usable/

37. Tweaking search user interfaces to web archives Technical Report, https://sobre.arquivo.pt/wp-content/uploads/tweaking-search-user-interfaces-to-web-archives.pdf

38. Web Audio API \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/Web\_Audio\_API

39. WAI-ARIA Roles \- ARIA \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles

40. AAO and City of Vancouver Usability testing \- AtoM wiki, https://wiki.accesstomemory.org/wiki/Development/Projects/AAO\_CVA\_Usability\_testing