DEV Community: Aleksandr Gusev

Fabric.js Wasn't the Problem. Our Architecture Was.

Aleksandr Gusev — Wed, 30 Sep 2026 11:04:48 +0000

We build an interactive office map.

There is a floor plan in the background, desks, meeting rooms, parking spaces, lockers, points of interest, and pods — groups of desks that can move together.

Admins drag objects around, rotate them, change their shapes, print the floor plan, and save drafts.

The canvas is built with Fabric.js 5. The application around it is Angular 19.

And for a long time, Fabric.js wasn't just the rendering layer.

It was basically the architecture.

That was the problem.

The Old Map Was a Fabric Application That Happened to Have Entities

In the old implementation, a DeskPresenter extended fabric.Group.

Its constructor took entityData.viewConfig and passed properties such as:

left
top
scaleX
angle

directly into Fabric.

The presenter kept a reference to the Desk.

The Desk kept a reference back to the presenter.

So instead of having:

Domain Entity
      +
Canvas Object

we effectively had:

Desk
  ↕
DeskPresenter
  ↕
Fabric.Group

The distinction between our domain model and the canvas object became increasingly blurry.

It was convenient at first.

Then the side effects started appearing.

When Fabric Became Too Global

We had a FabricExtension that modified fabric.Object.prototype at application startup.

It added things like custom corners, caching behavior, snapAngle, centeredRotation, and custom rendering.

There was also older map code modifying:

fabric.Canvas.prototype.setCursor

and even adding functionality to:

CanvasRenderingContext2D

Some custom selection controls lived on those prototypes too.

That means these changes weren't limited to the office map.

They were effectively process-global.

Open another screen that happened to use Fabric and it could inherit behavior that was originally created specifically for the office map.

That was a pretty good sign that the boundaries weren't where they should be.

Events Had the Same Problem

The old AngularJS implementation also had a ToParentEventsConnector.

Its job was to translate Fabric-related events into $scope events.

The class had a large switch over things like:

DeskHoveredEvent
ParkingMouseOutEvent
CreateDragBookingEvent
...

Every new map object could mean another event class and another branch.

Again, Fabric events, application events, and AngularJS communication were tightly connected.

The map wasn't just rendering objects.

It was becoming responsible for communicating with the rest of the application.

Why We Kept Fabric.js

We did consider whether rebuilding the rendering layer from scratch would give us a cleaner architecture.

We decided not to.

Fabric already solves many difficult problems:

object selection;
transformations;
zooming;
hit testing;
object caching;
grouping;
rotation;
serialization.

Our desks aren't simple rectangles either.

They're assembled from multiple paths and wrapped in Fabric groups.

Pods are also groups of desk presenters.

Reimplementing all of that with raw Canvas would mean spending our time rebuilding functionality that Fabric already handles well.

So the decision became:

Keep Fabric. Stop letting Fabric define the application architecture.

That was the reason for introducing MapEngine.

Introducing MapEngine

The new architecture puts an application-level boundary between Angular and Fabric.

Conceptually:

Angular
   │
   ▼
MapEditor
   │
   ▼
MapEngine
   ├── MapStage
   ├── MapViewport
   ├── ObjectRegistry
   └── ChangesTracker
   │
   ▼
Fabric.js

The responsibilities are deliberately separated.

MapStage owns the Fabric canvas.

MapViewport owns the camera.

ObjectRegistry maps application entities to their canvas representations.

ChangesTracker tracks what needs to be saved.

That separation turned out to be much more important than simply moving code into smaller files.

MapStage Is the Canvas

MapStage owns the actual Fabric canvas.

It deals with things like:

adding objects;
removing objects;
canvas size;
rendering;
active objects.

It doesn't need to know how the application thinks about zoom.

That's the viewport's job.

This distinction sounds small, but it gives us a useful rule:

The canvas renders. The engine decides what the canvas means.

The Camera Is a Matrix

One of the decisions I'm particularly happy with is how we handle panning and zooming.

The tempting approach is:

"The user panned the map, so move every object."

We deliberately don't do that.

MapViewport works with Fabric's:

viewportTransform

The objects stay in their original plan coordinates.

The camera moves.

              Camera
                │
                ▼
        viewportTransform
                │
                ▼
        ┌───────────────┐
        │ Office Floor  │
        │               │
        │  Desk   Desk  │
        │       Room    │
        └───────────────┘

That gives us a useful separation:

Object position = position on the floor

Viewport transform = what the user currently sees

This matters later when we need to save, print, or calculate coordinates.

The desk shouldn't suddenly have different coordinates just because the user zoomed to 200%.

Zoom Isn't Just `canvas.setZoom()`

The viewport logic also has to deal with constraints.

For example, fitBackground() calculates the scale required to fit the floor plan.

The editor allows zooming below that level, but only within a configured minimum.

The maximum zoom is also limited.

When zooming out, the viewport is gradually pulled back toward the center of the floor plan so the map doesn't drift away into empty space.

relativePan() converts wheel movement into an absolute translation based on the current viewport state.

And after zooming, the transform is normalized again so small numerical errors don't accumulate.

None of this belongs in an Angular component.

It belongs in the viewport.

Interaction Is Another Layer

PanInteraction sits on top of the viewport.

The interaction rules are roughly:

Wheel / trackpad
       ↓
      Pan

Ctrl/Cmd + wheel
       ↓
      Zoom

Space + drag
       ↓
      Pan

While space-dragging is active, we also disable target finding so the pointer doesn't accidentally select a desk while the user is trying to move the camera.

That's another useful property of the architecture.

The interaction logic doesn't need to know how a desk is rendered.

It only needs to know what the viewport can do.

The Registry Is a Pair, Not a Subclass

One of the biggest changes was separating the application entity from the Fabric object.

The new ObjectRegistry stores:

export interface IMapCanvasObject {
  entity: IEntityData;
  presenter: fabric.Object;
  label?: fabric.IText;
}

That's intentionally small.

The entity is our application data:

id
type
name
assignment
viewConfig
...

The presenter is the Fabric representation.

The label is separate as well.

So instead of:

Desk = Fabric.Group

we now have:

Desk entity
    │
    └── Fabric presenter

This is a subtle change, but it gives us something very important:

the domain object doesn't have to be a canvas object.

ObjectRegistry Doesn't Know How to Draw a Desk

The registry only provides operations such as:

register()
getById()
removeById()
getAll()

It doesn't know how to create a desk.

That's handled by MapObjectFactory.

The factory decides which Fabric representation belongs to a particular SpaceType.

This keeps object creation away from the registry and keeps the registry away from rendering details.

It's a small abstraction.

But small abstractions are often the useful ones.

Serialization Is Where the Boundary Gets Interesting

We still have to move data between the application model and Fabric.

When an object changes, serializeMapPresenter() reads properties such as:

left
top
scale
angle

and writes them back into the entity's viewConfig.

Then ObjectModificationInteraction can notify the ChangesTracker that the entity changed.

This means the flow is roughly:

User moves desk
       ↓
Fabric event
       ↓
ObjectModificationInteraction
       ↓
serialize presenter
       ↓
update entity
       ↓
ChangesTracker

Fabric is involved.

But it isn't the source of truth for the whole application.

That's the boundary we were missing before.

There Is Still Some Leakage

The architecture isn't perfect.

For example, presenters still contain:

presenter.data.mapObjectId
presenter.data.mapObjectType

Those values are used to identify the application entity when a Fabric event arrives.

It's a practical lookup key.

But it's also a leak.

Fabric still needs to know which application object generated an event.

We haven't found a better way to completely remove that connection without making event handling more complicated than it needs to be.

And that's okay.

An abstraction doesn't have to hide every implementation detail.

It just needs to hide the details that would otherwise spread everywhere.

ActiveSelection Instead of Group

This was one of those small Fabric.js details that caused a surprisingly important architectural decision.

Fabric normally turns multiple selected objects into a:

fabric.Group

We override that behavior and use:

fabric.ActiveSelection

instead.

Why?

Because a selection and a group are not the same thing in our domain.

A group represents a real relationship between objects.

A pod is a group of desks.

A temporary selection of three desks is not a new domain object.

If we turned the selection into a Group, we'd be changing the structure of the map just because the user selected several objects.

That's not what we want.

So our UnCanvas creates an ActiveSelection instead:

_createGroup(target: fabric.Object) {
  const groupObjects = [
    this._activeObject,
    target,
  ];

  return new fabric.ActiveSelection(groupObjects, {
    canvas: this,
    ...MAP_CONTROL_STYLE,
  });
}

The selected objects remain independent.

The selection is temporary.

The domain model stays intact.

And Then There Are Coordinates

This is another place where Fabric's internals become important.

Inside an ActiveSelection, the selected object's left and top are relative to the selection.

Scale and rotation can also exist on the selection rather than directly on the desk.

So before saving a modified object, we have to flatten the transform.

Our implementation uses:

calcTransformMatrix()

and:

qrDecompose()

to extract the actual transform that belongs to the object.

This is one of those problems that looks trivial until you have a real editor.

The user sees:

"I moved the desk."

Fabric sees:

"A selection with a transformed child was modified."

The application needs to turn the second statement back into the first one.

ChangesTracker: Don't Save the Whole Map

The new architecture also gives us a better place for change tracking.

The old implementation already had a ChangesTracker.

It maintained:

initialState
currentState

CREATE
UPDATE
DELETE

So the idea of sending changes instead of the entire map wasn't new.

What changed was the boundary.

The canvas can change without becoming the application's source of truth.

The flow is now conceptually:

User changes object
        ↓
Fabric
        ↓
MapEngine
        ↓
Entity updated
        ↓
ChangesTracker
        ↓
CREATE / UPDATE / DELETE
        ↓
Save draft

That makes the save operation about what changed, rather than about serializing everything currently sitting on the canvas.

Angular Doesn't Need to Know Fabric

This is probably the biggest architectural improvement.

MapCanvasComponent owns a MapEngine.

It can ask the engine to:

initialize;
zoom;
print;
convert client coordinates to canvas coordinates.

MapEditorComponent owns the higher-level editor behavior.

It creates the ChangesTracker, hydrates it from the draft or published map, and attaches it to the engine.

The editor can also provide callbacks for things such as:

opening an edit modal;
confirming deletion;
building a pod;
updating sidebar state.

Fabric events stop at the engine boundary.

Angular receives application-level information.

That's the part we wanted.

The Workspace Doesn't Need to Know About Fabric Either

The editor has several workspace modes:

Settings
Arrangement
Print

Each mode has different capabilities.

For example:

Arrangement
├── move
├── delete
├── group
└── add

Print
└── view only

We resolve these capabilities separately and let the engine apply the required locks.

That means we don't need to sprinkle:

if (mode === 'print') ...

through every presenter.

The mode affects capabilities.

It doesn't redefine the canvas architecture.

Was the New Architecture Perfect?

No.

And that's probably the most useful part of the story.

There are still places where Fabric concepts leak through.

The presenter still carries an object ID.

Serialization still has to understand Fabric transforms.

Some legacy coordinate assumptions still exist.

And the old map is still in the repository, which means the new implementation has to understand its coordinate language.

But the important difference is that these problems now have a place to live.

They don't automatically become problems for every Angular component.

What Actually Changed

The biggest improvement wasn't fewer lines of code.

It was the direction of dependencies.

Before:

AngularJS
   ↕
Domain objects
   ↕
Fabric
   ↕
Events
   ↕
Services

Everything knew about everything.

Now:

Angular
   ↓
MapEngine
   ↓
Fabric

with the domain model and change tracking sitting behind explicit boundaries.

That doesn't make the system magically simple.

It makes complexity local.

And that is usually what we actually want from architecture.

Final Thoughts

We didn't replace Fabric.js.

We stopped asking Fabric.js to be our application architecture.

That distinction turned out to be more important than the choice of canvas library itself.

Fabric is very good at being a canvas engine.

It doesn't need to know what a desk means to our business.

It doesn't need to know how drafts are saved.

It doesn't need to know what a workspace mode is.

And Angular doesn't need to know how Fabric calculates a transform matrix.

The goal of MapEngine isn't to hide every Fabric API.

It's to create a boundary where both sides can do what they're good at.

We're still refining that boundary.

But the map editor is now a system we can continue to evolve instead of a collection of UI code sitting directly on top of a canvas.

And honestly, that's probably the biggest difference between the old map and the new one.

This article is based on our experience building and maintaining a production interactive map editor. Code examples have been simplified or anonymized where necessary.

How We Migrated a Large AngularJS Application Without a Big-Bang Rewrite

Aleksandr Gusev — Fri, 14 Aug 2026 11:39:53 +0000

Migrating a large AngularJS application to modern Angular sounds simple on paper:

Rewrite the old application, move everything to Angular, remove AngularJS, and ship it.

In a real production product, that's rarely an option.

Our application has been running for years, new features still need to be delivered, and users don't care that we're in the middle of a framework migration. They expect the product to keep working.

So instead of a Big-Bang rewrite, we chose a hybrid approach.

Today, our application runs AngularJS 1.8.3 and Angular 19 side by side in a single application.

It's not a temporary demo.

It's production.

And roughly half of the application has already moved to Angular.

This is what that migration actually looks like.

Where We Started

The legacy application is based on AngularJS 1.8.3.

The new application currently uses:

{
  "@angular/core": "19.2.14"
}

Our target is Angular 19.

Not "the latest Angular eventually".

We deliberately chose a specific target version and are migrating toward it incrementally.

The repository is large enough that the migration can't be described as simply replacing controllers with components.

The rough picture today looks like this:

src/js
└── ~1000 legacy files

src/ng-app
└── ~1500 Angular TS/HTML files

The Angular side already contains around 20 feature areas.

At this point, Angular isn't just an experiment sitting next to the legacy application.

It's becoming the main platform.

But AngularJS is still very much alive.

Why We Didn't Rewrite Everything

The obvious alternative was to create a new Angular application and gradually move everything into it.

We decided against that.

The problem wasn't just the amount of code.

The application is a living product.

While we're migrating the framework, the product still needs:

new features;
bug fixes;
customer requests;
integrations;
analytics;
improvements to existing workflows.

Stopping development for a year and saying "we'll come back when the rewrite is finished" isn't realistic.

We needed the migration and product development to happen simultaneously.

That led us to one principle:

New functionality should be written in Angular, while legacy functionality can continue running until it is replaced.

This sounds obvious.

Making it work is not.

One Application, Two Frameworks

The most important architectural decision was to keep everything inside one hybrid application.

There is no iframe.

There are no separate deployments.

There isn't a second application running next to the old one.

It's one application with two frameworks sharing the same runtime.

The bridge is provided by Angular's @angular/upgrade package.

The simplified bootstrap process looks like this:

platformBrowserDynamic()
  .bootstrapModule(AppModule)
  .then(platformRef => {
    const upgrade = platformRef.injector.get(UpgradeModule);

    upgrade.bootstrap(
      document.body,
      ['unSpotApp']
    );
  });

Angular starts first.

AngularJS is then bootstrapped through UpgradeModule.

This gives us a single application lifecycle while allowing both frameworks to coexist.

The Router Is Still AngularJS

This is one of the strangest parts of the migration.

We have Angular 19.

But our router is still UI-Router from the AngularJS side.

So the application doesn't have a clean boundary like:

Legacy Application
        ↓
New Application

Instead, it's more like:

                 UI-Router
                     │
          ┌──────────┴──────────┐
          │                     │
     AngularJS             Angular
     components            components

The router still knows about the application's states.

New Angular components are exposed to AngularJS using downgradeComponent().

For example, an Angular component can become something that the old router understands:

export const ungLogin = downgradeComponent({
  component: LoginComponent,
});

And then the state can reference it:

{
  name: 'login',
  component: 'ungLogin'
}

From the router's perspective, it is just another component.

Underneath, it's Angular.

This allowed us to move entire pages to Angular without immediately replacing the routing infrastructure.

The Other Direction: Angular Calling AngularJS

Migration would be much easier if Angular only needed to consume old functionality once.

Unfortunately, real applications don't work that way.

Angular sometimes needs legacy services.

For example:

const state = injector.get('$state');

There are still AngularJS services that haven't been migrated yet:

$state;
authService;
legacy image cropping functionality;
various existing application services.

So Angular can temporarily access the old dependency injection system.

The important word here is temporarily.

AngularJS Can Also Use Angular

The dependency direction works both ways.

We have new Angular services and state that legacy code needs to access.

For example, the new application state is exposed back to AngularJS through downgradeInjectable().

Conceptually:

@Injectable({
  providedIn: 'root',
})
export class AppState {
  // ...
}

And then:

angular.module('unSpotApp')
  .factory(
    'ngAppState',
    downgradeInjectable(AppState)
  );

Now legacy code can use the new Angular service.

This creates an interesting situation:

             Angular
                │
                │ downgradeInjectable
                ▼
          AngularJS code


          AngularJS
                │
                │ $injector
                ▼
             Angular

Both directions are possible.

And that flexibility is what makes incremental migration possible.

It's also one of the things that makes hybrid applications surprisingly difficult to reason about.

Two DI Containers

One of the first things you learn in a hybrid application is that you effectively have two dependency injection worlds.

Angular has its own DI system.

AngularJS has $injector.

During migration, both have to coexist.

Sometimes Angular uses a legacy service.

Sometimes AngularJS consumes a new Angular service.

Sometimes both implementations temporarily exist.

That means dependency ownership becomes an architectural concern.

We have to constantly ask:

Which side owns this service now?

And more importantly:

Which side should own it after the migration?

This sounds like a small detail.

Across a large codebase, it isn't.

State: One Truth, Two Worlds

We introduced a new application state based on RxJS.

Angular consumes it directly.

But some of the initial information still originates in AngularJS.

For example, after authentication, the legacy application already knows about the company.

Instead of rewriting the entire authentication flow immediately, AngularJS pushes the information into the new state:

ngAppState.setCompanySettings(
  $rootScope.company
);

The result is effectively:

                 Login
                   │
                   ▼
              AngularJS
                   │
                   │ company settings
                   ▼
               AppState
                   │
                   ▼
                Angular

This is one of the compromises we intentionally accepted.

For now, we have two worlds and a manually maintained bridge between them.

It's not beautiful.

But it works.

And more importantly, it lets us migrate the consumers before migrating the producer.

Two Translation Systems

Internationalization created another similar problem.

The legacy application uses:

angular-translate

The Angular application uses:

ngx-translate

So during migration, we have two translation systems running at the same time.

Again, the long-term goal is obvious.

We want one system.

But rewriting every translation dependency wasn't necessary to start migrating pages.

So we allowed the old system to remain where it was needed while new Angular features use the new implementation.

This is one of the recurring patterns throughout the migration:

Don't migrate infrastructure just because it is old. Migrate it when the application boundary requires it.

What Has Already Been Migrated

The Angular side is no longer a small part of the application.

Several production areas have already moved to Angular, including:

login;
analytics;
employee schedules;
visitors;
requests;
buildings;
users;
organizational structure;
integrations;
check-in;
office settings;
displays;
services;
parts of the administration area.

New features are also being developed in Angular.

At the same time, some important parts are still AngularJS:

the application shell;
header;
employee map;
parts of the administration area;
office map legacy functionality;
schedules;
desks;
meeting rooms;
lockers;
inbox;
space and group administration.

So the migration isn't:

AngularJS → Angular

It's currently closer to:

AngularJS  ───────────────┐
                          │
                          ▼
                     Hybrid App
                          ▲
                          │
Angular  ────────────────┘

The balance is roughly 50/50.

Angular is no longer a side project.

But AngularJS is still the owner of some fundamental parts of the application.

The Biggest Problem: Living in the Hybrid

The hardest part of the migration hasn't been Angular 19 itself.

It's the hybrid architecture.

Every time we touch a feature, we have to understand which world we're working in.

Is the service Angular or AngularJS?

Is the state coming from the old application or the new one?

Which translation service should be used?

Which router API is available?

Can this component be converted directly?

Does the legacy code expect an AngularJS object?

Can Angular safely depend on this old service?

The framework migration becomes less about syntax and more about managing boundaries.

The Router Problem

We still have UI-Router from the AngularJS world.

There is even a LegacyRouterService in the new application with a TODO that basically says:

// TODO: remove after the new router is introduced

That comment has been around while the migration continues.

It's a good reminder that migrations are rarely linear.

Sometimes the cleanest architecture is not the architecture you build immediately.

It's the architecture that lets you move from the old architecture to the new one without stopping the business.

The TypeScript Problem

There is another interesting side effect of running a modern Angular application inside a large legacy build.

Our Angular 19 code currently lives in an environment where TypeScript 4.9 is still part of the build constraints because of the existing webpack setup and the old application's dependencies.

So we're effectively putting:

Angular 19
      +
TypeScript 4.9
      +
AngularJS 1.8.3
      +
legacy webpack configuration

into one application.

It works.

But it makes you appreciate how many layers exist between a framework and the code you actually write.

The Interactive Map: Where the Two Worlds Meet

The office map is currently one of the largest remaining migration challenges.

We are rebuilding the administrative map editor using Angular and Fabric.js.

But the old employee map and some of the existing map infrastructure still belong to the legacy world.

That means the new implementation needs to understand data produced by the old engine.

One particularly painful example is coordinates and viewConfig.

If the new editor interprets the old coordinate system incorrectly, objects don't simply throw an error.

They move.

The desks are there.

The data is there.

Fabric.js is working.

But everything appears in the wrong place.

This is a particularly good example of why framework migration isn't just about rewriting components.

You are migrating assumptions.

Why We Don't Migrate Everything at Once

At this point, it might be tempting to say:

"We've already migrated half the application. Why not just finish it?"

Because the remaining half isn't necessarily the easy half.

Some of the oldest parts are also the most interconnected.

The office map, for example, touches:

legacy data models;
coordinates;
rendering;
permissions;
routing;
administration;
employee-facing functionality.

Moving it isn't equivalent to moving a simple settings page.

The migration has to follow the actual dependency graph of the product, not an arbitrary percentage target.

Our Current Migration Strategy

The strategy has become relatively simple.

1. New features go to Angular

We don't create new AngularJS functionality unless there is a very good reason.

This prevents the legacy side from growing again.

2. Migrate complete feature boundaries

Whenever possible, we move an entire user-facing area instead of converting random components one by one.

This reduces the amount of hybrid code.

3. Keep bridges temporary

downgradeComponent, downgradeInjectable, $injector, and other compatibility mechanisms are tools for migration.

They aren't the architecture we want to keep forever.

4. Don't migrate unrelated infrastructure

If a legacy service still works and isn't blocking the current migration, we leave it alone.

5. Remove old code only after the new implementation is stable

The goal isn't to have two implementations forever.

The goal is to create a safe path from one implementation to another.

What We Would Do Differently

If we were starting this migration today, I would pay more attention to the boundaries before writing the first Angular component.

In particular:

define ownership of shared state earlier;
establish clearer rules for AngularJS/Angular service dependencies;
document which side owns each piece of infrastructure;
define a migration strategy for routing earlier;
identify coordinate systems and data contracts before touching UI code.

The hardest problems weren't caused by Angular.

They were caused by unclear boundaries between the old and new systems.

The Most Important Lesson

A framework migration is often described as a technical rewrite.

In practice, it is closer to changing the architecture of a running system without stopping the system.

That's a different problem.

You don't get a clean slate.

You have users.

You have production data.

You have business requirements.

You have old code that still works.

And you have new code that needs to coexist with it.

The most useful mindset we found was this:

Don't try to make the old system disappear first. Make the new system capable of replacing it piece by piece.

Once that becomes the goal, the migration becomes much more manageable.

Where We Are Now

We are approximately halfway through the migration.

Angular 19 is already responsible for a significant part of the production application.

New functionality is being built on Angular.

Legacy functionality is gradually being replaced.

The AngularJS application is still responsible for the bootstrap process and routing, so we aren't at the finish line yet.

But the important part is that the direction has changed.

AngularJS is no longer where the product grows.

Angular is.

And that's probably the most meaningful milestone of the migration so far.

Final Thoughts

A Big-Bang rewrite gives you the cleanest architecture on paper.

A hybrid migration gives you something more valuable in a production product:

a way to improve the architecture without stopping the product.

It isn't always elegant.

Sometimes you'll have two dependency injection systems.

Two translation libraries.

An old router controlling new components.

A legacy service being injected into modern Angular code.

And a TODO saying:

// TODO: remove after migration

that survives much longer than anyone expected.

But if each new feature moves the system a little further toward the target architecture, eventually the old framework becomes the smaller part of the application.

And one day, you can finally remove it.

We're not there yet.

But we're getting closer.

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.

DEV Community: Aleksandr Gusev

Fabric.js Wasn't the Problem. Our Architecture Was.

The Old Map Was a Fabric Application That Happened to Have Entities

When Fabric Became Too Global

Events Had the Same Problem

Why We Kept Fabric.js

Introducing MapEngine

MapStage Is the Canvas

The Camera Is a Matrix

Zoom Isn't Just canvas.setZoom()

Interaction Is Another Layer

The Registry Is a Pair, Not a Subclass

ObjectRegistry Doesn't Know How to Draw a Desk

Serialization Is Where the Boundary Gets Interesting

There Is Still Some Leakage

ActiveSelection Instead of Group

And Then There Are Coordinates

ChangesTracker: Don't Save the Whole Map

Angular Doesn't Need to Know Fabric

The Workspace Doesn't Need to Know About Fabric Either

Was the New Architecture Perfect?

What Actually Changed

Final Thoughts

How We Migrated a Large AngularJS Application Without a Big-Bang Rewrite

Where We Started

Why We Didn't Rewrite Everything

One Application, Two Frameworks

The Router Is Still AngularJS

The Other Direction: Angular Calling AngularJS

AngularJS Can Also Use Angular

Two DI Containers

State: One Truth, Two Worlds

Two Translation Systems

What Has Already Been Migrated

The Biggest Problem: Living in the Hybrid

The Router Problem

The TypeScript Problem

The Interactive Map: Where the Two Worlds Meet

Why We Don't Migrate Everything at Once

Our Current Migration Strategy

1. New features go to Angular

2. Migrate complete feature boundaries

3. Keep bridges temporary

4. Don't migrate unrelated infrastructure

5. Remove old code only after the new implementation is stable

What We Would Do Differently

The Most Important Lesson

Where We Are Now

Final Thoughts

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

Where It All Started

Why We Decided to Rewrite It

Building a New Architecture

Moving the Camera Instead of Moving Objects

The Hardest Problem Wasn't Angular

Attempt #1

Attempt #2

Attempt #3

One More Unexpected Problem

What Changed After the Migration

What We Learned

Final Thoughts

What's Next?

angular #typescript #webdev #architecture

Should Angular Apps Still Rely on RxJS in 2026?

Two different mental models

RxJS: asynchronous streams

Signals: local reactive state

Code comparison

Signals example

RxJS example

The real problem is not technology, but mixing models

Where RxJS is still the right tool

Where Signals are a better fit

Architectural boundary

Final thoughts

Angular Signals

Angular Signals — A Shift in Angular Reactivity

What are Signals?

Why this matters

Zoom Isn't Just `canvas.setZoom()`