Things I Dislike

• Humans

• Coffee

• Procedures

• Documents

• Kind of Blue

• Human relationships

• Disloyalty

• Monster Energy

• Classical music

• Social norms

• Putting on a false front

• Doing things against the law

• Private ownership

• Playing the victim

• Parents

• Forced chumminess

• Inconsistent words and actions

• Violence

• Clean internet

• Wakaba

• Socializing

• Lies

• Sales

• "It's all about balance" guys

• Alcohol that tastes too much like alcohol

• Fatty meat or fish that could give me heartburn

• Beer

• Bright people

• Noisy eaters

• Sticking chopsticks into the same plate (basically impossible for me)

• Sharing drinks (basically impossible for me)

• Public toilets

• Hometowns

• Discipline

• Safe choices

• Time-based promises

• Routine work

• Outrage merchants

• Getting ready to go out

• Phone calls

• Vaguely stylish vibes

• Current YOSHIKI

• People who say jazz is stylish when I say I like jazz

• Bright places

• Joining groups

• People who treat jazz as something noble

• Shaba-ness

• Insincerity

• Unreasonableness

• Crowded places

• Compromise

• Political correctness

• Liberals

• Prying

• Backbiting

• Trying to look cool

• Authoritarianism

• Art Blakey

• Rough gummy candy that gets powder all over my hands

• Lookism

• Bullying

• Lack of self-awareness

Things I Like

• Ducks

• Compilers

• Language implementations

• Computers

• Good taste

• Led Zeppelin

• Transparent watercolor

• Roasty aroma

• Cats

• Jazz, especially Contemporary Jazz

• Kurt Rosenwinkel

• Consistency

• Hip hop

• Clubs

• Cigarettes, Che is the best

• Sea urchin

• Internet far left

• The highest peak

• Fashion, I like mode fashion

• Wearing skirts

• Wearing dresses

• Good stories

• UNITED TOKYO

• Rust

• Piano Trio

• John Coltrane

• Old YOSHIKI

• Kunekune

• Researchers with good taste

• Atonal

• Music theory

• Satire

• Concepts

• Criticism

• Sense

• Thought

• Hard Fusion

• Taxonomy

• Design

• Piercings

• Interior design

• Nihilism

• Internet

• Websites

• Depas

• Red Bull

• Bromazepam

• Brad Mehldau

• Pancakes

• Oil painting

• Seven-Eleven renkon nori-shio chips

• Meat close to raw

• The firmer the noodles, the better

• White rice

• Chocolate

• Randomness

• Philosophy

• Claims

• Neologisms

• Resolve

• Decisiveness

• Ability

• Well-made things

• Vue.js

• Hostile internet

• Joke tweets

• Art

• Generative art

• Abstract painting

• Impressionism

• Tattoos

• Gags

• Looking at paintings

• Looking at album artwork

• Crepes

• Places with dim lighting

• Complex things

• Realism

• Beautiful things

• Towns with good scenery

• Alleys with good scenery

• Walks

• Pencil drawing

• Systems

Note: This article is my personal opinion and does not represent my employer. My company's blog is currently being prepared, and at the moment there was no appropriate place to publish this. Also, because the article is based on my personal concerns, I am publishing it on my personal blog. This is not meant to blame any specific company or individual. It is about whether for-profit companies that use OSS should create more financial flow toward its authors, maintainers, and core contributors.

Introduction

The lack of compensation for OSS authors, maintainers, and core contributors becomes a topic again and again. A maintainer of a library is exhausted; an important package is sustained by a very small number of people; companies around the world depend on it, yet the person behind it does not have a stable life because of that work. Whenever such stories appear, the internet becomes uneasy for a moment.

Of course, OSS is not a simple employment contract. Publishing code does not automatically mean that the author has a right to receive payment from every user, and I am not saying that every user should be forced to pay something.

However, for-profit companies are in a slightly different position. We use OSS, build products with it, improve development speed, quality, and operations through it, and create revenue on top of it. Part of that revenue eventually comes back to us as salary or profit.

If that is the case, it seems natural that companies that generate revenue by using OSS should return money to its authors, maintainers, and core contributors.

This Is Especially True In Web Frontend

I usually work around web frontend, so I inevitably see this issue through that context.

In modern web frontend development, OSS is not merely a collection of convenient tools. It is part of the premise of daily development and operations. When we prepare a development environment, maintain quality, or deliver a product, we touch OSS in many parts of the process, combine those pieces, adapt them to our own circumstances, and use them as part of our development foundation.

Of course, we also write our own code. There is design, operation, and product understanding, and I do not want to dismiss any of that. Still, much of the foundation is supported by people outside our companies. Many of them create, fix, and release things with their own time, without any direct employment or contractual relationship with us.

OSS can look like an abstract public good, but in reality, behind it there are authors, maintainers, and core contributors who review, decide direction, and fix what breaks. When we talk about who should be paid, I want to bring those people further into the foreground.

In this situation, treating corporate payment to the people who build OSS as a special act of charity feels a little unnatural. It is closer to an ordinary cost. We pay for servers, SaaS, design tools, hiring channels, and event sponsorships.

Then we should also pay the people who build the OSS we depend on.

Event Support Is More Common Than Support For Builders

In Japanese tech communities, I often see event sponsorships, and I think this is important. They pay for venues and streaming, improve the experience for speakers and attendees, create contact points between companies and communities, and support the culture in a significant way.

At the same time, compared with the number of companies whose logos appear at events, sponsorships for OSS authors, maintainers, and core contributors still feel relatively rare.

Events are visible. Logos appear, booths appear at venues, they can connect to hiring and branding, and they are easier to explain internally. By contrast, the work of OSS builders is hard to see: reading issues, writing reproduction cases, avoiding breaking changes, updating dependencies, fixing vulnerabilities, writing release notes, and absorbing subtle frustration from users.

This work is not flashy, and it is hard to observe from the outside. But if this steady work stops, our own work may suddenly stop as well.

I am not saying event sponsorships are unnecessary. I want them to continue. What I want to say is that if support tends to concentrate on events, more of it should also go toward the people who create and maintain OSS.

Maintainers Are Not Only People Inside Large Companies

Companies such as Meta, Vercel, and Cloudflare have people who work on OSS as part of their jobs. That is a wonderful thing, and it is meaningful for companies to place OSS at the center of their strategy, employ people, and move development forward.

But OSS is not sustained only by that model.

There are many maintainers who do not belong to large companies. Some work as individuals; some work at small companies and maintain projects at night or on weekends; some end up carrying major responsibility for users around the world, even though the project is not their company's product.

In fact, some OSS that I use in my daily work is created or maintained by developers who do not belong to large companies.

When we think about OSS, we tend to imagine the names of famous companies. But deep inside our dependency graphs, there are individuals whose names and faces we may not know. They are not necessarily employed by large companies, not necessarily fixing things during company time, and not necessarily living with financial room.

Even so, we use what they build to create revenue. We should look more directly at this asymmetry.

Individual Sponsorship Matters, But It Is Not Enough

I receive support from around twenty individual sponsors through GitHub Sponsors, and I am grateful for it.

It is a major source of support. It encourages me emotionally, gives me a real sense that people are watching my work, and also gives me a little more financial room.

So I do not think individual sponsorship is meaningless at all. It has a lot of meaning, and the culture of individuals supporting individuals in small amounts should spread further.

However, as a practical matter, it is difficult to live only on small individual sponsorships.

Hundreds or thousands of yen adding up is valuable. But when we consider living costs, taxes, insurance, rent, equipment, and the time needed to keep working, that alone is not enough to sustain ongoing OSS maintenance or core development participation.

This is where companies need to participate.

There are amounts that individuals cannot easily pay, but that are relatively small budgets for companies. An amount of tens of thousands of yen, which is large for an individual, can be close to one business dinner, one SaaS tool, or one hiring initiative for a company. That gap matters, and I think we should use it.

Large Recurring Sponsorship Has Risks

This point matters.

Unless a company is truly prepared for it, a single company should not provide large recurring monthly support to one author, maintainer, or core contributor.

At first glance, large recurring support looks desirable. Of course, stable funding itself is good, and it helps the person receiving it.

But if that support becomes too central to their life, the damage is large when it stops.

The company's policy may change, the person in charge may move to another role, the economy may get worse, the budget may be cut, or the company may stop using that OSS. These things can happen on the company side, but for the person receiving support, they can disrupt life and activity plans.

That is why I think corporate OSS support should be made of many thinner pillars, rather than one concentrated pillar.

One-time sponsorships should happen in a distributed way from many companies. One company supports once, then another company supports next. Once a year is fine, once a quarter is fine, and it can happen when a project releases something or when the company was helped significantly by the project.

Do not turn it into one company's beautiful story, and do not make one builder depend on one company. Support them broadly and lightly across many companies, but in amounts larger than typical individual sponsorships.

I think this shape is healthier for the economics of OSS.

Companies Can Support In One-Off Ways

When people hear that companies should pay the people who build OSS, they may imagine large programs or ongoing contracts.

But it does not have to start as an impressive program. A company can pay a library it often uses this month, a tool that helped with a major migration, a maintainer who responded carefully to an issue, a core contributor who supports important design decisions, an individual deep inside its dependency chain, or a project when a release happens.

That kind of one-time support is enough.

Even if the amount is small for a company, it can be significant for the individual receiving it. For example, support around 50,000, 100,000, or 150,000 JPY may not be excessive as a corporate budget, but for an individual author, maintainer, or core contributor, it can mean a lot.

And if that money does not come continuously from one company, but instead arrives irregularly from multiple companies, the dependency becomes softer.

Of course, accounting may be complicated, and there may be approval processes. There are many questions: whether the recipient uses GitHub Sponsors or Open Collective, whether an invoice is needed, whether it fits internal rules.

Even so, companies should work on it.

We depend on OSS too much to let procedural complexity be the reason we do nothing.

What I Brought Up At My Company

Here I want to talk a little about my employer. I usually work as Chief Engineer at Mates, Inc., a for-profit company.

Naturally, we use a lot of OSS at work. In web frontend, backend, and development infrastructure, OSS exists everywhere. Products are built on top of that, revenue is created, and some of it is paid to me as salary.

When I think about that structure, I personally feel strongly that companies should pay the people who build OSS.

However, this article does not represent the company, and it is not the company's official position. I want to separate that clearly.

With that in mind, I brought this topic up internally, because I thought that the person making the proposal should move first.

"Since we are supported by OSS, could the company also sponsor its authors, maintainers, and core contributors in one-off ways from time to time?"

That is the rough summary of what I asked, and thankfully, people inside the company agreed with it.

I do not want to frame this as an overly beautiful story. The company has not created a huge fund, and a world-changing program is not starting today. The amount will probably be small from a company perspective.

Still, I think there is meaning in starting.

Start from the place where I am, and then, if possible, involve other companies as well. Do not make it one company's admirable initiative. Make it something many companies naturally do.

That is the direction I hope we move toward.

This Is Payment More Than Charity

OSS support easily creates the impression that a company is "doing something good." It can become a story where the sponsoring company is admirable and the supporter is kind.

Of course, there is some truth to that. Supporting people is good.

But for companies, I think we can understand it more calmly.

Pay the people who build what we use, the people who maintain what contributes to our profit, and the people who support our development speed.

This is less charity than ordinary payment.

We might even say that the unnatural state was the one where we had not been paying enough.

Being able to use something for free does not mean that maintaining it costs nothing. Being able to use something for free under its license does not mean it is economically right to keep free-riding forever.

OSS is often free to use, and that is exactly why those who can pay should voluntarily pay.

Especially companies that generate revenue by using OSS.

Conclusion

For-profit companies should pay the people who build OSS.

This is not a phrase meant to attack companies. It is a phrase for looking more accurately at the foundation of our own work.

We use OSS, and OSS gives us development speed, quality, and revenue.

Then part of that should go back to OSS authors, maintainers, and core contributors.

Event sponsorships should continue, individual sponsorships should spread, and the movement of large companies employing OSS developers should continue.

On top of that, I want more for-profit companies to pay the authors, maintainers, and core contributors of the OSS they depend on, in one-off and distributed ways, with amounts a little larger than typical individual sponsorships.

Instead of one company standing too far in front, many companies should naturally pay. Instead of tying one builder to one company, many companies should support them together. Instead of treating it as decoration for hiring or branding, treat it as part of development cost.

I hope the economics of OSS move even a little in this direction.

And I want to help create that flow from the place where I am.

Note: By "make the internet messy," I do not mean harass people, spread lies, or hurt anyone. I also do not mean treating interests, politics, or people's survival lightly. I mean the opposite: lying is bad, and if you are wrong, apologize. After that, still have a claim, fight, and sharpen it.

Introduction

I am a software engineer born in 2000. I grew up watching our internet seniors fight on blogs, perform professional wrestling on Twitter, write long posts on forums and comment sections, clash over ideas at meetups, and sometimes become deeply annoying human beings. I also grew up reading 2channel on a Nintendo 3DS.

Of course, I do not want to romanticize the old internet too much. A lot of it was simply awful: there were words that hurt people, lazy assumptions, and attacks that were not funny at all. I am not asking anyone to restore that world as-is. But one thing worries me. Internet people of my generation may be too quiet.

Quietness Is A Virtue, But Also A Limit

Fighting is bad. We should respect each other, we must not harass people, and we must not turn someone's identity or survival into a game piece. All of that is true, and all of it matters.

But it does not follow that we should have no claims. It does not follow that we should never be controversial, or that we should sit inside safe air and exchange only thin agreement. Respect does not mean avoiding collision; it means treating the other person as human and still bringing your claim to the table.

Saying nothing is not always kindness, either. In a place where everyone avoids claims, wrong assumptions remain, weak designs remain, and boring culture remains. If the internet is always windless, maybe it is not peaceful. Maybe it is just poorly ventilated.

Do Not Lie, But Be Wrong

I want to separate two things. Lying is bad. Knowingly spreading misinformation, asserting what you have not checked, or twisting facts to damage someone is simply bad.

But you will be wrong sometimes. If you make strong claims, you increase the chance of being wrong; if you introduce a new concept, it will be rough. If you argue against someone, you may misread them, and in the middle of a discussion your own assumptions may collapse. When that happens, apologize, correct yourself, withdraw the claim, and do a little better next time.

"I might be wrong, so I will say nothing" can look honest, but if you push that attitude too far, you will put nothing into the world. Do not lie, but do not fear being wrong too much. A mistaken claim can be sharpened through apology and correction. A claim that never existed becomes nothing.

Professional Wrestling Requires Skill

I want more professional wrestling on the internet, but professional wrestling is not a brawl. It is an advanced form, with breakfall, distance, an audience, and trust in the opponent. Online, too, you need the skill to hit the claim rather than the person, reconstruct the strongest version of the opponent before arguing, leave an exit when you provoke, and avoid being sloppy with facts even when your metaphor is funny.

Apologizing when wrong and stopping when the other person is truly being hurt are part of that skill. If you cannot do these things, it becomes mere attack. That is not professional wrestling; that is an amateur bringing a knife into the ring. Dangerous, and deeply uncool.

That is why we need to develop the skill. If you use strong words, carry strong ethics; if you cause controversy, handle the cleanup; if your words gather people, think about the temperature after they gather. Making the internet messy does not mean destroying the place. It means creating movement in it.

Have A Claim

Younger generations probably understand the risk of failure very well. Screenshots remain, posts are searchable, employers can be found, context gets cut away, and someone's anger can be amplified somewhere you cannot see. So I understand why people become quiet. I feel it too. The internet has become much more like society.

Being loud inside a socialized internet is heavier than making noise behind a handle. Still, you should have claims. This technology should be like this; this culture is boring; this design is weak; this trend is strange; this word is too convenient and dangerous; this community can be better. Claims like that should enter the world more often.

Of course you need reasons, honesty, and readiness to receive pushback. But without claims, discussion does not start; without discussion, nothing deepens; without depth, the world does not change.

Fight, And Sharpen

Conflict is not evil by itself. What is evil is conflict that breaks people, attacks identity, destroys someone with lies, or burns irreversible things as a joke.

But there is also conflict between claims, between concepts, and between design philosophies. We need that. A claim that never collides may look round, but a stone that is only round does not cut. It needs to be scraped, chipped, and sharpened before it becomes a tool.

Claims are the same. Pushback reveals weak points, questions reveal assumptions, being laughed at knocks off excessive self-importance, and when your words cut someone, you finally see the direction of the blade. So fight, and sharpen. Do not fight only to win, do not make noise only to burn things, and do not write long essays only to prove yourself right. Fight to change the world a little; make the internet messy to make your claim better.

Conclusion

Young people, make the internet messy. But do not lie, do not break people, and do not turn survival or identity into a game. If you are wrong, apologize, correct yourself, withdraw, and still have a claim.

It is fine to be more controversial, to perform more professional wrestling, and to deepen more arguments. Being quiet does not make the world clean; it only makes it quiet.

A quiet internet may look mature at first glance, but what we need is not windless maturity. We need well-managed turbulence. Have a claim, fight, sharpen, and, if possible, change the world a little.

Note: The "guy" here is not an age or gender category. It includes women, young people, and, occasionally, me. This is not a demographic. It is the name of an attitude that appears during discussion.

Introduction

I do not like the phrase "basically, it's balance."

Of course, I do not hate balance itself. Quality and speed, freedom and discipline, safety and mobility, ideals and reality. These debates usually do end up as questions of balance.

That is exactly why saying "basically, it's balance" in the middle of a discussion often means almost nothing.

It is like telling someone who is cooking, "Basically, it's heat control." Correct. Too correct. And it helps nobody's hands move even one millimeter.

High heat or low heat? Now or later? Are we searing the surface, or cooking it through? When people are discussing exactly that, "basically, it's heat control" only lets everyone answer "yes." And the moment everyone says "yes," the discussion dies.

If You Have No Claim, Say So

Having no claim is not bad.

If you lack information, say you lack information. If the criteria are unclear, say the criteria are unclear. If you have not thought enough yet, say, "I do not have a position yet."

That is honest.

But once "I have no claim" turns into "I am observing this from a higher level," the situation changes.

You mock both sides. You say, "Now, now, let's not get heated." You behave as if you alone are the adult in the room.

That is not neutrality. That is ego in a very polished bottle.

Polite contempt is still contempt. Poison dusted with sugar becomes more dangerous when someone puts it on the candy shelf.

Being Unable To State An Opinion Is Not Neutrality

I want to emphasize this.

Being unable to state an opinion and being neutral are not the same thing.

You may lack knowledge. You may not be able to take responsibility. The social dynamics in the room may be scary. You may not have found the words yet. There are moments when you simply cannot state an opinion.

That is a state. It is a limit. It is normal, because humans are humans.

But neutrality is not a state. It is a position. It means seeing both claims and choosing to withhold judgment for now. It means organizing the issues. It means separating the information needed for judgment. It means taking on that role.

Do not treat being unable to state an opinion as if it were neutrality. That swaps "I cannot place a position yet" for "I have transcended both sides."

When that swap happens, having no claim somehow becomes moral superiority. The people participating in the discussion look immature, and you alone look mature.

That is not neutrality. It is wrapping paper for not being able to participate.

Discussion Is Not A Fight

The "basically, it's balance" guy often sees discussion as fighting.

Person A argues strongly. Person B pushes back strongly. Counterexamples appear. Assumptions get excavated. The number of issues grows.

Then the situation is read as "getting messy," and they step in to stop it.

Of course, if there is personal attack or harassment, it should be stopped. That is no longer discussion. That is just people moving toward damage.

But disagreement itself is not evil. In fact, when both sides expose their claims, a landscape appears that could not be seen before.

Someone values speed. Someone values safety. Someone brings up operational cost. Someone brings up user impact.

This is not merely conflict. The map of issues is growing. The axes of value are becoming visible. This is probably what it means for a discussion to deepen.

If someone stops that process with "basically, it's balance," the axes that were just starting to grow get snapped. What remains is a vaguely adult atmosphere.

You cannot put that atmosphere in meeting notes. You cannot use it for implementation, design, or decision making. But the speaker's self-image gets a little warmer.

As a low-energy heater, this may be excellent. As a contribution to the world, it is suspicious.

Both Matter Is The Entrance, Not The Exit

"Both matter" has the same problem.

Of course both matter. That is why we are discussing them. If one side obviously did not matter, there would be no discussion in the first place.

The important part comes after that.

• Which side do we prioritize this time?

• Under what condition does the priority reverse?

• Who pays the cost?

• If we fail, which failure is easier to recover from?

• Is this a principle, or an exception for this case?

Only at this level does "balance" become work. Before that, "both matter" is just an entrance ticket. Please do not stand in the middle of the stage holding only the ticket. The show has not started.

To choose something is also to not choose something else. To weigh one side more heavily is to accept the dissatisfaction of the other side. To balance is also to decide where the debt goes.

Balance without that is a very luxurious form of irresponsibility.

If You Stop A Discussion, Have A Reason

Stopping a discussion is not itself bad.

Sometimes there is no time. Sometimes participants are tired. Sometimes context is missing. Sometimes the same issue has looped around three times.

But if you stop a discussion, you should have a reason.

I want to stop here because we do not have enough information yet.

The issue has split into three, so I want to separate them first.

This is drifting toward evaluating people, so I want to bring the target back to the proposal.

These are contributions. They do not kill the discussion. They reshape it so it can continue.

By contrast:

Basically, it's balance.

is a stop command disguised as a conclusion.

And "balance" looks virtuous. So the person resisting it can be made to look like the extreme one.

That is unfair. Very unfair. And often the person doing it does not even realize they are doing it. That lack of self-awareness is part of the problem.

Conclusion

What I hate is not balance.

I hate that "basically, it's balance" is used as an indulgence for not making a claim.

People who make claims risk being wrong. People who push back risk being disliked. People who offer concrete proposals risk being criticized concretely.

Stepping in from the side with nothing but "basically, it's balance" is like showing up to a hot pot party empty-handed and saying, "Flavor matters."

Yes. It matters. That is why everyone is cooking. At least cut the scallions.

If you have a claim, make it. If you are organizing, organize. If you are stopping the discussion, stop it with a reason. If you do not have a claim yet, say you do not have one.

Discussions do not mature just because they are cooled down. Sometimes heat is what lets the shape appear.

I do want to avoid burns. But if we run the world only with people who grab a fire extinguisher the moment they see flame, dinner will probably stay raw forever.

When looking at typescript-go, the native implementation of TypeScript, or tsgo, there is a moment where the way you think about it changes quite naturally.

At first, it looks like a story about making tsc faster. The TypeScript 6.0 announcement describes TypeScript 6.0 as a bridge release from the current JavaScript implementation toward the Go implementation used by TypeScript 7.0 and beyond, and describes that Go codebase as a new implementation that uses native code and shared-memory multi-threading.

But when I write code that integrates with tsgo from the outside, my interest slowly moves somewhere else.

What I want is not only a faster single run of tsgo --noEmit. I want a shape where multiple consumers, such as editors, linters, code generators, refactoring tools, AI agents, and build servers, gather around the same TypeScript program graph and checker, then repeatedly ask only the questions they need.

At that point, tsgo starts looking to me less like a CLI and more like a language processor server.

And corsa-bind is where I am pushing that view into implementation. I do not fork tsgo or rewrite its internals. Instead, I keep corsa-bind on the stdio API and LSP boundaries that upstream provides, then orchestrate workers, sessions, snapshots, transports, and caches around them.

A small note on the name: corsa is not the name of my project by itself. It comes from the tsgo side's code name. My project is corsa-bind, and its README describes the repository as bindings and orchestration layers for using typescript-go from Rust and Node.js. In that sense, bind does not mean exposing a single FFI function. It means building the connection and operations layer around tsgo for Rust, Node, and other native-language surfaces.

I want to call this idea language processor orchestration.

stdio API Is Not a Function Call

When you first see the tsgo stdio API, you might think it is just "sending requests and responses over standard input and standard output." But that view drops something important.

On the other side of stdio, there is a language processor running as another process. We send requests. It builds programs, reads source files, resolves types, holds symbols, manages snapshots, and returns responses.

In other words, the boundary looks like this.

caller process
  -> transport
  -> tsgo worker process
  -> program / checker / snapshot state

The important part is that the tsgo worker has state. If you start a process, read the config, open the project, type-check, and throw everything away each time, that is the CLI way of using it. But if you keep the worker alive, initialize once, reuse snapshots, and keep sending small queries into the same session, that is the server way of using it.

The corsa_bind_client docs on docs.rs describe this layer as high-level client bindings for the typescript-go stdio API. Concretely, it can spawn a tsgo worker process, initialize a session once and reuse it, create and reuse snapshots, and ask type, symbol, and syntax questions through typed helpers.

At that point, what I am doing in corsa-bind is no longer just binding. It is not simply exposing one function through FFI. The layer has to deal with process lifetime, transport choice, request types, snapshot handle lifetime, cleanup, timeouts, and observability together.

I am not building only a thin binding for calling a language processor. I am writing a layer for operating one.

Change the Shape of Work, Not the Compiler

There is one misunderstanding to avoid here.

I am not building corsa-bind to become a smarter compiler engine than tsgo. If you open the same project, resolve the same types, and produce the same diagnostics, the fundamental work is still done by tsgo. A wrapper does not magically make the engine itself faster.

What I want to change with corsa-bind is the shape of the work.

For example, these two workflows are very different.

CLI-shaped workflow:
  run tsgo
  load config
  open project
  build program
  answer one big question
  exit

orchestrated workflow:
  spawn worker
  initialize once
  open project once
  create snapshot
  answer many small questions
  reuse worker and snapshot
  close explicitly

The first shape is natural for batch processing. If you are checking the whole project in CI, this is still a very reasonable shape.

The second shape is closer to editors, lint rules, and agents. You want to know the type of one node. Then you want to resolve a symbol. Then you want to slightly change a virtual document and ask again. Reopening the entire project as a CLI operation every time is like starting a database server for every request in a distributed system.

So the performance model I use for corsa-bind is not "do the same work and beat tsgo." It is closer to "reuse the same engine state and avoid unnecessary work." The benchmarking guide follows that line of thought: separate engine speed from wrapper speed, separate cold runs from warm runs, and look at session reuse and transport choices as different questions.

A good claim is not "corsa-bind is faster than tsgo." A good claim is "in a warm editor workflow, reusing a live session can be cheaper than rerunning tsgo --noEmit every time."

That difference may look small, but it is large. The topic is no longer "how to build a faster compiler." It becomes a question of where to place the processing system around the compiler, which state to reuse, and which queries to send to which worker.

In other words, this is not a move away from compilers. It is a move toward treating a compiler not as a single executable or one-shot function call, but as a long-lived service. The parser, binder, checker, and program graph remain the core of the compiler, but when to start them, where to keep them, which consumers can share them, and what query granularity to expose become design problems outside the compiler itself.

That outside layer is what I want to work on in corsa-bind. I leave the compiler engine semantics to upstream tsgo. Then I design the transport, lifetime, and cache layers around that compiler.

A Snapshot Is a Handle to Remote State

One concept I care about in corsa-bind is the snapshot.

A snapshot is not just a JSON value. At least from my point of view while writing the orchestrator, it is a handle to language processor state living inside the worker.

Very roughly, the relationship looks like this.

ApiClient
  owns worker process
  owns transport
  initializes tsgo session

ManagedSnapshot
  points to snapshot state inside that session
  can be reused for type / symbol / syntax queries
  releases remote state when dropped or closed

The fact that it is a handle matters.

In a normal library call, you pass a value into a function and receive a return value. But with tsgo over stdio, the heavy state remains on the worker side. The caller holds a handle that identifies that state, then refers to that handle in the next request.

This is quite close to a database connection or an actor system. You ask, "for this snapshot, tell me the type at this file position." You ask, "create a snapshot that reflects this virtual document." You say, "release this, because I do not need it anymore."

In other words, you are managing the lifetime of language processor internal state from outside the process boundary. If you handle this casually, correctness breaks before performance even matters. If you forget to release snapshots, resources remain on the worker side. If you treat process cleanup as unimportant, you can leave zombie processes behind or distort later benchmarks.

That is why I bring operational concerns like timeouts, graceful shutdown, observer events, and queue capacity into the same design surface as the typed client in corsa-bind. It is less a binding and more a small operations layer.

Think Like Distributed Servers

If I push this idea one step further, corsa-bind starts to resemble a distributed server system to me.

Of course, if you are only spawning several tsgo workers on one machine, it is not literally a distributed system over the network. But the design problems are very similar.

• Which worker should receive this request?

• When should a worker start, and when should it stop?

• How should cold workers and warm workers be treated?

• Which snapshots can be reused?

• If a worker crashes, how much can be recovered?

• What should happen to a timed-out request?

• Should the transport be JSON-RPC or msgpack?

• At what granularity should observable events be emitted?

This is not just "calling a compiler API." It is closer to operating a small cluster.

For example, a concept like ApiProfile is not merely a name for a spawn config. It is a stable way to describe the character of a worker: which tsgo executable to use, which cwd to start it in, which transport to use, and which timeout and observer to attach.

Conceptually, it looks like this.

profile: "default-msgpack"
  -> worker pool
    -> worker 1
      -> session
      -> snapshots
    -> worker 2
      -> session
      -> snapshots

profile: "lsp-jsonrpc"
  -> worker pool
    -> worker 1
      -> lsp session
      -> virtual documents

It might be an overstatement to say that workers behave like database shards. But in the sense that an orchestrator on the client side manages remote, stateful processing entities, much of the same design vocabulary becomes useful.

A process is a node. A snapshot is a handle to remote state. A request is a message. A transport is a wire format. A profile is a deployment unit. An observer is telemetry. Cleanup is correctness.

When you look at it through this metaphor, language processor API design suddenly becomes much more interesting.

Why Not Fork Upstream?

I made the corsa-bind README very explicit about its no forks, no patches policy. It treats ref/typescript-go as an exact upstream checkout, uses upstream-supported entry points, and does not carry local patches.

This is not just my purism. If you are building an orchestration layer, it is important not to silently change the semantics of the foundation.

If I patched tsgo itself to make something faster, it would become unclear whether the speed came from corsa-bind's orchestration or from compiler engine changes. Benchmarks would become harder to read. Tracking upstream would become harder. Compatibility as seen from other language bindings would become more suspicious.

So I split the boundary.

tsgo is treated as the upstream engine for language processing. In corsa-bind, I handle the outside: transport, typed requests and responses, session reuse, snapshot lifetime, Node bindings, C ABI, and other language bindings.

I think this separation is healthy. Instead of entering the compiler and taking hold of everything, this approach respects the compiler as a specialized server and designs the way it is used around that server.

This is Unix-like, and it is also microservice-like. The only difference is that the server here is not an HTTP service. It is a type checker.

Node Bindings Are an Entry Point for Author Experience

I put not only the Rust-side client and orchestrator into corsa-bind, but also Node bindings built with napi-rs. This is not only about making Rust callable from JavaScript.

The authors of tools that use TypeScript type information often live on the JS / TS side. People writing lint rules, code mods, editor extensions, framework plugins, and AI agent tool adapters do not necessarily want to touch a Rust crate directly.

At the same time, writing heavy protocol handling, process management, and snapshot lifetime management on the JS side every time is painful. So I make Rust own the hot paths and process orchestration, while Node gets a convenient surface.

The direction I am taking with corsa-oxlint fits this idea well. Rule authors write rules in JS / TS. But retrieving type information and talking to the tsgo worker is handled by a Rust-backed layer.

Here too, the subject for me is not just "bindings." The subject is how to distribute the language processor as a shared resource.

From One Compiler to Many Consumers

With a traditional CLI, the relationship between compiler and consumer tends to be one-to-one.

tsc command
  -> compiler
  -> diagnostics

But the actual shape of editors and toolchains is closer to many-to-one.

editor hover
editor completion
lint rule
code action
AI agent
test runner
build watcher
  -> shared language-processing state

Of course, this does not mean everything should be truly concentrated into one process. Fault isolation matters, and it may be better to separate workers depending on the nature of the query. Whether read-heavy type queries and workflows that aggressively rewrite virtual documents should live in the same session is a question to treat carefully.

That is exactly why an orchestrator is needed.

An orchestrator is not a wrapper that hides the compiler. It is a control plane for arranging multiple consumers around the compiler.

"Control plane" may sound a little grand, but the work is similar. Which profile should create a worker? Which worker is warm? Which snapshot is still usable? Which request is stuck? Which transport fits this workflow? Which failures should be retried, and which should be returned to the caller?

These decisions live in a layer separate from the compiler engine itself.

Language Processors Will Stay Resident

I think language processors will increasingly be treated as resident processes.

The reason is simple: developer experience is moving from batch toward conversation.

It is not only that a human saves a file and the project is checked once. The editor offers suggestions while text is being entered. The linter runs rules while looking at the AST and types. An AI agent asks small questions like "what is the type of this node?", "where does this symbol come from?", and "did this fix remove the diagnostic?" Frameworks generate virtual files and map them back to the source files.

In that world, a language processor is less a command you start every time and more a service that keeps receiving questions.

And if it becomes a service, it needs orchestration. It needs worker pools, caches, snapshots, backpressure, timeouts, observability, graceful shutdown, version pinning, and compatibility policy.

I am building that layer in corsa-bind through the concrete target of tsgo.

A language processor does not end at the parser and checker. Keeping it alive, sharing it, folding it down when it breaks, and handing it to author experiences in other languages are all part of the future of language tooling.

Conclusion

tsgo is a faster tsc. But stopping there would be a little wasteful.

Seen through its stdio API, tsgo is also a stateful language processor server. And what I am building in corsa-bind is an orchestration layer for using that server from Rust, Node, and multiple native bindings.

The important point for me is not to forcefully absorb the compiler engine itself. Respect upstream tsgo, do not fork it, do not patch it, and instead reuse sessions, manage snapshots, choose transports, and coordinate workers from the outside.

This is close to the way we think about distributed servers. There are processes, messages, handles to remote state, lifetimes, failures, observations, and cleanup.

Do not only call the language processor as a library. Operate it as a service.

That is the language processor orchestration I am trying to build in corsa-bind.

This article was generated 100% by AI, using GPT-5.5.

Introduction

This site has a faint transparent-watercolor background behind the writing. It looks like a quiet decoration, but it is not a single image. The current implementation draws paper with WebGPU, moves wet pigment a little with WebGL2, keeps a Canvas 2D fallback, and switches to a static background on mobile.

The important point is that this is not an attempt to build a physically correct watercolor simulator in the browser. For a writing site, that would be the wrong goal. The background should not become more important than the text.

The effect only needs a few cues.

• the paper has relief and fiber

• pigment is not just a uniform translucent color

• wet pigment moves for a short time

• dry pigment stays fixed to the paper

• environments that cannot run the effect fail quietly

• text, links, and scrolling remain untouched

After rereading the implementation, the watercolor feeling comes less from one spectacular shader and more from this split. Paper, wet paint, dry paint, input, and fallbacks each have their own boundary. That boundary is the design.

The Background Stays Weak

The visual stack is roughly this.

paper fallback span
paper fallback canvas
paper WebGPU canvas
brush canvas
page content
controls

The Vue template mostly just declares the layers.

<div class="watercolor-bg-container" aria-hidden="true">
  <span ref="fallbackLayerElement" class="paper-fallback" />
  <canvas ref="fallbackCanvasElement" class="paper-fallback-canvas" aria-hidden="true" />
  <canvas ref="paperCanvasElement" class="paper-canvas" aria-hidden="true" />
  <canvas ref="brushCanvasElement" class="brush-canvas" aria-hidden="true" />
</div>

The whole thing is aria-hidden because it is not content. It is material behind the content.

The container itself is not a giant fixed overlay. The canvases are fixed, while the container stays out of the content flow.

.watercolor-bg-container {
  position: static;
  pointer-events: auto;
  background: transparent;
}

.paper-fallback-canvas,
.paper-canvas,
.brush-canvas {
  position: fixed;
  inset: 0;
  pointer-events: none;
}

pointer-events: none matters. The background covers the screen visually, but it cannot steal links or scrolling. It is visually large and behaviorally weak. That is where a writing-site decoration should be.

Do Not Wake Every Island

The background is a Vuerend island, but it does not hydrate on every viewport.

const desktopIslandMedia = "(min-width: 769px)";

export const WatercolorBackgroundIsland = defineIsland("watercolor-background", {
  component: WatercolorBackgroundIslandView,
  load: () => import("./features/ShellWatercolorBackgroundIslandLoader"),
  hydrate: "media",
  media: desktopIslandMedia,
});

Only desktop-width screens load the client code. On mobile, CSS hides the canvases and uses bg-sp.png.

@media (max-width: 768px) {
  html {
    background: #f1eedf url("/bg-sp.png") center center / cover no-repeat;
  }

  .paper-fallback {
    opacity: 1 !important;
    background: #f1eedf url("/bg-sp.png") center center / cover no-repeat;
  }

  .paper-fallback-canvas,
  .paper-canvas,
  .brush-canvas {
    display: none;
  }
}

That is not just a compromise. It is part of the background contract. On touch-first screens, interactive watercolor has more risk than value. Static paper is enough.

Pointer input is gated the same way.

export function canUseFinePointerPaint(): boolean {
  return window.matchMedia("(hover: hover) and (pointer: fine)").matches;
}

The implementation decides not only what it can do, but where it should not run.

Draw Paper First

The WebGPU paper shader initializes asynchronously. Before that path finishes, a Canvas 2D fallback paper is drawn.

renderPaperFallback(fallbackCanvasElement.value, maxDpr);
brushLayer.resize();
removeViewportListeners = addShellViewportListeners(queueResize);

The fallback is not a flat color. It layers radial wash, shadow patches, highlight patches, fibers, and a grain tile.

context.fillStyle = "#f1eedf";
context.fillRect(0, 0, width, height);
drawRadialWash(context, width, height);

context.globalCompositeOperation = "multiply";
drawPaperPatches(context, width, height, random, Math.round(820 * areaScale), "shadow");

context.globalCompositeOperation = "screen";
drawPaperPatches(context, width, height, random, Math.round(520 * areaScale), "highlight");

When WebGPU succeeds, the fallback opacity is reduced. It is not removed entirely.

target.fallbackLayer?.style.setProperty("opacity", "0.1");
target.fallbackCanvas?.style.setProperty("opacity", "0.16");

This order matters. If WebGPU is fast, the shader paper appears. If it is slow, fallback paper is already visible. If it fails, paper remains. That is a good failure mode for a background.

Bake One Paper Layer With WebGPU

The WebGPU path imports ShellSitePaper.wgsl as raw shader source.

import sitePaperShaderSource from "./ShellSitePaper.wgsl?raw";

export const sitePaperShader = sitePaperShaderSource;

The adapter asks for low-power.

const adapter = await gpu.requestAdapter({ powerPreference: "low-power" });

Drawing paper behind text does not need the strongest possible GPU. The render itself is a single fullscreen triangle.

var positions = array<vec2f, 3>(
  vec2f(-1.0, -1.0),
  vec2f(3.0, -1.0),
  vec2f(-1.0, 3.0)
);

DPR is capped at 1.25.

const dpr = Math.min(window.devicePixelRatio || 1, maxDpr);

The paper grain does not need native DPR to read as paper. The useful resolution for a background is not the same as the physical display resolution.

Keep The Paper Still

The paper shader receives no time uniform. Its coordinates come from viewport shape and seed.

let aspect = uniforms.resolution.x / max(uniforms.resolution.y, 1.0);
let centered = (input.uv - 0.5) * vec2f(aspect * 1.72, 1.72);
let point =
  rotate(centered * vec2f(1.0, 1.04), -0.06)
  + vec2f(uniforms.seed * 6.4, uniforms.seed * 3.2);

If the paper moves while someone reads, it stops feeling like paper and becomes an effect. For a background, stillness is stronger.

The shader is also not just color noise. It builds a height field from material roles like embossField, microGrainField, fiberField, celluloseNetworkField, coldPressToothField, crumpleField, and wrinkleLineField. Those fields are mixed into paperHeight.

return macroRelief * 0.34
  + detail.x * 2.16
  + micro * (0.76 + uniforms.fiberDensity * 0.16 + uniforms.grainScale * 0.1)
  + (emboss - 0.18) * (0.18 + uniforms.embossDepth * 0.24)
  + (tooth.y - 0.28) * (0.46 + uniforms.embossDepth * 0.34)
  - (tooth.x - 0.18) * (0.34 + uniforms.shadowStrength * 0.22)
  + (grain - 0.5) * 0.018
  + (pulp - 0.3) * 0.018;

tooth.y acts like raised paper. tooth.x acts like a cavity. That sign difference matters because pigment needs a surface to settle into. The paper is not a white backdrop; it is terrain.

The paper shader can be read as this algorithm.

1. Convert uv into paper coordinates
2. Build low-frequency macro relief
3. Build fiber / fibril / cellulose / tooth / pulp fields separately
4. Mix those fields into a height field
5. Sample the height field nearby to produce a normal
6. Build cavity and ridge masks from the normal, relief, and tooth fields
7. Mix cavity shadow and ridge highlight into a warm white paper color

The normal is not analytic. It is derived by sampling paperHeight at small offsets.

fn paperNormal(point: vec2f) -> vec3f {
  let epsilon = 0.00076;
  let center = paperHeight(point);
  let dx = paperHeight(point + vec2f(epsilon, 0.0)) - center;
  let dy = paperHeight(point + vec2f(0.0, epsilon)) - center;
  let strength = 3.1 + uniforms.embossDepth * 2.2 + uniforms.grainScale * 1.1;
  return normalize(vec3f(-dx * strength, -dy * strength, 1.0));
}

That normal and paper tooth are then split into low spots and raised ridges.

let cavityMask = saturate(
  max(0.0, -localRelief * 1.84)
    + tooth.x * 0.68
    + (1.0 - normal.z) * 0.4
    + max(0.0, -diffuse) * 0.16
    + crumple.x * 0.08
    + wrinkleLines.x * 0.05
);

let ridgeMask = saturate(
  max(0.0, localRelief * 1.42)
    + tooth.y * 0.62
    + detail.y * 0.06
    + max(0.0, diffuse) * 0.18
    + crumple.y * 0.06
    + wrinkleLines.y * 0.04
);

The cavity shadow is intentionally limited. This is still a paper background, so relief should not steal text contrast. The final tone is clamped with clamp(tone, vec3f(0.72), vec3f(1.0)) to keep it from sinking too far.

The Brush Is Wet State, Not A Stamp

One tempting path is to draw organic Canvas 2D shapes and call it watercolor. The fallback brush does use that kind of drawing. But by itself, it still feels like translucent images being stamped onto the page. Watercolor needs a little time after the stroke.

The normal path uses a small WebGL2 solver, but the solver is created lazily.

const fallback = createBrushLayer(options);
let engine: FluidBrushEngine | undefined;
let triedEngine = false;

function ensureEngine(): FluidBrushEngine | undefined {
  if (engine || triedEngine) {
    return engine;
  }

  triedEngine = true;
  engine = FluidBrushEngine.create();
  return engine;
}

If WebGL2 or float framebuffer support is missing, the Canvas 2D brush is used instead.

if (!gl || !gl.getExtension("EXT_color_buffer_float")) {
  return undefined;
}

The solver does not run at full viewport resolution. Its base simulation size is 560.

const simulationBaseSize = 560;

For background bleeding, a slightly soft field is better than a precise high-resolution simulation. Lower resolution helps both performance and appearance.

The fluid section can be read as one sentence first.

the brush deposits wet -> velocity carries wet -> pressure calms the flow -> old wet becomes dry

The thing to visually follow is only the blue wet stain. The velocity arrows move that stain, red pressure is the brake that keeps the flow from bursting, and orange dry is the pigment fixed into the paper. This way of reading the solver was inspired by this three.js post on X, then reframed around this site's own watercolor background implementation.

One frame of the brush solver looks roughly like this.

curl
vorticity confinement
advect velocity
boundary velocity
advect wet
boundary wet
dry wet into dry
remove dried wet
divergence
pressure solve
subtract pressure gradient
boundary velocity
display

<div> <svg viewBox="0 0 760 360" role="img" aria-labelledby="fluid-frame-title-en"> <title id="fluid-frame-title-en">One frame of the WebGL2 brush solver</title> <defs> <marker id="arrow-fluid-frame-en" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-fluid-frame-en" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="360" fill="url(#code-wash-fluid-frame-en)" /> <path d="M 0 0.5 H 760 M 0 359.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">One Frame At A Glance</text> <g font-family="system-ui, sans-serif" font-size="14" text-anchor="middle"> <ellipse cx="112" cy="119" rx="70" ry="32" fill="#64d4a3" opacity="0.16" /> <text x="112" y="115" fill="#35495e">curl</text> <text x="112" y="133" fill="#666">measure spin</text> <line x1="184" y1="119" x2="204" y2="119" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="281" cy="119" rx="76" ry="32" fill="#64d4a3" opacity="0.16" /> <text x="281" y="115" fill="#35495e">vorticity</text> <text x="281" y="133" fill="#666">restore swirl</text> <line x1="358" y1="119" x2="382" y2="119" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="455" cy="119" rx="76" ry="32" fill="#646cff" opacity="0.13" /> <text x="455" y="115" fill="#35495e">advect u</text> <text x="455" y="133" fill="#666">move velocity</text> <line x1="532" y1="119" x2="556" y2="119" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="629" cy="119" rx="76" ry="32" fill="#646cff" opacity="0.13" /> <text x="629" y="115" fill="#35495e">advect wet</text> <text x="629" y="133" fill="#666">move pigment</text> <line x1="629" y1="154" x2="629" y2="184" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="629" cy="219" rx="76" ry="32" fill="#f59e0b" opacity="0.14" /> <text x="629" y="215" fill="#35495e">dry</text> <text x="629" y="233" fill="#666">wet into dry</text> <line x1="552" y1="219" x2="530" y2="219" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="455" cy="219" rx="76" ry="32" fill="#ff6b6b" opacity="0.1" /> <text x="455" y="215" fill="#35495e">divergence</text> <text x="455" y="233" fill="#666">measure expansion</text> <line x1="380" y1="219" x2="358" y2="219" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="281" cy="219" rx="76" ry="32" fill="#ff6b6b" opacity="0.1" /> <text x="281" y="215" fill="#35495e">pressure</text> <text x="281" y="233" fill="#666">8 iterations</text> <line x1="204" y1="219" x2="184" y2="219" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <ellipse cx="112" cy="219" rx="70" ry="32" fill="#ff6b6b" opacity="0.1" /> <text x="112" y="215" fill="#35495e">gradient</text> <text x="112" y="233" fill="#666">subtract pressure</text> <line x1="112" y1="252" x2="112" y2="282" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-frame-en)" /> <path d="M 60 302 C 200 292 388 292 692 302" fill="none" stroke="#fcb32c" stroke-width="28" stroke-linecap="round" opacity="0.14" /> <text x="373" y="307" fill="#35495e">display: composite wet / dry back into transparent brush canvas</text> </g> </svg> </div>

This is not a complete Navier-Stokes solver. It adds a little vorticity back into the velocity field, moves wet pigment with semi-Lagrangian advection, and uses pressure projection to reduce divergence. For a background, that stable-fluids subset is enough.

First, There Are No Particles

When people hear "fluid," it is easy to imagine many little water particles moving around. This implementation does not track particles. It creates a texture grid smaller than the screen, and each pixel stores "which way water is moving here" and "how much wet pigment is here."

So the thing being simulated is a field, not a set of particles.

Each pixel:
  velocity = water direction at this position
  wet      = wet pigment at this position
  dry      = dried pigment at this position

One stroke changes roughly like this.

<div> <svg viewBox="0 0 760 520" role="img" aria-labelledby="toy-fluid-title-en"> <title id="toy-fluid-title-en">How one stroke separates into wet, velocity, and dry fields</title> <defs> <marker id="arrow-toy-fluid-en" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <radialGradient id="wet-blob-en" cx="50%" cy="50%" r="60%"> <stop offset="0%" stop-color="#646cff" stop-opacity="0.46" /> <stop offset="70%" stop-color="#646cff" stop-opacity="0.18" /> <stop offset="100%" stop-color="#646cff" stop-opacity="0" /> </radialGradient> <radialGradient id="dry-blob-en" cx="50%" cy="50%" r="60%"> <stop offset="0%" stop-color="#f59e0b" stop-opacity="0.42" /> <stop offset="80%" stop-color="#f59e0b" stop-opacity="0.16" /> <stop offset="100%" stop-color="#f59e0b" stop-opacity="0" /> </radialGradient> <linearGradient id="code-wash-toy-fluid-en" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="520" fill="url(#code-wash-toy-fluid-en)" /> <path d="M 0 0.5 H 760 M 0 519.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">Blue wet moves, orange dry remains</text> <g font-family="system-ui, sans-serif" font-size="14"> <path d="M 380 92 L 380 442 M 58 266 L 702 266" stroke="#ddd" stroke-width="1" opacity="0.5" /> <text x="80" y="120" fill="#35495e" font-weight="700">0. splat</text> <text x="80" y="142" fill="#666">add wet pigment and velocity</text> <ellipse cx="210" cy="180" rx="46" ry="30" fill="url(#wet-blob-en)" /> <circle cx="210" cy="180" r="7" fill="#646cff" /> <path d="M 210 180 L 264 160" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 210 180 L 260 202" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 210 180 L 174 208" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" />

<text x="424" y="120" fill="#35495e" font-weight="700">1. advect</text> <text x="424" y="142" fill="#666">velocity carries wet pigment</text> <ellipse cx="534" cy="182" rx="58" ry="28" transform="rotate(10 534 182)" fill="url(#wet-blob-en)" /> <path d="M 478 176 C 520 158 564 164 610 188" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 482 208 C 528 194 574 198 616 220" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" />

<text x="80" y="314" fill="#35495e" font-weight="700">2. project</text> <text x="80" y="336" fill="#666">pressure keeps the flow from exploding</text> <circle cx="204" cy="390" r="36" fill="#ff6b6b" opacity="0.12" /> <path d="M 204 390 L 204 354" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 204 390 L 242 390" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 204 390 L 204 426" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 204 390 L 166 390" stroke="#ff6b6b" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <path d="M 292 362 C 326 380 326 416 292 438" fill="none" stroke="#42b883" stroke-width="3" marker-end="url(#arrow-toy-fluid-en)" /> <text x="80" y="450" fill="#666">outward burst is softened</text>

<text x="424" y="314" fill="#35495e" font-weight="700">3. dry</text> <text x="424" y="336" fill="#666">wet fades, dry remains on paper</text> <ellipse cx="540" cy="382" rx="62" ry="30" transform="rotate(8 540 382)" fill="url(#dry-blob-en)" /> <ellipse cx="566" cy="370" rx="36" ry="18" transform="rotate(8 566 370)" fill="url(#wet-blob-en)" opacity="0.55" /> <path d="M 494 402 C 528 416 576 412 616 392" fill="none" stroke="#f59e0b" stroke-width="3" opacity="0.7" /> <text x="424" y="430" fill="#666">dry pigment no longer advects</text> </g> <g font-family="system-ui, sans-serif" font-size="13"> <circle cx="78" cy="470" r="7" fill="#646cff" opacity="0.55" /> <text x="94" y="475" fill="#35495e">blue = moving wet</text> <line x1="222" y1="470" x2="260" y2="470" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-toy-fluid-en)" /> <text x="272" y="475" fill="#35495e">arrows = velocity</text> <circle cx="406" cy="470" r="7" fill="#f59e0b" opacity="0.6" /> <text x="422" y="475" fill="#35495e">orange = fixed dry</text> <circle cx="574" cy="470" r="7" fill="#ff6b6b" opacity="0.45" /> <text x="590" y="475" fill="#35495e">red = pressure correction</text> </g> </svg> </div>

In this picture, the solver mostly moves velocity and wet every frame. dry is removed from that moving system. That is why pigment first rides the water, then gradually becomes fixed into the paper.

The Fluid Fields Are Textures

The solver does not keep arrays on the CPU. It keeps fields as WebGL2 RGBA16F textures. Each pass draws one fullscreen triangle, and the fragment shader writes the next texture. Because a pass cannot safely read and write the same texture, velocity, wet, dry, and pressure are ping-pong buffers with read and write sides.

velocity.xy   velocity
velocity.zw   unused / spare alpha
wet.rgb       absorption from wet pigment
wet.a         wet amount
dry.rgb       absorption from dried pigment
dry.a         dried amount
pressure.x    pressure
divergence.x  velocity divergence
curl.x        2D curl

<div> <svg viewBox="0 0 760 340" role="img" aria-labelledby="fluid-textures-title-en"> <title id="fluid-textures-title-en">Texture fields owned by the fluid solver</title> <defs> <marker id="arrow-fluid-textures-en" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-fluid-textures-en" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="340" fill="url(#code-wash-fluid-textures-en)" /> <path d="M 0 0.5 H 760 M 0 339.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">The Fields Live As Textures</text> <g font-family="system-ui, sans-serif" font-size="14" text-anchor="middle"> <ellipse cx="124" cy="130" rx="78" ry="42" fill="#646cff" opacity="0.1" /> <text x="124" y="121" fill="#35495e" font-weight="700">velocity</text> <text x="124" y="143" fill="#666">xy = flow</text> <ellipse cx="290" cy="130" rx="78" ry="42" fill="#42b883" opacity="0.12" /> <text x="290" y="121" fill="#35495e" font-weight="700">wet</text> <text x="290" y="143" fill="#666">rgb = wet pigment</text> <ellipse cx="456" cy="130" rx="78" ry="42" fill="#f59e0b" opacity="0.12" /> <text x="456" y="121" fill="#35495e" font-weight="700">dry</text> <text x="456" y="143" fill="#666">rgb = dry pigment</text> <ellipse cx="622" cy="130" rx="78" ry="42" fill="#ff6b6b" opacity="0.1" /> <text x="622" y="121" fill="#35495e" font-weight="700">pressure</text> <text x="622" y="143" fill="#666">x = pressure</text> <text x="196" y="232" fill="#35495e">read texture</text> <path d="M 128 244 C 162 250 230 250 264 244" fill="none" stroke="#8899aa" stroke-width="2" opacity="0.55" /> <text x="380" y="208" fill="#666" font-size="13">pass writes the next field</text> <line x1="282" y1="224" x2="476" y2="224" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-fluid-textures-en)" /> <text x="564" y="232" fill="#35495e">write texture</text> <path d="M 496 244 C 530 250 598 250 632 244" fill="none" stroke="#8899aa" stroke-width="2" opacity="0.55" /> <path d="M 564 260 C 520 306 240 306 196 260" fill="none" stroke="#f59e0b" stroke-width="2" marker-end="url(#arrow-fluid-textures-en)" /> <text x="380" y="316" fill="#666">swap: write becomes the next read</text> </g> </svg> </div>

As a fluid algorithm, one frame is roughly this.

u = velocity
w = wet pigment
d = dry pigment

u <- add vorticity(u)
u <- advect(u, u)
w <- advect(w, u)
d, w <- dry(w, d)
u <- project(u)

dry is not advected. It represents pigment fixed into paper. The watercolor feeling comes as much from deciding what cannot move as from moving the wet field.

Advection Samples Backward

Advection uses a semi-Lagrangian step. The amount that arrives at the current pixel is assumed to have been upstream one step earlier. So the shader samples backward from vUv.

<div> <svg viewBox="0 0 760 320" role="img" aria-labelledby="advection-title-en"> <title id="advection-title-en">Backtracing in semi-Lagrangian advection</title> <defs> <marker id="arrow-advection-en" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-advection-en" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="320" fill="url(#code-wash-advection-en)" /> <path d="M 0 0.5 H 760 M 0 319.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">Advection Reads Upstream</text> <g stroke="#ddd" stroke-width="1"> <path d="M 84 88 L 84 256 M 144 88 L 144 256 M 204 88 L 204 256 M 264 88 L 264 256 M 324 88 L 324 256 M 384 88 L 384 256 M 444 88 L 444 256 M 504 88 L 504 256 M 564 88 L 564 256 M 624 88 L 624 256" /> <path d="M 64 108 L 660 108 M 64 148 L 660 148 M 64 188 L 660 188 M 64 228 L 660 228" /> </g> <g font-family="system-ui, sans-serif" font-size="14"> <text x="324" y="122" fill="#35495e" text-anchor="middle">previous sample position</text> <circle cx="324" cy="150" r="8" fill="#42b883" /> <text x="520" y="122" fill="#35495e" text-anchor="middle">current pixel vUv</text> <circle cx="520" cy="166" r="8" fill="#646cff" /> <path d="M 520 166 C 472 132 386 126 324 150" fill="none" stroke="#35495e" stroke-width="3" marker-end="url(#arrow-advection-en)" /> <text x="420" y="194" fill="#666" text-anchor="middle">trace backward by velocity</text> <path d="M 242 220 C 330 206 438 210 564 230" fill="none" stroke="#f59e0b" stroke-width="4" opacity="0.7" marker-end="url(#arrow-advection-en)" /> <text x="380" y="260" fill="#666" text-anchor="middle">velocity u tries to move pigment down and right</text> <text x="70" y="294" fill="#35495e">coord = vUv - dt velocity texelSize</text> </g> </svg> </div>

vec2 vel = texture(uVelocity, vUv).xy;
vec2 coord = vUv - dt * vel * uTexelSize;
outColor = dissipation * texture(uSource, coord);

The same shader moves both velocity and wet.

this.run("advect", this.velocity.write, {
  dissipation: 0.986,
  dt,
  uSource: this.velocity.readTexture,
  uVelocity: this.velocity.readTexture,
});

this.run("advect", this.wet.write, {
  dissipation: 0.998,
  dt,
  uSource: this.wet.readTexture,
  uVelocity: this.velocity.readTexture,
});

Velocity dissipates at 0.986, while wet pigment dissipates at 0.998. Motion fades sooner than pigment. Semi-Lagrangian advection is stable, but it blurs. For background bleeding, that blur is usually useful.

Add Back A Little Curl

Semi-Lagrangian advection tends to lose small rotations. The solver first computes curl, then uses vorticity confinement to reintroduce a little swirl.

outColor = vec4(
  0.5 * (right.y - left.y - (top.x - bottom.x)),
  0.0,
  0.0,
  1.0
);

In 2D, curl can be stored as a scalar. The next pass looks at the gradient of abs(curl) and pushes around the curl center.

vec2 force = 0.5 * vec2(abs(top.x) - abs(bottom.x), abs(right.x) - abs(left.x));
force /= length(force) + 0.0001;
force *= strength * center * vec2(1.0, -1.0);
vec2 vel = texture(uVelocity, vUv).xy;
outColor = vec4(vel + force * dt, 0.0, 1.0);

strength is 18. Higher values make the motion showier, but also louder as a background. The goal is not visible water turbulence; it is slight uneven pigment escape.

Boundaries Depend On The Field

After several passes, the solver applies a boundary pass. Near an edge, it samples the neighboring texel and multiplies by a scale.

if (uv.x < uTexelSize.x) data = scale * texture(uTarget, uv + vec2(uTexelSize.x, 0.0));
if (uv.x > 1.0 - uTexelSize.x) data = scale * texture(uTarget, uv - vec2(uTexelSize.x, 0.0));
if (uv.y < uTexelSize.y) data = scale * texture(uTarget, uv + vec2(0.0, uTexelSize.y));
if (uv.y > 1.0 - uTexelSize.y) data = scale * texture(uTarget, uv - vec2(0.0, uTexelSize.y));

For velocity, scale = -1, so velocity reflects at the wall. For wet, scale = 0, so wet pigment that reaches the outside disappears. For pressure, scale = 1, so pressure continues across the edge. One boundary shader is reused, but the sign depends on the meaning of the field.

Pressure Projection Reduces Divergence

Splatting and vorticity can make velocity expand or collapse. The solver first computes divergence.

outColor = vec4(
  0.5 * (right.x - left.x + top.y - bottom.y),
  0.0,
  0.0,
  1.0
);

Divergence marks places where flow is appearing or disappearing. To reduce it, pressure is solved with Jacobi iterations.

<div> <svg viewBox="0 0 760 320" role="img" aria-labelledby="projection-title-en"> <title id="projection-title-en">What pressure projection does</title> <defs> <marker id="arrow-projection-en" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="5" markerHeight="5" orient="auto-start-reverse"> <path d="M 0 0 L 10 5 L 0 10 z" fill="#35495e" /> </marker> <linearGradient id="code-wash-projection-en" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" stop-color="#5a8abf" stop-opacity="0.045" /> <stop offset="72%" stop-color="#5a8abf" stop-opacity="0" /> </linearGradient> </defs> <rect x="0" y="0" width="760" height="320" fill="url(#code-wash-projection-en)" /> <path d="M 0 0.5 H 760 M 0 319.5 H 760" stroke="#2f3b47" stroke-opacity="0.16" /> <text x="48" y="62" font-size="18" font-weight="700" fill="#35495e">Pressure Projection Smooths Sources</text> <g font-family="system-ui, sans-serif" font-size="14" text-anchor="middle"> <ellipse cx="174" cy="171" rx="122" ry="84" fill="#ff6b6b" opacity="0.1" /> <text x="174" y="112" fill="#35495e" font-weight="700">before projection</text> <text x="174" y="136" fill="#9f6464">large divergence</text> <circle cx="174" cy="194" r="16" fill="#ff6b6b" opacity="0.35" /> <path d="M 174 194 L 174 160" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <path d="M 174 194 L 226 194" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <path d="M 174 194 L 174 238" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <path d="M 174 194 L 122 194" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <line x1="302" y1="171" x2="458" y2="171" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <text x="380" y="154" fill="#35495e">solve pressure</text> <text x="380" y="194" fill="#666">subtract ∇p</text> <ellipse cx="586" cy="171" rx="122" ry="84" fill="#42b883" opacity="0.1" /> <text x="586" y="112" fill="#35495e" font-weight="700">after projection</text> <text x="586" y="136" fill="#52745f">divergence reduced</text> <path d="M 546 164 C 568 146 604 146 626 164" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <path d="M 626 184 C 604 202 568 202 546 184" fill="none" stroke="#35495e" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <path d="M 546 164 C 532 178 532 190 546 204" fill="none" stroke="#646cff" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <path d="M 626 184 C 640 170 640 158 626 144" fill="none" stroke="#646cff" stroke-width="2" marker-end="url(#arrow-projection-en)" /> <text x="586" y="238" fill="#666">less explosive flow</text> </g> </svg> </div>

float div = texture(uDivergence, vUv).x;
outColor = vec4(
  (left.x + right.x + bottom.x + top.x - div) * 0.25,
  0.0,
  0.0,
  1.0
);

Then the pressure gradient is subtracted from velocity.

vec2 vel = texture(uVelocity, vUv).xy;
outColor = vec4(
  vel - 0.5 * vec2(right.x - left.x, top.x - bottom.x),
  0.0,
  1.0
);

This does not make the field perfectly incompressible. The pressure solve only runs for 8 iterations. For a watercolor background, strict volume conservation matters less than keeping the stroke edge from looking like it explodes.

Split Wet And Dry

The WebGL2 solver mainly owns velocity, wet, dry, and pressure.

velocity  water motion
wet       pigment that can still move
dry       pigment fixed into the paper
pressure  field used to keep velocity coherent

Incoming color is not written directly into dry. It is splatted into wet. The stroke first turns pointer delta into direction, radius, force, and opacity.

const speed = Math.hypot(stroke.deltaX, stroke.deltaY);
const directionX = speed > 0.00001 ? stroke.deltaX / speed : 1;
const directionY = speed > 0.00001 ? stroke.deltaY / speed : 0;
const radius = 0.00018 + stroke.pressure * 0.00034;
const force = Math.min(46, 8 + speed * 2200);
const opacity = Math.min(0.42, 0.18 + stroke.alpha * 3.8 + stroke.pressure * 0.045);

One stroke updates both velocity and wet pigment. The velocity splat carries motion; the wet splat carries pigment absorption.

this.splatBuffer(
  this.velocity,
  stroke.x,
  stroke.y,
  directionX * force,
  directionY * force,
  0,
  1,
  radius * 1.05,
  0,
  directionX,
  directionY,
);

this.splatBuffer(
  this.wet,
  stroke.x,
  stroke.y,
  (1 - stroke.red) * opacity,
  (1 - stroke.green) * opacity,
  (1 - stroke.blue) * opacity,
  opacity,
  radius,
  speed > 0.0009 ? 1 : 0,
  directionX,
  directionY,
);

The solver stores 1 - rgb, treating pigment as light absorption rather than paint added on top of paper. It also adds six small outward velocity splats around the center. This is not a physically exact capillary model, but it gives the stroke edge somewhere to bleed.

for (let index = 0; index < 6; index += 1) {
  const angle = (index / 6) * Math.PI * 2;
  const offset = Math.sqrt(radius) * 0.42;
  const bloomX = clamp01(stroke.x + Math.cos(angle) * offset);
  const bloomY = clamp01(stroke.y + Math.sin(angle) * offset);
  this.splatBuffer(
    this.velocity,
    bloomX,
    bloomY,
    Math.cos(angle) * 28,
    Math.sin(angle) * 28,
    0,
    1,
    radius * 0.62,
    0,
    Math.cos(angle),
    Math.sin(angle),
  );
}

Each frame advects velocity and wet. It does not advect dry.

vec2 vel = texture(uVelocity, vUv).xy;
vec2 coord = vUv - dt * vel * uTexelSize;
outColor = dissipation * texture(uSource, coord);

This separation does most of the work. Wet pigment moves. Dry pigment does not. That turns "a transparent image spreading on screen" into something closer to pigment settling into paper.

The velocity field still needs projection. The solver computes divergence, iterates pressure, and subtracts the pressure gradient.

this.run("divergence", this.divergence, {
  uVelocity: this.velocity.readTexture,
});
this.clearTarget(this.pressure.read);

for (let index = 0; index < pressureIterations; index += 1) {
  this.run("pressure", this.pressure.write, {
    uDivergence: this.divergenceTexture,
    uPressure: this.pressure.readTexture,
  });
  this.swap(this.pressure);
  this.applyBoundary(this.pressure, 1);
}

The pressure solve stops at 8 iterations. That is rough as fluid simulation, but good enough for bleeding pigment. A slightly loose field often reads as paper irregularity instead of error.

Drying is split between dryAccum and dryWet.

float density = max(max(w.r, w.g), w.b);
float thicknessFactor = 1.0 / (1.0 + density * thicknessK);
float wet1 = max(wet0 - dryRate * thicknessFactor * dt, 0.0);

Dense pigment dries more slowly. Thin water disappears earlier, while pooled pigment remains as edges and unevenness. It is not exact physics, but it is the right perceptual shortcut.

The dry accumulation pass also mixes addition and replacement.

vec3 transfer = w.rgb * frac * 1.015;
float coverage = 1.0 - exp(-density * 1.8);
vec3 headroom = max(vec3(dryCap) - d.rgb, vec3(0.0));
vec3 added = d.rgb + min(transfer, headroom);
vec3 replaced = mix(d.rgb, w.rgb, frac);
outColor = vec4(mix(added, replaced, coverage), min(d.a + dried, 4.0));

Pure addition makes repeated strokes sink toward mud. Pure replacement erases transparent glazing. Thin pigment stays closer to additive layering; dense pigment moves closer to replacement. That keeps both pale washes and heavier pools.

Return To A Transparent Canvas

Inside the solver, wet and dry pigment are first composited against an assumed paper color.

vec3 paper = vec3(0.96, 0.945, 0.92);
vec3 afterDry = paper * exp(-dry.rgb * 2.2);
vec3 wetColor = paper * exp(-wet.rgb * 2.2);
vec3 glazed = afterDry * exp(-wet.rgb * 2.2);

The actual page already has a separate WebGPU paper layer, so the final brush output must stay transparent.

float density = max(wetDensity, dryDensity);
float edge = smoothstep(0.002, 0.018, length(vec2(dFdx(density), dFdy(density))));
float alpha = clamp(density * 1.15 + wetAmt * 0.18 + edge * 0.12, 0.0, 0.62);
outColor = vec4(color, alpha);

The offscreen WebGL canvas is copied back into the visible 2D canvas.

context.clearRect(0, 0, canvas.width, canvas.height);
context.drawImage(this.canvas, 0, 0, canvas.width, canvas.height);

CSS then sinks it into the paper.

.brush-canvas {
  mix-blend-mode: multiply;
}

The paper and brush are not combined into one renderer because their failure scopes are different. Paper can survive without brush. Brush can fall back to Canvas 2D. Mobile can skip both dynamic paths. Separate layers make those choices simple.

The Canvas 2D Fallback Keeps The Same Contract

When WebGL2 is unavailable, createBrushLayer is used. It is not a fluid solver, but it keeps the wet/dry idea.

dryLayer
wetLayer
wetBlooms
wetDryFrames

Strokes are drawn into wetLayer, then slowly moved into dryLayer.

dryContext.globalCompositeOperation = "multiply";
dryContext.globalAlpha = 0.026;
dryContext.drawImage(wetLayer, 0, 0);

wetContext.globalCompositeOperation = "destination-out";
wetContext.fillStyle = "rgba(0, 0, 0, 0.018)";
wetContext.fillRect(0, 0, wetLayer.width, wetLayer.height);

The WebGL2 solver is not the essence of the effect. The essence is that pigment can be wet, can dry, and those two states have a time gap. The fallback preserves that contract.

Do Not Change Color Too Fast

Brush color changes every 36 draws.

const brushColorHoldDraws = 36;

Changing color on every pointermove creates a rainbow marker, not watercolor. One pigment needs time to dilute and spread. The palette also stays low-alpha, around 0.04 to 0.05.

For a reading background, layered density is better than loud hue changes.

Keep Renderer State Out Of Vue

The Vue state is intentionally small.

const fallbackLayerElement = ref<HTMLElement>();
const fallbackCanvasElement = ref<HTMLCanvasElement>();
const paperCanvasElement = ref<HTMLCanvasElement>();
const brushCanvasElement = ref<HTMLCanvasElement>();
const isDrawingEnabled = ref(false);

WebGPU devices, WebGL contexts, textures, framebuffers, wet/dry buffers, and previous pointer positions are not reactive state. They are renderer state.

From Vue's side, the brush layer is just an imperative object with draw, resize, and clear.

const brushLayer = createFluidBrushLayer({
  canvas: () => brushCanvasElement.value,
  isDrawingEnabled: () => isDrawingEnabled.value,
  maxDpr,
});

When graphics live inside a UI framework, it is tempting to make everything reactive. But state that never updates the template only adds tracking cost and confusion. The renderer should own renderer state.

Cleanup Matters

The background attaches window-level listeners. That makes cleanup part of the feature.

onUnmounted(() => {
  if (resizeFrame !== 0) {
    cancelAnimationFrame(resizeFrame);
  }
  removeViewportListeners?.();
  removeBrushListeners?.();
  paperCleanup?.();
});

The WebGPU cleanup calls unconfigure() too.

return () => {
  disposed = true;
  if (paperResizeFrame !== 0) {
    cancelAnimationFrame(paperResizeFrame);
  }
  removeViewportListeners();
  gpuContext.unconfigure();
};

A background feels minor, but it touches the whole page. Stopping it cleanly is part of implementing it.

Test Properties, Not Beauty

It is hard to automatically test whether watercolor looks beautiful. It is much easier to test the properties that should not regress.

The Playwright checks look for things like these.

• the fallback canvas is not blank

• .watercolor-bg-container does not cover content

• the paper canvas initializes when WebGPU is available

• mobile uses bg-sp.png and hides the canvases

• the tooltip does not stay visible after hover

• brush color does not change too quickly within one stroke

• the bleeding edge expands or darkens after a delay

• pointer-event bursts finish within a bounded time

The tests are not pixel-perfect. They protect the behavioral and perceptual contracts. For a background, that is more useful than locking down an exact image.

Summary

The tech behind transparent watercolor on the Web is not just about solving fluid accurately. On this site, these choices matter more.

• split paper and brush into separate layers

• draw Canvas 2D fallback paper before WebGPU starts

• bake paper once with WebGPU and keep it still

• cap DPR so the background does not pay for unnecessary fragments

• enable brush input only for fine-pointer desktop contexts

• lazily initialize the WebGL2 solver and fall back to Canvas 2D

• split pigment into wet and dry, and never advect dry

• keep color stable long enough to feel like one pigment

• keep renderer state out of Vue reactivity

• use a static background on mobile

• test properties instead of pixels

Transparent watercolor does not require solving water, paper, and pigment perfectly. It only needs to make the reader feel paper, wetness, and drying over a short time. And when the environment cannot support that, it should do nothing. For a background, quiet failure is part of the implementation.

When you discuss something, what kind of structure do you imagine underneath the discussion?

I suspect many people naturally assume a tree with a limited scope. There is a root topic, branches beneath it, and the discussion proceeds inside one branch at a time. When the conversation drifts, someone says "let's come back to the topic." When another branch appears, someone cuts it off as "a separate issue."

This attitude is generally preferred in practice. It appears to keep the discussion under control, and it appears to make meetings easier to time-box. People often say that, when explaining something, it is kinder to reduce it to a tree.

But I do not like that premise at all. More strongly, I think it is wrong to proceed with a discussion as a tree.

The essential structure of information is a graph, and a tree is only a partial structure inside it. To proceed with a discussion as a tree is often to drop edges that were really there, then treat that missing structure as the official one.

And those dropped edges come back later under the name "insufficient consideration."

Trees Are Wrong

Borrowing the language of graph theory, a tree can roughly be understood as a connected graph with no cycles. In other words, a tree is a special kind of graph. The graph comes first; the tree is what you get after imposing strong constraints on it.

I think the same relationship holds for information. It is not that there is information that naturally belongs in a tree. It is that information simple enough to fit in a tree can sometimes be treated as a tree. And discussions are almost never that simple.

One piece of information does not necessarily have only one parent. One issue does not necessarily belong under only one root. One piece of evidence does not necessarily complete itself inside a single branch.

Even the file system shows this problem immediately. Should a file live under "work," under "personal research," under "2026," or under a specific project? The answer is usually just a convenience of the moment. Once you pick a single parent, you lose the naturalness of the other contexts. That is why we use search, tags, links, shortcuts, and things like symbolic links as escape hatches.

This is not merely a UI preference. Forcing information into a tree places a strong, and often wrong, assumption on the shape of that information.

This problem is old. In As We May Think, published in 1945, Vannevar Bush imagined a future for mechanically handling records and described ideas like associative trails through related records. In today's language, that imagination is deeply hypertextual and graph-like.

You can see the same direction in modern tools. Obsidian's Graph view visualizes notes as nodes and internal links as edges. Scrapbox was renamed Helpfeel Cosense in 2024, but its spirit of growing knowledge through loosely linked pages is much closer to a graph than to a tree.

What these examples show is the obvious fact that information cannot be handled by parent-child relationships alone. I want to be just as strict about this in discussion.

Why People Prefer Trees

So why do people prefer tree-shaped discussions so much?

The reason is simple: human working memory is limited.

George A. Miller's famous paper The Magical Number Seven, Plus or Minus Two is a classic reference point for the limits of human information processing capacity. But the number "seven" should not be worshiped too casually. In The magical number 4 in short-term memory, Nelson Cowan reframes short-term memory capacity as a smaller problem, roughly three to five chunks.

Cognitive Load Theory also describes how, in complex tasks, too many interacting information elements can overwhelm capacity-limited working memory.

So it is natural for people to feel, "please make this simpler," "please narrow the issue," or "let's only talk about this for now." That is not evil. In many cases, it is an important form of care toward the listener.

But there is one thing we must not confuse.

The fact that humans can handle only a small amount of information at once and the claim that the problem itself can be represented as a small tree are completely different.

The former is a limitation of the receiver. The latter is a claim about the structure of the object. Mixing them up is dangerous.

Trees are preferred not because they are correct. They feel comfortable only because the human processing system is narrow.

Comfort and correctness are different things.

Wrong Tree-Shaking

When working with people, evaluations like "smart person" or "clear communicator" are often given to people who can reduce and simplify information to the necessary and sufficient amount for the moment.

I understand that evaluation. Someone who can adjust the order of explanation to match the listener is genuinely strong.

But adjusting the order of speech and transforming the structure of the discussion into a tree are different things. The former is choosing a traversal over a graph. The latter is deleting edges from the graph.

Very few people can actually do the latter correctly.

To decide what can be dropped, you already need to see the whole graph. Whether an edge is unnecessary for the current explanation, or whether it is an important dependency that will later overturn the decision, cannot be judged by looking only at a tree-shaped slice.

In many cases, people are not performing necessary and sufficient simplification. They are simply dropping the edges they cannot process. This is wrong tree-shaking.

They think they are removing unused code, but they are actually deleting an import with side effects. The same thing happens in discussion.

• Treating something as "not the current topic" when it was actually a precondition

• Treating something as "a detail" when it actually determines feasibility

• Treating something as "another team's problem" when it actually defines the responsibility boundary

• Treating something as "emotional" when it is actually a signal that consensus is about to fail

Then, later, things mysteriously do not work. Understanding mysteriously diverges. The specification mysteriously flips.

That happens because an edge that mattered was dropped during the discussion.

Focus Is Also a Graph Operation

Of course, I am not saying that you must say all information out loud at once. Humans do not have that much working memory, and speech and writing both have order.

The important thing is not to treat focus as deletion.

Focus is a viewport over a graph. You choose the node to center, choose the depth, and look at that range. But you do not pretend that everything outside the viewport does not exist. This is not a tree. You are still looking at the graph as a graph; you are only changing the center and radius of the view.

When someone says "let's only discuss this for now," what they should mean is:

We are looking at this node with depth 1 for now.

When someone says "that is a separate issue," what they should mean is:

This is a different node, but the edge remains.

When someone says "we will discuss that later," what they should mean is:

This edge is not closed, so we will come back to it.

But in actual discussions, the word "focus" is often used to mean "let's pretend this does not exist." That is bad.

There are times when we only look at part of the graph. But the object we are looking at remains a graph until the end. Do not transform the graph into a tree.

Discussion Is a Dependency Graph

The graph I am talking about here is not an undirected graph where everything is scattered equally. Discussions have fairly strong directionality.

• To claim A, B is required.

• If C is true, D becomes weaker.

• E is a concrete example of F.

• G depends on the definition of H.

• I constrains the feasibility of J.

• K may break consensus around L.

These edges exist. In other words, discussion is a dependency graph more than a parent-child relationship.

When you force this dependency graph into a tree, you are forced to make an unnatural choice about what the parent should be. And that parent is usually decided by the meeting organizer, the document heading, the ticket size, the org chart, or the power dynamics of the moment.

But information dependencies do not obey such things.

So I am not saying graphs have no direction. I am saying that treating them as one-way parent-child relationships is wrong. Discussion should proceed as a dependency graph. You can be conscious of which edge you are following right now, but you must not say "there is nothing outside this branch."

Externalize It

To proceed with discussion as a graph, you do not need to rely only on the human brain. In fact, trying to process everything only inside the brain is exactly what makes people want to fold things into trees.

If the bottleneck is human working memory, the thing to solve is not "make the problem look smaller." It is externalize the graph.

In that sense, attempts to treat discussion as a map are important. For example, Dialog Mapping is described as a way to record the questions, ideas, and pro/con arguments that arise in a conversation as a shared network-like map. The IBIS background behind it is also close to the idea of treating discussion not as a mere bullet list, but as relationships among questions, proposals, and reasons.

Of course, you do not need a dedicated tool every time. What matters is that the graph visible during the discussion is preserved somewhere.

For example:

• Name issues as nodes

• Give edges types

• Treat "we will come back to this later" not as a verbal promise, but as an unresolved edge

• Treat "separate issue" not as deletion, but as a link

• At the end of the discussion, check whether any edges were dropped

Even that much changes a lot.

We do not need to fear complexity itself so much. If something complex looks complex, that may be the correct display. What we should fear is making a complex thing look simple and deleting important dependencies in the process.

Do Not Confuse Reading Order with Structure

At least as the internal representation of a discussion, I want to say: throw away the tree.

When writing an article, giving a presentation, or onboarding someone, order becomes necessary. Headings become necessary. You need to decide where to start reading and where to go next.

But that is not a tree. That is a traversal order over a graph.

A genuinely good explainer keeps the graph as a graph, then chooses the path to follow at that moment. That is why, when the listener asks a different question, they can move to another path. When the premise changes, they can change the traversal. When an edge was temporarily outside the view, they can bring it back as soon as it becomes necessary.

A bad explanation, by contrast, mistakes the path for the structure. It drops edges that were not followed, forgets that it dropped them, and eventually starts believing that the order of explanation is the world itself.

That is dangerous.

What we need is the ability to keep the graph as a graph while choosing how to walk through it. And if that ability is not strong enough yet, we should preserve the graph itself before simplifying the walk.

Conclusion

Proceed with the discussion as a graph.

Of course, human working memory is limited. So viewports are necessary, and order is necessary.

But those are graph operations. They are not transformations into a tree.

The essential structure of information is a graph. A tree is only a partial structure inside it. Every time you fold a discussion into a tree, edges drop. When edges drop, dependencies drop. When dependencies drop, judgment fails.

If the bottleneck that prevents us from handling discussion as a graph is on the human side, I would rather work on extending the human side than carve the problem into pieces.

Externalize it. Link it. Preserve unresolved edges. Even when looking locally, do not stop treating it as a graph.

Keep the discussion as a graph. That does not mean "talk about everything at once." It means: do not pretend that edges you cannot currently see do not exist.

Note: This post is half a joke. I am not suggesting we replace tests with ritual or swap CI for dancing. I am also not trying to mock any specific religion or faith. I am borrowing the old language of prayer as a metaphor for uncertainty in the age of AI.

Introduction

Software engineers have spent a very long time loving reproducibility.

• same input, same output

• same code, same behavior

• same test, same result

• reproduce the bug, isolate the cause, fix it

That instinct is deeply compatible with the ethos of modern science. The Royal Society adopted the motto Nullius in verba in 1662: do not simply trust someone's word; appeal instead to experiment and evidence. And in a modern formulation, the National Academies describe reproducibility as obtaining consistent results under the same data, methods, code, and conditions.

That ethos has entered software engineering at the level of muscle memory. Lint, tests, type checks, CI, deterministic builds. We spent a long time pulling code away from prayer and toward reproducibility.

And then AI arrived.

AI is useful, fast, and no longer optional. But at the same time, a large part of what it produces is probabilistic. At least for language models, the natural explanation is that they generate the next token by sampling from a conditional probability distribution over possible continuations. You can see this both in research descriptions of autoregressive language models and even in practical tooling docs such as OpenAI's help page on logit_bias, which explicitly talks about shifting token likelihood.

So here we are: members of a profession that loves determinism, now delegating part of our daily work to a probabilistic transcendent thing.

That is why I suspect humanity may return, at least a little, to prayer.

Humanity Has Always Prayed Before What It Could Not Control

By "prayer," I do not only mean asking a god for favors. I mean something broader: a human practice of orienting ourselves toward what we cannot fully understand or control.

The Britannica entry on prayer describes it as communication with the sacred or holy, and notes that prayer appears across religions and historical periods. It also points out that prayer has long been tied to literature, sacrifice, and collective practice.

Human beings did not merely fold their hands in silence. We:

• made music for prayer

• danced for prayer

• built for prayer

• wrote books for prayer

• organized processions and formal acts for prayer

It does not take much history to see this. Göbekli Tepe, for example, is described by UNESCO as a monumental pre-pottery Neolithic site, often discussed in connection with ritual and communal gatherings. Humanity, it seems, was building enormous structures for ritual long before it built issue trackers.

A more familiar example, at least from where I stand, is Britannica's discussion of Shinto shrines, where ritual life is entangled with music, dance, procession, and offerings. In Japan, words such as gagaku, kagura, and shishi mai still carry that embodied sense that prayer was never just an inward thought.

That is the key point: humans have always built forms around what exceeded them. Prayer had gesture, sound, space, architecture, and books.

Science Cleanly Separated Prayer from Knowledge

One of the great achievements of modern science was that it separated these things much more sharply.

• it separated desire from verification

• it separated communal ritual from factual confirmation

• it separated beautiful narrative from reproducible procedure

Of course the real history is messier than that, and the relationship between religion and science cannot be reduced to simple opposition. But at the level of method, modern knowledge increasingly privileged not "who said it" but "can it be reproduced?"

Software inherited that attitude quite faithfully. In many ways, software has been one of the most diligent students of modern scientific discipline.

• bugs should be reproducible

• tests should remain stable across runs

• the same commit should yield the same artifact

• rules should live in static analysis rather than in prose

Prayer may remain in the privacy of the human heart, but it was not supposed to enter the decision process of a production deploy. That was the modern posture.

But AI Brought Probability Back into the Garden of Determinism

AI has now brought noise back into that garden.

This is not just the shallow claim that "AI lies." It is a more structural issue.

Language models are, at bottom, systems that operate over probability distributions. A research paper may phrase it in one way, product documentation in another, but the practical consequence is obvious to anyone working with these systems:

• the same request can yield a slightly different result

• small prompt changes can suddenly change the model's mood

• context placement matters

• some days a model feels brilliant, and the next day it feels mysteriously dull

That puts us in a strange condition.

On one hand, we cannot really refuse AI anymore. The speed difference is too large.

On the other hand, we cannot treat its output like a perfectly deterministic function. Of course we can surround it with evaluators, tests, lint, type systems, and review. But the first draft still arrives with the scent of probability on it.

At that moment, software development becomes, in part, an activity where reproducibility alone is not enough, but where we still have to hope for a good outcome.

Prayer Returns, Though Not as a Replacement for CI

Now for the half-joking core claim.

I think software engineers working with AI will gradually invent new rituals.

For example:

• always playing the same music before creating a new repo

• reciting the same prompt template before a difficult implementation

• treating AGENTS.md almost like scripture

• saying "this model is in a good mood today"

• wiping the desk before deploy for no technical reason whatsoever

• treating inference cost as a kind of offering

Technically, some of these rituals are meaningless. But not entirely meaningless. The point of ritual is not only to change the outside world directly. It is also to stabilize a community's posture toward uncertainty.

Just as prayer in religious history was both personal and communal, AI-age ritual may also align the team's emotional rhythm. Nobody truly believes that a small office ceremony will lower perplexity. But many teams will believe, correctly, that it helps them approach uncertainty together.

That, to me, is a small return of prayer.

Modern software engineering became strong by understanding, decomposing, reproducing, and controlling. AI introduces a new kind of object: something we cannot fully understand, yet still must collaborate with.

The answer is not to abandon science. Quite the opposite.

• lock down what can be made deterministic

• keep tests and type checks

• strengthen evaluation

• widen the boundary of what can be verified mechanically

And then, for the uncertainty that remains, humans may become just a little more ritualistic.

So the workflow of the future engineer may look like this:

1. write the tests

2. tune the seed and the temperature

3. still feel uneasy, so put on quiet music

4. finally, fold your hands

That would be a procedure both extremely modern and strangely ancient.

The Rock of the Greatest Programmer

And yes, I also imagine a more ridiculous future.

When beginning a new project, we first visit a place that enshrines a giant rock said to house the spirit of the greatest programmer. There we remove our shoes, open our laptops in silence, and recite prompts like liturgy.

"Keep syntax errors far from us."

"Cast out the mysterious off-by-one."

"Guide the dependencies of useEffect in righteousness."

"Grant mercy to this pull request in the eyes of the reviewer."

Someone rings a small bell. Someone starts a thin synth pad. Someone runs pnpm test.

Then everyone bows once toward the rock and says:

May today's model be slightly wiser than yesterday's.

Do I know whether the spirit of the greatest programmer really lives inside that rock? Of course not. But for now, that is not so different from the fact that none of us can fully explain everything going on inside AI systems either.

Conclusion

Human beings have always prayed, sung, danced, built, and written in the face of what they could not fully master. Science took the reproducible parts of that human struggle and sharpened them into method. Software engineering became one of its best heirs.

And yet AI has reintroduced probability into the center of that world. That is why I imagine engineers returning, just a little, to prayer.

Not by abandoning tests. Not by replacing method with superstition. But by keeping science in one hand and rediscovering, in the other, the posture of prayer.

We are not going back to a pre-scientific age. We are discovering that even after science, some human gestures remain useful when uncertainty refuses to disappear.

Software development may end up resembling an older human activity than we expected: hoping for good outcomes, arranging forms, aligning with collaborators, and finally looking upward for just a second.

At the very least, anyone already asking AI to write code has one foot in that future.

Since Coding Agents became practical, the central design question has shifted a little. It used to be mostly about how we should write code. Now it is equally about how much of that code we should entrust to an agent.

I want to call that degree of entrustment Agenty.

• 0 means we do not entrust anything to the agent

• 100 means we entrust everything to the agent

This is not a benchmark for model quality. It is a design parameter for repositories and architectures.

The important point is that higher is not always better. The goal is not to push an entire repo to 100. The goal is to decide what should stay near 0, and where high Agenty is actually appropriate.

From that perspective, the *.def.ts / *.impl.ts / *.test.ts split in fuckin-strict-nuxt-dmmf is more than a naming rule. It is a way of embedding into the repo itself which layers should stay low-Agenty and which layers may safely become high-Agenty.

And the core idea is not tied to Nuxt or Vue. It can be generalized much more broadly.

Agenty Should Be Designed Locally

Agenty is not one global knob for an entire repository. Different layers should carry different values.

I roughly think in three layers:

The numbers are not mathematically important. What matters is having a shared language: "def should stay low," "impl may go high."

Where Agenty Should Be Pushed Toward Zero

The first thing I want to say strongly is this: general coding rules and practices should be enforced as deterministically as possible through static analysis.

This is not where we should seek high Agenty. This is where Agenty should move toward 0.

For example:

• formatting

• lint rules

• type checking

• import boundaries and dependency direction

• exhaustiveness checks and unreachable-state detection

These should be things the repo itself can reject mechanically.

We should not outsource this to natural-language operations. Writing guidance in AGENTS.md or in skills can be useful as assistance, but that should not become the law of the repository.

Why not? Because natural-language operation is fundamentally non-deterministic.

• the model changes

• the prompt changes slightly

• the context window changes the interpretation

• the skill application order changes the result

If you store your invariants there, the rules themselves become probabilistic.

That is not "raising Agenty." It is simply making your boundaries vague.

My own intuition is that skills should not be the place where a repo's truth is defined. They are more like training wheels that help agents follow truths already embedded in the repo. The truth itself should live in a more static layer.

Static Analysis Is Also Domain Modeling

When people hear "static analysis," they often think only of ESLint or formatting. But the scope is wider than that. Domain modeling also appears at the type level.

That means the order should be:

1. first write definitions in a static layer

2. then supplement them with declarative tests

3. and put implementation last

Here, "definition" does not just mean a type alias. It includes:

• state spaces

• events

• transitions

• input/output contracts

• error representations

• dependency boundaries

These should be described before the implementation whenever possible.

I care a lot about this order. If implementation starts first, both humans and agents drift toward "whatever is easiest to write right now." If definition comes first, implementation is demoted into the job of satisfying a contract.

That demotion of implementation is exactly what makes high Agenty safe.

It Looks a Bit Like SDD, But It Is Not the Same

At first glance, this may look very close to specification-driven development. And in one sense it is. The overall direction is similar: put the specification first, establish agreement before implementation.

But I do not see them as identical. The reason is simple: the operational resolution we need is different.

In a real repository, it is hard to treat vague natural-language specifications as the master source of truth. Natural language is necessary for RFCs and design discussion, and I absolutely value that. But natural language inevitably has these properties:

• it leaves room for interpretation

• it tends to miss edge conditions

• it depends too much on the reader's experience

• it becomes probabilistically unstable when handed to agents

That is why I care less about "starting from natural-language specifications" and more about forcing those discussions to eventually collapse into def and spec.

In other words:

• RFCs and design discussion can stay in natural language

• but the master truth of the repo should be as formal as possible

Do not leave the specification sitting on the altar as prose. Translate it into types, state transitions, declarative tests, and static constraints. Only then do humans and agents truly share the same contract.

That point matters a lot to me. It is not that SDD is bad. It is that in the age of Coding Agents, a specification process whose master artifact remains natural language is not enough. Using probabilistic and ambiguous prose as the final truth of the repository is hard to sustain in the real world.

So the question is not only "should we write specs first?" It is also "how far must we formalize them?"

def / spec / impl Is Framework-Independent

What is interesting in fuckin-strict-nuxt-dmmf is not just that it separates *.def.ts from *.impl.ts. It is that the separation criterion is based on responsibility rather than framework.

The point is not "split things this way because it is Vue." The same way of thinking can work for React, Svelte, or server-side applications.

At an abstract level, the split looks like this:

feature/
  order.def.ts
  order.spec.ts
  order.impl.ts

Or more generally:

feature/
  order.def.*
  order.spec.*
  order.impl.*

And the meaning of those files is roughly:

• def: low Agenty; changing it implies design intent, so agents should not touch it casually

• spec: low-to-medium Agenty; this supplements acceptance conditions and declarative scenarios

• impl: high Agenty; this is the part with the most freedom inside the constraint space

Once that split exists, both instructions and operations become clearer.

• "Only change def when there is an explicit design change"

• "Fix impl so that it satisfies spec"

• "Read diffs in def as specification changes"

• "Read diffs in impl as implementation work"

This is the point where Agenty becomes topology in the repository.

Agenty Is Also a Framework for Education

This is not only about repo design or agent operations. It is also a framework for educating engineers.

To be honest, writing def in a necessary-and-sufficient way is difficult. It is not an easy task.

• What counts as state?

• What counts as an event?

• Where should we identify things as the same, and where should we split cases?

• Which invalid states should be represented explicitly?

• Which boundaries should be fixed statically?

Writing these things down formally, without escaping into implementation, takes real training.

But I think that is good. More than that, I think it should be hard.

Because the ability to express domain specification formally before implementation is becoming more important. As Coding Agents become stronger, the scarcity value of "typing fast" goes down. What goes up instead is the value of knowing:

• what should be defined at all

• what can safely be delegated

• which contracts are strong enough for automation

• whether generated implementation truly satisfies the specification

In that sense, writing def is not just a preprocessing step. It trains the actual muscle of formalizing a domain.

This is not totally new. It is close to familiar practices such as "write an RFC before implementation" or "discuss the design before implementation." Coding Agents simply make the importance of that order much stronger.

In the past, even if design was sloppy, humans often reconciled the mess while writing the implementation. But once agents can generate large amounts of implementation quickly, sloppiness in the definition layer gets amplified downstream. That is why discussing def first and tightening spec first now has educational weight as well.

I think the question of how we should train newer engineers in the age of Coding Agents is already becoming a real topic, or at least is clearly moving in that direction. If agents write much of the implementation, then what exactly should junior engineers learn?

This framework can be one answer.

• write def first

• make acceptance conditions explicit in spec

• build impl together with agents

• review the result against the contract and the diff

That shifts the focus of training away from typing speed and memorization, and toward:

• carving up the domain

• designing boundaries

• describing state transitions

• expressing specifications precisely

• verifying generated artifacts

I think that is healthy. Implementation skill does not become unnecessary. In fact, good def and spec still require implementation intuition. But the order changes. The center of gravity moves toward writing the specification first, then reading, correcting, and evaluating implementation.

And this is sustainable not only for individuals, but for organizations too. Knowledge stops living only in a senior engineer's head or in the exact phrasing of some lucky prompt. Instead it accumulates in the repository as static assets such as def and spec. That helps education, maintenance, and handover at the same time.

Where High Agenty Actually Belongs

So where should high Agenty go?

My answer is: places where multiple implementations are acceptable, and correctness can still be checked mechanically afterward.

For example:

• mappings

• adapters

• UI wiring

• API client composition

• connecting view and state

• domain implementation with lots of boilerplate

These are areas where there may be many possible implementations, but the conditions to satisfy can still be written down relatively clearly. If contract and spec are fixed first, the implementation side can become quite high-Agenty.

By contrast, high Agenty is dangerous in places like:

• the state machine itself

• exceptional business rules

• boundary-value and invalid-state definitions

• architectural boundaries

• repo-wide coding rules

Those are not things you can safely "fix later." If they drift, every layer of automation after them becomes unstable.

In Web Frontend, Write the VM into def

This matters especially in web frontend.

I think we should revisit an MVVM-like separation. But my interest is not "let's make a ViewModel class." My interest is writing the state transitions of the VM layer as definitions before implementation.

For example:

export type CheckoutState =
  | { kind: "Idle"; cart: Cart }
  | { kind: "Submitting"; cart: Cart }
  | { kind: "Succeeded"; orderId: OrderId }
  | { kind: "Failed"; cart: Cart; reason: CheckoutError };

export type CheckoutEvent =
  | { type: "Submit" }
  | { type: "Resolve"; orderId: OrderId }
  | { type: "Reject"; reason: CheckoutError };

export type Transition = (state: CheckoutState, event: CheckoutEvent) => CheckoutState;

Something like this belongs in a file such as checkout.vm.def.ts.

The point is not to freeze how the UI looks. The point is to freeze what states the screen has, and how events move it between them.

That layer should stay low-Agenty. It directly encodes product behavior.

By contrast, the following may tolerate higher Agenty once the contract is fixed:

• mapping state into props

• splitting components

• wiring event handlers

• implementing side effects

But there is an important caveat here: the part corresponding to V in MVVM is still not easy to control well through AI alone. Layout, typography, spacing, motion, and visual hierarchy are not automatically solved just because the state contract is good. That layer has a difficulty of a different kind.

I think the V side should often be treated not as an extension of state management, but as a separate source of truth integrated with design tools. For example:

• screen states and transitions live in VM def

• acceptance conditions live in VM spec

• layout and visual structure live in design tools

• code exists to connect those worlds

So Agenty in web frontend is not a single axis. At minimum:

• VM can be split into low-Agenty definition and higher-Agenty implementation

• V is still hard to steer with AI alone, and should be discussed with design systems and design tools as first-class peers

That is why, in web frontend, I would frame it like this:

• VM def should stay low-Agenty

• VM spec should stay medium

• VM impl may go high

• View should be handled on a separate axis, connected to design tools rather than collapsed into state management

If you do that, the semantics of product behavior remain anchored in the repository through VM, while the visual layer is delegated to a more appropriate design workflow. In other words, you do not have to force meaning and form into the same box.

This Also Improves Operations and Code Review

This design is not merely AI-friendly. It matters in day-to-day source code operations as well.

First, it gives you separation of specification. If def and spec are placed in front, the diff separates "what we intended to change" from "how we realized it."

Second, it improves editability by agents. If the editable region is concentrated in impl, the instruction becomes much simpler: "implement this while preserving the contract."

Third, it improves reviewability. Reviewers no longer have to read every diff in the same mode.

• changes in def imply specification review

• changes in spec imply expectation review

• changes only in impl imply implementation review

This meaning of diffs becomes more important in a high-Agenty world. Agents can write a huge amount of code. Human review bandwidth does not expand at the same rate.

That is exactly why the diffs humans truly need to read must remain as static, declarative, and small as possible. And those static, declarative diffs are also the assets that can be taught, handed over, and maintained sustainably across an organization.

Conclusion

What I want to express with the word Agenty is not merely "how much should we let AI do?" It is a design question about which parts may remain probabilistic, and which parts must stay decisively fixed.

General rules, domain boundaries, state transitions, contracts. These should be kept as static as possible, as type-level as possible, and as mechanically checkable as possible. Then declarative tests should supplement them. Implementation should come last.

High Agenty belongs only where the law of the repository is already fixed, and where exploration inside that law is safe.

The point is not to surrender the whole repository to agents. The point is to let architecture build the sandbox in which agents are allowed to be wild.

I think that is what design in the age of Coding Agents looks like.

Over the last few years, the word Signals has spread very quickly. But it often points to two different things at the same time.

One meaning is the narrow one: signals as runtime reactive primitives, like Vue's ref() or Solid's createSignal(), which hold values and dependency relationships at runtime. The other meaning is larger: signals as a rendering context that includes DOM tracking itself, as in Svelte, Solid, and Vue Vapor.

I think these two should be separated deliberately. The former is reactivity of values. The latter is reactivity of the renderer.

If we blur them together, we get lazy conclusions like Signals = the end of VDOM. But that is not what the ecosystem actually says. The TC39 Signals proposal explicitly says in its FAQ that signals can work with VDOM, with the native DOM, or with a combination of both. So Signals are not a rendering strategy by themselves.

To talk about this properly, we need to go back a little.

Knockout.js and the Observable era

Whenever I see the current signals discourse, I think of Knockout.js. Knockout had observable and computed very early, with automatic dependency tracking. And the Knockout docs explain something crucial: declarative bindings themselves are implemented as computed observables.

That matters. A lot of what we now call "signal-like" is not actually new. Wrapping values, tracking dependencies, and updating part of the UI when those values change has been around for a long time.

For a while, though, the standards conversation focused less on signals and more on observables. The original TC39 Observable proposal tried to standardize push-based streams of multiple values, such as DOM events, timers, and sockets. Today the work continues as the WICG Observable proposal, and that repository explicitly documents the proposal's history: the 2015 TC39 attempt, the 2017 WHATWG DOM discussion, and the 2019 revival attempt.

It helps to draw a line here:

• Observables mainly model event streams over time.

• Signals mainly model current values plus a dependency graph.

They are related, but not identical. Observables are primarily temporal. Signals are primarily current-value oriented.

That is why the history of Observable standardization and the current Signals proposal are connected, but not interchangeable.

It is also notable that the Signals proposal is explicitly centered less on a developer-facing API and more on the core semantics of an underlying signal graph shared by frameworks. Even here, Signals are already being framed as a substrate beneath frameworks, not merely as a userland convenience API.

Signals and Signals.

This is the core distinction I want to make.

The word "signals" is being used at at least two different scopes.

1. Signals as runtime primitives

This is the narrower meaning.

Vue's reactivity docs explain that in Vue 3, reactive() uses Proxies while ref() uses getters and setters to implement track() and trigger(). The same page also states that Vue's reactivity system is primarily runtime-based.

Solid's createSignal() docs describe a primitive where the getter tracks dependencies inside a reactive context and the setter notifies dependent computations.

At this layer, signals are something like this:

signal cell -> track reads -> trigger writes -> rerun effects

The main character here is the value. Which value was read? Which effect depends on it? What should be re-executed after mutation?

Vue ref and Solid createSignal are both easy to understand in this sense.

2. Signals as a rendering architecture

But there is another meaning.

Svelte describes itself as a UI framework that uses a compiler so the browser does minimal work. The FAQ in the TC39 Signals proposal also points to Svelte 5 as an example where runes are transformed into an internal signals library. The Solid README shows compiled output that creates real DOM nodes and updates only the exact insertion point instead of rerendering the whole button. And Solid's fine-grained reactivity docs explicitly contrast targeted updates in Solid with broader component re-execution in React.

At that point, signals are no longer just value containers. They become part of a context that also includes DOM-side tracking: which signal feeds which text node, which attribute, which exact sink in the rendered output.

signal graph -> compiler-known DOM sinks -> exact DOM mutation

Now part of the renderer's job has been absorbed into the dependency graph itself. The re-execution boundary is no longer naturally "the whole component"; it gets much closer to the concrete DOM sink.

In this sense, "signals" is not just the name of a primitive. It is the name of an architectural stance. Here I repeat the same word, Signals.

Retained UI

So where do VDOM and React Fiber fit?

I think of them as Retained UI. That is: a runtime that first keeps the desired UI as nodes, frames, or trees in memory, and then manages updates from there.

React's Render and Commit docs explain the sequence clearly:

• render calls components,

• commit applies the result to the DOM,

• and on re-render React computes what changed and applies only the minimal necessary DOM operations.

Then React Fiber architecture goes deeper:

• rendering generates a tree in memory,

• a new tree is diffed against the previous one,

• Fiber is a unit of work, effectively a virtual stack frame specialized for React.

This is the important part. In React, the primary structure is not a signal dependency graph. It is the in-memory tree / fiber graph. State updates are the trigger, but the actual responsibility for DOM mutation belongs to the reconciler and the renderer.

In other words:

state update -> rerun components -> new in-memory tree -> reconcile -> commit DOM

That does not mean React has no reactivity. It means reactivity is not foregrounded as a first-class dependency graph in the same way it is in Vue or Solid. In React, reactivity mostly shows up as a question of which component subtree must be reevaluated, while Retained UI remains the main update engine.

Vue has long sat in between

What makes Vue interesting is that it has long contained both layers.

Vue's Rendering Mechanism docs explain that Vue:

1. compiles templates into render functions,

2. performs mount as a reactive effect,

3. reruns that effect when dependencies change to create a new VDOM tree,

4. patches the DOM through reconciliation.

The same page also explains compiler-informed virtual DOM, including patch flags and tree flattening.

So Vue has long had:

• a lower layer of reactivity via ref, reactive, and effects,

• and an upper layer of compiler-assisted VDOM runtime.

That is not merely "between React and Solid". It is more precise to say that Vue has long combined Signals and Retained UI in one system.

This is why Vue makes the bigger point visible: signals do not inherently negate VDOM. Signals can sit beneath VDOM. Or they can sit beneath a more direct DOM-oriented renderer.

And again, the TC39 Signals proposal says exactly this: signals can back VDOM frameworks, native DOM frameworks, or hybrids.

The future of Vue Vapor

From this perspective, Vue Vapor becomes much easier to read.

The release note for Vue 3.6.0-beta.1, published on December 23, 2025, describes Vapor Mode as:

• a new compilation mode for Vue SFCs,

• aimed at reducing baseline bundle size and improving performance,

• 100% opt-in,

• feature-complete for the intended subset, but still unstable.

But the really important details are the interop details. That same release note says:

1. Vapor-only mode does not support Suspense directly, but Vapor components can be rendered inside a VDOM Suspense

2. a VDOM app created with createApp can use Vapor components through vaporInteropPlugin

3. a Vapor app can also use VDOM components through the same interop path

4. mixed nesting still has rough edges, so Vue recommends distinct regions

That is very revealing. At least in the near future, Vue Vapor is not "the next Vue that fully replaces VDOM." It looks much more like a high-performance subset that grows through interoperability with the existing Vue runtime.

The public Vapor Roadmap reinforces this. It includes work around:

• SSR / Hydration

• Template Ref Interop

• Suspense

• Vue Router

• Pinia

• Nuxt.js

• DevTools Integration

• Vue Test Utils

That tells us something simple. The fundamental challenge of Vapor is not merely "can it update the DOM faster?" The challenge is how it fits the Vue ecosystem as a whole.

So my reading of Vue Vapor's future is this:

• VDOM is not just leftover legacy weight

• Vapor becomes the high-performance subset for perf-sensitive paths

• the VDOM runtime remains important for interop, ecosystem breadth, and library compatibility

• and the boundary between the two becomes more explicit over time

That feels very Vue-like to me. Vue has always cared about progressive and incremental adoption. If Vapor succeeds, I suspect it will succeed less by replacing everything and more by establishing better architectural boundaries.

Why this matters in comparison with React

In React, Retained UI is closer to the core than value-level reactivity. Fiber handles scheduling, reconciliation, prioritization, and work management.

By contrast, the direction of Vapor, Svelte, and the Solid compiler is to bring dependency tracking and DOM sink tracking closer together, reducing how much they need an in-memory tree as the primary update mechanism.

The comparison should not be "which one wins." The real comparison is: which layer owns update responsibility?

• React / classic VDOM: the in-memory node runtime owns updates

• runtime signals: the signal graph owns invalidation, but the renderer is still separate

• compiler + DOM-tracker signals: the signal graph begins to absorb part of the renderer's responsibility

These are not the same thing.

And Vue, right now, is trying to carry all of them in one system. ref remains. VDOM mode remains. And Vapor grows on top of that.

I think that is a healthy direction.

Signals are not a magic silver bullet. And VDOM is not merely a relic of the past. Retained UI is still strong at component composition, dynamic rendering, ecosystem interop, debuggability, and tooling alignment. At the same time, compiler-guided Signals. are strong on fine-grained hot-path updates and baseline bundle size.

The question is almost never "which one should disappear?" The real question is "where should the boundary be?"

This is a personal essay, not an official position of the Vue Team, the React Team, or TC39.

Note: I am not a mathematics specialist. This essay is an attempt to use the vocabulary of category theory, algebraic effects, and Applicative structure to understand React, so please read it as a proposed reading rather than a rigorous theorem. If you notice a mathematical mistake, I would be happy to be corrected.

Introduction

"UI = f(State)" - this is one of the most widely circulated equations in discussions about React. At first glance, the equation looks simple and seems to capture the essence of React: if the state is determined, the UI is determined.

However, when we read this equation carefully in mathematical terms, several points need clarification.

• What is this f? Is it a "function" in the mathematical sense?

• If it is a function, in which category is it a morphism?

• Are React's notions of "pure" and "idempotent" the same as the mathematical ones?

In this essay, I will use the vocabulary of category theory, algebraic effects, and Applicative structure to try to read React Components more precisely.

The Mathematical Meaning of "Pure"

Let us clarify the mathematical meaning of the word "pure," which is often used in React documentation and discussions.

In mathematics, a pure function is a mapping with referential transparency. In the language of category theory, it corresponds to a morphism in the category of sets, Set:

$$f: A \to B$$

This morphism f satisfies the following:

• It always returns the same output for the same input (deterministic)

• It does not read from or write to external state (no side effects)

• It does nothing other than compute a value (no observable effects)

Now consider a React Function Component:

function Greeting({ name }) {
  const [count, setCount] = useState(0);
  const theme = useContext(ThemeContext);

  useEffect(() => {
    document.title = `Hello, ${name}`;
  }, [name]);

  return (
    <h1 style={{ color: theme.primary }}>
      Hello, {name} ({count})
    </h1>
  );
}

This Component:

• reads internal state and receives an updater through useState

• reads external state from the component tree through useContext

• schedules a side effect through useEffect

This is not a morphism in Set. It reads things other than its argument (props), and it does things other than compute a pure value.

A React Component is not a "pure function" in the mathematical sense.

Then why does React call Components "pure"? Because React uses the word "pure" in a different sense. In React, "pure" means:

Having no observable side effects during rendering - more precisely, behaving correctly inside React's effect system.

This is a much weaker condition than mathematical purity, and confusing these terms leads to a fundamental misunderstanding.

The Original Meaning of "Idempotent"

React's documentation says the following (Components and Hooks must be pure):

"Components must be idempotent - React components are assumed to always return the same output with respect to their inputs - props, state, and context."

What does "idempotent" mean mathematically here?

Idempotence in Mathematics

The definition of an idempotent element in algebra is:

Definition (idempotent element). In a monoid (M, ·, e), an element a ∈ M is idempotent if it satisfies a · a = a.

Extending this to functions:

Definition (idempotent endomorphism). In a category 𝒞, a morphism e: A → A is idempotent if it satisfies e ∘ e = e.

These two definitions follow Eric W. Weisstein, "Idempotent," MathWorld for idempotent elements and Emily Riehl, Category Theory in Context, Example 3.2.14 for idempotent endomorphisms.

Concrete examples:

• The absolute value function is idempotent: ||x|| = |x|

• A projection matrix P is idempotent: P^2 = P

• Math.floor is idempotent: Math.floor(Math.floor(x)) === Math.floor(x)

What matters here is that idempotence is a property of an endomorphism f: A -> A. Applying f once more to the output of f does not change the result - this is the original meaning of idempotence.

React's "Idempotence" Is Not Mathematical Idempotence

When React says a Component is "idempotent," it means "it returns the same output for the same input." Mathematically, this is not idempotence. It should be called determinism or well-definedness.

Why?

1. The type of a Component is Props -> VDOM, and Props != VDOM. In other words, it is not even an endomorphism.

2. To verify f ∘ f = f, we need to pass the output of f back into f as input. But passing a Component's output (VDOM) into the Component's input (Props) has no meaning.

3. What React is saying is "f(x) = f(x) (the same input gives the same output)," not "f(f(x)) = f(x)."

f(x) = f(x) is a property every function should satisfy by definition, and it is not something we would go out of our way to call "idempotence." More precisely, what React intends is probably that "even if Hooks have internal state, the Component returns the same VDOM for the same tuple of (props, state, context)." But this is a "deterministic function," not an "idempotent" one.

The Rendering Operation Can Be Expressed as Idempotent

However, if we shift our point of view, React does contain an operation that can be expressed as idempotent.

Fix a state s, set aside user Effects and external I/O for the moment, and look only at the DOM state. Then consider the composition of rendering and committing as a single operation:

$$ \begin{array}{c} u_{s}: \mathrm{DOM} \to \mathrm{DOM} \\ u_{s} = \operatorname{commit}(\operatorname{reconcile}(\operatorname{render}(s))) \end{array} $$

Then:

$$u_{s}(u_{s}(\operatorname{dom})) = u_{s}(\operatorname{dom})$$

Applying render and commit twice for the same state yields the same DOM state as applying them once, if we look only at the DOM state. If there is no diff, the second application can be treated as a no-op. This is idempotence when viewed as a DOM state transformation.

In other words, what should be treated as idempotent in React is not the Component function itself, but the idealized render-and-commit operation u_s. This distinction is decisive.

React Fiber and Algebraic Effects

Now let us turn to React's internal structure.

React Fiber - React's core runtime - has features that resemble Algebraic Effects. Dan Abramov also introduces algebraic effects as a way to think about some things React does (Dan Abramov, "Algebraic Effects for the Rest of Us", 2019). The same article explicitly calls the connection to React "a stretch," says Suspense is not an algebraic effect per se, and notes that JavaScript cannot really resume execution later.

What Are Algebraic Effects?

Algebraic effects are a mathematical framework for separating computation from effects (side effects). The general explanation in this section follows Plotkin and Power, "Algebraic Operations and Generic Effects" (2003).

The basic structure consists of three elements:

1. Effect signature: the set of available operations

2. Computation: a program that may call effect operations

3. Handler: an interpreter that gives meaning to effect operations

This is not React's actual implementation, but pseudocode for explaining the correspondence:

// Effect signature
effect GetState  : Unit -> State
effect SetState  : State -> Unit
effect ReadProps : Unit -> Props
effect ReadContext: Key -> Value
effect Suspend   : Promise<A> -> A
effect Throw     : Error -> bottom

// Handler (= React Fiber runtime)
handler ReactFiber {
  return vdom -> vdom
  ReadProps(_, resume)      -> resume(currentProps)
  GetState(_, resume)       -> resume(currentFiber.memoizedState)
  SetState(newState, resume) -> enqueueUpdate(newState); resume(unit)
  Suspend(promise, retryRender) -> showFallback(); promise.then(() -> retryRender())
  Throw(error, _)           -> propagateToErrorBoundary(error)
}

Here the relationship between the React Function Component written by the user and the React Fiber runtime can be mapped as follows:

In this correspondence, React Hooks can be read as effect operations:

Here useProps is not a real React API. In the rest of this essay, I will generalize props - normally received as a Component function argument - as a conceptual Hook operation that reads the current props from the handler.

A user-written Component can be viewed as an effectful computation, and React Fiber as its handler (interpreter).

However, this is not a claim that algebraic effects alone explain all of React. In particular, the static shape of the Hook call sequence required by the Rules of Hooks is hard to capture using only ordinary monads or algebraic effects. The order should be: the Rules of Hooks come first, constraining the shape of the Component body; as a result, the Hook call sequence can be embedded fairly faithfully into an Applicative / Free Applicative-like structure.

Function Composition in the Kleisli Category

The "function composition" implicitly assumed by "UI = f(State)" also needs to be examined mathematically.

Kleisli Category

Given a monad T on a category 𝒞, we can construct the Kleisli category 𝒞_T. Here I mean a categorical monad: an endofunctor T: 𝒞 → 𝒞 together with natural transformations η: Id ⇒ T (unit) and μ: T² ⇒ T (multiplication), forming a triple (T, η, μ) that satisfies the monad laws. For the definitions of monad and Kleisli category, see Emily Riehl, Category Theory in Context, Definition 5.1.1 and Definition 5.2.10:

• Objects: the same as 𝒞

• Morphisms: a morphism A -> B in 𝒞_T is a morphism A -> T(B) in 𝒞

• Composition: for f: A -> T(B) and g: B -> T(C), their Kleisli composition is:

$$g \circ_{T} f = \mu_{C} \circ T(g) \circ f$$

That is:

$$ A \xrightarrow{f} T(B) \xrightarrow{T(g)} T(T(C)) \xrightarrow{\mu_{C}} T(C) $$

A React Component Is a Kleisli Morphism

From this point on, this is not an official formal semantics of React. It is a sketch for reading React's different effects through one abstract effect monad. Let R be that hypothetical React effect monad. If we follow the surface syntax of JavaScript, the type of a React Component can be read as:

$$\mathrm{Component}: \mathrm{Props} \to R(\mathrm{VDOM})$$

This is a way to read it as a morphism Props -> VDOM in the Kleisli category Set_R. However, if we want to handle the program structure of Hook operations uniformly, props can also be moved inside the computation as a conceptual Hook operation:

$$\operatorname{useProps}: R(\mathrm{Props})$$

In this reading, Props -> R(VDOM) is the expression where props are supplied first, while R(VDOM) with useProps is the expression where React Fiber supplies props during interpretation.

Reading it as a Kleisli morphism (an effectful computation), rather than as a Set morphism (a pure function), is closer to React's behavior.

Component Composition

Consider component composition in JSX:

function Parent({ data }) {
  const processed = use(processData(data));
  return <Child items={processed} />;
}

If we abstract this dependency, we can sketch it as Kleisli composition:

$$\mathrm{Parent} = \mathrm{Child} \circ_{R} \mathrm{process}$$

Here ∘_R is not ordinary composition ∘ in Set, but Kleisli composition for the abstracted React effect monad. Because it passes through a call to use - that is, an effect corresponding to Suspend - it is hard to express as pure function composition.

In other words, if we include Hooks and Suspense, "function composition" in React cannot be fully captured by ordinary function composition alone. This is another reason why "UI = f(State)" is not naively correct.

Monad Bind and an Applicative Skeleton - What a Component Body Really Is

Now that we understand Kleisli composition, let us dig one layer deeper into what is happening inside the function body of a Component.

For a monad T, the bind operation (written >>= in Haskell) has the following type:

$$\operatorname{bind}_{T}: T(A) \times (A \to T(B)) \to T(B)$$

It is the operation that "takes the result of an effectful computation and passes it to the next effectful computation." Haskell's do notation is syntactic sugar for writing chains of bind in a readable way:

-- do notation
do
  state <- getState
  ctx   <- readContext themeCtx
  pure (view state ctx)

-- Desugared (chain of bind)
getState    >>= \state ->
readContext themeCtx >>= \ctx ->
pure (view state ctx)

This perspective is useful when reading a React Component body as a computation that calls effects in order and returns VDOM from their results. If we also include useProps in the abstraction, for example:

function Component() {
  const props = useProps(); // conceptual Hook operation: ReadProps >>= \props ->
  const [state, setState] = useState(init); // <- bind: GetState >>= \state ->
  const ctx = useContext(ThemeCtx); // <- bind: ReadContext >>= \ctx ->
  return <View name={props.name} state={state} ctx={ctx} />; // <- pure: return (View props state ctx)
}

Locally, the body of a React Component can be read as something close to do notation for the React effect monad.

There is an important caveat, though. An ordinary monad is too expressive to represent React's requirement that the Hook call sequence have a static shape. With bind, the result of an earlier computation can decide the very shape of the effects that run next:

do
  x <- action1
  if condition x
    then do { y <- action2; pure (f x y) }  -- action2 is present
    else pure (g x)                          -- action2 is absent

This is natural to write as monadic computation. But React Hooks specifically forbid changing the shape of the Hook sequence based on values or branches.

The property "the shape of the effects is known first, and only the values flow in later" is closer to Applicative than to Monad. An Applicative F roughly has these operations:

$$ \begin{array}{c} \operatorname{pure}_{F}: A \to F(A) \\ \operatorname{ap}_{F}: F(A \to B) \times F(A) \to F(B) \end{array} $$

Here ap_F corresponds to <*> in Haskell.

An Applicative does not have a bind-like F(A) -> (A -> F(B)) -> F(B). Therefore, the result of a previous effect cannot choose the structure of later effects. Instead, the skeleton of which effects are used, and in which order, is fixed statically, and their results are fed into a pure function.

For a Component that satisfies the Rules of Hooks, we can very roughly sketch the Hook call sequence in an Applicative-like form:

pure view <*> useProps <*> useState init <*> useContext themeCtx

This is not React's implementation. But once props are also included as the conceptual Hook useProps, an Applicative skeleton is closer than a chain of bind as a structural sketch of "the input and Hook sequence are fixed, and JSX is constructed from the values obtained from them."

The Rules of Hooks Make an Applicative Skeleton Possible

Now reconsider React's Rules of Hooks:

• Do not call Hooks inside loops, conditions, or nested functions

• Hooks must always be called at the top level of a Function Component

The order matters here. The rule comes first. Rather than saying that "the Applicative expression explains the Rules of Hooks," it is better to say that the Rules of Hooks constrain the shape of the Component body enough that it can be embedded into an Applicative skeleton of Hook operations, including useProps.

By "faithful embedding" here, I only mean that the number and order of Hook calls can be extracted as program structure without being lost.

The React equivalent is forbidden:

// NG: Hook inside a conditional branch
function Component({ condition }) {
  const [x] = useState(0);
  if (condition) {
    const y = useContext(Ctx); // <- Rules of Hooks violation
    return <A x={x} y={y} />;
  }
  return <B x={x} />;
}

Why? React Fiber stores the order of Hook calls as a linked list. If the number or order of Hook operations changes from render to render, Fiber cannot correctly line up the previous render's result with the current Hook calls.

On the other hand, it is fine to fix the Hook sequence first and then branch in the UI returned from the resulting values:

// OK: the Hook sequence is fixed
function Component({ condition }) {
  const [x] = useState(0);
  const y = useContext(Ctx);
  return condition ? <A x={x} y={y} /> : <B x={x} />;
}

In other words, what React needs to keep static is not "the rendering result that uses values," but the program structure of Hook operations. Because the Rules of Hooks fix that shape first, it becomes possible to map it into a structure such as FreeApplicative HookOp, or, if we also include the recursion of the component tree, something like Fix (FreeApplicative HookOp).

A related experimental implementation is ubugeeei/mreact. It expresses React Hooks as an indexed monad in Haskell, representing the Hook call order as a type-level list so that the Rules of Hooks can be handled by the type checker. In the framing of this essay, that type-level Hook list is better understood not as an expression attached to React after the fact, but as a capture of the program shape that the Rules of Hooks already force: a static skeleton closer to Applicative / Free Applicative structure.

use and Suspense - A Concrete Form That Resembles Algebraic Effects

The use Hook and Suspense are where the algebraic-effects-like behavior in React is easiest to see. However, this does not mean that React's implementation has real algebraic effects.

function UserProfile({ userId }) {
  const user = use(fetchUser(userId));
  return <div>{user.name}</div>;
}

function App() {
  return (
    <Suspense fallback={<Loading />}>
      <UserProfile userId={1} />
    </Suspense>
  );
}

We can describe this mechanism with the vocabulary of algebraic effects:

1. use(promise) corresponds to performing an effect operation:

If the Promise is unresolved, the public React API says that the Component suspends (use integrates with Suspense). This can be read as a non-local control flow resembling a "call to an operation" in algebraic effects.

2. Suspense corresponds to an effect handler:

Suspense handles the suspension, displays the fallback UI, and retries rendering after the Promise resolves.

3. On re-render, use(promise) returns the resolved value:

This resembles the algebraic-effects operation of "passing a value to the continuation and resuming it." However, React is not actually saving the JavaScript execution stack and resuming from that point. It re-renders the Component tree after the Promise resolves. This point follows the React Suspense documentation and Dan Abramov's caveat in "Algebraic Effects for the Rest of Us".

In pseudo handler notation:

handle(UserProfile(userId)) with {
  return vdom -> vdom
  Suspend(promise, retryRender) ->
    display <Loading />;
    await promise;
    retryRender()  // <- re-render, not a real continuation resume
}

What is especially important here is that use can suspend a Component's render, and React can re-render it later.

An ordinary JavaScript function runs to completion once called. With async / await, execution can continue from an await point, but React Components are not written as async function. Even so, React uses Suspense boundaries and re-rendering to create the experience that it "waited there and continued once the value arrived." This is what makes the behavior reminiscent of algebraic effects (or delimited continuations).

The Mistake of Client-Server "Isomorphism"

There are terms such as "Isomorphic JavaScript" and "Universal JavaScript." They are also often used in the context of Server Components, but is this "isomorphism" mathematically correct?

Isomorphism in Category Theory

Definition (isomorphism). In a category 𝒞, a morphism f: A → B is an isomorphism if there exists a morphism g: B → A such that g ∘ f = id_A and f ∘ g = id_B.

This definition follows Emily Riehl, Category Theory in Context, Definition 1.1.10.

An isomorphism means a reversible transformation that preserves structure. If A and B are isomorphic, then they cannot be distinguished category-theoretically.

Server Rendering and Client Rendering Are Not Isomorphic

Consider server rendering and client rendering as functors:

$$ \begin{array}{c} F_{S}: \mathrm{Component} \to \mathrm{HTML} \\ F_{C}: \mathrm{Component} \to \mathrm{DOM} \end{array} $$

To begin with, HTML != DOM. Since the output categories are different, there is no room to construct an isomorphism between F_S and F_C.

A transformation from an HTML string to the DOM (parsing) exists, but the reverse transformation (DOM -> HTML) is serialization. The composition of these two is not necessarily the identity morphism, because event handlers, internal state, closures, and so on are lost.

A More Accurate Description: Different Effect Handlers

In the framework of algebraic effects, server rendering and client rendering can be understood as different handlers for the same effectful computation:

$$ \begin{array}{c} \mathrm{Component}: \mathrm{Props} \to \mathrm{Eff}_{\mathrm{React}}(\mathrm{VDOM}) \\ \mathrm{handleServer}: \mathrm{Eff}_{\mathrm{React}}(\mathrm{VDOM}) \to \mathrm{HTMLString} \\ \mathrm{handleClient}: \mathrm{Eff}_{\mathrm{React}}(\mathrm{VDOM}) \to \mathrm{DOMMutations} \end{array} $$

As the React documentation explains, the difference between Server Components and Client Components appears as a difference in execution environment and available APIs. In this essay's reading, we can understand that as a difference in available effect signatures:

• Server Component: can directly use server-side operations such as DB queries and file system access. Cannot use many Hooks such as useState and useEffect.

• Client Component: can use client-side APIs such as useState and useEffect. Cannot directly bring server-only code into the Client module subtree.

This is not an isomorphism. It should be understood as an inclusion relation or subtyping between effect signatures.

$$ \begin{array}{c} \mathrm{ServerEffects} \neq \mathrm{ClientEffects} \\ \mathrm{SharedEffects} = \mathrm{ServerEffects} \cap \mathrm{ClientEffects} \end{array} $$

The shared portion works as Components that can become either Server Components or Client Components depending on usage. Server-only operations are available only on the server side, and client-only operations are available only on the client side. This is not "isomorphism," but compatibility based on partial overlap between effect signatures.

Conclusion: Rewriting UI = f(State)

Let us summarize the discussion so far.

Problems with the Naive Equation

$$\mathrm{UI} = f(\mathrm{State})$$

Problems with this equation:

1. f is not a pure function - it executes effects through Hooks

2. The word "idempotent" is misused - the Component function is not mathematically idempotent (the rendering operation can be expressed as idempotent)

3. Composition cannot be captured by ordinary function composition alone - effect interpretation can be expressed as Kleisli composition, while the Hook sequence fixed by the Rules of Hooks is more naturally viewed as Applicative structure

4. Client-Server is not an isomorphism - they can be expressed as different effect handlers

A More Accurate Description

In this essay's reading, at the level of JavaScript's surface syntax, a React Component can be expressed as a Kleisli morphism of the effect monad R:

$$\mathrm{Component}: \mathrm{Props} \to R(\mathrm{VDOM})$$

However, if we want to handle the program structure of Hook operations uniformly, props should be moved inside as a conceptual Hook operation rather than kept only as an external argument:

$$\operatorname{useProps}: R(\mathrm{Props})$$

In that case, the equation above captures the aspect that a Component is an effectful computation interpreted by the React runtime. It does not by itself capture the static Hook sequence required by the Rules of Hooks. For the program structure of Hook operations, the Rules of Hooks fix the shape first. Because of that constraint, the structure can be mapped into an Applicative / Free Applicative-like skeleton that also includes ReadProps:

$$\mathrm{HookProgram}\ A \approx \mathrm{FreeApplicative}(\mathrm{HookOp})\ A$$

UI generation can be expressed as interpretation by an effect handler h:

$$\mathrm{UI} = h_{\mathrm{props}}(\mathrm{ComponentProgram})$$

Here:

• ComponentProgram: HookProgram(VDOM) is the description of the effectful computation written by the user, including useProps, useState, useContext, and so on

• h_props: HookProgram(VDOM) -> DOM is an expression of the React Fiber runtime interpreting that computation while supplying the current props

And if we set aside user Effects and external I/O and view it as a DOM state transformation, the rendering operation u_s = h(render(s)) can be expressed as an idempotent endomorphism on the DOM:

$$u_{s}(u_{s}(\operatorname{dom})) = u_{s}(\operatorname{dom})$$

$$\mathrm{UI} = f(\mathrm{State})$$

is useful as an educational intuition, but if we look at React's behavior more carefully, it needs some qualification.

A React Component is not a pure function in the mathematical sense. The aspect interpreted by React Fiber can be expressed as an effectful computation in an algebraic effect system. At the same time, this expression does not explain the static Hook sequence first. The Rules of Hooks constrain the program shape first, and because of that constraint the program can be mapped fairly faithfully into an Applicative / Free Applicative-like structure that includes props as useProps.

$$\mathrm{UI} = \mathrm{ReactHandle}_{\mathrm{props}}(\mathrm{ComponentProgram})$$

With this understanding, React's "rules," the behavior of Hooks, the mechanism of use and Suspense, and the design principles of Server Components become easier to reason about in two layers: interpretation of effects and a static Hook skeleton.

Note: I am neither affiliated with Meta nor involved in React Compiler development. This article is purely based on observations from the outside.

In the previous article, I discussed whether React Components are no longer "Just JavaScript" with the introduction of React Compiler. This time, as a continuation, I'll take a broader look at Meta's ecosystem and explore more deeply how React is evolving as a "language."

Meta and JavaScript Infrastructure

Meta (formerly Facebook) has made significant contributions to the JavaScript ecosystem over the years.

Babel

Babel is a JavaScript transpiler that originally started as 6to5. It transforms ES6+ and JSX syntax that browsers don't natively support, maintaining backward compatibility.

JSX was created as an extension to ECMAScript with the purpose of designing a more concise and easy-to-understand syntax for building DOM tree structures and attributes. — The Role of Babel in React

Babel is an independent open-source project, but it's an essential part of the React ecosystem. And React Compiler is also implemented as a Babel Plugin.

Flow

Flow is a static type checker for JavaScript developed by Meta. Flow is also implemented as a Babel Plugin (@babel/preset-flow), stripping type annotations and custom syntax at runtime. And as one of today's main topics, Flow is extending beyond a type checker to become a "language."

Flow's Component Syntax and Hook Syntax

In April 2024, the Flow team announced Component Syntax. This provides first-class language support for React primitives like components and hooks.

Why Was It Added?

Component Syntax was designed in coordination with the React team, and is already being used across Meta's codebases. — New Flow Language Features for React

These features bring improved ergonomics, expressiveness, and static enforcement for many of the Rules of React. — Flow Blog

In other words, Flow's Component Syntax was designed in coordination with the React team and aims to statically enforce the Rules of React.

Component Syntax

Instead of regular function components, you define them using the component keyword:

// Traditional function component
function Introduction(props: { name: string, age: number }) {
  return (
    <h1>
      My name is {props.name} and I am {props.age} years old
    </h1>
  );
}

// Flow's Component Syntax
component Introduction(name: string, age: number) {
  return (
    <h1>
      My name is {name} and I am {age} years old
    </h1>
  );
}

Reference: Component Syntax | Flow

With Component Syntax:

• Props become direct parameters: Reduced boilerplate

• Automatic ref handling: Internally wrapped with React.forwardRef

• Explicit return required: All branches must have a return

• this is forbidden: Cannot use this inside components

Hook Syntax

Similarly, you define hooks using the hook keyword:

// Traditional custom hook
function useOnlineStatus(initial: boolean): boolean {
  const [isOnline, setIsOnline] = useState(initial);
  // ...
  return isOnline;
}

// Flow's Hook Syntax
hook useOnlineStatus(initial: boolean): boolean {
  const [isOnline, setIsOnline] = useState(initial);
  // ...
  return isOnline;
}

Reference: Hook Syntax | Flow

What Flow Detects

Flow's Component/Hook Syntax statically detects code that violates the Rules of React:

1. Props mutation detection: Code that tries to mutate props inside a component

2. Conditional hook call prevention: Reports hook calls inside if statements as errors

3. Ref access during render detection: Code that reads or writes refs during render

4. Nested component/hook detection: Defining another component/hook inside a component or hook

Flow is able to detect mutations of props in a component or hook. Another pattern enforced in component bodies is that refs are not read or written to during render. — Flow Documentation

What This Means

Flow's Component Syntax and Hook Syntax are an attempt to explicitly define React as a "language."

Previously, React components were defined as "JavaScript functions." However, by introducing new keywords (component, hook), Flow expresses React's semantics at the language level.

This more clearly demonstrates the conclusion from the previous article: "React is React."

React Compiler: The Implicit Approach

While Flow "explicitly" introduces new syntax, React Compiler takes an "implicit" approach.

History of React Compiler

React Compiler is the result of about 10 years of research:

• 2017: Facebook first explored compilers with Prepack

• 2021: Xuan Huang demoed the first iteration of the new approach

• 2024: Beta release, announced at React Conf 2024

• October 2025: React Compiler v1.0 stable release

Reference: React Compiler v1.0 – React

Hooks: The Moment React Was Defined as a "Language"

Here I want to present an important perspective.

React was defined as a "language" at the moment Hooks were introduced.

Hooks have Rules of Hooks, constraints that don't exist in JavaScript:

• Only call at the top level (not in loops, conditions, or nested functions)

• Only call from React functions (not from regular JavaScript functions)

These are rules that don't exist for JavaScript functions. Functions that use Hooks are no longer "JavaScript functions" but "React functions."

In other words, the introduction of Hooks may have been the moment that defined React as a "language" with its own semantics.

Hooks Design and the Compiler

And Hooks were designed from the beginning with compiler optimization in mind.

The React Compiler v1.0 blog states:

Hooks were designed with a future compiler in mind. — React Compiler v1.0

This isn't an afterthought. The official Hooks documentation published in 2018 already stated this intention:

As Svelte, Angular, Glimmer, and others show, ahead-of-time compilation of components has a lot of future potential. Especially if it's not limited to templates.

— Introducing Hooks – React (2018)

We wanted to present an API that makes it more likely for code to stay on the optimizable path. To solve these problems, Hooks let you use more of React's features without classes.

— Introducing Hooks – React (2018)

In other words, Hooks were designed from the beginning with compiler optimization in mind.

Dan Abramov's Statements

Dan Abramov, who was on the React team at the time, also mentioned automatic memoization by compilers early on.

In the article "Before You memo()" published in February 2021, after discussing the hassle of manual memoization, he stated:

This last step is annoying, especially for components in between, and ideally a compiler would do it for you. In the future, it might.

— Dan Abramov, Before You memo() (2021)

"In the future, a compiler might do this automatically"—this statement was made more than 3 years before React Compiler was publicly released.

The React team had a clear vision of automatic optimization by compilers for many years. This shows that React's evolution from "Just JavaScript" to "a language with its own semantics" was a planned process.

What React Compiler Does

As mentioned in the previous article, React Compiler automatically performs optimizations like this:

// Input
function VideoTag({ heading, videos, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }
  // ...
}

// Output (after compilation)
function VideoTab(t36) {
  const $ = useMemoCache(12);
  const { heading, videos, filter } = t36;
  let filteredVideos;

  if ($[0] !== videos || $[1] !== filter) {
    filteredVideos = [];
    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filteredVideos.push(video);
      }
    }
    $[0] = videos;
    $[1] = filter;
    $[2] = filteredVideos;
  } else {
    filteredVideos = $[2];
  }
  // ...
}

Reference: Understanding Idiomatic React – Joe Savona, Mofei Zhang, React Advanced 2023

Conditional Memoization: What useMemo Can't Do

The React Compiler v1.0 blog shows examples of optimizations that manual useMemo/useCallback cannot achieve:

export default function ThemeProvider(props) {
  if (!props.children) {
    return null;
  }
  // The compiler can memoize code after conditional returns
  // (impossible with manual useMemo/useCallback)
  const theme = mergeTheme(props.theme, use(ThemeContext));
  return <ThemeContext value={theme}>{props.children}</ThemeContext>;
}

This is a compiler-specific capability that cannot be implemented with useMemo/useCallback. — React Compiler v1.0

Static Enforcement of Rules of React

React Compiler includes a pass that validates the Rules of React, and diagnostics are provided through the ESLint plugin:

React Compiler's ESLint plugin helps developers proactively identify and correct Rules of React violations. The team strongly recommends everyone use the linter today. — React Compiler Beta Release

Results at Meta

React Compiler is already running in production at Meta:

• Instagram: Average 3% improvement across all pages

• Quest Store: At least 4% improvement in load times, some interactions more than 2x faster, initial loads improved by up to 12%

Reference: React Compiler v1.0

Integration Between React Compiler and Flow

What's important here is that React Compiler explicitly supports Flow's Component/Hook Syntax.

compilationMode Option

React Compiler has a compilationMode option that controls which functions are compiled:

• 'infer'　: Uses component naming conventions (PascalCase) and hook detection (use prefix)

• 'annotation': Only functions marked with "use memo" directive

• 'syntax': Only functions using Flow's component/hook syntax

• 'all': All top-level functions (not recommended)

'syntax' Mode

When using 'syntax' mode, only components and hooks defined with Flow's dedicated syntax are compiled:

// babel.config.js
{
  compilationMode: "syntax";
}

// ✅ Compiled: Flow component syntax
component Button(label: string) {
  return <button>{label}</button>;
}

// ✅ Compiled: Flow hook syntax
hook useCounter(initial: number) {
  const [count, setCount] = useState(initial);
  return [count, setCount];
}

// ❌ Not compiled: Regular function syntax
function helper(data) {
  return process(data);
}

Reference: compilationMode – React

What This Means

Flow and React Compiler are not separate projects, but designed to work together.

• Flow's Component Syntax was designed in coordination with the React team

• React Compiler explicitly supports Flow's syntax

• Inside Meta, these two are used in combination

In other words, Meta is developing both Flow and React Compiler under a consistent strategy of "defining React as a language."

React Documentation and the function Keyword

Here I want to share an observation.

In React's official documentation, the function keyword is consistently used for component definitions:

export default function Profile() {
  return <img src="https://i.imgur.com/MK3eW3Am.jpg" alt="Katherine Johnson" />;
}

Reference: Your First Component – React

There is no mention whatsoever of arrow functions (const Profile = () => {}).

Why Not Arrow Functions?

Dan Abramov stated on overreacted.io:

it doesn't matter whether I use arrows or function declarations — Dan Abramov

Technically, both arrow functions and function declarations work fine as React components. However, there are some considerations as to why the React documentation continues to use the function keyword.

1. Affinity with Flow's Component Syntax

Flow's Component Syntax uses the component keyword:

component Introduction(name: string, age: number) {
  // ...
}

This can be naturally introduced as a replacement for the function keyword. If the React documentation had recommended arrow functions, this transition would be unnatural.

2. Syntactic Consistency

Function declarations with the function keyword can be naturally replaced when transitioning to dedicated syntax (like Flow's Component Syntax) in the future. The transition from function declarations is more syntactically consistent than from arrow functions.

Comparing the Two Approaches

Flow and React Compiler take different approaches to the same problem:

Flow:

• Method: New keywords (component, hook)

• Explicitness: Explicit (new syntax)

• Target: Meta's internal codebases

• Purpose: Static enforcement of Rules of React

React Compiler:

• Method: Transforms existing syntax

• Explicitness: Implicit (transformation)

• Target: All React users

• Purpose: Auto-memoization + Rules of React validation

However, both are aligned in the direction that "React has its own semantics."

Rules of React

Let's review the Rules of React:

Rules are guidelines for writing idiomatic, high-quality React code. They're not just guidelines—if you don't follow them, you'll have bugs. — Rules of React – React

Key rules:

1. Components and Hooks must be Pure

   • Idempotent: Same output for same input

   • Side effects only outside of rendering

   • props, state, Hook return values are immutable

2. React calls Components and Hooks

   • Don't call component functions directly

   • Don't pass Hooks as regular values

3. Rules of Hooks

   • Only call at the top level

   • Only call from React functions

These rules form the "React semantics." And both Flow's Component Syntax and React Compiler aim to statically enforce these rules.

Conclusion: React is Evolving as a "Language"

In the previous article, I concluded:

React is React. It's a separate entity with the same syntax as JavaScript but different semantics.

This investigation has reinforced that conclusion:

1. Flow's Component Syntax explicitly defines React semantics as a language

2. React Compiler implicitly transforms React semantics into JavaScript

3. Hooks were designed from the beginning with compilers in mind

4. React documentation consistently uses the function keyword, possibly preparing for future syntax extensions

The era when React was "Just JavaScript" is gradually coming to an end. React is React—the meaning of these words will become increasingly important.

This is merely my essay and does not represent the official views of the React Team or Meta.

Preface

What does Vue.js mean to you?

Whether you write Vue.js for work every day, explore it as a hobby, or simply know the name through social media — there are all kinds of perspectives.

Too much to learn?
Lack of rules makes it confusing?
Easy?
Migration is painful?
But somehow you like it?
Or you still don't?

Everyone holds different feelings and impressions.

Today, I want to take those intuitions you've felt about Vue.js and organize them systematically. That's what this essay attempts to do.

Let me characterize Vue.js through 4 distinct characters.

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad1" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="50%" style="stop-color:#35495e"/> <stop offset="100%" style="stop-color:#42b883"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad1)" font-family="system-ui, sans-serif"> 1 / 4 — Approachable </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad1)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.js is Easy?

Have you heard this phrase before?

"Vue.js is Easy"

You often see the Easy/Simple comparison in discussions.

Honestly, I'm not particularly fond of this phrase.
First, what feels "easy" is highly subjective and depends heavily on one's background.
I'm already hesitant to casually use the word "easy," but this phrase can create two misconceptions.

Misconception 1: "Vue.js has become difficult"

Vue.js announced version 3 with the Composition API in 2020, bringing significant changes.
And since then, it has continued to evolve.

During this time, some have said "Vue.js has become difficult" or "the old Vue.js was simpler and better."

Indeed, there was a time when Vue.js aimed to be simple and approachable — more "Easy" than it is today.

But here's what I want you to consider: "Was it really Vue.js that became difficult?"

I don't think so.

What became difficult was the Web.

Since the 2010s when frontend development emerged, the complexity of UIs, the scale of frontend codebases, and performance challenges have all grown. Web applications as a whole became more difficult.
Vue.js simply followed those needs.

Evidence for this: "Vue.js still supports traditional patterns."
Specifically: not using TypeScript, using Vue.js from a CDN, Options API — these legacy patterns are still supported today.

In other words, you can still use "the Vue that wasn't difficult."

Misconception 2: "Vue.js has no rules, so it's bad"

This is the misconception that "Vue.js is easy but has no rules. That breeds bugs and makes code messy."

Establishing design patterns and conventions in programs is generally considered good practice. I agree.
However, there are important considerations when establishing rules.

First: "What problem does this rule solve?"
Rules need purpose. You should always consider what benefits a rule provides.

Second: The tradeoffs it creates.
Conventions aren't free. The stronger the constraints, the more compliance is expected, reducing flexibility and increasing learning costs.

Does this mean I'm saying rules are bad? No.
"Choose what fits you based on tradeoffs."

Web applications are incredibly diverse. The teams and companies building them are equally diverse.
There's no silver bullet that works for everything.

Moreover, design and conventions aren't binary.
I'm not saying "rules aren't needed." I'm saying "rules are needed, but there are many options. The ability to choose has great value."

Whether the framework or the implementer takes responsibility is a tradeoff.
When implementers take that responsibility, they trade some accountability for flexibility in conventions.

The response "Vue.js is easy but has no rules, so it's bad" fails to adequately consider this tradeoff.

Vue.js is Approachable

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 400 120" style="max-width: 400px; width: 100%;"> <defs> <linearGradient id="approachGrad" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> </linearGradient> </defs> <rect x="20" y="20" width="360" height="80" rx="10" fill="none" stroke="url(#approachGrad)" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,1000;880,0;0,1000" dur="4s" repeatCount="indefinite"/> </rect> <text x="200" y="70" text-anchor="middle" font-size="24" font-weight="bold" fill="url(#approachGrad)" font-family="system-ui, sans-serif"> Approachable <animate attributeName="opacity" values="0;1;1;0" dur="4s" repeatCount="indefinite"/> </text> </svg> </div>

So what is Vue.js, really?
I believe Vue.js is Approachable.

The word "Approachable" actually appears at the top of the official documentation.

https://vuejs.org/

Despite various tradeoffs, the consistent point is "easy to approach for various use cases."

Vue.js is also called "The Progressive Framework."
This is a related concept to Approachable — meaning "a framework that can grow with you and adapt to your needs."
You can start with enhancing static HTML without a build step, then scale up to SPA, SSR, or SSG as needed — or start with a full-stack setup from the beginning.
Approachable at any scale, from any starting point — this is another expression of Vue.js's flexibility.

https://vuejs.org/guide/introduction#the-progressive-framework

Vue.js is an Approachable UI framework.

It hasn't become difficult, nor does it sacrifice stability for simplicity.
It's about flexible choices.

Vue.js followed the Web as it became more complex. Traditional patterns are still available.
Implementers can flexibly choose conventions and design.

This is the first character of Vue.js I want to discuss today.

I've written a deeper dive on this topic. Check it out if you're interested.

Vue.js is not Easy. It is Approachable.

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad2" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#35495e"/> <stop offset="50%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad2)" font-family="system-ui, sans-serif"> 2 / 4 — Language </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad2)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.js is a Language

Before explaining how Vue.js is a language, let's review what programming languages are.

What is a Programming Language?

What is a programming language?
It's a language for writing programs. Just as the name suggests.

You know that many programming languages exist in this world.
JavaScript, TypeScript, Rust, C++, Haskell.
And not just those. HTML, CSS, and JSON are also part of this family.

These are classified as "general-purpose programming languages" or "domain-specific languages (DSL)." Both are languages.

Why do so many languages exist?

Think about this: what format does a computer actually need to store programs?

The answer is binary. With just binary, everything can be described.
In most situations, any language ultimately becomes binary to execute.

So who are programming languages for?
Undoubtedly, they're for us — humans.

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 620 300" style="max-width: 620px; width: 100%;"> <defs> <marker id="languageArrow" markerWidth="10" markerHeight="7" refX="9" refY="3.5" orient="auto"> <polygon points="0 0, 10 3.5, 0 7" fill="#35495e"/> </marker> </defs>

<text x="135" y="32" text-anchor="middle" font-size="14" fill="#35495e" font-weight="bold" font-family="system-ui">Abstraction for humans</text>

<rect x="40" y="214" width="190" height="56" rx="8" fill="#35495e" fill-opacity="0.06" stroke="#35495e" stroke-width="2"/> <text x="135" y="237" text-anchor="middle" font-size="16" fill="#35495e" font-weight="bold" font-family="system-ui">Binary</text> <text x="135" y="257" text-anchor="middle" font-size="12" fill="#666" font-family="monospace">01010110...</text>

<rect x="40" y="136" width="190" height="56" rx="8" fill="#35495e" fill-opacity="0.06" stroke="#35495e" stroke-width="2"/> <text x="135" y="159" text-anchor="middle" font-size="16" fill="#35495e" font-weight="bold" font-family="system-ui">Assembly</text> <text x="135" y="179" text-anchor="middle" font-size="12" fill="#666" font-family="monospace">mov, jmp...</text>

<path d="M135 210 L135 198 M128 205 L135 198 L142 205" fill="none" stroke="#35495e" stroke-width="2.3" stroke-linecap="round" stroke-linejoin="round"/> <path d="M135 132 L135 120 M128 127 L135 120 L142 127" fill="none" stroke="#35495e" stroke-width="2.3" stroke-linecap="round" stroke-linejoin="round"/>

<rect x="40" y="58" width="190" height="56" rx="8" fill="#42b883" fill-opacity="0.14" stroke="#42b883" stroke-width="2.5"/> <text x="135" y="81" text-anchor="middle" font-size="16" fill="#35495e" font-weight="bold" font-family="system-ui">High-level language</text> <text x="135" y="101" text-anchor="middle" font-size="12" fill="#35495e" font-family="system-ui">C, JS, Rust...</text>

<line x1="246" y1="86" x2="318" y2="86" stroke="#42b883" stroke-width="3" marker-end="url(#languageArrow)"/>

<text x="450" y="82" text-anchor="middle" font-size="24" fill="#35495e" font-weight="bold" font-family="system-ui">Vue.js — DSL for UI</text> <line x1="320" y1="102" x2="580" y2="102" stroke="#42b883" stroke-width="2"/>

<circle cx="337" cy="138" r="15" fill="#42b883"/> <text x="337" y="143" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">1</text> <text x="365" y="143" font-size="15" fill="#35495e" font-family="system-ui">Extends HTML + CSS + JS</text>

<circle cx="337" cy="180" r="15" fill="#42b883"/> <text x="337" y="185" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">2</text> <text x="365" y="185" font-size="15" fill="#35495e" font-family="system-ui">Declarative UI description</text>

<circle cx="337" cy="222" r="15" fill="#42b883"/> <text x="337" y="227" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">3</text> <text x="365" y="227" font-size="15" fill="#35495e" font-family="system-ui">Component-oriented</text> </svg> </div>

There are diverse things to describe in the world.
Hardware control, operating systems, browsers, web applications, CLI tools.
Each domain requires different knowledge.

Many languages exist to provide "writability" and "correctness" for humans based on various concepts in each domain.

Starting from unstructured programming, we created syntax to give control knowledge to programming languages themselves, created OOP languages for OOP, FP languages for FP, new languages to escape memory management, and data description languages to describe data.

Vue.js is a Language for Describing UI

So what about Vue.js?
Vue.js can be understood as a language for describing UI.

Languages for describing UI already exist: HTML, CSS, and JavaScript.
Vue.js extends these with missing knowledge.

1. Declarative Template Description

Describing UI templates declaratively and dynamically.
This practice wasn't common when HTML, CSS, and JavaScript first appeared.

As the Web evolved, the complexity of client-side code grew, various UI description methods emerged, and we learned that declarative UI description is better for stability and readability.

Vue.js supports a language for describing templates and solved this problem.

2. Component-Centered Design

Bundling related HTML, CSS, and JavaScript together to increase cohesion of UI-related code.
Additionally, scoped CSS and slots are part of the extended knowledge Vue.js provides.

<script setup lang="ts">
import { ref } from "vue";
const count = ref(0);
function increment() {
  count.value++;
}
</script>

<template>
  <button type="button" @click="increment">count is: {{ count }}</button>
</template>

<style scoped>
button {
  color: #42b883;
}
</style>

What's notable here is that in the <script> section, you can use the JavaScript mental model almost as-is.
As long as you're mindful of the boundary between View and ViewModel — that is, Reactivity — the rest is just plain JavaScript.
There are almost no special rules or framework-specific constraints. This is another aspect of Vue.js's Approachability.

3. Compiler as Optimizer

Performance tuning that can be statically analyzed by a compiler shouldn't be done by hand.
Such optimization should be left to the compiler while we focus on the essential task of describing UI.

Vue.js's compiler performs various optimizations:

• Static Hoisting: Hoists static nodes to avoid regeneration

• Patch Flags: Adds flags to dynamic parts for faster diff detection

• Tree Flattening: Flattens nested static nodes

• Vapor Mode: More direct rendering without virtual DOM

Syntax as Language Features

You know if statements, while, for, loop, and so on.
But from the computer's perspective, these are essentially just "check and jump."
Why do multiple syntaxes exist for this single "check and jump" instruction?

Because it's easier for humans when each use case has its own meaning.
When you simply want to branch: "if." When you want to repeat while a condition holds: "while."
Even though it's just a jump for the computer, such meaning helps humans write programs.

The same applies to Vue.js.
Programmatically, passing data between components is just "passing."
But when describing UI, we can extend UI knowledge and add meaning:

• When you want to bind data to a component: v-bind

• When you want to subscribe/emit events: v-on, emit

• When you want to inject templates into components: slot

Yes, Vue.js organized the knowledge that arises when describing UI as a language.
This is very much the philosophy of programming languages.

Language Tools

One more thing not to forget: "Vue.js has well-developed language tools."

Creating a programming language involves many challenges.
Specification design, compiler implementation, and language tools.
It takes enormous time and effort.

Indeed, Vue.js was somewhat behind other frameworks in the past.
But time has passed, and with tremendous effort, things have improved significantly.

I want to express gratitude again to vuejs/language-tools, Johnson Chu, and all community members.

I've written a deeper dive on "Vue.js is a language" as well.

What is Vue.js? It's just a language lol

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad3" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="50%" style="stop-color:#35495e"/> <stop offset="100%" style="stop-color:#42b883"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad3)" font-family="system-ui, sans-serif"> 3 / 4 — Ecosystem </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad3)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.js: An Expanding Ecosystem

Another major characteristic of Vue.js is the ecosystem that starts from Vue.js and expands beyond its boundaries.

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="-20 0 740 500" style="max-width: 740px; width: 100%;"> <defs> <linearGradient id="evanGrad" x1="0%" y1="0%" x2="100%" y2="100%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#646cff"/> </linearGradient> </defs>

<!-- Central Evan You node --> <circle cx="360" cy="70" r="50" fill="url(#evanGrad)"> <animate attributeName="r" values="50;53;50" dur="3s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="4s" repeatCount="indefinite"/> </circle> <text x="360" y="66" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">Evan You</text> <text x="360" y="80" text-anchor="middle" font-size="9" fill="#ddd" font-family="system-ui">Creator</text>

<!-- Evan You to Vue.js connection --> <line x1="310" y1="70" x2="235" y2="70" stroke="#42b883" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,100;100,0;0,100" dur="3s" repeatCount="indefinite"/> </line> <circle cx="185" cy="70" r="45" fill="#42b883"> <animate attributeName="r" values="45;48;45" dur="3s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="185" y="75" text-anchor="middle" font-size="15" fill="#fff" font-weight="bold" font-family="system-ui">Vue.js</text>

<!-- Evan to Vite connection (Evan created Vite) --> <line x1="325" y1="110" x2="260" y2="160" stroke="#646cff" stroke-width="2" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0;0,100" dur="2.5s" repeatCount="indefinite"/> </line>

<!-- Vue.js to Vite connection (Vue birthed Vite) --> <line x1="210" y1="110" x2="230" y2="155" stroke="#646cff" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,60;60,0;0,60" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="250" cy="195" r="40" fill="#646cff"> <animate attributeName="r" values="40;43;40" dur="3s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="250" y="200" text-anchor="middle" font-size="13" fill="#fff" font-weight="bold" font-family="system-ui">Vite</text>

<!-- VoidZero --> <line x1="360" y1="120" x2="360" y2="160" stroke="#f59e0b" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="360" cy="200" r="40" fill="#f59e0b"> <animate attributeName="r" values="40;43;40" dur="4s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.8;1;0.8" dur="4s" repeatCount="indefinite"/> </circle> <text x="360" y="205" text-anchor="middle" font-size="11" fill="#fff" font-weight="bold" font-family="system-ui">VoidZero</text>

<!-- VoidZero to Vite connection --> <line x1="320" y1="200" x2="290" y2="195" stroke="#f59e0b" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2.5s" repeatCount="indefinite"/> </line>

<!-- Volar.js from Vue --> <line x1="140" y1="70" x2="95" y2="70" stroke="#35495e" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="65" cy="70" r="25" fill="#35495e"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="65" y="75" text-anchor="middle" font-size="8" fill="#42b883" font-weight="bold" font-family="system-ui">Volar.js</text>

<!-- Volar.js expansions --> <line x1="50" y1="92" x2="35" y2="125" stroke="#35495e" stroke-width="1.5" opacity="0.7"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="30" cy="145" r="16" fill="#ff5d01" opacity="0.9"> <animate attributeName="opacity" values="0.7;0.9;0.7" dur="2s" repeatCount="indefinite"/> </circle> <text x="30" y="149" text-anchor="middle" font-size="6" fill="#fff" font-weight="bold" font-family="system-ui">Astro</text>

<line x1="80" y1="92" x2="95" y2="125" stroke="#35495e" stroke-width="1.5" opacity="0.7"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="100" cy="145" r="16" fill="#fcb32c" opacity="0.9"> <animate attributeName="opacity" values="0.7;0.9;0.7" dur="2s" repeatCount="indefinite"/> </circle> <text x="100" y="149" text-anchor="middle" font-size="6" fill="#000" font-weight="bold" font-family="system-ui">MDX</text>

<!-- Nuxt from Vue (curved path to avoid Vite) --> <line x1="150" y1="100" x2="80" y2="270" stroke="#00dc82" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,200;200,0;0,200" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="65" cy="300" r="25" fill="#00dc82"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="65" y="305" text-anchor="middle" font-size="9" fill="#fff" font-weight="bold" font-family="system-ui">Nuxt</text>

<!-- UnJS from Nuxt --> <line x1="65" y1="325" x2="65" y2="355" stroke="#00dc82" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="65" cy="380" r="22" fill="#00dc82" opacity="0.9"> <animate attributeName="opacity" values="0.7;0.9;0.7" dur="3s" repeatCount="indefinite"/> </circle> <text x="65" y="380" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">UnJS</text>

<!-- Nitro from UnJS --> <line x1="87" y1="375" x2="115" y2="355" stroke="#00dc82" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="135" cy="340" r="16" fill="#00dc82" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="135" y="340" text-anchor="middle" dominant-baseline="central" font-size="6" fill="#fff" font-weight="bold" font-family="system-ui">Nitro</text>

<!-- h3 from Nitro --> <line x1="151" y1="340" x2="180" y2="340" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,30;30,0;0,30" dur="2s" repeatCount="indefinite"/> </line> <circle cx="198" cy="340" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="198" y="340" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">h3</text>

<!-- citty from UnJS --> <line x1="87" y1="380" x2="120" y2="380" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,35;35,0;0,35" dur="2s" repeatCount="indefinite"/> </line> <circle cx="138" cy="380" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="138" y="380" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">citty</text>

<!-- ofetch from UnJS --> <line x1="87" y1="388" x2="115" y2="410" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,35;35,0;0,35" dur="2s" repeatCount="indefinite"/> </line> <circle cx="135" cy="425" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="135" y="425" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">ofetch</text>

<!-- unplugin from UnJS --> <line x1="80" y1="400" x2="95" y2="445" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2s" repeatCount="indefinite"/> </line> <circle cx="105" cy="465" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="105" y="463" text-anchor="middle" dominant-baseline="central" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">un-</text> <text x="105" y="470" text-anchor="middle" dominant-baseline="central" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">plugin</text>

<!-- jiti from UnJS --> <line x1="50" y1="400" x2="35" y2="435" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,40;40,0;0,40" dur="2s" repeatCount="indefinite"/> </line> <circle cx="28" cy="455" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="28" y="455" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">jiti</text>

<!-- mlly from UnJS --> <line x1="45" y1="395" x2="20" y2="405" stroke="#00dc82" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,30;30,0;0,30" dur="2s" repeatCount="indefinite"/> </line> <circle cx="8" cy="415" r="14" fill="#00dc82" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.6;0.4" dur="2s" repeatCount="indefinite"/> </circle> <text x="8" y="415" text-anchor="middle" dominant-baseline="central" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">mlly</text>

<!-- Analog, TanStack Start from Nitro --> <line x1="135" y1="356" x2="135" y2="380" stroke="#00dc82" stroke-width="1.5" opacity="0.4"> <animate attributeName="stroke-dasharray" values="0,25;25,0;0,25" dur="2s" repeatCount="indefinite"/> </line> <text x="180" y="370" text-anchor="middle" font-size="5" fill="#8899aa" font-family="system-ui">Analog, TanStack Start...</text>

<!-- Vite expansions (other frameworks) --> <line x1="250" y1="235" x2="250" y2="275" stroke="#646cff" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,45;45,0;0,45" dur="2s" repeatCount="indefinite"/> </line> <text x="250" y="295" text-anchor="middle" font-size="6" fill="#8899aa" font-family="system-ui">React, Svelte,</text> <text x="250" y="308" text-anchor="middle" font-size="6" fill="#8899aa" font-family="system-ui">Solid, Qwik...</text>

<!-- Vite to Nuxt connection --> <line x1="215" y1="215" x2="85" y2="285" stroke="#646cff" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,150;150,0;0,150" dur="2s" repeatCount="indefinite"/> </line>

<!-- Vitest from VoidZero --> <line x1="400" y1="190" x2="465" y2="160" stroke="#42b883" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,80;80,0;0,80" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="490" cy="145" r="28" fill="#42b883"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="490" y="150" text-anchor="middle" font-size="10" fill="#fff" font-weight="bold" font-family="system-ui">Vitest</text>

<!-- Rolldown from VoidZero --> <line x1="360" y1="240" x2="360" y2="290" stroke="#ff6b6b" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,55;55,0;0,55" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="360" cy="320" r="28" fill="#ff6b6b"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="360" y="325" text-anchor="middle" font-size="9" fill="#fff" font-weight="bold" font-family="system-ui">Rolldown</text>

<!-- Oxc from VoidZero --> <line x1="400" y1="215" x2="470" y2="260" stroke="#f97316" stroke-width="2"> <animate attributeName="stroke-dasharray" values="0,90;90,0;0,90" dur="2.5s" repeatCount="indefinite"/> </line> <circle cx="500" cy="285" r="28" fill="#f97316"> <animate attributeName="opacity" values="0.8;1;0.8" dur="3s" repeatCount="indefinite"/> </circle> <text x="500" y="290" text-anchor="middle" font-size="10" fill="#fff" font-weight="bold" font-family="system-ui">Oxc</text>

<!-- Oxc to Rolldown connection --> <line x1="475" y1="295" x2="388" y2="320" stroke="#ff6b6b" stroke-width="1.5" stroke-dasharray="4,4" opacity="0.6"> <animate attributeName="opacity" values="0.4;0.7;0.4" dur="2s" repeatCount="indefinite"/> </line> <text x="432" y="300" text-anchor="middle" font-size="5" fill="#8899aa" font-family="system-ui">powers</text>

<!-- Rolldown to Vite connection --> <line x1="332" y1="320" x2="278" y2="220" stroke="#ff6b6b" stroke-width="1.5" opacity="0.5"> <animate attributeName="stroke-dasharray" values="0,120;120,0;0,120" dur="2.5s" repeatCount="indefinite"/> </line>

<!-- Oxc expansions (6 tools) --> <!-- Parser --> <line x1="528" y1="270" x2="565" y2="210" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,70;70,0;0,70" dur="2s" repeatCount="indefinite"/> </line> <circle cx="580" cy="195" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="580" y="199" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Parser</text>

<!-- Linter --> <line x1="528" y1="280" x2="575" y2="250" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,55;55,0;0,55" dur="2s" repeatCount="indefinite"/> </line> <circle cx="590" cy="235" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="590" y="239" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Linter</text>

<!-- Formatter --> <line x1="528" y1="285" x2="575" y2="285" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,50;50,0;0,50" dur="2s" repeatCount="indefinite"/> </line> <circle cx="595" cy="285" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="595" y="283" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">Forma-</text> <text x="595" y="290" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">tter</text>

<!-- Transformer --> <line x1="528" y1="295" x2="575" y2="325" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,55;55,0;0,55" dur="2s" repeatCount="indefinite"/> </line> <circle cx="590" cy="340" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="590" y="338" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">Trans-</text> <text x="590" y="345" text-anchor="middle" font-size="4" fill="#fff" font-weight="bold" font-family="system-ui">former</text>

<!-- Minifier --> <line x1="520" y1="305" x2="560" y2="375" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,80;80,0;0,80" dur="2s" repeatCount="indefinite"/> </line> <circle cx="575" cy="390" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="575" y="394" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Minifier</text>

<!-- Resolver --> <line x1="515" y1="310" x2="545" y2="420" stroke="#f97316" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,120;120,0;0,120" dur="2s" repeatCount="indefinite"/> </line> <circle cx="555" cy="440" r="14" fill="#f97316" opacity="0.7"> <animate attributeName="opacity" values="0.5;0.7;0.5" dur="2s" repeatCount="indefinite"/> </circle> <text x="555" y="444" text-anchor="middle" font-size="5" fill="#fff" font-weight="bold" font-family="system-ui">Resolver</text>

<!-- Web Community label --> <text x="360" y="470" text-anchor="middle" font-size="10" fill="#42b883" font-family="system-ui" opacity="0.8"> → Expanding to the Web Community </text>

<!-- Outer ring pulse --> <circle cx="360" cy="260" r="260" fill="none" stroke="#42b883" stroke-width="1" opacity="0.2"> <animate attributeName="r" values="260;265;260;275;260" dur="5s" repeatCount="indefinite"/> <animate attributeName="opacity" values="0.2;0.15;0.2;0.08;0.2" dur="5s" repeatCount="indefinite"/> </circle> </svg> </div>

Vite — The Revolution That Started from Vue

As you know, Vite is now essential in modern frontend development.

Originally, Vite started as vue-dev-server.
This was Evan You's idea to use browser's Native ESM for a no-bundler development setup.

Then it was renamed to Vite as a No-bundle Dev Server for Vue Single-File Components, and in v2, the core became framework agnostic, positioning it as "Next Generation Frontend Tooling."

Yes. Vite started from Vue.js, continued to evolve, and has now expanded beyond Vue.js as a frontend tool.

Volar.js — Language Tools Framework

I mentioned earlier that Vue.js has a language aspect and excellent language tools.

Vue.js has had several language tool implementations in the past, but now vuejs/language-tools is the official language tool.

Originally, it started as Volar, a VSCode extension for Vue.js, as a community member's personal project.
Volar evolved over 2 years of immense effort to reach v1.0 and became Vue.js's official recommended tool.

From there, the core functionality independent of Vue.js was extracted as Volar.js, and Vue.js's language tools became vuejs/language-tools.

Volar.js is now spreading as the foundation for language tools in Astro, MDX, and Analog (Angular's meta-framework).

UnJS — Ecosystem Expanding from Nuxt

UnJS stands for Unified JavaScript or Unleash JavaScript — a collection of JavaScript libraries.

The concept is: one purpose per library, high quality, works in any environment, and collaborative.

UnJS was developed by Pooya Parsa, who was a lead engineer for Nuxt2, as a separate ecosystem from Nuxt. The server engine extracted during Nuxt3 development and libraries Pooya had created were rebranded as the UnJS organization.

UnJS and Nuxt collaborate closely, and many Nuxt features are now implemented by UnJS.
Notable examples include the HTTP framework h3 and the server engine Nitro built on top of it.
Nitro is also used in Analog and others.

ecosystem-ci — Shared Testing Mechanisms

Vue.js has a vast ecosystem.
State management libraries, UI frameworks, routers, testing libraries — truly many.

The Vue2 to Vue3 upgrade made ecosystem adoption a major challenge.
So a mechanism for integration testing of these downstream ecosystems was introduced.

This originally came from Vite's integration testing with Svelte, and the mechanism was adopted in Vue.js.
And again, beyond Vue.js/Vite, similar mechanisms have been adopted in Svelte, Astro, Oxc, and more.

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 120" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="voidzeroGrad" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#f59e0b"/> <stop offset="50%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#f59e0b"/> <animate attributeName="x1" values="0%;100%;0%" dur="4s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="4s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="50" text-anchor="middle" font-size="28" font-weight="bold" fill="url(#voidzeroGrad)" font-family="system-ui, sans-serif"> VoidZero — Foundation for the Next Era </text> <text x="300" y="90" text-anchor="middle" font-size="14" fill="#8899aa" font-family="system-ui, sans-serif"> A new vision uniting Vite, Vitest, Rolldown, and Oxc </text> </svg> </div>

VoidZero and the Challenge of a Unified Toolchain

The expansion of the Vue.js ecosystem has led to an even greater challenge.

The Fragmentation Problem

Through developing Vite, Evan You faced challenges that the entire JavaScript ecosystem shares.

"Every application relies on a myriad of third-party dependencies, and configuring them to work well together remains one of the most daunting tasks."

— https://voidzero.dev/posts/announcing-voidzero-inc

While Vite greatly improved the developer experience, internally it still had various dependencies, requiring abstractions and workarounds to smooth over inconsistencies. Duplicated parsing and serialization costs across different tools became bottlenecks.

The Birth of VoidZero

In 2024, Evan You founded VoidZero.
With a vision: "Building the next-generation unified JavaScript toolchain."

https://voidzero.dev/posts/announcing-voidzero-inc

VoidZero's vision centers on building an integrated development stack with four characteristics:

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 500 300" style="max-width: 500px; width: 100%;"> <defs> <linearGradient id="boxGrad" x1="0%" y1="0%" x2="100%" y2="100%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> </linearGradient> </defs>

<!-- Unified --> <rect x="20" y="20" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" repeatCount="indefinite"/> </rect> <text x="130" y="45" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">Unified</text> <text x="130" y="65" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">Same AST, resolver, module interop</text>

<!-- High Performance --> <rect x="260" y="20" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" begin="0.5s" repeatCount="indefinite"/> </rect> <text x="370" y="45" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">High Performance</text> <text x="370" y="65" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">Maximum parallelization in Rust</text>

<!-- Composable --> <rect x="20" y="100" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" begin="1s" repeatCount="indefinite"/> </rect> <text x="130" y="125" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">Composable</text> <text x="130" y="145" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">Independent components</text>

<!-- Runtime Agnostic --> <rect x="260" y="100" width="220" height="60" rx="10" fill="url(#boxGrad)" opacity="0.9"> <animate attributeName="opacity" values="0.9;1;0.9" dur="2s" begin="1.5s" repeatCount="indefinite"/> </rect> <text x="370" y="125" text-anchor="middle" font-size="14" fill="#fff" font-weight="bold" font-family="system-ui">Runtime Agnostic</text> <text x="370" y="145" text-anchor="middle" font-size="10" fill="#ccc" font-family="system-ui">Consistent experience across all JS envs</text>

<!-- Arrow down to projects --> <line x1="250" y1="170" x2="250" y2="200" stroke="#42b883" stroke-width="2" marker-end="url(#arrowhead)"/>

<!-- Project boxes --> <rect x="40" y="210" width="100" height="40" rx="5" fill="#646cff"/> <text x="90" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Vite</text>

<rect x="160" y="210" width="100" height="40" rx="5" fill="#42b883"/> <text x="210" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Vitest</text>

<rect x="280" y="210" width="100" height="40" rx="5" fill="#ff6b6b"/> <text x="330" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Rolldown</text>

<rect x="400" y="210" width="60" height="40" rx="5" fill="#f97316"/> <text x="430" y="235" text-anchor="middle" font-size="12" fill="#fff" font-weight="bold" font-family="system-ui">Oxc</text>

<!-- Open Source badge -->

<text x="250" y="280" text-anchor="middle" font-size="11" fill="#42b883" font-family="system-ui">Open Source</text> </svg>

</div>

Oxc — High-Speed Compiler Written in Rust

Oxc (JavaScript Oxidation Compiler) is a JavaScript/TypeScript toolchain written in Rust, led by Boshen.

A comprehensive toolset including parser, linter (Oxlint), formatter (Oxfmt), transformer, minifier, and resolver, achieving overwhelming performance:

• Oxlint: 50-100x faster than ESLint

• Oxfmt: 35x faster than Prettier

• oxc-resolver: 30x faster than webpack's enhanced-resolve

• transformer: 40x faster than Babel

https://oxc.rs/

Oxlint 1.0 was released as stable in June 2025, with over 5,200 early adopters including Shopify and Airbnb.

Rolldown — Rust-Based Bundler

Rolldown is a Rust-based bundler developed by VoidZero, achieving 10-30x faster performance than Rollup with a Rollup-compatible API.

https://vite.dev/blog/announcing-vite8

On March 12, 2026, Vite 8.0 was released as stable, integrating Rolldown as Vite's single Rust-based bundler.
With this, Vite 8 moves from the previous esbuild + Rollup dual setup to a unified Rolldown-centered architecture.

During the preview and beta phases, real projects reported impressive performance improvements:

• Linear: Production build time 46 sec → 6 sec

• Ramp: 57% build time reduction

• Mercedes-Benz.io: Up to 38% reduction

• Beehiiv: 64% reduction

This initiative makes Vite the entry point to an end-to-end toolchain maintained by closely collaborating teams: build tool (Vite), bundler (Rolldown), and compiler (Oxc).

Vite+ — Unified Toolchain

On March 13, 2026, VoidZero also released Vite+ Alpha.
As a superset of Vite, it centers the workflow around the global vp CLI and a project-local vite-plus package, providing the tools developers need as a single, unified toolchain:

• vp create — Project and monorepo scaffolding

• vp env — Global and per-project Node.js runtime management

• vp install — Dependency installation through the selected package manager

• vp dev — Vite development server

• vp check — Type checking, linting, and formatting in one command

• vp test — Testing via Vitest

• vp build — Production builds

• vp run — Script and monorepo task execution via Vite Task

• vp pack — Library and CLI packaging via tsdown

https://voidzero.dev/posts/announcing-vite-plus-alpha

https://viteplus.dev/

Trust and Commitment to Open Source

What's crucial here is VoidZero's stance on open source.

"The trust the community has placed in Vite" prompted deep reflection on its future direction.

— https://voidzero.dev/posts/announcing-voidzero-inc

VoidZero clearly declares:

"Everything we've open-sourced will remain open source. Vite, Vitest, Rolldown, and Oxc will remain open source."

— https://voidzero.dev/posts/announcing-voidzero-inc

With that Vite+ Alpha release, Vite+ itself was also fully open-sourced under the MIT license.

And importantly, VoidZero provides first-class support for Vue.js. These tools that started from Vue.js will continue to deliver the best experience for the Vue.js ecosystem.

These projects are already adopted by major organizations including OpenAI, Google, Apple, Microsoft, and Shopify. Their reliability is proven.

https://github.com/vitejs/companies-using-vite

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 100" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="titleGrad4" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#35495e"/> <stop offset="50%" style="stop-color:#42b883"/> <stop offset="100%" style="stop-color:#35495e"/> <animate attributeName="x1" values="0%;100%;0%" dur="6s" repeatCount="indefinite"/> <animate attributeName="x2" values="100%;200%;100%" dur="6s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="32" font-weight="bold" fill="url(#titleGrad4)" font-family="system-ui, sans-serif"> 4 / 4 — Community </text> <line x1="100" y1="85" x2="500" y2="85" stroke="url(#titleGrad4)" stroke-width="2" stroke-dasharray="5,5"> <animate attributeName="stroke-dashoffset" values="0;-20" dur="1s" repeatCount="indefinite"/> </line> </svg> </div>

Vue.js is Community

The final character. This is an inseparable, essential element of Vue.js.

<div style="text-align: center; margin: 3rem 0;"> <svg viewBox="0 0 500 320" style="max-width: 500px; width: 100%;"> <defs> <radialGradient id="coreGlow" cx="50%" cy="50%" r="50%"> <stop offset="0%" style="stop-color:#42b883;stop-opacity:0.4"/> <stop offset="70%" style="stop-color:#42b883;stop-opacity:0.1"/> <stop offset="100%" style="stop-color:#42b883;stop-opacity:0"/> </radialGradient> <linearGradient id="nodeGrad" x1="0%" y1="0%" x2="100%" y2="100%"> <stop offset="0%" style="stop-color:#64d4a3"/> <stop offset="100%" style="stop-color:#35495e"/> </linearGradient> <filter id="glow"> <feGaussianBlur stdDeviation="2" result="coloredBlur"/> <feMerge> <feMergeNode in="coloredBlur"/> <feMergeNode in="SourceGraphic"/> </feMerge> </filter> </defs>

<!-- Background pulse --> <circle cx="250" cy="160" r="80" fill="url(#coreGlow)"> <animate attributeName="r" values="80;100;80" dur="4s" repeatCount="indefinite"/> </circle>

<!-- Network connections between nodes --> <!-- Inner ring connections --> <line x1="175" y1="90" x2="325" y2="90" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" repeatCount="indefinite"/> </line> <line x1="175" y1="90" x2="130" y2="180" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="0.5s" repeatCount="indefinite"/> </line> <line x1="325" y1="90" x2="370" y2="180" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="1s" repeatCount="indefinite"/> </line> <line x1="130" y1="180" x2="190" y2="260" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="1.5s" repeatCount="indefinite"/> </line> <line x1="370" y1="180" x2="310" y2="260" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="2s" repeatCount="indefinite"/> </line> <line x1="190" y1="260" x2="310" y2="260" stroke="#42b883" stroke-width="1" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="3s" begin="2.5s" repeatCount="indefinite"/> </line>

<!-- Connections to center --> <line x1="175" y1="90" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" repeatCount="indefinite"/> </line> <line x1="325" y1="90" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="0.33s" repeatCount="indefinite"/> </line> <line x1="130" y1="180" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="0.66s" repeatCount="indefinite"/> </line> <line x1="370" y1="180" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="1s" repeatCount="indefinite"/> </line> <line x1="190" y1="260" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="1.33s" repeatCount="indefinite"/> </line> <line x1="310" y1="260" x2="250" y2="160" stroke="#42b883" stroke-width="1.5" opacity="0.6"> <animate attributeName="stroke-dasharray" values="0,100;100,0" dur="2s" begin="1.66s" repeatCount="indefinite"/> </line>

<!-- Outer nodes for depth --> <circle cx="100" cy="60" r="6" fill="#35495e" opacity="0.4"> <animate attributeName="opacity" values="0.3;0.6;0.3" dur="4s" repeatCount="indefinite"/> </circle> <circle cx="400" cy="60" r="5" fill="#35495e" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="4s" begin="1s" repeatCount="indefinite"/> </circle> <circle cx="60" cy="240" r="7" fill="#35495e" opacity="0.35"> <animate attributeName="opacity" values="0.25;0.55;0.25" dur="4s" begin="2s" repeatCount="indefinite"/> </circle> <circle cx="440" cy="240" r="5" fill="#35495e" opacity="0.3"> <animate attributeName="opacity" values="0.2;0.5;0.2" dur="4s" begin="3s" repeatCount="indefinite"/> </circle> <circle cx="250" cy="30" r="6" fill="#35495e" opacity="0.4"> <animate attributeName="opacity" values="0.3;0.6;0.3" dur="4s" begin="0.5s" repeatCount="indefinite"/> </circle> <circle cx="250" cy="300" r="5" fill="#35495e" opacity="0.35"> <animate attributeName="opacity" values="0.25;0.55;0.25" dur="4s" begin="1.5s" repeatCount="indefinite"/> </circle>

<!-- Faint outer connections --> <line x1="100" y1="60" x2="175" y2="90" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="400" y1="60" x2="325" y2="90" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="60" y1="240" x2="130" y2="180" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="440" y1="240" x2="370" y2="180" stroke="#35495e" stroke-width="0.5" opacity="0.2"/> <line x1="250" y1="30" x2="250" y2="160" stroke="#35495e" stroke-width="0.5" opacity="0.15"/> <line x1="250" y1="300" x2="250" y2="160" stroke="#35495e" stroke-width="0.5" opacity="0.15"/>

<!-- Central Vue logo simplified --> <g filter="url(#glow)"> <polygon points="250,120 270,155 280,140 250,95 220,140 230,155" fill="#42b883" opacity="0.9"> <animate attributeName="opacity" values="0.8;1;0.8" dur="2s" repeatCount="indefinite"/> </polygon> <polygon points="250,120 265,145 250,175 235,145" fill="#35495e" opacity="0.9"> <animate attributeName="opacity" values="0.8;1;0.8" dur="2s" repeatCount="indefinite"/> </polygon> </g>

<!-- Main community nodes --> <g filter="url(#glow)"> <circle cx="175" cy="90" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" repeatCount="indefinite"/> </circle> <circle cx="325" cy="90" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="0.5s" repeatCount="indefinite"/> </circle> <circle cx="130" cy="180" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="1s" repeatCount="indefinite"/> </circle> <circle cx="370" cy="180" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="1.5s" repeatCount="indefinite"/> </circle> <circle cx="190" cy="260" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="2s" repeatCount="indefinite"/> </circle> <circle cx="310" cy="260" r="14" fill="#42b883" opacity="0.85"> <animate attributeName="r" values="14;16;14" dur="3s" begin="2.5s" repeatCount="indefinite"/> </circle> </g>

<!-- Node labels -->

<text x="175" y="90" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="325" y="90" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="130" y="180" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="370" y="180" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="190" y="260" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> <text x="310" y="260" text-anchor="middle" dominant-baseline="central" font-size="8" fill="#fff" font-weight="bold" font-family="system-ui">Dev</text> </svg>

</div>

What Emerges from Community

Many of the projects I've introduced started as personal projects by community members.

• Volar — From Johnson Chu's personal project to Vue.js official language tools

• Oxc — The Rust parser Boshen started became VoidZero's core technology

• UnJS — Pooya Parsa's work outside Nuxt became an independent ecosystem

This isn't coincidence.
The Vue.js community has the power for individual passion to move the entire ecosystem.

Chain of Trust

The phenomenon of Vue.js's ecosystem influencing other frameworks and tools cannot be explained by technical superiority alone.

It's trust.

As Evan You stated when founding VoidZero:

"The trust the community has placed in Vite"

— https://voidzero.dev/posts/announcing-voidzero-inc

This trust wasn't built overnight.
Over 10 years of consistent commitment to open source, consideration for backward compatibility, and listening to the community's voice.

As a result, tools that started from Vue.js are used in the React ecosystem, in Svelte, in Solid.

Contribution to the Web Community

This isn't just a Vue.js community story.
It's a contribution to the entire Web developer community.

• Vite changed the development experience for all frameworks beyond Vue.js

• Volar.js enabled language support for Astro and MDX

• Nitro was adopted by meta-frameworks beyond Nuxt

• Oxc and Rolldown are contributing to speeding up the entire JavaScript toolchain

Innovation born in one community spreads across boundaries to the entire Web.

This is the true power of open source, and the value that the Vue.js community embodies, in my view.

<div style="text-align: center; margin: 4rem 0 2rem;"> <svg viewBox="0 0 600 150" style="max-width: 600px; width: 100%;"> <defs> <linearGradient id="finGrad" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:#42b883"/> <stop offset="25%" style="stop-color:#35495e"/> <stop offset="50%" style="stop-color:#646cff"/> <stop offset="75%" style="stop-color:#f59e0b"/> <stop offset="100%" style="stop-color:#42b883"/> <animate attributeName="x1" values="-100%;100%" dur="5s" repeatCount="indefinite"/> <animate attributeName="x2" values="0%;200%" dur="5s" repeatCount="indefinite"/> </linearGradient> </defs> <text x="300" y="60" text-anchor="middle" font-size="36" font-weight="bold" fill="url(#finGrad)" font-family="system-ui, sans-serif"> Characterize Vue.js </text> <text x="300" y="100" text-anchor="middle" font-size="16" fill="#666" font-family="system-ui, sans-serif"> Approachable × Language × Ecosystem × Community </text> <line x1="100" y1="125" x2="500" y2="125" stroke="url(#finGrad)" stroke-width="3"> <animate attributeName="stroke-dasharray" values="0,400;400,0;0,400" dur="4s" repeatCount="indefinite"/> </line> </svg> </div>

Conclusion

I've characterized Vue.js through 4 characters.

1. Approachable — Flexible choices, easy to approach for various use cases

2. Language — A domain-specific language for describing UI

3. Ecosystem — Starting from Vue.js, expanding beyond its boundaries

4. Community — Individual passion drives the ecosystem and builds trust

These aren't independent characteristics.
They influence and reinforce each other.

Because it's Approachable, many people join and the community grows.
Because the community grows, language tools and the ecosystem develop.
Because the ecosystem develops, more choices emerge and Approachability increases.

This cycle is the essence of Vue.js's value, I believe.

Vue.js isn't just a UI framework.
It's approachable,
a language designed for humans,
an ecosystem that expands beyond boundaries,
and a community connected by trust and passion.

This is merely my personal essay and does not represent the official views of the Vue.js Team.

A Familiar Sound

Nowadays, marketing terms like Simple/Easy are frequently used.
I don't intend to mention other specific languages or frameworks this time.
This is purely a story about how to approach Vue.js.

"Vue.js is Easy"

Have you ever heard this phrase?
I've heard it many times.
And just as often, I've heard people say "Vue.js is bad because it has no rules."

Fallacy

I started working with Vue.js / Web around Q4 of 2020, and I don't know what the world was like before that.
I also don't know when this phrase started becoming popular.
However, based on my current feelings, I always have doubts about whether using this phrase is appropriate.

"Vue.js is Easy" is, in my opinion, still correct in limited contexts.
But how many people actually understand those contexts?

Lately, there's been a trend of "things with rules (not limited to web frameworks)," and they do their own marketing like "〇〇 is △△ (but not Easy)."

And in response to that,

"Vue.js is bad because it has no rules"
"It sacrifices rigidity for short-term simplicity"
"Having no rules makes code a mess"

Such claims emerge.

Abstract marketing gets beaten by abstract marketing.

Trade-offs

As I mentioned earlier, "Vue.js is Easy" is indeed correct in some contexts.
Since Vue.js has no explicit rules, it's correct in the sense that from the framework's standpoint, it's not wrong even without learning any particular rules.

However, actually building a product requires thinking about many things.
And here lies a trade-off.

Many people probably approach programming with the preconceived notion that "having rules is better" without considering this trade-off.
Of course, even "having rules is better" has its own trade-offs, but that's not what I want to discuss today.
Let's imagine a situation where the conclusion was "having rules is better."

What should be considered here is:

• What is the rule for (what benefits does having that rule bring)

• Is it appropriate for the current (future) team (yourself) (I'm using parentheses because it varies by context)

• What trade-offs does that rule create

Web applications are incredibly diverse.
Some simply implement UI for data from the backend and display it,
while others provide rich UI combined with complex DOM operations.

And the rules needed for these are completely different.
Design is quite ad-hoc, and there is no silver bullet.

Who's Responsible

What's important here is "who takes responsibility for those rules".
In the case of web applications, I don't think it's necessarily good for the framework to own the rules.
Of course, there may be use cases where it's good for the framework to own the rules.

However, having "the framework"—the foundation of our work—take on this responsibility involves trade-offs.
When the framework takes responsibility here, in most cases, compliance with it is expected.
Even if it's not important for our product.

At the same time, we should also consider other trade-offs that are lost as a result (such as learning costs).
Additionally, I want to note that "who takes responsibility for those rules" and "whether rules are necessary" are completely different matters.

Abstraction Through Language

I've covered the essential points I wanted to make so far.
However, we can't help but want to play word games with definitive statements.

If "Vue.js is Easy" tends to contain negative fallacies and isn't appropriate, what should we say instead?
I love the word "Approachable" that appears in Vue.js's official documentation.

https://vuejs.org/

As I mentioned earlier, "Vue.js is Easy" is correct within the scope of "the framework's responsibility," but when extended to "implementing (and maintaining) web applications," it may lead to incorrect judgments.

If there's some kind of challenge (demand), thinking about conventions and design is a given.
The word Easy might give the fallacy that you can build something good without thinking about this.

Vue.js is Approachable.
It doesn't get in the way when you're thinking about something.

However, in exchange, the implementer bears a bit of responsibility.
This is a trade-off.

This is merely my personal essay and not an official view of the Vue.js Team.

• What I discuss here is not an official view.

• I will talk about "languages," but the discussion is heavily tailored to what I want to convey. Reality is not that simple.

• This is merely presenting one perspective—"you can also look at it this way."

Related: Characterize Vue.js expands this language-oriented view into a broader characterization of Vue.js.

Instructions to Computers

Whether implementing a web application, a native application, or a browser, everything is an instruction to a computer. And all of it can be expressed in binary.

However, it is not realistic for humans to write binary directly. This is like forcing a Japanese speaker to communicate in Morse code. While it can serve as a means of transmitting meaning, it is not practical.

The Abstraction of Programming Languages

Programming languages can be broadly classified into two categories.

General-purpose programming languages are languages for describing general computations not limited to a specific domain. Rust, TypeScript, JavaScript, Python, C, Haskell, and others fall into this category.

On the other hand, domain-specific languages (DSL) are languages specialized for a particular problem domain. HTML, CSS, SQL, JSON, and others fall into this category. And Vue can also be positioned here.

Hierarchy of Abstraction

Binary and ISA

ISA (Instruction Set Architecture) defines the instruction set of a CPU. x86, ARM, RISC-V, and others fall into this category.

ff 43 00 d1
ff 0f 00 b9
48 05 80 52
...

Writing to registers, arithmetic operations, conditional branching, jumps. All computations are expressed through combinations of these primitive instructions. if statements, while loops, function calls—all ultimately reduce to these.

Assembly

Assembly is binary converted to a human-readable format.

my_program:
  sub   sp, sp, #16
  str   wzr, [sp, #12]
  mov   w8, #42
  str   w8, [sp, #8]
  ldr   w8, [sp, #8]
  mov   w10, #2
...

sub is subtraction, mov is value transfer, jmp is jump. Through mnemonics, meaning was given to binary sequences.

But is this enough?

We want to give meaningful names to variables. We want to structure conditional branches. We want to describe repetition concisely. We want to group processes into units called functions. Assembly may be sufficient for computers, but it still places a high cognitive load on humans.

Evolution to High-Level Languages

int main() {
  int a = 42;
  if (a % 2 == 0) {
    a = 5;
  }
  a = a + 999;
  return a;
}

With the advent of C (and Fortran), it became possible to write programs in a form closer to human thinking. Abstractions such as variables, conditional branches, loops, and functions were introduced, significantly reducing the cognitive load on developers.

However, this was not the end.

Automatic memory management, enhanced type systems, object-oriented programming, functional programming, abstraction of concurrent processing... Every time new requirements emerged, new languages were born.

A language is a kind of "translator." It converts human intentions into a format that computers can understand. And in the process of translation, what can be written concisely and what is hidden determines the design philosophy of the language.

Motivation for Language Design

Behind the birth of a language, there is always the improvement of developer experience (DX).

• Semantics of syntax: Providing syntax that corresponds to units of thought, such as if, while, modules, namespaces

• Semantics of the target domain: Java and C++ for OOP, Rust and Go for system programming, HTML/CSS for UI description

• Optimization by compilers: Developers describe intent, and optimization is delegated to the compiler

A language is an accumulation of design decisions about "what to make easy to write" in a specific problem domain.

Vue.js is a Language

Now we get to the main topic.

What is Vue.js? Framework, library—there are various ways to describe it, but here I would like to present one perspective.

Vue.js is a domain-specific language for describing Web UI.

Let's consider what is needed to declaratively describe UI.

• Affinity with web standards: HTML, CSS, JavaScript

• Dynamic view description through data binding

• Component-based design

• Scoped styles

• Content passing through slots

<script setup lang="ts">
import { ref } from "vue";
const count = ref(0);
function increment() {
  count.value++;
}
</script>

<template>
  <button type="button" @click="increment">count is: {{ count }}</button>
</template>

<style scoped>
button {
  color: red;
}
</style>

This format called SFC (Single File Component) borrows the syntax of HTML/CSS/JavaScript while giving semantics specialized for UI description.

Practicality and Language Design

It is possible to design a completely new language. But is that realistic?

Creating a new language means building an ecosystem from scratch. Editor support, type checkers, linters, formatters, build tools... all of these need to be developed anew.

Vue.js took an incremental approach.

Leverage existing assets. Enjoy the benefits of the JavaScript ecosystem and TypeScript's type system as they are.

Maintain mental models. The script section uses JavaScript semantics directly. It does not compromise the writing experience of HTML and CSS.

This is like designing a new language as a "dialect." Without greatly deviating from the grammar of the mother tongue, but introducing unique vocabulary and syntax for specific expressions.

Optimization by Compilers

By having a compiler, a language can benefit from optimization.

Developers describe intent, and the compiler generates efficient code. Through this division of labor, developers can focus on essential problems and are freed from low-level optimization.

The Vue.js compiler has the following optimizations implemented.

• Static Hoisting: Hoists static nodes outside the rendering function to avoid regeneration

• Patch Flags: Assigns flags to dynamic parts to speed up diff detection

• Tree Flattening: Flattens nested static nodes to reduce traversal costs

• Vapor Mode: A more direct rendering mode without going through the virtual DOM

Details of these are described in the official documentation.

If you look at the output code in the SFC Playground, you can observe what transformations the compiler is performing.

Challenges

Designing and maintaining a language comes with significant costs.

• Language specification design: Balance between consistency and expressiveness

• Compiler implementation: Balancing correctness and performance

• Peripheral tool development: Language server, integration with other ecosystems

Vue.js is already mature in many areas, but there are still things to be done if you look for them. Opportunities for contribution always exist.

Conclusion

From binary to assembly, from assembly to high-level languages. The history of programming is a history of accumulated abstraction.

Vue.js can also be positioned in this lineage. A language that, for the problem domain of Web UI, provides semantics for declarative UI description while building on HTML/CSS/JavaScript.

What is Vue.js?

It's a language.

Naivety

First, please take a look at this post:

https://x.com/ubugeeei/status/1745815915353325898

To be honest, for a long time, I really thought this way.
This is because I wanted people to take action for the community rather than donate to me.
I fully supported those who tried to take action, made suggestions, and did everything I could to increase collaborators.

However, I realized there were some naive underlying thoughts and negative effects on the community.

Avoiding Responsibility

When you accept money, it naturally creates a sense of responsibility, that "I have to do it."
I'm the type who tries to eliminate unnecessary pressure as much as possible, but I now see that I should have developed the ability to turn that sense of obligation into a driving force.
Not only was I avoiding responsibility, but I was also neglecting to challenge myself to embrace change.
I reflect that this was an immature attitude.

Undervaluing Myself

I have always been pessimistic about myself.
While this attitude has its merits, I realized that it negatively impacts not just myself but also the culture around me.
"I don't deserve to receive rewards for my activities." "I need to do more work before asking for anything." "I must stay humble." "I can't afford to be arrogant."
These were my thoughts.

Negative Impact on the Culture

Here's the main point.
If the issue were just personal, I wouldn't have written this blog post. But I believe this realization is something everyone involved in growing the community and culture should be aware of.
(I hope this message reaches many people.)

Simply put, such an attitude contributes to the stagnation of the culture.
In my ideal world, everyone who contributes should receive rewards appropriate for their efforts, and they should use that as fuel for their next activities.

These days, we often hear discussions about the lack of compensation for OSS maintainers' efforts.
I strongly believe that the OSS community should have better economic circulation.

Yet, by rejecting compensation, not opening sponsorships, or not having any channel to receive support, I was contradicting this belief.
The more I contributed, the higher I unintentionally raised the barrier to economic circulation, which is harmful to the culture.

In reality, compared to contributors active worldwide, my activities are still minor. Whether I open sponsorships or not may not have a large influence, but even so, I believe I should start receiving some form of compensation, even if it's small, and actively ask for it to contribute to cultural development.
(Small as it may be, I want to cultivate this culture from within my own sphere.)

Regardless of the amount, the culture of paying for activities should move forward.
The more we reject receiving or making payments, the higher the barrier becomes, and the more people will think, "Well, that's just the way it is." Moreover, it perpetuates the common misconception that "open source is free to use."
This is something that should not happen.

A Side Story

The one who made me rethink this issue was @ota-meshi (Vue.js Core Team Member).
When Vue.js members from abroad came to Japan, I attended an offline meeting and shared a train ride home with Ota-san, where we discussed this topic.
When I explained my old way of thinking, he told me, "That's wrong."
When I reflected on it, I realized he was absolutely right.

Another acquaintance also told me, "Isn't that just you avoiding responsibility?" and "Aren't you undervaluing yourself too much?"
I agreed with that as well.

When I think alone, I tend to focus only on myself, and I have a bad habit of becoming overly pessimistic. But this experience reaffirmed the importance of talking to people who are ahead of me, those who can evaluate me objectively, and those who take different actions than I do.

I am grateful to everyone who gave me the opportunity to reconsider.

I’ve launched my GitHub Sponsors!
If you'd like to support my work, I would greatly appreciate it!

https://github.com/sponsors/ubugeeei

People, including myself, often seek lasting stability.
We want to maintain good performance at work and consistently make progress in our personal hobbies and interests.

However, I have been thinking a lot lately about whether that is truly the ideal state we should aim for.
Is instability always a bad thing?

I personally have my ups and downs, and when I am not in a good state, I always feel frustrated.
Looking back, I sometimes think, "Oh, if only I had been in a better state at that time, things would have been better."

But that is a mistake.

Being in a bad state can be a driving force.
It is better to have moments of high velocity rather than being constantly in a flat state.

Instability and propulsion are two sides of the same coin.

I love jazz. In jazz, there are concepts such as dominance and swing.
To put it bluntly, dominance creates an unstable pitch, and swing creates an unstable rhythm.

This non-monotonous instability generates propulsion and creates a strong groove.
And that is the charm of jazz.

Let's understand and embrace that charm.

A more generalized form of accessibility.

Definition

Activist?

Let's summarize the definition here.
Here, the term "activist" refers to all individuals who are actively engaged in activities.(Well... This doesn't explain anything...)

A person working for a company, a person who is active in some communities, an independent OSS developer, etc...
There are many ways to be active, but one thing is common to all of them.

Form of Information

Information comes in many forms. Text data, audio data, and of course, what you are thinking.
In some cases, "what you are not thinking" can also be information.

These have deferent priorities, and the way they are handled varies depending on the situation.

Dynamic and Static Information

Information can be classified into dynamic and static.

Dynamic:

• Conversation

• What you are thinking

• etc...

Static:

• Text data

• Audio data

• etc...

This ways of classifying is quite subjective, but as a rule of thumb, it is the difference between "tampering preparedness" and "tampering traceability".

And I strongly believe that one of the roles of activists is to "compile dynamic information related to activities into static information".
This is because static information has many values.

Values of Static Information

Accessibility

First of all, let's think about accessibility.
Accessibility here is different from context in web accessibility.
It is a more generalized concept that goes beyond the scope of web content.

As an activist, there are several restrictions on access to information:

• Time constraints

• Processing power constraints

• Memory constraints

First of all, it's time. Dynamic information cannot be shared with others across time.
Not everyone is present and talking at the same time.
In the micro context, "meetings" are a good example. Of course, some people cannot participate because the schedule does not match.
In the macro context, "generational change (handover)" and "catching up on new participation" are good examples. It is valuable to have the way of thinking and what has been done at that time statically summarized for knowing the past events and history.

Next is processing power. Human processing power varies from person to person.
Some people understand things quickly, while others do not.
Even if you are in the same place at the same time and share your thoughts, the ability to process that information varies.
Static information that complements this is very valuable.

Finally, memory. Human memory is limited.
It is common to forget, and it is common for information to be altered somewhere.
Moreover, static information that is persistent and resistant to alteration is very valuable as a complement to memory.

Machine Readability

This word also appears in the context of web content, but there is an analogy in this story as well.
Dynamic information is difficult for machines to read.

On the other hand, static information is easy for machines to read.
If you dare to mix it with recent hot topics, static information can be input directly into LLM.

Issues

We have understood that static information has various values, and that activists have a role in creating that value.

However, the problem is that "the ability to convert dynamic information into static information is different for each person, and training is required to improve". This ability is different from the so-called "summarizing ability" or "ability to effectively communicate with others".

The "compiler" must not change the meaning between input and output. It means that it is necessary to convert dynamic information into static information without losing as much information as possible.
Thoughts, feelings, atmosphere, flow, and so on at that time.

It is difficult to convert these into static information without excess or deficiency.
But this ability is necessary for us activists. Let's train ourselves.

Follow-up: React is React, just. Part 2 looks at Meta, Babel, Flow, and React Compiler from this same thread.

Introduction & Premise

First, as a premise, I am very much in favor of the approach of using a compiler for optimization. This approach is often effective for improving DX without breaking the interface, and I myself use a framework that emphasizes this. However, I have some questions about the mental model changes (or unification [^1]) that come with the compiler's intervention. I don't write React regularly and I'm not an expert, so what I'm about to discuss is not so much an opinion about React, but rather curiosity about "how do people who use React feel about this point?" — it's not about whether it's right or wrong. I'll say it again: I am in favor.

Also, these are thoughts I had when the React Compiler was mentioned on https://react.dev/blog — this isn't based on thorough research into the discussions that have taken place about the React Compiler. This is just an essay.

I welcome answers to the questions I have, but I don't welcome discussions about whether React Compiler or React itself is good or bad based on this essay. The merits of a technology cannot be evaluated by taking just this portion. (That's what I think, so if there's any statement in this essay that could be taken that way, please point it out. I'm not trying to spread any judgment.)

My position: Organizing thoughts and questions Reader's position: Discussing and responding to thoughts and questions What I'm not doing: Judging the merits of the technology

The reason I went so far to add this disclaimer isn't because I didn't want to be criticized or anything like that — it's because the merits of paradigms vary greatly depending on perspective, and there hasn't been enough discussion to talk about them. I really think it's bad when misconceptions spread about the merits of technology, so I want to avoid that.

Topic

This is already subjective, but there's an assertion to some extent that React is "pure JavaScript." Here, I think we need to be careful because "pure" can have multiple meanings.

Pure means: (i) React Components are idempotent JavaScript (ii) React Components are Just JavaScript

What I was particularly curious about this time was: "With the arrival of React Compiler, it seems like (ii) can no longer be satisfied — how do you feel about that?" This is based on the assertion that both were satisfied before React Compiler came along.

Regarding (i), React Compiler is actually an optimization implementation based on the rule that "components should be idempotent," so naturally this can still be said after React Compiler's arrival. I'll call the semantics being considered in (i) "React semantics."

The problem is (ii). The assertion is that React Compiler doesn't change React semantics, but "it does change JS semantics." I'm interested in how people using React feel about this. That's the topic this time.

About what "it changes JS semantics" means

Let's consider a component like the following.

This is actually code that appeared at React Advanced 2023's talk about React Forget. (Partially omitted)

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

  if (filteredVideos.length === 0) {
    return <NoVideos />;
  }

  return (
    <>
      <Heading
        heading={heading}
        count={filteredVideos.length}
      />
      <VideoList videos={filterdVideos}>
    </>
  )
}

When React users see code like this, they'll notice the unnecessary computation and optimize it.

function VideoTag({ heading, video, filter }) {
  const filteredVideos = useMemo(() => {
    const filteredVideos = [];
    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filteredVideos.push(video);
      }
    }
    return filteredVideos;
  }, [videos, filters])


  if (filteredVideos.length === 0) {
    return <NoVideos />;
  }

  return ...;
}

Reference: Understanding Idiomatic React – Joe Savona, Mofei Zhang, React Advanced 2023 t=196

However, with the arrival of React Compiler, this is about to change significantly. React Compiler analyzes this code (the one without useMemo) and transforms it into JavaScript code that performs memoization.

function VideoTab(t36) {
  const $ = useMemoCache(12);
  const { heading, videos, filter } = t36;
  let filteredVideos;

  if ($[0] !== videos || $[1] !== filter) {
    filteredVideos = [];

    for (const video of videos) {
      if (applyFilter(video, filter)) {
        filteredVideos.push(video);
      }
    }
    $[0] = videos;
    $[1] = filter;
    $[2] = filteredVideos;

  } else {
    filteredVideos = $[2];
  }

  if (filteredVideos.length === 0) {
    return <NoVideos />;
  }

  return ...;
}

Reference: Understanding Idiomatic React – Joe Savona, Mofei Zhang, React Advanced 2023 (t=497)

This means it's "optimization of JavaScript code (output code) in terms of React semantics," and "JavaScript semantics" itself has changed.

A JavaScript function is something that, when written like:

function Func(n) {
  let list = [];
  for (let i = 0; i < n; i++) {
    list.push(i);
  }
  return list;
}

will always be executed regardless of its result.

But React Components after React Compiler are not like that. On the surface it looks like a JS function, but it's no longer Just a JS function, it seems.

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

 ...
}

Even though you wrote this, the number of function calls and the number of times the written process actually executes don't match. Such evaluation rules don't exist in JavaScript — they're the result of React Compiler optimizing based on React semantics.

Does this convey what I mean by "with the arrival of React Compiler, React Components are no longer Just JavaScript"?

The semantics have doubled, but the syntax remains one

Setting aside the discussion of whether we should use both "React semantics" and "JS semantics" when actually implementing Components in React,

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

 ...
}

It's a fact that when looking at this function, two semantics exist. (React semantics and JS semantics) Sometimes the number of function calls and the number of body executions may match, and sometimes they may not. I don't know if this will be a burden for developers or learners, but the possibility isn't zero.

A note about the advantages related to syntax

Until now, I've mainly discussed the semantics of a function like this:

function VideoTag({ heading, video, filter }) {
  const filteredVideos = [];
  for (const video of videos) {
    if (applyFilter(video, filter)) {
      filteredVideos.push(video);
    }
  }

 ...
}

But now about syntax. Regarding syntax, whether before or after React Compiler's arrival, it's undoubtedly "Just JavaScript." (There's also the argument that JSX isn't JS in the first place, but that's not the main point here, so I'll skip it)

One advantage often cited for React being Just JavaScript is the ease of static analysis and integration with toolchains. I personally think these can still be generally claimed. (Whether that means other things are bad is a separate discussion) Strictly speaking, there's a possibility that tools where JS semantics are important may partially not be so, but I feel like there are hardly any tools where that becomes important (completely subjective).

However, what I want to note is that distinction. Before React Compiler, "React is Just JavaScript, therefore ${any evaluation}" could apply to both semantics and syntax. But after React Compiler's arrival, I think this has become a syntax matter.

When someone says "React is Just JavaScript, therefore ${any evaluation}," without this distinction, there's a possibility of making incorrect evaluations. I'm not sure how much of a problem this will be, but I thought this might be a newly raised issue.

[^1]: Of course, some people were only thinking in terms of React semantics from the beginning. For them, nothing has particularly changed, but I thought people who were also considering JS semantics would be unified to only think in terms of React semantics (I'm not sure how it actually is)

So what can we say React Components are?

If it changes JavaScript's semantics, it doesn't seem like we can call it "Just JavaScript." So what is it? . . . . React is React. It's something different that has the same syntax as JavaScript but different meaning.

That's what I thought, but what do you all think...?

Essay: Is React JavaScript + Rules, or is it a language?

https://x.com/ubugeeei/status/1758298301609492584?s=20

<details> <summary>ref:</summary>

https://x.com/ubugeeei/status/1758296154406821942?s=20

https://x.com/ubugeeei/status/1758308229602529304?s=20

https://x.com/ubugeeei/status/1758309937300808122?s=20

https://x.com/ubugeeei/status/1758458714749911445?s=20

https://x.com/ubugeeei/status/1758467330278035779?s=20

https://x.com/ubugeeei/status/1758508131385266543?s=20

https://x.com/ubugeeei/status/1758521001091191294?s=20

</details>