PokémonĀkaibu - Modular Vanilla JS Pokédex

The Challenge

The assignment was to create a vanilla JavaScript application that:

• Fetches data from a public API (PokéAPI),
• Presents that data in a scrollable, responsive UI,
• Allows users to drill down into details,
• And handles performance and compatibility without relying on React, Angular or similar frameworks.

On top of that, I wanted the codebase to be modular and maintainable: clear separation between data fetching, UI rendering and user interaction, with an eye toward being understandable to other developers.

Objectives and Success Criteria

I set a few concrete goals for PokémonĀkaibu:

• Make browsing easy at scale
  Display Pokémon in batches, with a smooth infinite-scroll-style experience instead of dumping the entire Pokédex at once.

• Provide meaningful detail views
  When a user clicks a Pokémon, show a focused modal with its name, artwork, stats, types and abilities.

• Support basic search
  Allow users to search Pokémon by name from the main screen. Searching by ID is noted as a planned enhancement for later.

• Be friendly across devices and browsers
  Use responsive layout and polyfills so the app remains usable on older browsers as well as modern ones.

• Keep the JavaScript modular
  Organize code into small, focused modules for fetching data, transforming it and rendering UI, so it’s easier to extend.

I considered the project successful if: users could scroll, search, and open detailed modals without noticeable lag, and the code stayed readable enough that I’d be happy to build on it later.

• Static hosting, dynamic data
  The app is just static assets (index.html, css/, js/, img/). There’s no backend of its own; all dynamic behavior happens in the browser via JavaScript.

• Modules & responsibilities
  JavaScript is split into responsibilities such as:

  • fetching Pokémon lists and details from PokéAPI,
  • transforming responses into a normalized format,
  • rendering list items and detail modals,
  • and wiring up scroll and search behavior.

• Data loading strategy
  Pokémon are loaded in batches. As the user scrolls, new batches are requested, appended to the DOM and cached in memory. This keeps initial load time low and avoids fetching the full Pokédex up front.

• UI layer
  The UI uses:

  • Bootstrap 5 for the grid, basic layout and modal component,
  • custom CSS for Pokémon-specific styling,
  • jQuery plus vanilla JS for DOM querying, event handling and small UI utilities.

• Compatibility & polyfills
  Because the app targets a mix of browsers, it:

  • uses the Fetch API for network requests,
  • ships polyfills for fetch and Promises so older browsers can still run the app,
  • avoids build tools by writing code in a way that works directly in the browser.

• Development workflow
  The app is designed to run via a simple static server; during development, I used the VS Code Live Server extension for quick reloads and easier debugging.

Phase 1 – Exploring PokéAPI and shaping the UI

I started by exploring the PokéAPI response structure:

• which endpoints to call for listing Pokémon,
• how to get detail information (stats, types, abilities),
• and what data to show in the list vs. detail view.

From there, I sketched a simple UI:

• a scrollable list of Pokémon cards with names and images,
• a search bar at the top,
• and a modal that shows full details when a card is clicked.

Key learning: understanding the API first made it easier to avoid over-fetching or duplicating data.

Phase 2 – Building the list and detail workflow

Next, I implemented the basic list → detail flow:

• Fetch a batch of Pokémon,
• Render each as a card with image and name,
• Attach click handlers that fetch (or reuse cached) detail data,
• Populate and open a Bootstrap modal with stats, types and abilities.

The aim was to keep the interaction fast and predictable: click → see details, close → return to the same scroll position.

Phase 3 – Incremental loading and performance

To make the app scalable, I focused on incremental loading:

• Load an initial batch of Pokémon on page load,
• Detect when the user nears the end of the list and fetch the next batch,
• Append new cards to the DOM without re-rendering everything.

This reduces the initial payload and keeps the UI responsive, even on slower connections.

Phase 4 – Search and client-side filtering

Once the basic browsing worked, I added search:

• A search input listens for text changes,
• The displayed list is filtered client-side by Pokémon name,
• Clearing the search restores the full (currently loaded) list.

Search by ID is planned as a future addition, but the name-based search already covers common usage for fans who know at least part of a Pokémon’s name.

Phase 5 – Compatibility and polish

Finally, I refined compatibility and UX:

• Included polyfills for fetch and Promises so older browsers can run the app,
• Tweaked layout breakpoints and font sizes for mobile vs. desktop,
• Added loading indicators and simple error states if network requests fail.

Key learning: even for a “simple” app, performance and compatibility decisions have a big impact on how polished it feels.

The testing approach included:

• Manual functional testing

  • verifying that batches of Pokémon load correctly as you scroll,
  • opening and closing detail modals for different Pokémon,
  • using the search bar with partial and full names,
  • deliberately triggering network errors (e.g. offline mode) to see error handling.

• Responsive checks

  • testing the layout across different viewport sizes to ensure the grid and modal remain usable on mobile and desktop.

• Cross-browser sanity checks

  • checking behavior in modern browsers and confirming that polyfills keep core functionality working in older ones.

• Linting and formatting

  • using ESLint and Prettier to catch obvious mistakes and enforce consistent code style.

If I revisit the project, I’d like to add basic automated tests around data transformation and maybe a few integration-style tests that simulate the scroll + load + detail flow.