Proposal: Ditch Angular and Switch to a new frontend framework

[bobbai00]

Proposal: Ditch Angular, Switch to React

Today's Texera Frontend

Texera's frontend is built with Angular 21. It has three major components:

1. Resource pages: the dashboard and the community hub list workflows, datasets, models, and computing units, with detail pages for workflows, datasets, and models. They have 45 components built on ng-zorro (Ant Design for Angular).
2. Collaborative workflow canvas: the workflow editor is built on JointJS 3.5, and users edit the same workflow together through Yjs over y-websocket. About 2,100 lines of glue code connect JointJS to the workflow model.
3. AI components: the agent chat panel is hand-written. It has about 5,300 lines of code, including our own WebSocket protocol, message rendering, and tool-call views.

Limitations

Based on my experience of developing several components in Texera, I found three major limitations with current Texera's frontend framework:

• Limitation 1: Limited community support for AI components: Angular is no longer a popular frontend framework. For example, React has 30 times more weekly downloads (252M vs. 8.4M) and 2.5 times more developers (44.7% vs. 18.2%). As a result, many new frontend components, especially advanced AI components, support only React and not Angular.

• Limitation 2: Deprecated workflow canvas library: our workflow canvas is built on JointJS 3.5, a 2022 version whose npm package is now deprecated. Newer libraries, such as React Flow, are much faster in our tests. Unfortunately, React Flow supports only React, so we cannot adopt it in Angular.

• Limitation 3: Ad-hoc and duplicate code** for each resource**: each kind of resource (e.g. workflow, dataset) has its own hand-built pages, which are often copied from one another. For example, the model detail page repeats 65% of the dataset detail page's template and 88% of its styles. Moreover, these pages hard-code 210 colors instead of using one theme, so they do not look alike. As a result, every new kind of resource, such as agents, needs yet another copy.

Proposal: Switch To A New Frontend Framework

To solve these limitations, I suggest switching to a new frontend framework. To identify an eligible framework, I think three requirements need to be met

• Requirement 1: Large developer community: the framework should be widely used, so that new libraries, fixes, and developers are easy to find.

• Requirement 2: Mature AI components: the framework should have mature libraries for AI components, such as chat, so that Texera does not need to build them from scratch.

• Requirement 3: Real-time collaborative workflow canvas: the framework should have a mature node-graph library that works with shared editing, so that several users can edit the same workflow together.

I compare today's Angular with four candidates against these requirements: React, Vue, Svelte, and Solid.

Candidate Comparison

Requirement	Angular (current)	React	Vue	Svelte	Solid
R1. Large developer community	18.2% of developers: 8.4M weekly downloads	44.7% of developers: 252M weekly downloads	17.6% of developers: 25M weekly downloads	7.2% of developers: 9.4M weekly downloads	Not in the survey: 11.2M weekly downloads, largely via TanStack devtools
R2. Mature AI components	Early: CopilotKit 0.6, AI SDK binding	Mature: assistant-ui, CopilotKit, AI Elements	Good: Nuxt UI chat, CopilotKit, AI SDK binding	Partial: AI SDK binding, AI Elements port (community)	Weak: AI SDK binding deprecated, no chat kit
R3. Real-time collaborative workflow canvas	Deprecated: JointJS 3.5; alternative Foblex Flow, 98k weekly downloads	24M weekly downloads: React Flow, Yjs example, Hocuspocus binding	1.3M weekly downloads: Vue Flow, used by n8n, no release since Jan 2026	358k weekly downloads: Svelte Flow, no collaboration example	1.6k weekly downloads: solid-flow, community port
Meets all requirements	No: misses R2 and R3	Yes	Yes, weaker on R3 compared to ReAct	No: misses R2	No: misses R2 and R3

Developer usage is from the Stack Overflow Developer Survey 2025.

My Proposal: Switch to React

Based on the comparison result, I propose switching to** React**, because it is the only candidate that meets all three requirements.

This is apparently a huge topic. I hope developers, especially those who are familiar with Texera's frontend development, can chime in.

[zyratlo]

Thanks for putting this together. I have a few questions about JointJS, and will put other thoughts in a separate comment. Please correct me if I am misunderstanding anything.

From what I can gather, the jointjs npm package is deprecated because it was renamed to @joint/core in v4 (Feb 2024). The library is still actively maintained, the latest release (4.3.4) came out on Oct 27, see https://www.npmjs.com/package/@joint/core. The license also hasn't changed, it's MPL-2.0, the same as the 3.5 we currently use. If we already know this and there is a reason we haven't upgraded, please correct me and the rest of this comment is moot.

The reason I bring this up is that, going by JointJS's changelog, we're missing a lot by staying on 3.5. There are security fixes, and 4.2 added viewport-based rendering options for large graphs. If the React Flow speed comparison was run against our current 3.5 setup, I don't think it tells us much about current JointJS.

Another thing is that JointJS now has an official React binding, @joint/react (MPL-2.0, released with 4.3.0 in July, see https://www.npmjs.com/package/@joint/react). It's still new, but it means React Flow isn't the only canvas option if we do go with React. Using @joint/react could let us keep much of our existing JointJS code instead of rewriting the canvas from scratch, though our shapes would still need the v4 migration.

So in summary, my questions are:

1. Is there a reason we can't upgrade to @joint/core 4.3.4? I see Migrate frontend workflow editor from JointJS 3.5.4 to @joint/core v4 #5366 scoped the migration but it was closed without a PR.
2. Was the React Flow comparison done against JointJS 3.5? If so, and we can upgrade, a comparison against 4.3.4 would tell us more.
3. If we do switch to React, would you be open to evaluating @joint/react alongside React Flow and the other collaborative canvas libraries before we decide?

[zyratlo]

JointJS also has a paid commercial edition, JointJS+ (formerly Rappid), with premium features and a proprietary license. That may be where the mix-up came from, but the open-source @joint/core is a separate package and is still maintained under MPL-2.0.

[kunwp1]

Thanks for putting this together. I agree that the current UI looks outdated, and I support exploring a new framework.

Popularity and maturity matter more than before. The three requirements mostly measure how popular and mature each framework is. I think this is a strong argument for AI-assisted coding, since coding agents write better code for frameworks and libraries that have more code and examples to learn from. Thus, a popular stack could directly speed up our development.

Before deciding, I would like to see a prototype that rebuilds one component in the new framework, mainly the workflow canvas.

What the prototype could show.

i) How the UI changes: the same workflow on the current canvas and on the new one, side by side.

ii) How the code changes: the new code next to the ~2,100 lines of JointJS glue code mentioned in the proposal, with line counts for the same features. To keep the comparison fair, the prototype could cover the features that make our canvas unique, namely operators with multiple ports, live operator status during execution, and the region overlay.

[aglinxinyuan]

I believe the prototype should match our current Texera frontend exactly, with the same UI and features. The choice of frontend framework is separate from UI design and functionality, so switching frameworks should preserve both.

Any UI improvements, such as redesigning the workflow canvas or switching to a different canvas library, should be handled as a separate effort.

[zyratlo]

I'd also like to see a prototype before we decide, the canvas side by side with the current one is a nice option.

[zyratlo]

Here are my thoughts on the rest of the proposal.

I'm not against moving off Angular, but it will be a huge effort and take a lot of planning, so it needs to be worth it. I agree with the three listed requirements as the way to judge that.

For limitation 1, I think a larger community is a real advantage, even if Angular can do everything we need right now. It means more libraries and updates, and like @kunwp1 said, it's easier for coding agents to work with. We could also run into something later that React supports and Angular doesn't.

For limitation 2, see my separate JointJS comment.

In general, I support the switch since the benefits are real and valuable. The deciding factor for me is the effort and time required to do this whole process. I might be getting ahead of myself here since this is still just a proposal to switch, but seeing a roadmap and/or plan timeline would help with gauging the effort needed to do the switch.

[aglinxinyuan]

I built an AI-assisted prototype of the Angular-to-React migration: draft PR #9389. The prototype keeps the existing JointJS canvas.

The AI agent’s result isn’t perfect, mainly in the CSS. Each component still needs human verification and testing to confirm that its UI and behavior match the current frontend. That makes migrating everything in one step difficult. We can migrate one component at a time and verify each before moving on.

Here are three side-by-side comparisons, with Angular on the left and React on the right. They are also included in the draft PR.

[Yicong-Huang]

Nice. Can't imagine this to be done so quickly years ago.

[Xiao-zhen-Liu]

Thanks @bobbai00 for starting this discussion. Here is some context on the workflow canvas and our Yjs shared-editing implementation:

1. JointJS package rename: On npm, the unscoped jointjs package was deprecated when the maintainers renamed it to @joint/core, which continues to receive releases (version 4.3.4 was published last week with zero dependencies).
2. Why shared editing required manual sync logic:
   • Plain objects vs. Yjs types: The workflow canvas and the operator property forms read and write plain JavaScript objects, whereas Yjs only synchronizes edits made directly to its shared data types (Y.Map, Y.Array, Y.Text). Replacing a whole operator property object on every form edit would overwrite other users' concurrent edits and break live cursors in the shared text and code editors, so we had to write recursive conversion and array-diffing logic to apply changes in place to nested Y.Map, Y.Array, and Y.Text structures.
   • Local UI state and graph constraints: Not every canvas change belongs in the shared workflow model. Per-user state (such as selection highlights or a link being dragged before it attaches to a port) must stay local, and concurrent edits or undos from multiple users can produce invalid links (such as duplicate or disconnected links) that must be validated and cleaned up after Yjs merges them.
3. How this maps to React and React Flow:
   • Texera already runs yjs 13.6.31 (the latest stable release is 13.6.33).
   • React Flow has no built-in Yjs adapter (its collaborative example is under the paid xyflow Pro license, and its multiplayer documentation notes that applications must write their own two-way sync to separate shared node and edge fields from per-user selection, drag, and DOM measurement state), and @hocuspocus/provider-react only provides hooks for WebSocket connection status and user awareness.
   • In a new frontend framework, our plain-object-to-Yjs diffing logic is plain TypeScript and can be carried over as-is, while the two-way sync between Yjs, the canvas library, and the operator property forms would need to be written for the new libraries.

[bobbai00]

Thanks for the information!

[chenlica]

I support the idea of migrating to a better frontend framework, if the effort is manageable. For instance, if it takes a member a few weeks to do so, I believe it's worth it, as the benefits are significant.

[aicam]

I agree, I also propose to review the PRs differently.
Based on my experience with AI coding in the past few years, they are extremely powerful in frontend. Also, testing frontend is much easier compared to backend, in frontend, to test a change or feature, developer can just open the browser go to the corresponding page and check. In this regard, I believe we do not need thorough review to merge PRs, to some extent, testing on browser is more efficient than reading the code. This is a personal opinion but I think frontend code does not need thorough review backend requires.

[aglinxinyuan]

I somewhat disagree. AI agents are generally good at frontend logic (JavaScript), but much weaker at layout and styling (HTML/CSS). Unlike code, visual changes require launching a browser and taking screenshots to verify, and AI still struggles to detect subtle layout issues.

AI can easily generate an impressive-looking frontend when requirements are flexible. But reproducing our current Texera UI exactly in a different framework is a very different challenge. In my experience, AI agents often struggle with even simple layout adjustments and tend to produce unnecessarily complicated CSS.

That’s why I think frontend PRs still need careful review, especially when preserving the existing UI features is a requirement.

[chenlica]

As an exercise, I wonder how easy it is to migrate our current shared-editing feature from Angular to React. @Xiao-zhen-Liu @aglinxinyuan, thoughts?

[aglinxinyuan]

As an exercise, I wonder how easy it is to migrate our current shared-editing feature from Angular to React. @Xiao-zhen-Liu @aglinxinyuan, thoughts?

The share-editing feature is probably the most challenging to migrate, given its extensive dependencies on other components and libraries, as well as its substantial custom logic.

[Xiao-zhen-Liu]

Thanks @bobbai00 for starting this discussion. Here is some context on the workflow canvas and our Yjs shared-editing implementation:

1. JointJS package rename: On npm, the unscoped jointjs package was deprecated when the maintainers renamed it to @joint/core, which continues to receive releases (version 4.3.4 was published last week with zero dependencies).

2. Why shared editing required manual sync logic:

   • Plain objects vs. Yjs types: The workflow canvas and the operator property forms read and write plain JavaScript objects, whereas Yjs only synchronizes edits made directly to its shared data types (Y.Map, Y.Array, Y.Text). Replacing a whole operator property object on every form edit would overwrite other users' concurrent edits and break live cursors in the shared text and code editors, so we had to write recursive conversion and array-diffing logic to apply changes in place to nested Y.Map, Y.Array, and Y.Text structures.
   • Local UI state and graph constraints: Not every canvas change belongs in the shared workflow model. Per-user state (such as selection highlights or a link being dragged before it attaches to a port) must stay local, and concurrent edits or undos from multiple users can produce invalid links (such as duplicate or disconnected links) that must be validated and cleaned up after Yjs merges them.

3. How this maps to React and React Flow:

   • Texera already runs yjs 13.6.31 (the latest stable release is 13.6.33).
   • React Flow has no built-in Yjs adapter (its collaborative example is under the paid xyflow Pro license, and its multiplayer documentation notes that applications must write their own two-way sync to separate shared node and edge fields from per-user selection, drag, and DOM measurement state), and @hocuspocus/provider-react only provides hooks for WebSocket connection status and user awareness.
   • In a new frontend framework, our plain-object-to-Yjs diffing logic is plain TypeScript and can be carried over as-is, while the two-way sync between Yjs, the canvas library, and the operator property forms would need to be written for the new libraries.

I already posted my thoughts about shared editing above. It doesn't look super challenging with the help of agents, but will be among the tricker frontend migrations (I think this is true for the whole workflow editor canvas), and extensive manual verification will be needed.