DEV Community: Aleksandr Gusev

What We Learned Rewriting an Interactive Map Editor: Fabric.js, CORS, and 20,000 Lines of Legacy TypeScript

Aleksandr Gusev — Tue, 07 Jul 2026 18:43:01 +0000

A story about how migrating an interactive office map editor turned into an engineering investigation involving Fabric.js, tainted canvas, and an architecture that's finally easy to extend.

In most software projects, one sentence usually makes every developer nervous:

"Let's rewrite this module from scratch."

It often means months of development, regression risks, and endless architecture discussions.

Our project was no different.

We develop, a workspace management platform that allows companies to manage office spaces and book desks. One of its core features is an interactive office map editor, where administrators upload floor plans, place desks and meeting rooms, and publish maps for employees.

Over the years, this editor slowly evolved into a real monolith.

And the problem wasn't simply the number of lines of code.

Where It All Started

The editor dated back to the AngularJS era.

The main component had gradually grown into a single file responsible for almost everything:

loading maps
working with Fabric.js
CRUD operations
keyboard shortcuts
dialogs
saving
event handling

The main editor component alone contained nearly 2,270 lines of code.

Behind it lived another codebase — the map engine itself.

Almost 20,000 lines of TypeScript spread across more than 230 files.

One of the biggest architectural issues was an infinite rendering loop.

fabric.util.requestAnimFrame(() => this.tick());

Even when the user wasn't interacting with the editor, rendering continued forever.

It worked.

But every new feature became more expensive to build.

Why We Decided to Rewrite It

The motivation wasn't AngularJS itself.

The real reason was business requirements.

The product needed completely new capabilities:

map drafts
safe publishing
high-quality printing
multiple workspace modes
easier support for new object types

Every new feature pushed harder against the existing architecture.

Eventually it became obvious:

We weren't fighting individual bugs anymore.

We were fighting the architecture itself.

Instead of performing a risky Big Bang migration, we decided to build an entirely new administration module alongside the existing viewer.

Building a New Architecture

We kept Fabric.js.

Everything around it changed.

Instead of one massive controller, we introduced clear responsibilities.

Map Editor
        │
        ▼
   Map Engine
        │
 ┌──────┼─────────┐
 │      │         │
 ▼      ▼         ▼
Viewport Registry Changes
                Tracker
        │
        ▼
     Fabric.js

Each subsystem became responsible for exactly one concern.

Viewport controls camera movement.
Object Registry manages map entities.
Changes Tracker knows only about modifications.
Map Engine exposes a single API for the editor.

The most pleasant surprise came later.

Adding new functionality no longer required touching half of the application.

Moving the Camera Instead of Moving Objects

One architectural decision simplified much more than we expected.

Instead of physically moving every desk on the canvas, we move the camera using Fabric's viewportTransform.

Objects always stay in their original coordinates.

This dramatically simplified:

zooming
panning
exporting
printing

Sometimes one architectural decision solves several future problems at once.

The Hardest Problem Wasn't Angular

When the migration started, we believed rewriting nearly 20,000 lines of TypeScript would be the hardest challenge.

It wasn't.

The most difficult part looked completely harmless.

We simply needed to print the office map.

Attempt #1

The obvious solution:

window.print();

Unfortunately, browser printing renders the DOM at roughly screen resolution.

For large office maps, the result was blurry.

Even worse, parts of the editor UI appeared in the printed document.

Not acceptable.

Attempt #2

The next idea looked much better.

Export the Fabric canvas as a high-resolution image.

canvas.toDataURL();

Instead, the browser answered with:

SecurityError:
The canvas has been tainted by cross-origin data.

Why?

The floor plan image was stored on Amazon S3.

Although it rendered perfectly inside the browser, exporting the canvas became impossible because the background image wasn't available with the required CORS configuration.

The browser was doing exactly what it was supposed to do.

Attempt #3

This one finally worked.

Instead of exporting a single PNG, we split printing into two independent layers.

The background image remained untouched.

The Fabric objects were exported separately without the background.

Conceptually, the pipeline became:

Background Image
        +
Objects Layer
        =
Printable Document

The implementation looked roughly like this:

const objectsDataUrl = exportCanvasRegion({
    hideBackground: true,
});

return {
    backgroundUrl,
    objectsDataUrl,
};

The solution looked more complicated.

In reality, it proved to be much more reliable.

One More Unexpected Problem

After solving the SecurityError, another issue appeared.

Objects slowly drifted away from their correct positions during printing.

The reason turned out to be surprisingly subtle.

The background image was positioned in pixels.

The overlay objects were positioned using percentages.

When the browser recalculated layout for printing, the two layers no longer aligned.

The final fix was surprisingly simple.

We switched background positioning to percentage-based coordinates as well.

Immediately both layers aligned perfectly again.

Problems like this are often the hardest to debug.

Not because the code is wrong.

But because the coordinate model itself is wrong.

What Changed After the Migration

Interestingly, success wasn't measured by fewer lines of code.

The new implementation actually introduced new functionality:

draft support
printing
safe publishing
multiple workspace modes
a much cleaner architecture

The number of lines became a meaningless metric.

The important improvement was something else.

Adding new features no longer felt dangerous.

What We Learned

Projects like this remind you that the hardest engineering challenges rarely belong to a particular framework.

Angular evolves.

Fabric.js evolves.

TypeScript evolves.

But the real complexity usually appears somewhere between these technologies.

Sometimes rewriting twenty thousand lines of code isn't the hardest part of the project.

Sometimes it's the seemingly innocent Print button.

That single feature forced us to better understand browser rendering, CORS, Canvas security, coordinate systems, and software architecture than any framework migration ever could.

Final Thoughts

Looking back, the migration wasn't really about Angular.

It was about making the product easier to evolve.

The new architecture didn't dramatically reduce the amount of code.

Instead, it reduced the cost of future changes.

Sometimes that's a far more valuable metric than lines of code.

What's Next?

If this story is interesting, I'd be happy to write a follow-up article explaining how we designed our MapEngine, why we decided to keep Fabric.js, and how we migrated the administration module without stopping product development.

This article is based on our experience building and maintaining an enterprise workspace management platform. Code samples have been simplified, and implementation details have been generalized to respect product confidentiality while preserving the engineering decisions and lessons learned.

angular #typescript #webdev #architecture

Should Angular Apps Still Rely on RxJS in 2026?

Aleksandr Gusev — Fri, 22 May 2026 17:09:09 +0000

Angular is going through a quiet but important shift in how reactivity is handled. With the introduction of Signals, many developers are starting to ask a simple question:

Do we still need RxJS in Angular applications in 2026?

The short answer is: yes — but not everywhere.

The real answer is more interesting, and it’s about architecture, not preference.

Two different mental models

To understand the discussion, it helps to separate two fundamentally different models of reactivity.

RxJS: asynchronous streams

RxJS is built around:

event streams
asynchronous composition
time-based operations

It shines when dealing with:

HTTP requests
WebSockets
complex async workflows
event orchestration

RxJS is about time and events.

Signals: local reactive state

Signals represent a different idea:

synchronous reactivity
local state tracking
explicit dependencies

They are best suited for:

UI state
derived state
component-level reactivity

Signals are about state and UI consistency.

Code comparison

Signals example

import { signal, computed } from '@angular/core';

const count = signal(0);

const doubled = computed(() => count() * 2);

function increment() {
  count.set(count() + 1);
}

Signals make state and dependencies explicit. No subscriptions, no hidden wiring.

RxJS example

import { BehaviorSubject, map } from 'rxjs';

const count$ = new BehaviorSubject(0);

const doubled$ = count$.pipe(
  map(value => value * 2)
);

function increment() {
  count$.next(count$.value + 1);
}

RxJS introduces a stream-based model where everything flows through observables.

The real problem is not technology, but mixing models

The biggest architectural issue in modern Angular applications is not choosing between RxJS and Signals.

It is mixing them without clear boundaries.

When both are used everywhere:

state becomes duplicated
logic becomes scattered
it becomes unclear where the “source of truth” lives

Where RxJS is still the right tool

Even in 2026, RxJS is still essential:

HTTP request pipelines
cancellation and retry logic
real-time data streams
coordination of multiple async sources

If the problem involves time, concurrency, or event composition, RxJS is still the better abstraction.

Where Signals are a better fit

Signals work better when the problem is local and state-driven:

component state
derived UI values
form state
simple reactive bindings

Signals reduce unnecessary complexity and make data flow more explicit.

Architectural boundary

A simple rule:

RxJS handles the outside world.
Signals handle the UI world.

RxJS = integration layer
Signals = presentation layer

When this boundary is respected, Angular applications become significantly easier to maintain.

Final thoughts

In 2026, RxJS is not obsolete in Angular — it is simply no longer the only reactive model.

Signals introduce a second layer that allows developers to simplify UI logic without abandoning reactive power.

The best Angular applications are not those that choose one over the other, but those that clearly define when to use each.

Architecture is not about tools.
It is about boundaries.

Angular Signals

Aleksandr Gusev — Fri, 24 Apr 2026 18:34:08 +0000

Angular Signals — A Shift in Angular Reactivity

Angular has changed significantly over the past few years. What was once often perceived as a heavy framework with complex change detection and a strong reliance on Zone.js is gradually moving toward a more explicit and predictable reactivity model.

One of the key steps in this direction is Signals.

What are Signals?

Signals in Angular introduce a new way of handling state that makes reactivity more explicit.

In simple terms:

Angular used to rely heavily on Zone.js and implicit change detection
Now it introduces a model where state and dependencies are explicitly defined

A Signal is a reactive primitive that holds a value and notifies the system when that value changes.

Why this matters

One of the long-standing challenges in Angular was not complexity itself, but implicit reactivity.

Developers often had to deal with questions like:

What exactly triggered a UI update?
Why did this component re-render?
Where does change detection actually stop?

Signals make this behavior more explicit and predictable.

Now:

dependencies are directly readable
updates are more granular
less framework-level “magic” is involved

A simple mindset shift

Before Signals:

“Angular will figure out what needs to update.”

With Signals:

“I explicitly define what depends on what.”

This is not just a technical change — it’s a conceptual shift in how we think about UI reactivity.

What changes in practice

1. More predictable state management

Signals move Angular closer to simple reactive primitives instead of relying on global change detection mechanisms.

2. Reduced reliance on Zone.js

Angular is gradually moving toward a model where Zone.js is no longer the central piece of reactivity.

Note: What is Zone.js?

Zone.js is a library that was historically at the core of Angular’s change detection system.

In simple terms, it:

tracks asynchronous operations (setTimeout, HTTP requests, events)
and notifies Angular when it should check for UI updates

This allowed Angular to automatically update the UI without explicit developer intervention.

However, this convenience comes with a trade-off: behavior becomes less transparent, since it is not always clear what triggered a re-render.

Signals address part of this by making reactivity more explicit and controlled.

Signals vs RxJS

Signals do not replace RxJS — they serve different purposes.

RxJS:

streams and events
asynchronous workflows

Signals:

local state
synchronous reactivity
UI-driven updates

They complement each other rather than compete.

Where Signals shine

Signals are especially useful in:

complex UI state
forms and interactive interfaces
applications where predictability matters

Final thoughts

Signals are not just a new API in Angular.

They represent a shift toward:

more explicit reactivity
more predictable UI behavior
a simpler mental model for developers

It’s one of the most meaningful evolutions in Angular in recent years — aimed at reducing hidden complexity without sacrificing power.

Why Being a Senior Developer Is Less About Tech Stack and More About Thinking

Aleksandr Gusev — Tue, 20 Jan 2026 18:24:41 +0000

After nearly a decade in professional web development, I’ve noticed that many discussions about seniority focus on the wrong things. People ask which tech stack you need to learn or how many years it takes to become a senior. In my experience, those questions miss the point.

Being a senior developer is not about specific technologies or job titles. It’s about the way you think and the responsibility you take.

A Tech Stack Is a Tool, Not a Level

Throughout my career, I’ve worked with different frameworks and approaches. Some were trendy, others were already considered outdated when they were introduced. Almost all of them eventually changed.

What didn’t change was the level of responsibility.

A junior developer worries about how to write code.
A mid-level developer worries about how to write correct code.
A senior developer worries about why this code should exist at all.

Responsibility Comes Before the Title

Senior-level thinking often appears long before the official title:
— when you think about maintainability, not just delivery;
— when you question requirements instead of blindly implementing them;
— when you understand that there is no perfect solution, only trade-offs.

At some point, you stop writing code for machines and start writing it for people who will read and maintain it months or years later.

Architecture Is Not About Diagrams

Architecture is often associated with clean diagrams and well-known patterns. In reality, architecture is more about:
— where the system can break;
— how expensive changes will be;
— who will maintain it and how.

Sometimes the best architectural decision is the most boring one.

Experience Is Not the Number of Projects

Experience doesn’t come from the number of projects or lines of code. It comes from situations where you:
— had to fix someone else’s mistakes;
— rolled back your own wrong decisions;
— supported a product for years instead of shipping it and moving on.

These moments are what actually shape professional judgment.

Final Thoughts

Being a senior developer is not a goal or a status. It’s a side effect of long-term work on real products and taking responsibility for the consequences of your decisions.

You can learn a tech stack.
Professional thinking takes time to earn.

This way of thinking has helped me make better long-term decisions in real-world products.