baca-quran.id: a SvelteKit Qur'an reader that ships as static files

What baca-quran.id is, and the reader it replaces

The project is a web application for reading the Qur'an in a browser. Its own description makes three claims: no ads, no analytics, and free. The live site is at https://www.baca-quran.id/, and the README lists a blog and a stories section that live under the same domain but in separate repositories. The audience is anyone who wants to read the Qur'an on a phone or a laptop without an app store install, and the secondary audience is developers who want to self-host that reader rather than depend on someone else's deployment.

The design target is narrow on purpose. A reader has to render Arabic text with correct fonts, present translations, and stay out of the way. The dependency list reflects that: @fontsource/amiri, @fontsource/amiri-quran, @fontsource/noto-naskh-arabic and kfgqpc-uthmanic-script-hafs-regular are all font packages, which tells you typography was treated as a first-class problem rather than a CSS afterthought. There is no database client, no ORM and no server framework in package.json. That absence is the architectural decision.

Static output, client-side data, and where the Firebase keys fit

The build script chains four steps: svelte-kit sync, vite build, then two Node scripts, makeSitemap.js and makeTimestamp.js. The README says to copy the build folder to your hosting. Combined with @sveltejs/adapter-static in devDependencies, the picture is a prerendered site with no server runtime, which is why the deployment instruction can be one sentence long.

The .env.example file exposes a different layer. It declares PUBLIC_FIREBASE_API_KEY, PUBLIC_FIREBASE_AUTH_DOMAIN, PUBLIC_FIREBASE_PROJECT_ID, PUBLIC_FIREBASE_STORAGE_BUCKET, PUBLIC_FIREBASE_MESSAGING_SENDER_ID, PUBLIC_FIREBASE_APP_ID, PUBLIC_FIREBASE_MEASUREMENT_ID and PUBLIC_FEEDBACK_FISH_PROJECT_ID. These are public-prefixed, so they end up in the client bundle by design, which is normal for Firebase web config. What the README does not say is which features break when those values are empty. Given that the project advertises no analytics, the presence of a Firebase measurement ID is worth noting rather than assuming either way.

Several features depend on third parties the README credits explicitly: prayer schedules come from api.aladhan.com, reverse geolocation from nominatim.openstreetmap.org, and MP3 audio from kemenag.go.id. Those are runtime calls from the browser, not build-time data, so a self-hosted copy inherits their availability and their usage policies.

Running baca-quran.id locally with pnpm

The README states two requirements: Node v20, managed with nvm or another version manager, and pnpm v9. The repository also carries .nvmrc and .npmrc, so the versions are pinned in files as well as prose. Install dependencies first:

pnpm i

Then start the development server:

pnpm run dev

The package.json script maps dev to vite dev, so you should get a local URL printed by Vite and the reader should render in the browser. For a production build, the README gives one command:

pnpm run build

That runs svelte-kit sync, vite build, then the sitemap and timestamp scripts. Copy the resulting build folder to your hosting. There is also a build:ci script that sets CI_BUILD=true and skips the sitemap and timestamp generation, which tells you those two scripts are the parts that need a normal filesystem and a real build date.

Before relying on any feature that talks to Firebase, copy .env.example to a local env file and fill in the keys you need:

cp .env.example .env

The README does not document which keys are optional, so treat that as something to determine by reading the source in src/.

The parts the README leaves out

There is no documented test command. The scripts include check and check:watch, which run svelte-check against tsconfig.json, and lint, which runs Prettier in check mode followed by ESLint. Those are type and style gates, not behavioural tests. A codecov badge sits at the top of the README, but the README does not explain what is measured or at what threshold, and the repository layout shows no test directory at the top level.

There is also no rollback procedure. The README says to copy the build folder to your hosting, which means whatever atomicity you get is whatever your host provides. If a build is bad, the documented path back is to rebuild from a known commit, and the README does not describe that either.

Content provenance is another gap. Credits name quran-json for the Qur'an text, kemenag.go.id for MP3 audio, islam.nu.or.id for Asmaul Husna and the tahlil text, and Hisnul Muslim plus several hadith collections for the daily do'a. What the README does not state is how those sources are refreshed, whether the text is bundled at build time or fetched at runtime, or how corrections reach a deployed copy. For a text where accuracy matters, that is the single most important undocumented detail.

Finally, the repository has no retrieved releases and no last push date in the repository information reviewed, so there is no way to judge how often it changes. Anyone planning to depend on it should check the commit history directly rather than infer activity from the README.

Where a static reader is the wrong choice

A static build is a poor fit if you need per-user state that survives a device change. There is no server in this architecture, so bookmarks, last-read position and any personal notes live in the browser. Clear site data and they are gone. Firebase is present in the dependency list and in .env.example, so some account-backed feature may exist, but the README does not describe it, and you should not assume sync until you have read the source.

It is also the wrong tool if you are building a general Islamic content platform. The blog and stories sections live in separate repositories, mazipan-quran-offline/tulisan and mazipan-quran-offline/stories, and are linked from the README as separate projects. This repository is the reader.

And it is the wrong choice if offline reading is a hard requirement. The README describes a web app served from a build folder, and nothing in the README describes a service worker, an offline cache or a packaged binary. The name of the sibling GitHub organisation, mazipan-quran-offline, suggests offline work exists somewhere in the author's projects, but the README for this repository does not claim it.

How this differs from a general-purpose static site generator

The obvious alternative for a developer who wants to publish a Qur'an reader is to assemble one from a static site generator plus a Qur'an data package. Astro, Hugo or Eleventy with quran-json as a data source would give you the same prerendered output and a much larger ecosystem of themes and plugins.

The difference is what comes in the box. baca-quran.id ships the fonts as pinned npm packages, including a specific Uthmanic script face, and it ships the UI as Svelte components with Tailwind already wired through @tailwindcss/vite. A general generator gives you a blank page and a data file. You would be writing the Arabic typography, the surah navigation and the audio player yourself.

The trade-off runs the other way too. Because this project is a finished application rather than a toolkit, changing its layout means working inside someone else's component structure, and upgrading means tracking SvelteKit and Svelte major versions. The package.json pins Svelte 5.57.0 and @sveltejs/kit 2.70.3, so you are on the current major line and will inherit its migrations.

Licence and the cost of keeping a fork current

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The README states the copyright as 2018-present by Irfan Maulana. Note that MIT covers the code in this repository, not the content it displays: the README credits quran-json, kemenag.go.id, islam.nu.or.id, Hisnul Muslim and the hadith collections as sources for text and audio, and it does not state the licence of each of those. If you plan to redistribute the bundled text or audio, check those sources separately. That is a factual observation about what the README does and does not say, not legal advice.

The upgrade cost is mostly the SvelteKit toolchain. Because the app is prerendered, a dependency bump that changes the adapter or the Vite config can change the shape of the build folder, which is the artifact you deploy. The build script also runs two custom Node scripts, makeSitemap.js and makeTimestamp.js, so any change to routing has to keep the sitemap generator working. There is no documented release process, so a fork has to decide its own cadence.

Editorial conclusion

Adopt baca-quran.id if you want a static, ad-free Qur'an reader you can build with pnpm and host from the build folder, and you accept that the README documents no rollback, no data refresh process and no test suite. Do not adopt it if you need a documented release history or an upgrade path, because none was retrieved. Before deploying, verify the Node and pnpm versions against .nvmrc and .npmrc, and check that the Firebase keys in .env.example are optional for the features you plan to enable.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository