DEV Community: XiaoMoDern

What AI Anxiety Sounds Like in Chinese Developer Communities

XiaoMoDern — Mon, 10 Aug 2026 08:00:10 +0000

The fear sounds different here

My last post — the one about AI not killing my motivation — did something I didn't expect. A few hundred people read it in a week. A handful of people commented. A lot of you followed.

I was genuinely surprised. Reading through the responses, I noticed something I had not expected: the fear sounds different here from the English-language developer discussions I read every day.

In many English-language discussions, AI anxiety is framed as an existential question:

"Will AI make my skills worthless?"
"Am I still a 'real developer' if AI writes most of my code?"
"What's the point of mastering a craft that a model can replicate in seconds?"

In the Chinese communities I read and take part in — Juejin comments, V2EX threads, and WeChat developer groups — the emphasis is often somewhere else:

"If everyone uses AI, the ones who don't will fall behind."
"My company just hired two juniors who code with Cursor. I've been here five years. What's my edge now?"
"I'm 33. AI is one thing. The 35-year-old cliff is the real one."

The difference is not absolute, but it is noticeable.

One conversation often asks: "Will AI replace me?"
The other often asks: "Will AI help someone else replace me?"

Those questions overlap, but they lead to different practical concerns.

Fear #1: Not "will AI replace me" — "will AI arm someone else to replace me"

China's developer market was intensely competitive long before AI arrived. Terms such as "996" — 9 AM to 9 PM, six days a week — are part of the career conversation, whether people are describing job postings, past experience, or the pressure they expect from the market.

In that environment, the question is often less "will a tool replace me?" than "who becomes more competitive once this tool is widely available?" AI changes what a team can expect from each person.

That does not mean a junior suddenly becomes a senior. Context, review judgment, and ownership still matter. But AI can shorten the distance between an idea and a plausible implementation, so the baseline for routine work can move faster than people expect.

That is why, in the communities I follow, AI anxiety often appears as tool FOMO rather than a debate about craft: "Which model are you using?" "Have you tried Tongyi Lingma?" "Is Cursor worth paying for?" The conversation is usually tactical. In a competitive market, refusing to try a useful tool can feel less like a principle and more like a risk.

The recurring tension is simple: someone may want to keep their skills sharp, while also worrying that a team already using AI will move faster. That is the part of AI anxiety I hear most often here.

A few weeks back, I saw a thread where a developer asked: "My whole team started using AI tools. I refused — I wanted to keep my skills sharp. Now I'm the slowest one. Am I wrong?"

The top reply: "You're not wrong. You're just going to be unemployed and right."

That, in one sentence, is the Chinese developer AI anxiety in a nutshell.

Fear #2: The 35-year-old cliff is scarier than AI

If you're a Chinese developer over 30, you already know this term: the 35-year-old cliff (35岁危机).

It refers to a widely discussed concern that age can narrow opportunities in parts of the technology job market. The reality varies by company, role, city, and individual situation, but the concern is familiar enough that it shapes career decisions well before someone reaches 35.

AI did not create this fear. I heard versions of it from more experienced developers when I was a junior, and it still comes up whenever people talk about layoffs, career changes, or whether to keep specializing.

What AI changes is the feeling of how quickly the market can move.

If AI helps a less experienced developer complete more routine work, it can make the usual questions about experience, cost, and speed feel more immediate. That does not prove that AI creates an age cliff, but it can make an existing anxiety sharper.

That is why I see people say versions of: "I'm more worried about turning 33 than about GPT-5." They are not necessarily dismissing AI. They are ranking it alongside the pressures that already affect their jobs.

In conversations I have had, layoffs are usually discussed in terms of budgets, business changes, and cost. AI becomes part of that discussion because it may change what a smaller or cheaper team can deliver.

Fear #3: The "am I still a real developer" question is less common here

Here's a question you see constantly in English-language AI discourse: "If AI writes my code, am I still a real developer?"

I have read this framing many times. I see it much less often in the Chinese communities I follow.

Why? I think it comes down to how developer identity gets built in each context.

In some English-language open source and indie-hacking circles, the craft of writing code is closely tied to developer identity: typing the solution, understanding every line, and being able to recreate the stack from scratch. AI can feel disruptive because it puts a layer between the developer and the code.

In the Chinese teams and communities I know, the balance often tilts more toward outcomes: shipping the product, meeting the deadline, and getting through the release. If a tool helps a team move faster, people are usually willing to try it. That does not make the code less important; it changes what gets emphasized in day-to-day work.

Neither orientation is better. They simply put the pressure in different places. The equivalent concern I hear more often is: "If AI removes my speed advantage, what is my edge now?"

Fear #4: The tool reality is different here too

One assumption that does not travel well is that GitHub Copilot is the default tool for every Chinese developer. In the communities I know, it is not.

Network access and payment can add friction to some international tools. Developers I know use domestic alternatives — Tongyi Lingma (Alibaba's AI coding assistant), CodeGeeX (from Zhipu AI), or chat interfaces such as DeepSeek, Qwen, and GLM — alongside international tools. The stack often looks different from the "Cursor + Copilot + Claude" setup treated as a default in some English-language discussions.

This matters because the day-to-day AI experience can be less integrated than some product demos suggest. A multi-tool workflow — code completion in one place, chat-based debugging in another, then copying a revised function back into the codebase — has different costs and risks from an AI-native IDE workflow.

The gap between what a model can do in a demo and what it can do reliably in a real workflow still matters. That gap shapes both productivity and anxiety.

Fear #5: Work that resists neat automation

Many developer jobs sit outside big tech: small and medium companies, outsourcing teams, and traditional industries going through digital transformation. In China, this is often discussed as part of the sinking market (下沉市场).

These jobs often look nothing like the clean "AI is replacing us" narrative. The codebase may be old, requirements may change in conversation, and important business rules may exist only in the head of the one senior dev who's been there since 2015 and never documented anything. The system can be several applications connected by manual work and a shared spreadsheet.

Current AI tools do not remove the work of sitting in meetings, clarifying what a client means, and turning incomplete business context into a workable specification. That work is not only about writing code. It is about translating a moving, sometimes contradictory business situation into decisions a team can implement.

That complexity can limit what automation changes in the short term. It does not make those jobs safe, and it does not make the work less skilled. It means AI adoption looks different when the bottleneck is unclear ownership, incomplete requirements, or business context rather than typing speed. In other words: the automation can't even figure out what the job is. That's a different kind of moat.

So what are Chinese developers actually afraid of?

Not AI alone, and not always in the "will a model replace me" framing common in some English-language discussions.

The concerns I hear most often are speed — how quickly AI can narrow an existing advantage — age, and refusing to adapt. In a competitive market, standing still rarely feels neutral.

If you're a developer reading this from outside China and feeling the same existential dread about AI, here's what I'd offer from inside the Chinese dev bubble:

Ask a more concrete question. Instead of only asking "will AI replace me?", ask: "Where could AI make someone else faster than me, and where would it not?"
Rank your threats honestly. AI might be far down your list. Ageism, burnout, refusing to learn — those might be closer.
Pick a tool and actually use it for a week. Not to replace yourself. To see the gap between what AI can do and what it does do in your real workflow. The gap is where you live.
Invest in work that still needs judgment. Business context, communication, and the ability to leave a confusing meeting with a usable specification remain valuable, whether or not AI makes implementation faster.

The Chinese developer communities I know are not less concerned about AI. The concern is often shaped by a different labor market, different tools, and different day-to-day constraints. And the monster we're actually afraid of? It's usually the one that shows up.

I'm a frontend developer based in China, writing Dual-Track Dev — a blog about Chinese developer tools and trends for a global audience. If you're navigating the same AI anxiety from wherever you are, drop a comment. I read every one.

AI Won't Kill Your AI Won't Kill Your Motivation. But Mediocrity Might.

XiaoMoDern — Sat, 08 Aug 2026 03:49:34 +0000

My last post did something I didn't expect.

I wrote about AI killing my motivation, thinking it might get a few quiet nods from people feeling the same way. Instead, around 180 people read it in a day, some of you followed, and the comments turned into a much better conversation than I expected.

I'm still not entirely sure why. Maybe it hit a nerve. Maybe the timing was right and a lot of people were already sitting with the same discomfort. Could be both. I don't know.

A lot of people came back to the same question: are we still pilots, or are we becoming passengers while the autopilot does the flying?

There was one part of that conversation I didn't really address in the first post. Or maybe I was avoiding it. I'm still not sure which.

For many developers, the uncomfortable feeling is not just about what AI can do. It is about what AI makes harder to hide.

Before tools like ChatGPT and Copilot, it was possible to spend a long time getting by on familiar patterns. Learn React. Learn a framework. Build dashboards. Wire up forms, state, tables, APIs, and permissions.

That work matters. Products need it. But a lot of it is repetitive.

For a long time, being quick at repetitive work could still feel like being highly skilled. There was enough work around, and the difference between "competent" and "exceptional" was not always obvious.

AI changed that. Or it's changing that — I can't tell how fast, honestly.

It can now produce a first pass at the boilerplate, CRUD screens, common component patterns, and code you have written many times before. Not perfectly, but quickly enough that the old advantage starts to feel less valuable.

That part stings. I think that's the core of it.

That can be unsettling, especially if most of your growth has happened inside that category of work. Maybe "unsettling" is too soft. For some people I've talked to, it's been closer to devastating. And I get it.

I do not think that means people are useless or deserve to be replaced. At least I hope it doesn't. That would be a pretty bleak way to look at an entire profession.

I think it means many of us, myself included, discovered that parts of our skill set were narrower than we wanted to admit.

We confused speed with depth. I know I did. I still catch myself doing it.

The developers who seemed least shaken by AI were not necessarily the best at typing code. They were the ones already spending time on harder problems: understanding messy business rules, challenging vague requirements, making trade-offs, debugging production failures, and deciding what not to build.

I've met a few of these developers. They're not always the loudest in the room. Sometimes they're the quietest. They ask one question in a planning meeting and suddenly everyone realizes they've been solving the wrong problem for two days. That kind of thing.

When Copilot arrived, they did not see their whole job disappearing. They saw a way to spend less time on the predictable parts of it.

Tanay made a good point in the comments on the last post. He described AI as an autopilot. It can handle a lot when conditions are stable, but you still need someone who understands the route, recognizes bad weather, and knows what to do when the plan stops working.

That analogy stuck with me. I've turned it over a few times since.

The uncomfortable part is this: if you have only trained for clear weather, AI makes that obvious very quickly.

It did for me. Still does, if I'm being honest.

I sat with that for a while. So what do we actually do about it?

The distinction I keep coming back to is not "AI writes code and humans make decisions." That is too simple. AI can help with decisions too. It can surface options, explain trade-offs, and point out risks I missed. Actually, maybe I'm the one overcomplicating this. Let me try again.

Here's what I keep noticing: give AI a clearly defined problem and it can usually produce a useful starting point. Ask it whether the problem is worth solving, whether your team is accepting the wrong constraint, or whether a shortcut will become painful six months from now, and the answer depends on context it does not truly own.

It does not sit in the meeting when a stakeholder changes the goal halfway through the conversation. It does not carry the consequences when a technical decision creates maintenance work for the rest of the team. It does not know which compromise is acceptable for your product, your users, or your company.

That responsibility is still ours. For now, at least. I don't know what happens in five years, and anyone who tells you they do is guessing.

The developers I see doing well are not simply writing less code. They are getting better at framing problems before code exists.

They read more code. They ask better questions in planning. They clarify requirements that sound obvious but are not. They learn enough about the business to recognize when a technically clean solution solves the wrong problem.

That is not glamorous work. A good decision in a meeting does not show up as a polished screenshot or an impressive GitHub diff.

But it changes what gets built. I think. I'm still figuring out how to measure that.

I am still figuring this out myself. Some days I worry that I am not learning fast enough. Other days I look at what I shipped last month and realize that, without AI, it would have taken a much larger chunk of my time.

Maybe that's the whole thing right there. Not getting faster at the old work. Getting better at the new work that the old work was taking time away from.

The goal is not to compete with AI at the tasks it was designed to accelerate.

The goal is to use that time to become better at the parts of the job that need judgment: understanding people, understanding systems, spotting bad assumptions, and taking responsibility for the outcome.

AI did not kill my motivation.

It made me look more honestly at where my motivation came from, what I was actually good at, and what I still need to learn.

That part is uncomfortable. But it is also useful. At least I keep telling myself that.

I'm a frontend developer based in China, building Dual-Track Dev — a blog about Chinese developer tools and trends for a global audience. If you're navigating the same AI anxiety, reach out or drop a comment. I'd love to hear how you're handling it.

AI Didn't Kill My Motivation — Here's How I Use It as a Frontend Productivity Weapon

XiaoMoDern — Thu, 06 Aug 2026 09:35:02 +0000

The anxiety is real — and it's everywhere

Open any Chinese developer community right now — Juejin, Major, or WeChat groups — and you'll see the same posts dominating the timeline:

"AI is already writing better code than I can. What's the point of practicing anymore?"
"I've lost all motivation to learn. AI knows everything I know, and more."
"Frontend development is a dead-end career. Start pivoting now."

These posts routinely get hundreds of comments. The sentiment is unmistakable: a generation of developers who feel like they're watching their own obsolescence in real time.

I know because I was one of them.

Three months ago, I was staring at a Cursor-generated component that was cleaner than anything I'd written all week. The sinking feeling hit hard — what am I even doing here?

But then something shifted. And it wasn't because I ignored the AI wave. It was because I started using it.

The mental reframe: AI is not your replacement — it's your force multiplier

Here's the thing nobody tells you when you're deep in the anxiety spiral: AI is the best thing that has ever happened to a curious developer.

Yes, it can solve the LeetCode problem you're stuck on. Yes, it can generate a pixel-perfect landing page from a screenshot. But here's what it can't do:

Understand your team's business logic from a one-line Slack message
Decide that the shiny new framework will actually be a maintenance nightmare six months in
Push back on a bad product decision because you've seen this pattern fail before
Build trust with stakeholders who need a human to say "I'll own this"

Those things? That's the actual job. The code was always the easiest part.

Once that clicked, my motivation didn't die — it redirected. Instead of proving I could write every line myself, I started asking: what's the highest-leverage thing I can do right now that AI can't?

My actual daily workflow (tools and real scenarios)

I'm a frontend developer working on a side project — an English-language tech blog that covers Chinese developer tools and trends. Here's how AI fits into my week.

UI prototyping: v0 / bolt.new

When I need to go from "rough idea" to "something I can click through," I use v0 (Vercel's AI UI generator). A typical session:

Prompt: "Create a blog post page with a dark mode toggle, reading progress bar,
and a sidebar with category tags. Use Tailwind CSS and a clean typography design."

15 seconds later, I have a responsive page. But here's the key — I don't copy-paste the whole thing. I cherry-pick the parts I like, refactor them into my existing component structure, and adjust the design tokens to match my system.

Time without AI: ~90 minutes of writing layouts, tweaking spacing, debugging responsive breakpoints.

Time with AI: ~20 minutes — and most of that is me thinking about what I actually want.

Code review and debugging: ChatGPT / Claude

I treat ChatGPT like a senior engineer who's always available for a quick review:

"Here's my Astro component. The build passes but the dark mode flickers on first load. Spot the race condition."
"I'm using this Tailwind config. Is there a cleaner way to define these custom spacing tokens?"
"Review this TypeScript type definition — am I over-engineering this?"

In every case, I'm not asking AI to do my job. I'm asking it to accelerate my learning. The output goes through my judgment, and I only apply what makes sense.

Code completion: Tongyi Lingma / Continue

For routine coding — wiring up APIs, writing boilerplate components, filling in TypeScript types — I use AI code completion as my auto-pilot. It handles the predictable 60% so I can focus on the tricky 40%.

The rule I follow: if the AI suggestion makes me think instead of just nodding, I type it myself. Because that's where the learning happens.

Content creation: ChatGPT + DeepL

For my side blog (an English-language site covering Chinese developer tools), I use a translation-refinement pipeline:

Rough translation via DeepL from Chinese source material
ChatGPT rewrites for natural English technical writing
I do a final 10-15 minute review — fixing terminology, adding personal insight, and making sure the voice actually sounds like me

This pipeline turned a 4-hour-per-article process into 45 minutes. I'm not publishing AI-generated slop — I'm publishing my own analysis, just skipping the slowest part of the writing process.

The numbers: AI vs no-AI, same project

I tracked roughly how my side project changed before and after integrating AI into the workflow:

Task	Pre-AI	Post-AI	Leverage
Write and publish one blog post	3-4 hours	45-60 minutes	~4x
Build a new page from scratch	90 minutes	20 minutes	~4.5x
Debug a tricky layout issue	30-60 minutes	5-15 minutes	~4x
Review own code for bugs	15 minutes	2 minutes (AI flag, then verify)	~7x
Weekly total (side project)	6-8 hours	2-3 hours	~3x

I'm shipping more, learning faster, and — critically — enjoying it more. Because I'm spending less time in CSS grid debugging hell and more time actually thinking about what I want to build.

The real threat isn't AI — it's refusing to adapt

Here's my honest take, three months into this experiment:

AI won't kill your motivation. It will kill the motivation of developers who measure their worth by how many lines of code they wrote today.

If your identity as a developer is "I can type React components faster than anyone," then yes — AI is a threat to you. But that was never the valuable part of the job.

The valuable parts:

Understanding the problem before writing a single line
Knowing which tool or approach to use, and why
Communicating trade-offs to non-technical stakeholders
Building things people actually want to use

AI doesn't touch any of that. It makes the easy parts faster so you can spend more time on the hard parts that actually matter.

So what now?

If you're feeling the same anxiety I felt, here's what worked for me:

Stop doom-scrolling AI replacement threads on Twitter/Reddit. They're dopamine traps, not information sources.
Pick one AI tool and actually use it for a week. Not to replace yourself — to see what it can and can't do. The gap is where you live.
Shift your metric of success. Stop counting lines of code. Start counting problems solved, decisions made, things shipped.
Invest in what AI can't do: business understanding, system design judgment, communication, taste.

AI is a tool. A really, really good tool. And tools don't replace craftsmen — they make them more dangerous.

DeepSeek V4 Is Now the 'Kill Line' of AI Models — Here's What That Means

XiaoMoDern — Tue, 04 Aug 2026 03:40:05 +0000

On the last day of July, DeepSeek finally shipped V4 Flash-0731 — a 284B-parameter model that, according to early benchmarks, outperforms GLM-5.2 and trades blows with Anthropic's Opus 4.8. The Chinese developer community, which had been roasting CEO Liang Wenfeng as "Little Liang" during the delay, immediately restored his honorific: "Saint Liang."

But the V4 Flash isn't just another model release. It's triggered a concept that's spreading fast through Chinese AI circles: the kill line. And once you understand it, it changes how you think about the entire LLM market.

What Is the "Kill Line"?

The term originated from gamers — in RPGs, the kill line is the damage threshold above which you one-shot an enemy. In the AI context, it works like this:

If your model is both more expensive AND lower-performing than DeepSeek V4 Flash, you are below the kill line. Your model is dead.

A developer plotted it cleanly using Artificial Analysis data. Take every major model, chart them by price against performance score, and draw a rectangle anchored at DeepSeek V4 Flash's position. Everything in the bottom-right quadrant? Killed.

The Performance-Price Matrix

Here's how the battlefield looks after July 31:

Below the kill line (worse + more expensive): Most mid-tier models, legacy proprietary APIs. Dead.
Left of the kill line (cheaper): GPT-5.6 Luna (just cut price 80%), Xiaomi MiMo-V2.5. Surviving on price alone.
Top-right safe zone (better, more expensive): Kimi K3, Opus 5, Opus 4.8, GPT-5.6 Sol — and only in Max/High thinking mode.

The only models that escape either slashed prices by 80% or need to run in their most expensive thinking modes. For a 284B-parameter model to force that response from models with 5x the parameters? Unprecedented.

What Makes V4 Flash-0731 Special

Parameter efficiency that shouldn't work. 284B is mid-range. Opus 5 runs at ~1T+. GPT-5.6 Sol is in that ballpark. Yet V4 Flash is within striking distance. If DeepSeek has cracked something fundamental about training efficiency, the implications go far beyond one release.

The pricing is the weapon. DeepSeek has always competed on price, but V4 Flash makes it existential. Competitors face three bad options: match the price and lose money, stay premium and watch users migrate, or do nothing and fall below the kill line.

The kill line moves every quarter. V4 Flash-0731 revives DeepSeek's date-stamped versioning. Post-training improvements ship on a 2-3 month cadence. Every release raises the floor.

What This Means

The middle tier is collapsing. You're either competing at the absolute top or competing on being cheaper than DeepSeek. No comfortable middle.

Open-source absorbs the kill line. DeepSeek's weights are available. The kill line becomes the new floor for the entire open-source ecosystem — every fine-tune, every enterprise deployment, every local setup.

The English-language gap. DeepSeek's docs, community, and ecosystem are still heavily Chinese-language. For Western developers, the onboarding friction is real. The kill line exists, but accessing it requires crossing a language barrier most won't bother with.

What We Don't Know

V4 Pro is coming within weeks alongside DeepSeek's Harness agent framework, with roughly 5x the parameters of Flash. If Flash is already pushing Opus 4.8 territory, Pro could realistically challenge Opus 5 and GPT-5.6 Sol. The kill line is about to move up again.

Real-world performance vs benchmarks is still an open question. Leaderboards don't capture long-context reasoning, tool use, or agentic behavior. The real test is production workloads.

The Bottom Line

DeepSeek V4 Flash isn't just an impressive model. It's a market-making event. The kill line concept resonates because it captures something true: when a model this capable ships at this price point, it doesn't just compete — it redefines what competition means.

If you haven't tested DeepSeek V4 yet, you're making decisions based on outdated assumptions. If you're running an AI company, check your position on the chart. If you're in the bottom-right quadrant, you have until the next DeepSeek release.

The kill line moved on July 31. It's moving again soon.
https://technical-blog-ashen.vercel.app/blog/deepseek-v4-kill-line/

LobeChat: The 60K-Star Open-Source ChatGPT Alternative Nobody Talks About (And Why It Matters)

XiaoMoDern — Mon, 03 Aug 2026 06:37:59 +0000

I found it by accident. A Chinese developer friend mentioned "this chat tool everyone uses in China," and I expected another ChatGPT wrapper. What I found instead was a project with 60,000 GitHub stars that I'd never seen mentioned on Dev.to, Hacker News, or Reddit. Not once.

That project is LobeChat, and after deploying it and comparing it head-to-head with ChatGPT, LibreChat, and a few others, I think it deserves a real review in English.

What Is LobeChat?
LobeChat is an open-source chat interface for large language models, built by the LobeHub team in China. Think of it as your own private ChatGPT UI—except you control everything: which models to use, where your data lives, and how the interface behaves.

Under the hood: Next.js 14 + Ant Design, streamed through Server-Sent Events, packaged into a single Docker container.

Metric	Value
GitHub Stars	~60,000
LLM Providers	20+
UI Languages	15+
Plugins	50+
Deployment	Docker / Vercel / Zeabur / SealOS

The Core Pitch: Why You'd Want This

Multi-Provider Support (Not Just OpenAI) This is the killer feature. LobeChat doesn't tie you to one model. You can configure:

OpenAI (GPT-4, GPT-4o)
Anthropic (Claude 3.5 Sonnet, Claude Fable)
Google Gemini (Gemini 1.5 Pro)
DeepSeek (R1, V3)
Ollama (Llama, Mistral, Qwen — local models on your own hardware)
Azure, Bedrock, Groq, Perplexity, and 10+ more
And here's the kicker: you can switch models mid-conversation. Compare GPT-4 and Claude on the same prompt in seconds:

Click provider icon → Select different model → Retry query
No restart. No page reload. Each conversation remembers its provider.

Self-Hosted. Your Data, Your Rules. docker run -d -p 3210:3210 \ -e OPENAI_API_KEY=sk-xxx \ -e ACCESS_CODE=your-password \ --name lobe-chat \ lobehub/lobe-chat:latest That's it. Ten minutes from zero to a fully functional ChatGPT alternative running on your infrastructure. If your company has data residency requirements, this is a checkbox ChatGPT can't tick.

For teams, there's a Docker Compose setup with PostgreSQL for persistent conversation history and multi-user access control.

Plugin System With Real Capabilities LobeChat uses a manifest-based plugin architecture. Plugins declare their capabilities in a manifest.json and run in sandboxed iframes. The marketplace has ~50 plugins today, covering:

Web search (Google, Bing, SearXNG)
Code interpreter (execute Python, JS, SQL)
Image generation (DALL-E, Stable Diffusion)
Weather, news, calendar integration
MCP (Model Context Protocol) support — one-click install from the MCP marketplace
Writing custom plugins is straightforward: define the manifest, implement your API calls, and the chat UI renders it as an interactive tool. If you've worked with OpenAI function calling, the mental model transfers directly.

PWA: Install It Like a Native App
LobeChat ships as a Progressive Web App. On mobile, tap "Add to Home Screen" and it behaves like a native chat app—offline support, push notifications, full keyboard shortcuts. The desktop PWA experience is nearly indistinguishable from the ChatGPT desktop app, minus the electron bloat.
Actually Good Design
Open-source tools often look like open-source tools. LobeChat doesn't. The UI is polished, with custom themes (Dark mode is excellent), responsive layouts, and a chat experience that consistently matches or exceeds ChatGPT's own interface.

Built on Ant Design, it inherits a mature design system with consistent component behavior and accessibility. The team clearly has strong design sensibilities—unsurprising, given that the same group maintains Lobe UI, a popular React component library.

Comparison: LobeChat vs. The Rest

Feature	LobeChat	ChatGPT Web	LibreChat
LLM Providers	20+	OpenAI only	10+
Plugins	MCP + manifest, 50+	1000+ GPTs	Basic tools
PWA Support	Full	None	Partial
Multi-Language	15+	10	5
Self-Hosted	Yes	No	Yes
Built-in RAG	Via plugin	In GPTs	Yes, built-in
Mobile Experience	PWA, native-like	Responsive	Responsive
Theme Customization	Full	None	Minimal
Open Source	Yes (Apache 2.0)	No	Yes

The honest tradeoff: LibreChat has built-in RAG (document upload with vector search). LobeChat handles knowledge base functionality through plugins instead. If uploading PDFs and querying them is your primary use case, LibreChat might be the better fit today. For everything else—UI quality, provider flexibility, plugin ecosystem, mobile experience—LobeChat leads.

Why Haven't You Heard of It?
This is the most interesting part. LobeChat has 60,000 GitHub stars, an active community, and a polished product. Yet searching for "LobeChat review" in English returns almost nothing.

The reason is simple: language barrier and community separation.

LobeChat's documentation, community, and contributors are predominantly Chinese-speaking. The GitHub README exists in both English and Chinese, but discussions happen on Chinese forums. The English-language AI community simply hasn't discovered it yet.

This pattern repeats. Dify, another Chinese open-source project (LLM application builder), followed the same trajectory—explosive growth in China, near-invisible in English-speaking circles, then a slow burn of international adoption.

For developers willing to cross the language barrier, this is an information arbitrage opportunity: you get a tool that's battle-tested by a massive user base, while most English-speaking developers are still evaluating half-baked alternatives.

Limitations: Where LobeChat Falls Short
Honesty time.

No built-in RAG. You can't upload a PDF and ask questions about it without a plugin. The roadmap mentions native RAG, but today it requires extra setup.

Young plugin ecosystem. ~50 community plugins vs. ChatGPT's thousands. Building custom plugins requires understanding the manifest schema, though it's well-documented.

Rate limiting for free API tiers. If you're using a free-tier API key (OpenAI trial credits, etc.), LobeChat itself adds no rate limiting—but your provider will.

Chinese-leaning defaults. Fresh install defaults to some Chinese-language settings. One-minute fix in Settings → Language, but worth noting.

Who Should Use LobeChat?

Use Case	Recommendation
Individual developer tired of $20/month ChatGPT	Yes. Pay only for API usage.
Small team needing shared AI access	Yes. Docker Compose + multi-user mode.
Company with data residency requirements	Yes. Self-hosted. Data stays on your servers.
User who frequently switches between Claude, GPT, Gemini	Yes. Provider switching is the core UX.
Someone who primarily does document Q&A with RAG	Maybe. Use LibreChat if RAG is your main workflow.
Non-technical user who wants zero setup	No. Stick with ChatGPT.

The Bottom Line
LobeChat is not "ChatGPT but Chinese." It's "what ChatGPT could be if it were open-source, provider-agnostic, and designed for people who control their own infrastructure."

The 60,000-star GitHub count isn't hype. It reflects a real product solving real problems for a large user base. The only reason it hasn't crossed into the English-speaking dev world is visibility, not quality.

If you've been looking for a self-hosted AI chat interface that doesn't feel like a downgrade from ChatGPT's UI, deploy LobeChat tonight. It costs nothing but a Docker container and an API key you probably already have.

WeChat Mini Programs: The App Store Inside a Messaging App (and Why the West Has Nothing Like It)

XiaoMoDern — Fri, 31 Jul 2026 02:26:18 +0000

If you've never used WeChat, this will sound absurd: inside a messaging app, you can file your taxes, book a doctor's appointment, order groceries, play AAA-quality games, apply for a visa, and pay for street food — all without installing a single additional app.

These are WeChat Mini Programs, and they handle over 900 million monthly active users. Yet most Western developers and product managers barely know they exist.

What Is a Mini Program, Exactly?

A Mini Program is a sub-application that runs inside WeChat. Think of it as a lightweight app that doesn't need to be downloaded from an app store. Users open it by scanning a QR code, tapping a link in a chat, or searching within WeChat itself.

	Native App	WeChat Mini Program
Installation	App Store / Google Play	None — opens instantly
Size limit	No limit (typically 50-300MB)	20MB (2MB for the initial package)
Payment	Apple/Google 30% cut	WeChat Pay, 0.6% fee
User acquisition	ASO, ads, word of mouth	QR codes, group sharing, official accounts
Development	Native (Swift/Kotlin) or cross-platform	WeChat's proprietary framework (WXML + WXSS + JS)
Discovery	App Store search	Search within WeChat, location-based discovery

The 20MB size limit is intentional. It forces Mini Programs to be focused, fast, and single-purpose. Users scan a QR code, the app loads in 2-3 seconds, and they complete their task in under a minute.

How Big Is This, Really?

Tencent publishes figures annually. As of their latest report:

Metric	Number
Monthly active Mini Program users	900M+
Daily active Mini Programs	3M+
Total Mini Programs created	4.5M+
Annual transaction volume	¥10 trillion+ (~$1.4T USD)
Industries covered	200+ categories

To put that transaction volume in perspective: the entire global app store economy (Apple App Store + Google Play) did roughly $170 billion in 2024. WeChat Mini Programs processed over 8 times that.

Why Can't WhatsApp or iMessage Do This?

Three structural reasons:

1. Payments Aren't Built-In (in the West)

WeChat Pay is embedded at the OS level of WeChat. Tapping a Mini Program's "pay" button completes the transaction inside the app — no redirect to Stripe, no Apple Pay sheet, no credit card form. The payment infrastructure is woven into the chat app itself.

In the West, WhatsApp Pay exists in India and Brazil, but nowhere near the scale of WeChat Pay. Apple's iMessage has Apple Pay, but it's a transfer mechanism, not a commerce platform. The payment layer is what turns a chat app into a marketplace.

2. QR Codes Are Infrastructure, Not an Afterthought

In China, QR codes are everywhere — restaurant menus, street vendor carts, bus stops, hospital registration desks. Each code opens a specific Mini Program. This transforms physical-world touchpoints into digital entry points.

Western platforms have never treated QR codes as first-class infrastructure. Apple only added a QR scanner to the iPhone camera in iOS 11 (2017). By then, WeChat had already processed billions of QR code interactions.

3. Regulation and Lock-In

China's mobile ecosystem is dominated by a handful of super apps. Regulatory choices made Mini Programs a natural solution. Why fight app store approval when you can launch inside WeChat in 24 hours?

The West's anti-trust environment and Apple's walled garden make a WeChat-like ecosystem politically and technically near-impossible.

What Actually Runs on Mini Programs?

Not just games and shopping. Here's a sample of what Chinese users do without leaving WeChat:

Category	Examples
Government services	Tax filing, social security, visa applications, marriage registration
Healthcare	Hospital appointments, prescription refills, health codes
Transportation	Metro card top-up, bike sharing, train/flight booking
Food	Restaurant ordering, delivery, table QR code menus
Finance	Bank account opening, insurance claims, stock trading
Education	Homework submission, parent-teacher communication, online courses
Retail	Nike, Uniqlo, IKEA — all have Mini Programs that mirror their apps

The Chinese government actively pushes Mini Programs for public services. During COVID, the health code system — which every citizen needed to enter any building — was a Mini Program. That alone onboarded hundreds of millions of users who had never used an app before.

What This Means for Businesses Outside China

If you're a brand entering the Chinese market, you don't need to build an iOS app, an Android app, and maintain both. A single WeChat Mini Program covers both platforms, handles payments natively, and leverages WeChat's built-in sharing mechanics for organic growth.

Luxury brands figured this out early. Louis Vuitton, Gucci, and Burberry all run Mini Programs that handle product browsing, appointment booking, and direct purchase — without directing users to a separate app or website.

For SaaS companies: the Mini Program model is worth studying even if you can't replicate it. The core insight is that users don't want more apps — they want less friction. A 20MB sub-app that opens in 2 seconds and already has the user's payment info beats a 200MB download and a 5-step checkout.

Will the West Ever Get Something Like This?

Short answer: not in the current regulatory and platform environment.

Long answer: there are partial approximations. Telegram's bots handle payments and mini web apps. Discord's app directory lets bots integrate deeply. Apple's App Clips let you use a small part of an app without installing it. But none of them combine payment, identity, social sharing, and offline-to-online bridging the way WeChat does.

The super app model requires a willingness to let one company control payments, identity, distribution, and discovery — and neither Silicon Valley nor Brussels seems comfortable with that.

Key Takeaways

WeChat Mini Programs are not "apps within an app" — they're an alternative app economy with 900M+ users and $1.4T in annual transactions
The combination of built-in payments, QR code infrastructure, and regulatory alignment makes them uniquely Chinese
Western platforms lack the payment and identity layer necessary for a similar ecosystem
For foreign businesses, a Mini Program is often more effective than a native app for reaching Chinese consumers

The Mini Program isn't a feature — it's a platform strategy that redefined what a messaging app can be.

Originally published at Technical Blog

Getting Started with Ant Design — Build Your First React UI in 15 Minutes

XiaoMoDern — Thu, 30 Jul 2026 09:34:33 +0000

What Is Ant Design?

Ant Design (antd) is a React UI library built by Alibaba's Ant Group. It's the most starred React component library on GitHub from China, with over 90k stars — yet surprisingly undercovered in the English-speaking developer community.

If you've used Material UI or Chakra UI, Ant Design is the Chinese equivalent, but with its own design philosophy: consistent, predictable, and packed with enterprise-grade components out of the box.

Fun fact: Alibaba, Tencent, Baidu, and most Chinese tech companies use Ant Design in production. It powers dashboards that serve hundreds of millions of users.

Why Ant Design Over MUI?

Feature	Ant Design	Material UI
Components	60+	50+
Table (Pro)	Built-in sorting, filtering, pagination, row selection	Requires manual wiring
Form validation	Declarative, built-in	Requires react-hook-form or Formik
Tree-shaking	Supported (v5)	Supported
Bundle size (min)	~200KB gzipped	~140KB gzipped
Documentation	Chinese-first, English translations available	English-first
Design system	Ant Design System (custom)	Material Design (Google)

Ant Design wins on out-of-the-box productivity — especially for data-heavy apps like admin panels and dashboards. MUI wins on bundle size and first-party English docs.

Installation

npm install antd @ant-design/icons

No peer dependencies beyond React 16+.

Your First Ant Design Component

import React from "react";
import { Button, Space } from "antd";
import { SearchOutlined, DownloadOutlined } from "@ant-design/icons";

export default function App() {
  return (
    <Space>
      <Button type="primary" icon={<SearchOutlined />}>
        Search
      </Button>
      <Button icon={<DownloadOutlined />}>Download</Button>
      <Button type="dashed">Dashed</Button>
      <Button type="link">Link</Button>
    </Space>
  );
}

That's it. Five button variants with zero CSS.

Building a Data Table in 5 Minutes

import React, { useState, useMemo } from "react";
import { Table, Input } from "antd";

const data = [
  { key: "1", name: "John Doe", role: "Frontend", team: "Web" },
  { key: "2", name: "Jane Smith", role: "Backend", team: "API" },
  { key: "3", name: "Li Wei", role: "DevOps", team: "Infra" },
  { key: "4", name: "Sarah Chen", role: "Frontend", team: "Mobile" },
];

const columns = [
  { title: "Name", dataIndex: "name", sorter: (a, b) => a.name.localeCompare(b.name) },
  {
    title: "Role",
    dataIndex: "role",
    filters: [
      { text: "Frontend", value: "Frontend" },
      { text: "Backend", value: "Backend" },
      { text: "DevOps", value: "DevOps" },
    ],
    onFilter: (value, record) => record.role === value,
  },
  { title: "Team", dataIndex: "team" },
];

const searchStyle = { width: 240, marginBottom: 16 };
const pageConfig = { pageSize: 3 };

export default function TeamTable() {
  const [search, setSearch] = useState("");
  const filtered = useMemo(
    () => data.filter((item) => item.name.toLowerCase().includes(search.toLowerCase())),
    [search]
  );
  return (
    <>
      <Input
        placeholder="Search by name..."
        value={search}
        onChange={(e) => setSearch(e.target.value)}
        style={searchStyle}
      />
      <Table columns={columns} dataSource={filtered} pagination={pageConfig} />
    </>
  );
}

This gives you column sorting, filtering, client-side search, and pagination — in under 50 lines.

Forms That Actually Make Sense

import React from "react";
import { Form, Input, Button, Select, message } from "antd";

const formStyle = { maxWidth: 400 };

export default function SignupForm() {
  const [form] = Form.useForm();
  const onFinish = (values) => {
    console.log("Form values:", values);
    message.success("Signup successful!");
  };
  return (
    <Form form={form} layout="vertical" onFinish={onFinish} style={formStyle}>
      <Form.Item label="Email" name="email" rules={[
          { required: true, message: "Please enter your email" },
          { type: "email", message: "Invalid email format" },
        ]}>
        <Input placeholder="you@example.com" />
      </Form.Item>
      <Form.Item label="Password" name="password" rules={[
          { required: true, message: "Please enter a password" },
          { min: 8, message: "Must be at least 8 characters" },
        ]}>
        <Input.Password />
      </Form.Item>
      <Form.Item label="Role" name="role" rules={[{ required: true, message: "Please select a role" }]}>
        <Select options={[
          { value: "dev", label: "Developer" },
          { value: "designer", label: "Designer" },
          { value: "pm", label: "Product Manager" },
        ]} />
      </Form.Item>
      <Form.Item>
        <Button type="primary" htmlType="submit" block>Create Account</Button>
      </Form.Item>
    </Form>
  );
}

Key advantages: rules array handles all validation declaratively, error messages appear automatically, no useState for form state.

Theming in 3 Lines

import { ConfigProvider, theme, App } from "antd";

const customTheme = {
  algorithm: theme.darkAlgorithm,
  token: {
    colorPrimary: "#00b96b",
    borderRadius: 6,
  },
};

export default function ThemedApp() {
  return (
    <ConfigProvider theme={customTheme}>
      <App />
    </ConfigProvider>
  );
}

The entire antd component tree inherits the theme. No CSS overrides needed.

When to Use Ant Design
Use Ant Design when... Skip it when...
Building admin panels / dashboards Building a marketing landing page
Need tables, forms, data entry out of the box Need a lightweight blog or docs site
You value productivity over bundle size Every KB counts
Ant Design might be China's best-kept secret in the React ecosystem. Now you know.

Originally published at Technical Blog(https://technical-blog-ashen.vercel.app/blog/getting-started-with-ant-design)