DEV Community: Daffa Izzuddin

I picked frameworks to look different, it took me years to notice

Daffa Izzuddin — Fri, 30 Oct 2026 14:36:50 +0000

I write about programming at invasikode.com, and I have been writing code since high school. My day job now is mostly backend and AI plumbing, which is a strange place to arrive at for someone who spent years caring a lot about front end frameworks. This post is about those years.

The first thing I built that strangers actually used was a school election system, written in Pascal with Lazarus because that was the tool I had. It got rewritten more than once over the years, each time in whatever framework I had learned most recently. That habit, learning a tool and then looking for somewhere to put it, started early.

The honest version of the early years: Angular first, because plenty of tutorials covered it and The Net Ninja wrote a good number of them. Then React, still in the class component era. Up to that point every choice made sense, because each one followed the material that existed.

That part is fine. Following what is available is how most of us start, and it is a reasonable way to learn. The part I want to talk about starts one step after that.

The choices that had nothing to do with the work

Moving to Vue was not a technical decision. It was not better for the project I had in front of me. I had no benchmark, no comparison, no criteria list. I picked it because the people around me were on React, and I did not want to be one of them.

The thought in my head was not "this will be faster to build". It was "this will be mine".

Then Nuxt 2, for the same reason in reverse. The people near me used Next, so the choice fell to Nuxt. Again no comparison. Again the deciding factor was who I did not want to look like.

CSS went the same way. I was proud of indented SASS, the syntax with no braces. If you had asked me what it bought me, I would have had nothing to say. It looked sharper in a code block, and that was enough. Plain CSS and SCSS felt boring, even though the browser ends up with the exact same result. 😅

I am describing myself here. If you made a decision like this and it worked out, that is not a contradiction of anything below.

Why it took me years to see it

While you are still learning, you have nothing to point at. No product with real users, no system that has survived a few years of production. That is a normal stage. But it leaves a gap: you want something to show, and a stack is the cheapest thing to show.

Think of a club jacket. You may not be able to ride yet, but the jacket already says you are part of the group that can. A stack does exactly that. Mention a slightly rare tool and people assume you understand more than you said.

The places I was hanging out made this worse. Discord servers, Reddit threads, campus group chats with friends who were also learning. There was a small circle that knew better, and being in it felt good. Every time I said "ah, I don't use that one", something small happened in the conversation, and I got a little hit of being interesting. Pleasant things get repeated.

What the bill looked like

It arrived slowly enough that I did not connect it to the cause.

The first cost was depth. Every switch puts you back at the surface: learn the routing, learn how state is handled, learn the folder conventions, learn the build config that nobody wrote down. I know a little about a lot of tools and I am genuinely good at few of them. Depth comes from staying somewhere long enough to hit the problems that only show up in month eight.

The second cost was other people. If I am the only person on the project who understands the tool, everyone who touches that code pays for my choice. Something that felt like taste from my side looks like a learning tax from theirs.

The third one is the one I still wince at. I became the kind of person who made a small face at other people's choices. "Still using that?" It sounds like a joke. Said often enough, it changes how you look at people, and it makes you worse at listening. Some of the people I said that to had better reasons than mine. I never asked what they were.

What actually survived

After Vue came Svelte, then a migration to Nuxt 3, then a short attempt at TanStack and Astro that ended at the how-to guide, then finally Nuxt 4. What carried across all of that was not API knowledge. I could not write the router setup for half of those from memory today.

What carried across was the thinking. How to break a feature into pieces, where state should actually live, why a page feels slow before anyone opens the profiler.

At my current job the front end is vanilla. No directives, no compiler giving me a hand. That is where the difference becomes obvious: the parts I understand are the parts that survived. Everything else was a name I memorized for six months.

I want to be clear about one thing, because it would be dishonest to leave this post as a warning. I do not regret any of it. Vue and Nuxt are what I reach for by default now, and they earned that over years rather than over one weekend. Go is the language I pick when I want the work to feel comfortable, and Python is where all the AI plumbing lives. That is a pretty ordinary stack. I just arrived at it from an odd direction, and it still landed somewhere good.

CSS finished the same way. Bootstrap, then Tailwind, then PicoCSS out of curiosity, then back to Tailwind, then PostCSS because it was enough, then plain CSS. After going all the way around, the finish line is the thing I called boring in 2019. 🙃

Choosing differently was never the problem

I want to be clear about this part, because I think it is where people usually misread a post like this. Choosing the unusual tool is allowed. Sometimes it is right. If the rare tool is the best fit for your problem, use it. I would rather work with someone who picks the small library for a real reason than someone who picks the popular one out of reflex.

Two conditions, and that is the whole test: a technical reason you can state in one sentence, and a trade-off you can say out loud without getting defensive. "This is faster for our case, the community is smaller, and that is the risk." Say that sentence and nobody argues with your framework choice.

So the mistake was never the framework. At the time, the mistake was the reason. The same tool can be a good decision or a status decision. Only the reason changes.

What I ask myself now

When something new trends, I give it a week instead of an evening. If I still want it after a week, and I can say what it buys me, I try it on a branch. If I cannot say what it buys me, I close the tab and go back to work.

That is the whole rule. It is not strict, and I still break it. Being honest with yourself first is the cheap part. It is the npm install afterwards that gets expensive.

If you are in the middle of the phase I was in, nothing is broken. You will probably enjoy the tool you picked, and you will learn something from it even if the reason was not technical. The only thing I would ask you to keep is the sentence: can I explain why I chose this, out loud, without defending it?

If yes, go. And if the reason turns out to be mostly vanity, that is fine as well. Mine was, for longer than I would like to admit, and I still ended up with a stack I like and a job I can do.

I built the dev tools I was tired of looking for

Daffa Izzuddin — Thu, 29 Oct 2026 11:34:58 +0000

My browser normally has a JSON formatter, a JSON to TypeScript converter, a markdown to document converter, an HTML email previewer, a slug generator, a time zone converter, and a URL encoder open in separate tabs. Each one is its own website with its own ads, its own cookie banner, and a good chance it wants me to sign in before it will format 400 bytes of JSON.

The breaking point was pasting a work template into a free online preview tool and not being able to tell what it did with it. That is not a question I want to leave open, so I closed the tab and stopped using those.

The rule now is simple: anything I would not paste into a public gist does not go into a tool I did not build.

So I put the tools I actually use on one page: quoin.izzudd.my.id.

The part where I admit how it was built

This is 100% AI slop. I call it magic, and I am not going to hide that in the post where I announce it. I describe what I want, the model writes the code, I read it, I fix the parts that are wrong, and I keep the parts that work.

What the model does not do is decide what belongs on the site. Every tool on Quoin exists because I hit that problem during real work, usually while annoyed. The selection is the product. The code is mostly generated, and I say that plainly because the alternative, a post full of "hand-crafted with love", is a claim you can check against the commit history.

The name is the one part I will defend. A quoin is the wedge that locks type into a printing forme, and the corner stone that keeps a wall true. Small tool, keeps everything else in place.

What I do all day, and the tool that covers it

Structured output for agents. I write a JSON Schema, then I need the same shape as Pydantic, Zod, or a TypeScript type. Handwriting those conversions is how you end up with a field mismatch at 2am. So: schema builder with inference from a sample payload, plus a JSON to types tool that emits Pydantic, Zod, TS, Go structs, and Python dataclasses.
Markdown into Word or Google Docs. I take notes in Markdown, then someone asks for a document. Paste, convert, paste into Docs, formatting survives.
Email templates for customers. I want to see the HTML the way the recipient will see it, before it goes out. Live preview, no upload.
URLs copied out of a terminal. A long URL wraps across three lines and the copy brings the newlines and indentation with it, so pasting it into a browser loads nothing. Strip whitespace, then open.
Broken URLs from partners. Spaces, mixed case, accents, tracking junk, trailing punctuation from a chat message. Sanitize, slugify, encode, done.
Time zones. I am in WIB (UTC+7). The team is in UTC, Italy, Singapore, and Hong Kong. Converting by feel is how meetings get missed, and half the converters online get the abbreviation wrong in summer.
Dirty CSV into an INSERT statement. When I need seed data in a dev database, I want the INSERT now, not an import pipeline with a wizard and a schema mapping step. Paste the CSV from Excel, pick MySQL or Postgres, copy the statement, done. The column types are inferred from your data, so the inference gets some columns wrong, and for throwaway data I do not care. I am not proud of this workflow, but it is the one I use most, and it is fast.
Looking at JSON. Sometimes I do not need to edit it, I need to see the shape of it. Collapsible tree, search across keys and values.

That list is boring and specific on purpose. None of it is a hard problem. All of it costs ten minutes a day when the tools are scattered across six sites that each want something from me.

Opinionated by design

The rules are mine and they are not up for a product debate:

No accounts. There is nothing to sync, so there is nothing to sign in to.
Nothing leaves the tab. Every operation is a function running on your machine. No API call, no telemetry, no analytics SDK.
No AI inside the product. AI wrote the code. The tools themselves are deterministic, and I want them to give the same answer every time.
No workspace, no dashboard, no onboarding tour. Open it, use it, close it.
Dirty is allowed. The CSV to INSERT tool infers your column types and sometimes infers them wrong. For seed data that is a fair trade: it is a helper for throwaway data, not a migration tool, and I would rather it be fast than be right about everything.

If a tool needs a server, a login, or a paid tier, it does not get added. That constraint removes a lot of features I would otherwise have to build, which is the part I like most about it.

What is in there now

Six groups: JSON, strings, time, tables, web and HTML, markdown. I am not putting a number on it, because the number changes every time I get annoyed, and that is the point.

JSON: beautifier and minifier, interactive tree visualizer, stringify and unescape, schema builder with inference, JSON to Pydantic/Zod/TS/Go.

Strings: escaper and unescaper for HTML entities, URL components, regex specials, C-style slashes, and Base64; whitespace remover; slugifier; base encoder; text and Git diff.

Time: a DST-aware time zone converter, so the abbreviation is right in summer and in winter.

Tables: table and CSV editor, plus CSV to SQL INSERT statements for MySQL, PostgreSQL, SQLite and MSSQL with JSONL, TSV, Markdown and JSON export.

Web: HTML and email preview.

Markdown: live editor and preview, plus conversion to a paste-ready format.

Press Ctrl+P for the command palette, pin the tools you use daily, and your drafts survive a reload.

It keeps growing, and that is the invitation

Quoin is not a startup and it is not trying to become one. It is where I add a tool the next time I get annoyed. If you have the same annoyance, there are three ways in:

Open an issue with the workflow you need. If it fits the rules above, it gets built.
Send a PR. The tool registry is one file and a tool page is one file, with the same skeleton for all of them, so adding a tool is a small diff.
Fork it. Change the rules, add the server, add your own auth, keep your fork private for your team. It is MIT, and I would rather you have the tool you actually need.

Live: quoin.izzudd.my.id
Source: github.com/izzudd/quoin

If you use it and something breaks, tell me and I will fix it. If you do not, that is fine too.