Forem: sijiaoh

Why I Started Avoiding Frontend Development

sijiaoh — Sat, 17 Jan 2026 10:46:04 +0000

The jQuery Era

This story starts back in college. I took a web development class and got my first taste of building for the web. It was still the golden age of jQuery. HTML, CSS, and JavaScript in three separate files, linked together through classes. I hated it.

It was just tedious.

The instructor talked about the benefits of "separation of concerns," and I couldn't come up with a clever counterargument, so I let it go. But I wasn't convinced at all. I understood the philosophy of separating structure, style, and behavior. But jumping between three files just to change how a button looks—is that really "good design"? I didn't think so.

Meeting Vue.js

In my second year as a professional developer, I started doing frontend work seriously. It was Vue.js (v2).

I thought it was fantastic. Not because of reactivity or the virtual DOM or anything like that. It was the fact that HTML, CSS, and JavaScript lived in a single file. That alone made me happy.

I knew it. We never needed to split things into three files.

I liked Scoped CSS too. That massive, deeply nested, fundamentally unmaintainable mess (or so I firmly believe) known as global CSS—I could finally leave it behind.

Moving to React

It didn't take long to learn that Vue, as great as it was, wasn't the global market leader.

React was.

JSX, the newly introduced Function Components, Hooks—these new concepts intimidated me a bit, but I figured I'd give it a shot and see what the fuss was about.

It was fantastic. A sense of unity I'd never experienced before.

The rule that Hooks must be called in the same order every time made me think, "How is this design even allowed?" But the elegance of building small, focused components and reusing them everywhere genuinely moved me. CSS-in-JS had its critics, but I personally liked it.

At the end of the day, I just want everything about a component to live in one file.

The Redux Cloud

The winds shifted when Redux entered the picture.

Absurdly long, incomprehensible boilerplate. Countless restrictions I can barely remember now. I struggled through it all, thinking, "This is not the development experience I signed up for."

But Redux was the standard back then. Everywhere I went, it was "we use Redux." That's when I started hating frontend development again. When job hunting, I began avoiding frontend roles and prioritizing backend work. It started around this time.

The Pain Eased, But

When useContext came along, the pain eased a bit. The era of Redux dominance was coming to an end.

But I still couldn't bring myself to like frontend.

The boilerplate was disappearing. That wasn't the problem. Data and logic were merging with components—components that should be nothing more than a View layer for display. That bothered me.

Sure, most pages just render whatever the backend returns, so it's not a big deal. But that's exactly why, when you build complex features on top of that foundation, it's so easy to end up writing data management and business logic directly inside components.

Tailwind CSS: A Ray of Light

When Tailwind CSS came out, I was genuinely excited.

CSS, Sass, PostCSS, Vue Scoped CSS, CSS-in-JS. After all that wandering, I thought, "Finally, the right answer." Yes, classes tend to get long. But compared to CSS finally being manageable, that's not a problem at all.

I Still Avoid Frontend

Even now, I tend to avoid frontend work.

The reason is simple: there are too many traps.

Are they using Redux? Are they using something other than Tailwind for CSS? In complex features, is the logic tightly coupled with the view? Is the codebase stuck in an eternal transition period where all of the above coexist? Most of the time, you don't find out until you're already on the project. And more importantly, I'm the type of person who feels real pain when I encounter these problems.

Of course, you could say "just fix it." But the key decision-makers might not agree with my views, and there might not be time allocated for refactoring.

Backend, on the other hand, still feels relatively civilized.

There are traps there too—over-engineered layered architecture, raw SQL everywhere, DDD enthusiasts, homegrown framework advocates. By the way, when it comes to DDD, I agree with the domain modeling philosophy in the first half of the book, but I don't agree with the technical implementation patterns in the second half.

But backend traps are easier to spot in advance. Frontend traps require careful probing to uncover, while backend issues are relatively easy to assess. On top of that, Rails—my main battlefield—tends to be less accident-prone.

So honestly, I haven't had the courage to join a team focused primarily on frontend. If I'm going to do it, I need at least a full-stack environment where I can touch the backend too. That's been my honest take for years now.

That said, I do think the AI era might change things.

Shameless plug: I'm building Pockode—code with Claude Code on your home PC from your phone.

Original text: https://sijiaoh.com/en/posts/why-i-avoid-frontend/

In the AI Era, a Single Branch Isn't Enough — git worktree Pockode

sijiaoh — Sat, 17 Jan 2026 10:31:38 +0000

In my last post, I wrote about building Pockode to control Claude Code on my home PC from my phone.

After using it for a while, the next pain point became clear: parallel work.

When you're using Claude Code, the waiting time starts to feel like a waste.

Pockode's worktree switching feature

So I added git worktree management to Pockode.

A few taps in the sidebar, and you can create and switch worktrees.

Pockode was designed mobile-first, but I use it on my PC all the time too.

By focusing on making switching "as easy as possible" on mobile, it ended up being the smoothest workflow on desktop as well.

More and more tasks I want to run simultaneously

While Claude Code is working on one feature, other things keep popping into my head:

I want to push forward on another feature
I want to investigate a bug
I want to clear out the PR review backlog

Back when I was writing code by hand, I'd just do things one at a time. But with Claude Code, the urge to "have it do multiple things at once" comes naturally.

The question is: how do you manage parallel work?

Running in parallel in the same directory leads to collisions

If you run multiple Claude Code instances sharing the same working directory, things will go wrong:

Files being generated get overwritten by another task
Changes from one task break the assumptions of another
State keeps shifting, and you lose track of what's actually done

You can make it work if you're careful, but if parallel work is the norm, you have t

Original text: https://sijiaoh.com/en/posts/pockode-git-worktree-parallel-workflow/

Coding on Your Phone? Actually, Yes.

sijiaoh — Sun, 11 Jan 2026 21:54:57 +0000

I want to write code on my phone.

On the train, during a walk, waiting in line. Moments when I can't open my laptop, but my mind drifts to code—that function, that bug, that feature. But typing symbols on a phone is miserable. It's just not practical.

That's what I used to think.

Discovering Coding Agents

Everything changed when I started using coding agents seriously.

Natural language becomes code. Say "refactor this function" and it's refactored. Say "add tests" and tests appear. It can run commands too.

Then it hit me: if I can code with natural language, why not on my phone?

So I Built Pockode

At first, I considered setting up a dev environment in the cloud. But the setup was tedious, the performance mediocre. And honestly, I just wanted to use my familiar home setup.

So I built Pockode.

It lets you control Claude Code on your home PC from your phone. If you have Claude Code installed, one command spins it up. Scan a QR code and you're in.

Pockode is open source. You can disable the official relay and self-host. Your code and runtime stay entirely under your control.

I Stopped Opening Neovim

When I first started building Pockode, I still needed Neovim—at least to check git diffs.

One day, I added git diff and file browsing to Pockode. I was debugging while using Pockode to continue development, and before I knew it—Pockode was all I needed.

Now I only open Neovim when I want to dig deep into the codebase with full-text search.

I once fixed a bug while taking a walk. Gave instructions to the AI on my phone, had it generate code and run tests. By the time I got home, the feature was done.

99% of the Code Was Written by AI

99% of Pockode's code was generated by Claude Code. But I wasn't just delegating blindly—I discussed the design, reviewed the output, and corrected course when needed. Iterate, refine, repeat.

My Go experience barely goes beyond tutorials. I hadn't touched React in ages. Yet I shipped something that works. Go is readable enough that even with fuzzy syntax knowledge, I can tell if the logic is right. The AI suggests the right libraries, proposes approaches I wouldn't have thought of.

If I'd been coding alone, I probably would've abandoned it halfway. AI kept me going.

The Pitfalls of AI (and How to Deal with Them)

AI isn't perfect.

It goes off the rails. Gets stuck in local optimization, loses sight of the original goal. Keeps iterating on a flawed premise. When you notice it, stop it. Explicitly redirect.

It patches instead of fixes. Sometimes it slaps on a band-aid instead of solving the root cause. Patches pile up, and suddenly simple functionality is buried in convoluted code.

It writes meaningless code. This one's insidious. Variables defined but never used. Branches that never execute. Harmless since it doesn't affect behavior. But in the next session, the AI tries to make sense of it: "This variable must exist for a reason." And that's where new misunderstandings begin.

To catch these mistakes, you need to understand the big picture. You can't fully hand things off. But as long as you stay aware, AI is absolutely usable.

Keep Working Away from Your Desk

Coding agents have an annoying problem: permission prompts.

Writing files, running commands—each one pops up a confirmation. Want to step away and let it run? Sorry, it's stuck waiting for approval. But auto-approving everything feels risky.

With Pockode, you can check permission requests from anywhere and approve with a tap. No more waiting.

I used to hate stepping away when I was in the zone. Didn't want to break the flow. Now it's different. Walking around, on the train—I can check on the agent's progress and intervene when needed.

Code from anywhere. That's the life I wanted.

Pockode—give it a try if you're interested.

Original text: https://sijiaoh.com/en/posts/phone-claude-code-and-me/