Why We Chose Simplicity
When we set out to build ImpactMojo, we faced a fundamental architectural decision that every web project confronts: how much technological complexity to embrace. The prevailing wisdom in web development circles pushes toward React, Next.js, or similar JavaScript frameworks — powerful tools that enable dynamic, interactive experiences. We chose a different path. ImpactMojo is built on static HTML, CSS, and vanilla JavaScript, served through Netlify, with Supabase handling the few backend functions we need.
This was not a decision born of ignorance about modern frameworks. It was a deliberate choice grounded in our context and values. Our users include development professionals across South Asia accessing content on variable internet connections, older devices, and sometimes through data plans where every megabyte matters. A React application that ships 200KB of JavaScript before rendering any content is a luxury our audience cannot afford. A static HTML page that loads in under a second on a 3G connection is not just technically simpler — it is more equitable.
Our content — courses, games, labs, handouts — is fundamentally document-like. It does not require real-time data synchronisation, complex state management, or the sophisticated routing that frameworks excel at. Using React to serve what is essentially educational content would be like driving a Formula 1 car to the grocery store: impressive but unnecessary, expensive to maintain, and ill-suited to the actual journey.
The Stack in Detail
Static HTML/CSS/JS: Every page on ImpactMojo is a self-contained HTML file. Games are single HTML files with embedded CSS and JavaScript — no build step, no bundling, no transpilation. This means any developer (or motivated non-developer) can open a file in a text editor, understand its structure, and modify it. The barrier to contribution is as low as we can make it.
Our CSS uses custom properties (CSS variables) extensively for theming, including the dark/light mode toggle that persists across sessions via localStorage. We avoid CSS frameworks like Bootstrap or Tailwind — not because they are bad tools, but because the overhead of learning and maintaining a framework is not justified for our scale, and hand-written CSS gives us complete control over the user experience.
Supabase: For the few features that require a backend — user progress tracking, certificate generation, form submissions, and analytics — we use Supabase, an open-source Firebase alternative built on PostgreSQL. Supabase gives us a relational database, authentication, real-time subscriptions, and storage through a clean API, all without managing servers. The generous free tier supports our current scale, and the open-source foundation aligns with our values.
Netlify: Our hosting is on Netlify, which serves static files from a global CDN with automatic HTTPS, continuous deployment from our GitHub repository, and zero server management. A git push to the main branch triggers a deployment that propagates globally within minutes. The simplicity of this deployment pipeline means we spend our time creating content rather than managing infrastructure.
"The best technology for an educational platform is the technology that stays out of the way of learning. For us, that means static files, fast loading, and zero configuration for the end user."
Why No Frameworks?
The decision to avoid JavaScript frameworks deserves deeper explanation, because it is the choice that raises the most eyebrows among developers. Three factors drove this decision.
First, longevity. The JavaScript framework landscape changes rapidly. Angular was dominant, then React, then Vue, now a dozen contenders. Framework-dependent projects require ongoing maintenance just to keep pace with breaking changes, deprecated APIs, and security patches in the dependency tree. A static HTML file written in 2020 works exactly the same in 2026 — and will work the same in 2030. For an educational platform that aims to serve content for years, this durability matters enormously.
Second, accessibility. Static HTML is the most accessible format on the web. It works with screen readers, text-only browsers, low-bandwidth connections, and older devices without any special accommodation. Framework-rendered content can achieve the same accessibility, but it requires deliberate effort and expertise that many development teams lack. With static HTML, accessibility is the default rather than the aspiration.
Third, contributor friendliness. We want development professionals — not just software engineers — to be able to contribute content to ImpactMojo. Asking a monitoring and evaluation specialist to learn React, JSX, component architecture, and build tooling before they can contribute a handout on sampling methods is an unreasonable barrier. Asking them to write or edit an HTML file is not.
What We Use for Content Creation
Beyond the core stack, several tools support our content creation workflow. GitBook hosts our documentation, providing a clean interface for platform guides and contributor documentation. Formspree handles form submissions without requiring server-side code. Google Analytics (via Google Tag Manager) helps us understand how learners use the platform — which courses are most popular, where users drop off, and how discovery happens.
For game development, each game is a self-contained HTML file that includes all necessary CSS and JavaScript. This approach means games can be downloaded and played offline — a critical feature for users in areas with intermittent connectivity. The Indian folk art aesthetic that characterises our game illustrations (Warli, Madhubani, Gond, and other traditions) is rendered through CSS and SVG rather than heavy image files, keeping load times minimal while celebrating South Asian artistic heritage.
Trade-offs and Honest Limitations
No architectural choice is without trade-offs. Our static approach means we cannot easily implement features like real-time collaboration, dynamic content personalisation, or complex interactive simulations that would benefit from a framework's state management capabilities. As the platform grows, managing hundreds of static HTML files without a templating system or component architecture becomes increasingly challenging. We address this partly through generator scripts and shared CSS, but it is an honest limitation of our approach.
We also sacrifice some developer experience conveniences — hot module reloading, type checking, automated testing frameworks — that modern build tools provide. For our small team, the simplicity benefits outweigh these costs. For a larger engineering team, the calculus might be different. The key insight is that technology choices should be driven by context — user needs, team capabilities, content type, and organisational values — not by industry fashion. For ImpactMojo, simplicity is not a compromise. It is a feature.