Crafting a Nostalgic, Customizable 90s-Themed Portfolio Website Without AI Tools

Introduction: The Retro Web Revival

In an era where sleek, minimalist designs and AI-driven interfaces dominate the digital landscape, there’s a growing yearning for the raw, unfiltered charm of the past. This is the story of crafting a Windows 98-themed portfolio website—a project born from personal nostalgia and a defiance against the homogenization of modern web design. It’s not just a website; it’s a time machine, a functional artifact that resurrects the spirit of 90s computing and early 2000s internet culture. This journey is about proving that authenticity and creativity can thrive without leaning on AI tools or trendy frameworks.

The Appeal of Retro: Why Windows 98?

Windows 98 was more than an operating system—it was a cultural phenomenon. Its clunky interface, pixelated icons, and the iconic Start menu were the gateway to a world of experimentation. For those who grew up in this era, it’s not just about aesthetics; it’s about recapturing the freedom to tinker. The decision to replicate this interface wasn’t arbitrary. Its modular design allowed for the integration of an applet system, a feature that mirrors the OS’s extensibility. This wasn’t just nostalgia—it was a practical choice to create a customizable platform.

The Applet System: A Mechanical Breakdown

At the heart of this project is the applet system, a mechanism that allows users to install and customize mini-applications locally. Here’s how it works:

• Local Storage Integration: Each applet is stored in the browser’s localStorage, a non-volatile memory that persists even after the browser is closed. This mimics the permanence of installing software on a 90s PC.
• Vanilla JavaScript Execution: Without relying on frameworks, the applets are pure JavaScript. This ensures compatibility across browsers and avoids the bloat of modern libraries. The trade-off? Increased complexity in managing state and DOM manipulation, but it preserves the DIY ethos of the era.
• Dynamic Loading: Applets are loaded asynchronously, reducing initial load times. This is achieved by lazy loading scripts only when the user interacts with the interface, a technique that mirrors the resource constraints of 90s hardware.

Nostalgia as a Design Principle

The applets themselves are more than just features—they’re cultural artifacts. Take the inclusion of DOOM, for example. Running DOOM in a browser isn’t new, but integrating it into a Windows 98 interface requires WebGL rendering and precise emulation of the game’s original mechanics. The Half-Life Soundboard leverages HTML5 Audio API, while the 3D Maze recreates the classic screensaver using Canvas and trigonometric calculations to simulate depth. Each element is a mechanical recreation of the past, not a superficial overlay.

The Anti-AI Stance: A Practical Choice

The decision to avoid AI/LLM tools wasn’t just ideological—it was technical. AI-generated code often lacks the contextual understanding required for authentic retro design. For instance, an AI might replicate a Windows 98 interface but fail to capture the imperfections that made it endearing—the jagged edges of icons, the inconsistent spacing, or the 8-bit color palette. By coding everything manually, the creator ensured that every pixel, every animation, and every interaction was a faithful reproduction of the era’s limitations and quirks.

Edge Cases and Trade-Offs

This approach isn’t without its risks. Vanilla JavaScript lacks the error-handling robustness of frameworks, making debugging more labor-intensive. The localStorage system, while effective, has size limits (typically 5MB per domain), which could constrain future applet additions. Mobile compatibility, though partially achieved, suffers from touch input lag due to the desktop-first design. These are the costs of authenticity—trade-offs that prioritize fidelity over convenience.

Why This Matters

In a world where AI threatens to standardize creativity, projects like this serve as a counterpoint. They remind us that technology’s roots are in human ingenuity, not algorithmic efficiency. By preserving the essence of 90s computing, we don’t just honor the past—we inspire the future. This isn’t just a portfolio; it’s a manifesto, a proof of concept that the handcrafted spirit of early computing can still thrive in a modern context.

Designing the Nostalgic Experience: Crafting a Windows 98 Interface

Recreating the Windows 98 interface for a portfolio website isn’t just about slapping on a gray gradient and some jagged icons. It’s about reverse-engineering the visual language of an era—a time when 8-bit color palettes, pixelated textures, and inconsistent spacing were the norm, not the exception. The goal? To trigger that “oh, I remember this” moment in anyone who grew up with 90s computing. Here’s how it was done, step by step, without AI tools muddying the waters.

1. Color Schemes: The 8-Bit Palette Constraint

Windows 98 operated within the limits of an 8-bit color palette, a constraint that physically stemmed from the hardware of the time. CRT monitors and graphics cards couldn’t handle more than 256 colors simultaneously without significant performance degradation. To replicate this, the website’s CSS was locked to a 256-color palette, manually mapped to hex codes from the original Windows 98 system files. This deliberate limitation forces modern browsers to render colors in a way that mimics the dithering and banding effects of 90s displays. The result? A visual texture that feels authentically retro, not just “vintage-washed.”

2. Typography: System Fonts and Their Mechanical Failures

The default font of Windows 98, MS Sans Serif, was chosen not for its beauty but for its low memory footprint. Rasterized at specific sizes, it often appeared jagged or uneven, a side effect of the font’s bitmapped nature. To replicate this, the website uses a custom font file extracted from a Windows 98 virtual machine, embedded via @font-face. However, modern browsers’ anti-aliasing algorithms smooth out these imperfections by default. The solution? Disabling subpixel rendering in CSS (-webkit-font-smoothing: none;) to preserve the font’s original, mechanically flawed appearance.

3. Iconography: The Physics of Pixel Art

Windows 98 icons were 16x16 pixel bitmaps, designed to be legible at low resolutions. Each icon was a physical compromise between detail and clarity, limited by the screen’s pixel density. For the website, icons were recreated using a pixel-by-pixel approach, avoiding vector scaling to maintain their original sharpness. The jagged edges—a result of manual pixel placement—were preserved, as they are a hallmark of the era’s design constraints. Modern tools like Photoshop’s “pixel grid” were used only for reference, not for automated scaling, to avoid introducing unintended smoothing.

4. Window Borders and Controls: The Mechanics of Imperfection

The Windows 98 window borders were not mathematically precise. Their uneven spacing and slightly misaligned controls were a byproduct of the OS’s graphical rendering pipeline, which prioritized speed over perfection. To replicate this, the website’s CSS uses hardcoded pixel values for borders and padding, intentionally avoiding responsive design principles. For example, the title bar’s height is set to 19px, not 20px, to mimic the original’s slight asymmetry. This deliberate imperfection is what distinguishes an authentic recreation from a sanitized modern interpretation.

5. Trade-Offs: Why Vanilla JavaScript Was the Only Choice

Using a modern JavaScript framework would have introduced unnecessary abstraction layers, bloating the codebase and risking performance issues on older devices—a common edge case for retro enthusiasts. Vanilla JavaScript was chosen for its direct control over DOM manipulation, allowing precise replication of Windows 98’s quirks, like the laggy window resizing or the clunky drag-and-drop behavior. However, this decision comes with risks: limited error handling and labor-intensive debugging. The rule here is clear: If authenticity is the goal, use tools that mirror the era’s constraints.

6. Applet System: Local Storage as a Mechanical Limitation

The applet system relies on localStorage, a browser API with a 5MB per domain limit. This constraint mirrors the physical limitations of 90s storage media, like floppy disks. While this limits the number of applets that can be installed, it forces a curated, intentional design—a feature, not a bug. The trade-off? Future scalability is capped, but the website remains lightweight and true to the era’s resource-constrained ethos.

Key Takeaway: Authenticity Requires Constraints

The success of this project hinges on one principle: Embrace the limitations of the era you’re recreating. From the 8-bit color palette to the 5MB storage cap, every technical decision was a deliberate nod to the mechanical and physical constraints of 90s computing. AI tools, with their tendency to smooth over imperfections, would have stripped away the very essence of this project. Instead, the handcrafted approach ensures that every pixel, every jagged edge, and every laggy animation feels right—because it’s mechanically, historically right.

Building the Applet System: A Technical Deep Dive

Creating a functional applet system for a Windows 98-themed portfolio website without modern AI tools required a meticulous blend of legacy technologies and handcrafted coding. The goal was clear: authenticity over convenience, prioritizing the raw, unfiltered experience of 90s computing. Here’s how it was achieved, step by step, with a focus on the mechanics and trade-offs involved.

1. Core Mechanism: Local Storage as the Backbone

The applet system relies on the browser’s localStorage API for persistence. This choice was deliberate, mirroring the storage constraints of the 90s (e.g., floppy disks). The 5MB per domain limit acts as a natural constraint, forcing a lightweight, era-authentic design. Mechanistically, exceeding this limit would cause data to be silently dropped, breaking applet functionality. This constraint also prevents bloat, ensuring the system remains nimble and true to the era’s limitations.

2. Vanilla JavaScript: The Double-Edged Sword

Avoiding modern frameworks like React or Vue, the system uses vanilla JavaScript for direct DOM manipulation. This choice replicates the quirks of 90s software, such as laggy window resizing. However, it introduces complexity in state management and error handling. For example, without a framework’s lifecycle management, memory leaks become a risk, as orphaned event listeners accumulate over time. The solution? Rigorous manual cleanup and a disciplined coding style—a trade-off for authenticity.

Trade-Off Analysis: Vanilla JS vs. Frameworks

• Vanilla JS: Higher risk of memory leaks and harder debugging but ensures cross-browser compatibility and avoids abstraction layers.
• Frameworks: Easier state management and error handling but introduce bloat and modern abstractions that break the retro aesthetic.
• Optimal Choice: Vanilla JS, given the project’s emphasis on authenticity. Rule: If authenticity is the priority and performance on older devices is critical, use vanilla JS.

3. Dynamic Loading: Balancing Speed and Functionality

To reduce initial load times, scripts are lazy-loaded on user interaction. This mimics the 90s experience of waiting for programs to load from a CD-ROM. Mechanistically, this works by deferring script execution until an event (e.g., clicking an applet icon) triggers it. The risk here is increased latency on the first interaction, as the browser fetches and parses the script. However, this trade-off is acceptable given the desktop-first design, where users expect a more deliberate, slower interaction model.

4. WebGL and Canvas: Recreating Classics

Integrating games like DOOM and the 3D Maze required leveraging WebGL and Canvas. WebGL’s ability to render 3D graphics in the browser made it the optimal choice for DOOM, emulating the original game mechanics. Mechanistically, WebGL shaders process vertex and fragment data to recreate the game’s rasterized graphics. For the 3D Maze, Canvas and trigonometry were used to simulate depth, with perspective projection calculated manually to avoid modern 3D libraries.

Edge-Case Analysis: Mobile Compatibility

While the site is desktop-first, partial mobile support was implemented. However, touch input lag is noticeable due to the lack of touch-optimized event handling. Mechanistically, touch events are throttled by the browser to prevent accidental double-taps, causing a delay. A framework like React could mitigate this with debouncing, but that would violate the vanilla JS constraint. Rule: If mobile compatibility is critical, prioritize touch event optimization over strict vanilla JS adherence.

5. Design Authenticity: Embracing Imperfection

The Windows 98 interface was recreated by manually coding imperfections: jagged icons, uneven spacing, and an 8-bit color palette. For example, the MS Sans Serif font was rasterized at specific sizes, and subpixel rendering was disabled to preserve its bitmapped look. Mechanistically, disabling -webkit-font-smoothing prevents the browser from anti-aliasing the font, maintaining its jagged edges. This attention to detail ensures the visual fidelity of the era.

Key Takeaways

• Authenticity Over Convenience: Every technical choice prioritized fidelity to 90s computing, even at the cost of increased complexity.
• Human Ingenuity: The project underscores the handcrafted spirit of early computing, a stark contrast to AI-driven standardization.
• Trade-Off Rule: If X (authenticity) is the priority, use Y (vanilla JS, manual coding, era-specific constraints) even if it introduces Z (debugging complexity, performance trade-offs).

In an age dominated by AI and standardized frameworks, this project serves as a reminder of the creativity and ingenuity that defined early computing. By embracing the constraints and quirks of the 90s, it not only preserves a piece of technological history but also inspires a deeper appreciation for the roots of digital creativity.

Curating Nostalgic Discoveries: Easter Eggs and Hidden Gems

Strategically embedding nostalgic elements into a retro-themed portfolio isn’t just about decoration—it’s about recreating the exploratory joy of 90s computing. Each hidden gem serves as a mechanical trigger for memory, leveraging the brain’s associative recall. Here’s how the process works, grounded in technical and psychological mechanisms:

1. Sound Effects as Cognitive Anchors

Vintage sound effects (e.g., Windows 95 error chimes, dial-up tones) act as auditory anchors. When a visitor clicks an icon, the HTML5 Audio API loads a 8-bit WAV file, decoded by the browser’s audio processor. This triggers the reticular activating system (RAS) in the brain, instantly retrieving associated memories. The latency (typically 50-100ms) mimics 90s hardware delays, reinforcing authenticity.

2. Desktop Icons as Visual Hooks

Classic 16x16 pixel icons are manually rasterized to preserve jagged edges, a byproduct of 90s CRT monitor resolution. Each icon is a PNG sprite mapped via CSS grid, avoiding vector scaling. When hovered, the icon’s opacity drops to 50% (emulating Windows 98’s selection effect), achieved via CSS transitions with a 200ms delay—matching the original OS’s sluggish response.

3. Hidden Applets: Lazy-Loading for Discovery

Applets like DOOM or Hampster Dance are lazy-loaded on interaction, reducing initial load time by 40%. Scripts are fetched via XMLHttpRequest and parsed dynamically. This mimics the CD-ROM loading experience, where latency was a physical constraint (disc spin-up time: 200-500ms). The trade-off: first-interaction lag, but it preserves the era’s anticipatory ritual.

4. Easter Egg Mechanics: Conditional Triggers

Hidden surprises (e.g., a Half-Life soundboard activated by triple-clicking the taskbar) rely on event listeners chained in vanilla JS. The mechanism:

• Impact: User performs specific action (triple-click)
• Internal Process: Event queue triggers a debounced function (300ms delay) to prevent accidental activation
• Observable Effect: Soundboard modal appears, rendered via flexbox grid with 8-bit color overlay

This design fails on mobile due to touch event throttling, but the desktop-first constraint prioritizes authenticity over universality.

5. Storage Constraints as Creative Drivers

The 5MB localStorage limit forces applets to be modular and lightweight. Exceeding this silently drops data, breaking functionality—a modern echo of 90s floppy disk limits (1.44MB). This constraint deforms the design process, pushing the creator to optimize assets (e.g., compressing DOOM’s WebGL shaders to 2MB) and prioritize essential features.

Decision Dominance: Vanilla JS vs. Frameworks

Choosing vanilla JS over React/Vue is optimal for authenticity because:

• Direct DOM manipulation replicates 90s software quirks (e.g., laggy window resizing)
• Avoids abstraction layers, ensuring compatibility with older browsers (e.g., IE11)
• Trade-off: Higher risk of memory leaks (orphaned event listeners) requiring manual garbage collection

Rule: If authenticity is the goal, use vanilla JS. If mobile optimization is critical, consider a framework with debouncing (e.g., React) but accept visual/functional compromises.

Edge-Case Analysis: Mobile Failure Mechanism

Mobile compatibility breaks due to touch event throttling (browsers limit touch events to 16ms intervals). This causes input lag in applets like the 3D Maze, where Canvas trigonometry calculations require precise timing. Solution: Implement passive event listeners to bypass throttling, but this violates the "no modern optimizations" rule. Thus, mobile support remains partial by design.

Key Takeaway: Constraints as Creative Catalysts

The project’s authenticity stems from embracing limitations—8-bit colors, storage caps, manual pixel design. These constraints heat up creativity, forcing solutions like WebGL shaders for DOOM or trigonometric Canvas for the 3D Maze. The result: a portfolio that doesn’t just display nostalgia but mechanically recreates it, one jagged icon and dial-up tone at a time.

Balancing Functionality and Authenticity: The Retro Portfolio Dilemma

Creating a Windows 98-styled portfolio that’s both functional and authentically retro isn’t just about slapping on a 90s aesthetic. It’s a mechanical balancing act where every technical decision deforms the user experience in predictable ways. Here’s how I navigated the trade-offs, backed by causal explanations and edge-case analyses.

1. Vanilla JavaScript: The Authenticity Engine

Mechanism: Vanilla JS replicates the direct DOM manipulation and performance quirks of 90s software. For instance, laggy window resizing in the applet system mirrors the unoptimized rendering pipelines of Windows 98, achieved by avoiding abstraction layers in frameworks like React.

Trade-Off: Higher risk of memory leaks (orphaned event listeners) due to manual state management. Impact → Accumulated listeners → Memory bloat → Browser slowdown.

Rule: If prioritizing authenticity over convenience, use vanilla JS. If scalability is critical, frameworks are unavoidable, but they break the retro fidelity by smoothing out quirks.

2. localStorage: The 5MB Constraint

Mechanism: localStorage’s 5MB limit per domain mimics 90s storage constraints (e.g., floppy disks). Exceeding this silently drops data, breaking applet functionality. Impact → Data overflow → Silent failure → Applet corruption.

Trade-Off: Forces modular, lightweight applets (e.g., DOOM’s WebGL shaders compressed to 2MB). Mechanism → Compression → Reduced fidelity → Performance vs. authenticity balance.

Rule: If storage is a bottleneck, optimize applets aggressively. If scalability is non-negotiable, abandon localStorage for server-side storage, but this breaks the offline, era-authentic design.

3. Mobile Compatibility: The Touch Input Lag

Mechanism: Browsers throttle touch events (16ms intervals), causing lag in timing-dependent applets like the 3D Maze. Impact → Throttling → Input delay → Unplayable experience.

Trade-Off: Passive event listeners bypass throttling but violate the “no modern optimizations” rule. Mechanism → Passive listeners → Immediate event firing → Functional but inauthentic.

Rule: If mobile support is critical, use passive listeners. If authenticity is non-negotiable, accept partial mobile functionality and document the limitation as a feature, not a bug.

4. WebGL and Canvas: The 3D Nostalgia

Mechanism: WebGL renders DOOM by processing vertex and fragment shaders, while Canvas manually calculates perspective projection for the 3D Maze. Impact → Shader complexity → GPU load → Performance bottleneck.

Trade-Off: WebGL’s performance on older devices is unpredictable. Mechanism → Shader compilation → GPU overheating → Frame rate drops.

Rule: If targeting older hardware, limit shader complexity. If fidelity is paramount, accept performance trade-offs and document minimum system requirements.

5. Sound Effects: The Cognitive Anchors

Mechanism: HTML5 Audio API loads 8-bit WAV files, introducing 50-100ms latency to mimic 90s hardware delays. Impact → Latency → RAS activation → Memory recall.

Trade-Off: Modern browsers buffer audio, reducing perceived latency. Mechanism → Buffering → Smoothed playback → Authenticity loss.

Rule: If audio latency is critical, disable browser buffering. If compatibility is key, accept smoothed playback and prioritize cross-browser support.

Key Takeaways: When Authenticity Breaks Functionality

• Vanilla JS: Optimal for authenticity but fails under heavy state management. Mechanism → Memory leaks → Browser crash.
• localStorage: Enforces lightweight design but limits scalability. Mechanism → Data overflow → Applet failure.
• Mobile Support: Partial functionality is inevitable without modern optimizations. Mechanism → Touch throttling → Input lag.

Professional Judgment: Authenticity and functionality are inversely proportional in retro design. Prioritize constraints that drive creativity (e.g., 8-bit colors, storage limits) and accept failures as features. If X (authenticity) → use Y (manual coding, era-specific constraints). If Z (scalability) → abandon retro constraints.

Conclusion: Preserving Digital Heritage

In an era dominated by AI-driven automation and sleek, standardized interfaces, the act of crafting a 90s-themed portfolio website without modern tools is more than a nostalgic exercise—it’s a cultural preservation effort. By manually coding jagged icons, replicating 8-bit color palettes, and enforcing storage constraints like the 5MB localStorage limit, the project mechanically recreates the physical and technical limitations of 90s computing. This isn’t just about aesthetics; it’s about embedding the era’s constraints into the code itself, forcing creativity within boundaries that modern developers rarely encounter.

Why This Matters

The 90s and early 2000s internet culture was defined by unfettered experimentation and DIY ingenuity. Websites were handcrafted, often with vanilla JavaScript and hardcoded pixel values, because frameworks didn’t exist. By avoiding modern tools like React or AI, this project recreates the mechanical process of that era—direct DOM manipulation, manual state management, and intentional imperfections like uneven window borders. These choices aren’t arbitrary; they’re causally linked to the hardware and software limitations of the time, ensuring the experience is authentically retro, not just visually retro.

Technical Fidelity as Preservation

The applet system, for instance, isn’t just a feature—it’s a mechanical replication of 90s storage constraints. By using localStorage with a 5MB limit, the system physically enforces modularity, mirroring the 1.44MB floppy disk limitations. Exceeding this limit silently drops data, breaking functionality just as it would on a 90s machine. Similarly, the lazy-loading of applets via XMLHttpRequest introduces 200-500ms latency, mimicking CD-ROM load times and triggering the brain’s reticular activating system (RAS) for memory recall. These aren’t bugs—they’re features of authenticity.

Trade-Offs and Failure as Design

The project’s desktop-first design prioritizes authenticity over universality. Mobile compatibility suffers due to touch event throttling (16ms intervals), causing input lag in timing-dependent applets like the 3D Maze. While passive event listeners could mitigate this, they violate the “no modern optimizations” rule. This trade-off is intentional: partial mobile functionality is accepted as a feature of the era’s constraints, not a failure of design. Similarly, memory leaks from vanilla JS’s manual state management are mechanically linked to 90s software quirks, and their risk is mitigated by era-specific practices like manual garbage collection.

Inspiring Future Generations

By preserving these mechanical and technical details, the project doesn’t just recreate nostalgia—it educates. Future generations can experience the constraints that drove creativity, from 8-bit color palettes to storage limits. This isn’t about romanticizing the past; it’s about understanding the roots of digital innovation. If we lose these details to AI-generated retro themes or frameworks, we lose the *causal link between limitations and ingenuity.*

Final Rule for Preservation

If authenticity (X) → use manual coding, era-specific constraints (Y); if scalability (Z) → abandon retro constraints.

This project proves that preserving digital heritage requires more than visual mimicry—it demands mechanical fidelity. By embracing the constraints of the past, we not only honor it but also inspire future innovation rooted in understanding, not abstraction.