About Coding Dunia: Runnable Guides to the Interface Layer
Practical, in-depth guides on React, TypeScript, JavaScript, and modern frontend development. Written by engineers, for engineers.
The Byline, and What Sits Behind It
Marcus Bennett
Editor, Coding Dunia
Marcus Bennett is a pen name. What stands behind it is below, and every code sample here is run before it publishes.
The person typing started on a Commodore 64 in BASIC in the mid-nineties, moved to HTML and JavaScript when the web showed up, spent a long stretch building web systems in PHP, and ended up on the TypeScript and React stack this site is about. That's three decades watching one corner of the industry. Long enough to have believed a few things that turned out to be wrong, which is the part that actually shapes the writing here: when a guide on this site hedges, it's usually because the author already got burned by the confident version.
The practical upshot is a bias against whatever the ecosystem currently calls inevitable. Build tools, state libraries, and CSS methodologies have all had their turn being the obvious future. Most of them shipped something useful and then got replaced anyway.
The Interface Layer, and Where It Stops
This site is about the layer a user actually touches: React components, TypeScript types that describe real props, state that has to survive a re-render, CSS and layout, and the build tooling that turns all of it into something a browser will load. Vite, npm and pnpm, bundler config, the CI step that catches a broken build before a reader does. If it ships to a browser or runs on Node to get it there, it belongs here.
Go, Rust, Python, mobile-native, and career advice are all out. Not because they're uninteresting, but because writing about a stack you don't run produces guides that read fine and fall apart the moment someone tries them. Code quality as a subject in its own right, linters, coverage, dependency risk on a thirty-year horizon, is somebody else's beat too.
Every Snippet Runs Before It Ships
This is the part worth being specific about, because "we test our code" is the kind of claim every site makes. Here it means: the snippets in a TypeScript, React, or Node guide are executed against the exact versions the article names, before that article publishes. Not a similar version. The one in the heading.
Why bother stating the version at all? Because a React example that works in 18 and breaks in 19 is worse than no example, and you can't tell which one you're reading unless somebody writes the number down. When a major release lands, the affected guides get re-run against it rather than getting a new date on top of old code.
Benchmarks name their hardware, usually an M-series MacBook Pro or a Linux CI runner, because a number without a machine attached is decoration. Nothing here is copied out of a vendor's performance page.
What Goes Stale First
Frontend writing rots faster than almost any other kind, and pretending otherwise is how a site fills up with confidently wrong advice. The order is fairly predictable: install commands and flags go first, then config file shapes, then the API surface, and last of all the reasoning about why you'd want the thing at all.
So the guides here try to carry their weight in that last category, and anything version-pinned gets a freshness review every quarter. The "Last updated" stamp on a post means somebody re-checked the facts. It isn't a republish to make the date look newer, which is a trick that helps rankings for about a month and helps readers never.
Where the Domain Came From
This domain was bought at auction in March 2026. Before that it belonged to a different Coding Dunia, an Android and Java tutorial site running since 2019. This site isn't a continuation of that one, isn't run by the same people, and isn't affiliated with it.
That's spelled out because the original project still exists elsewhere, and its authors shouldn't have their name quietly absorbed by whoever won an auction. If you came looking for those Android tutorials, you're in the wrong place, and no archived version of them lives here. Nothing on this site was written before the domain changed hands.
Money, Links, and Corrections
No sponsored posts, and no payment for recommending a library, framework, or hosted service. When a guide names a paid tool, it's one that's actually in use on a project behind this site. Comparison posts get ranked from running the things, not from reading their landing pages.
Click a link in the text and you land where the anchor said you would. Nothing in the prose is rewritten through an affiliate hop or carries a campaign tag. The money comes from two places, both labelled: the Amazon boxes for books and hardware inside each article and the banner under it, which are affiliate links, and display ads. The disclosure page covers both. If paid tooling gets tested, the article says how access was obtained: free tier, trial, or paid for out of pocket.
Corrections happen in public. A deprecated API, a benchmark that no longer holds, a TypeScript release that changed behaviour, all of it gets fixed in the article with a note at the top. Old guides don't get deleted; they get updated, or marked outdated with a pointer to what replaced them. Found something wrong? The X and Bluesky accounts above get read faster than any contact form.