DEV Community: Dmitrii Zakharov

Asynchronous Loops in JavaScript

Dmitrii Zakharov — Sat, 01 Nov 2025 11:27:29 +0000

Asynchronous Loops in JavaScript

How can we iterate over an array asynchronously in JavaScript? Is it even possible?

Let's begin with the simplest method: using a for loop while calling await for asynchronous operations. Here's an example:

const callback = async (item, index, arr) => {
  // Async operation
};

const array = [1, 2, 3];
for (let i = 0; i < array.length; i++) {
  await callback(array[i], i, array);
}

This method is straightforward to implement. However, what are the drawbacks of this approach? The main concern is usability; we are all accustomed to using .map(), .forEach(), and other methods built into Array.prototype.

So, are there other ways to iterate through a loop? Yes, we can use recursion. In this method, each iteration is processed through a separate callback. Here's an example:

const iterate = async (index, array) => {
  // Await an operation
  if (index !== array.length - 1) {
    await iterate(index + 1, array);
  }
};

This recursive method offers no advantages over a for loop, but it is a valid implementation.

For years, I have relied on the first method across various projects. To simplify my work, I decided to create a small, publicly accessible library that can be utilized with any framework. Thus, I developed the library available at: 🔗 waitEach.

This library is easy to include and offers two methods: install and waitEach.

The first method extends Array.prototype by adding a new method, .waitEach, which functions similarly to .map(), .forEach(), and other native methods, providing a more convenient API.
The second method allows you to execute waitEach without extending Array.prototype.

I encourage you to try it out!

If you found this useful, leave a ❤️ or 🦄 so others can discover it too!

Using atomic design in Vue: The best approach for scalable component architecture

Dmitrii Zakharov — Fri, 11 Jul 2025 15:11:45 +0000

Selecting the appropriate architecture is crucial in any frontend project. A poorly chosen structure can transform even a small application into a confusing mess that is difficult to scale, test, or maintain.

Does every existing architecture scale well by default?
No, not all of them do.

When choosing a component architecture, I focus on three key aspects:
- Clarity - Is the structure easy to navigate and understand?
- Scalability - Can it grow alongside the application?
- Ease of Use - Does it enhance or hinder the developer experience?

One of the best frontend architectures I have encountered in my career is Atomic Design. If you're not familiar with the concept, I highly recommend starting with the original explanation by Brad Frost.

Why Atomic Design?

Atomic Design offers a clear mental framework for building user interface (UI) systems by breaking down components into five hierarchical levels:

Atoms - The basic building blocks (e.g., buttons, input fields).
Molecules - Simple combinations of atoms (e.g., an input field combined with a label).
Organisms - More complex components made up of molecules and atoms (e.g., a header, a form).
Templates - Page-level layouts that contain placeholder content.
Pages - Final pages filled with actual content.

In practice, I often skip the Templates stage, as it can seem unnecessary. You can still achieve a clean separation of elements without them.

Applying Atomic Design in a Vue Project

Imagine we are creating a straightforward "Contact Us" page. This page may consist of the following elements:

Headers and subheaders.
Descriptive text and instructions.
A feedback form that includes input fields and a submission button.
A header and footer for navigation and branding purposes.

Here's how we would organize that using Atomic Design in a Vue-based project:

🔹 Atoms

Atoms are the smallest components and should be reusable across your application. Keep them stateless and focused.

Logo.vue — logo contains an image or text.
Link.vue — link component used in the footer.
Input.vue, Button.vue — form elements.

🔹 Molecules

These are simple component compositions. They can receive data via props and render a structure of atoms.

Header.vue – composed of Logo, maybe some navigation links.
Footer.vue – combines text blocks and atomized Link components.

🔹 Organisms

Organisms are more complex components that combine both UI and internal logic. They often serve as the core building blocks for full-page layouts and can include other components such as atoms, molecules, or even other organisms.

FeedbackForm.vue – includes Input, Textarea, Button, and handles internal logic like validation and submission.

🔹 Pages

Pages consist of various components.

ContactUs.vue - includes FeedbackForm, Header, Footer.

Folder Structure Example

Here's a sample directory layout for this contact page:

Atomic Design works incredibly well with Vue (and other frameworks like React). It creates a shared vocabulary and natural hierarchy that reflects how we think about interfaces. More importantly, it makes it easier to:

Maintain consistency across your UI
Reuse components with confidence
Scale your application without losing control

If you're starting a new Vue project or refactoring an existing one, try adopting Atomic Design. You'll quickly see the benefits.

If you found this useful, leave a ❤️ or 🦄 so others can discover it too!

Animation vs Transition: Which one will kill your performance first? 🔥

Dmitrii Zakharov — Wed, 25 Jun 2025 11:15:08 +0000

🔥 CSS animation vs transition: Which Performs Better?

Every front-end developer has faced this dilemma at least once:

Should you use animation or transition?
The common wisdom says transition is faster — but is that true?
And does this hold for all CSS properties?

Let’s dive deeper.

🧪 Performance Testing at Scale

To get to the bottom of this, we built a stress-test environment with 7,500 animated elements and tracked a wide range of performance metrics:

✅ Average and lowest FPS
⏱️ Frame delay (delta) and maximum spikes
💾 JavaScript heap usage
📈 Peak memory consumption
🧮 Total allocated memory
🕐 Total task duration

👉 Try the live test yourself: click me

⚙️ How We Measured

To ensure objective and reliable results, our setup are:

Renders thousands of elements on screen
Waits briefly before starting animation or transition
Captures performance metrics on every animation frame
Repeats each test 50 times to collect median data

We tracked:

🎯 Average and lowest FPS
⏳ Frame delay and max spike
🧠 JavaScript memory usage
🔥 Peak memory during animation
⌛ Total duration of the effect

This method helps us understand how CSS animations behave under heavy load, not just in theory, but in actual browsers.

😱 What We Discovered

It might seem that modern browsers should handle thousands of animations effortlessly.

Spoiler: They don’t. Even 7,500 animated blocks cause visible frame drops and lag.

🧪 Test Case: `opacity`

Memory usage increased by 14.11% during animations compared to transitions, indicating higher resource consumption for animations.

Average FPS dropped to 12.04 with animations, which is 16.80% lower than with transitions. This shows that animations can cause more performance degradation under heavy load.

Transitions tend to use memory more efficiently due to simpler rendering and fewer internal calculations. Still, overall memory usage between the two remains comparable for small to moderate numbers of elements.

However, as the number of animated elements grows, animations increase memory consumption more steeply than transitions — a difference that becomes critical at high loads.

🤔 What About Other CSS Properties?

We also tested:

transform (GPU-accelerated property)
blur (expensive filter effect)
background-color (paint-heavy property)

The results vary significantly depending on the property, browser, and hardware. For example, transform animations often perform better because they leverage GPU acceleration, while animating blur or background-color is more taxing on the CPU and memory.

👉 Try the test yourself and see how your browser handles these properties: Live test link.

💡 Additional Insights

Transitions are often simpler: They represent a change from one state to another, which browsers can optimize more easily.
Animations offer more control: Complex keyframe animations provide granular timing and sequences, but this complexity comes with a performance cost.
Hardware acceleration matters: Animating properties like transform and opacity usually trigger GPU acceleration, which greatly improves smoothness and reduces CPU load.
Avoid animating expensive properties: Properties like width, height, box-shadow, filter (especially blur) cause layout recalculations and repaints, which hurt performance.
Batch animations: Group your animations and transitions where possible to reduce browser workload.

💬 Final Thoughts

Don’t assume one approach is always better. Performance depends on:

The CSS property you’re animating
The number of elements involved
Browser optimizations and GPU usage

In general, transitions consume less memory and GPU than animations, especially at scale. But animations give you more control and flexibility, so it’s a trade-off.

We encourage you to experiment, profile, and push your browser to the limits to find the best approach for your specific case.

If you found this useful, leave a ❤️ or 🦄 so others can discover it too!

CapacitorJS: One code base - many platforms

Dmitrii Zakharov — Mon, 23 Jun 2025 06:47:45 +0000

What is CapacitorJS?

CapacitorJS is an open-source runtime developed by the Ionic team. It wraps your web application in native containers, giving it access to native APIs - effectively turning your web app into a mobile app for Android and iOS, without abandoning the comfort of modern frontend tooling.

The learning curve is fairly approachable, especially if you already have experience with frontend frameworks like React, Vue, or Angular. But don't be fooled by its simplicity - Capacitor has a lot going on under the hood.

⚠️ A Quick Disclaimer

I'm not suggesting you should ditch native development entirely. Capacitor isn't a silver bullet, and for complex applications requiring intensive native features, traditional Android/iOS development still reigns supreme. That said, if you're working on a startup product or MVP, or if you're a solo dev trying to maximize reach with limited resources, Capacitor is a compelling option.

What makes capacitor stand out?

Here are a few things I appreciated most during development:

✅ Unified codebase

Write your app once in your favorite frontend framework and deploy it to web, Android, and iOS. No duplicated effort, no context switching.

✅ Native-like flexibility

Capacitor doesn't lock you out of the native layer. You can drop down to Swift/Kotlin whenever needed, and the configuration options are remarkably close to what you'd expect in native projects.
The tradeoffs: What You should know

Of course, no tool is perfect. Here are some challenges I ran into:

❌ Native vs. Web logic conflicts

If you're not careful, native methods and web logic can overlap or conflict, especially when dealing with plugins or custom APIs.

❌ Configuration complexity

Initial setup feels smooth, but once you start integrating push notifications, camera access, or other advanced native features, things can get a bit messy. Debugging across platforms can also be tricky.

❌ Performance

Pure native apps generally perform better, especially when working with animations, large datasets, or heavy computation. In my case, the performance hit was minimal, but for data-heavy applications, it's something to be aware of.

Real-world use case

In my most recent product, we used Capacitor to manage everything from:

3D rendering on canvas
Data persistence
Push notifications
Google API integration

All of that came from a single codebase. It wasn't always smooth sailing, but the time and development overhead we saved were massive.

If your goal is to launch across platforms fast without sacrificing too much on capability, CapacitorJS is well worth exploring. You get native integration, flexible configuration, and one codebase to rule them all.
Capacitor won't replace native development for everyone, but for many teams, especially lean ones, it offers an ideal middle ground.

👉 What do you think?

Have you worked with CapacitorJS or similar tools like React Native, Flutter, or Expo? I'd love to hear about your experiences, tradeoffs, and lessons learned in the comments below.

How we streamlined frontend development with OpenAPI 🚀

Dmitrii Zakharov — Thu, 12 Jun 2025 17:10:56 +0000

Many of you have probably used OpenAPI in your projects, or at least heard of it. But from my regular conversations with developers, I’ve noticed something surprising: a lot of frontend developers still don’t fully take advantage of it.

This article is about how using OpenAPI has helped us speed up development, improve code consistency, and eliminate entire categories of errors. I'll also walk you through how to set it up and integrate it into a TypeScript project.

🧩 What Is OpenAPI, really?

At its core, OpenAPI is a tool that takes your Swagger definitions and generates a full API client, including:

A wrapper for all your endpoints
Typed models and DTOs (based on Swagger schema)
Methods that handle requests for you (like axios or fetch) with built-in type safety

In short: no more manually writing interfaces and HTTP calls. You get a fully typed, ready-to-use client that’s always in sync with the backend.

💡 Why OpenAPI matters

Here are some of the biggest benefits we’ve seen:

Type safety out of the box: All request and response models are generated from Swagger. You no longer need to manually define interfaces or worry about mismatches.
No more manual fetch/axios calls: All endpoints come with pre-written request methods.
Consistency between backend and frontend: When something changes on the backend (e.g., a route is renamed or a payload changes), you just re-generate the schema and catch issues during compile time.
Zero maintenance: Once configured, it’s basically plug-and-play — just update the schema when needed.

🛠 Setting up OpenAPI in your project

To get started, install the OpenAPI generator:

yarn add @openapitools/openapi-generator-cli

Create a config file openapi/apiConfig.json with the following:

{
  "prefixParameterInterfaces": true,
  "supportsES6": true,
  "typescriptThreePlus": true
}

Now, add scripts to your package.json:

"scripts": {
  "openapi": "yarn openapi:download && yarn openapi:generate",
  "openapi:download": "curl https://yourserver.com/api/docs-json > ./openapi/openapi.json",
  "openapi:generate": "openapi-generator-cli validate -i ./openapi/openapi.json && rm -rf src/openapi/api && openapi-generator-cli generate -i ./openapi/openapi.json -c ./openapi/apiConfig.json -g typescript-fetch -o src/openapi/api"
}

⚠️ Note: You may need to install JRE (Java Runtime Environment) for the generator to work.

📦 Building the API Client

After running yarn openapi, you’ll get a fully generated src/openapi folder with models, APIs, and types.

To simplify usage, let’s build a centralized API client:

import {
  BonusApi,
  ChatApi,
  Configuration,
  ServiceApi,
  UserAccessApi,
  UserInfoApi,
  UsersApi,
  UserTasksApi,
  UserUtilsApi,
} from './api';

const configuration = new Configuration({
  accessToken() {
    return 'ACCESS_TOKEN';
  },
  get headers() {
    return {
      'x-language': 'en',
    };
  },
});

export const ApiClient = {
  chat: new ChatApi(configuration),
  service: new ServiceApi(configuration),
  user: {
    access: new UserAccessApi(configuration),
    info: new UserInfoApi(configuration),
    tasks: new UserTasksApi(configuration),
    utils: new UserUtilsApi(configuration),
  },
  users: new UsersApi(configuration),
};

Now calling an API is as simple as:

const { accessToken } = await ApiClient.user.access.login({
  appLoginPayloadDto: payload,
});

🔍 What’s under the hood?

Let’s take a look at the actual implementation of the login method:

async loginRaw(
  requestParameters: UserAccessApiLoginRequest,
  initOverrides?: RequestInit | runtime.InitOverrideFunction
): Promise<runtime.ApiResponse<AppAccessUserTokenDto>> {
  if (requestParameters['appLoginPayloadDto'] == null) {
    throw new runtime.RequiredError('appLoginPayloadDto', 'Required parameter is missing.');
  }

  const headerParameters: runtime.HTTPHeaders = {
    'Content-Type': 'application/json',
  };

  const response = await this.request({
    path: `/app/user/access/login`,
    method: 'POST',
    headers: headerParameters,
    body: AppLoginPayloadDtoToJSON(requestParameters['appLoginPayloadDto']),
  }, initOverrides);

  return new runtime.JSONApiResponse(response, (jsonValue) => AppAccessUserTokenDtoFromJSON(jsonValue));
}

async login(
  requestParameters: UserAccessApiLoginRequest,
  initOverrides?: RequestInit | runtime.InitOverrideFunction
): Promise<AppAccessUserTokenDto> {
  const response = await this.loginRaw(requestParameters, initOverrides);
  return await response.value();
}

You can see that everything is strictly typed — parameters, return values, and even runtime checks are in place.

⚠️ Limitations (for now)

There are still some things OpenAPI doesn’t support out of the box, such as:

WebSockets
Some custom middleware logic

These require custom solutions for now. But the OpenAPI ecosystem is rapidly evolving, and we expect more features to be supported over time.

See you in the comments — and thanks for reading! 🚀

Senior developers cry too: What's next after you're "Senior"?

Dmitrii Zakharov — Sun, 08 Jun 2025 11:39:20 +0000

🎯 Senior - and Stuck?

When you're just starting in tech, your growth path feels clear (*it can include levels on each position): Junior → Mid → Senior. Companies actively support this journey through mentorship, internal promotions, and learning budgets.

But then one day… you're a Senior Developer. And suddenly, the next step isn't obvious at all.

You start asking: What now? Do I specialize? Manage? Stay still? Leave?

🚀 Early career growth feels predictable

For juniors and mids, it's a numbers game. Apply enough, learn consistently, and build pet projects, and growth usually comes. Yes, the 2025 market is tighter than five years ago - there are fewer entry-level roles, and employers want experience - but the path still exists.

The real challenge? It's not obvious what the path is after you become "senior."

🧭 Post-Senior: What are your options?

Once you hit that senior wall, you realize: growth from here isn't linear, and it's definitely not guaranteed.
Let's talk about the two most common paths:

1. 🧠 The technical track: Becoming a Principal Engineer

This is about going deep - frameworks, systems design, architecture, and tooling. You become the go-to person for critical questions across projects and tech stacks.

But here's the catch:

Not every company defines this role clearly: Sometimes, companies expect Principal Engineers to also lead people, which muddles the waters. That's not always accurate: ideally, Principals work across teams, helping scale architecture and elevate technical direction, not directly managing engineers..
Often, there's only 1 Principal Engineer per 10–50 developers.
You'll likely need backend experience (Node.js, Express/Nest), deep frontend knowledge (React/Vue/Angular), and systems understanding (infra, CI/CD, monitoring).
You'll be expected to bridge tech silos, mentor seniors, and think about architecture, not just features.

It's a hard role to earn - and even harder to find.

2. 🤝 The Management Track: Becoming a Team Lead

This is about communication, adaptability, and people.
Yes, tech still matters - but what matters more is your ability to:

Guide a team's direction
Advocate for devs to PMs/stakeholders
Translate business needs into technical roadmaps
Manage conflict, mentoring, and team health

And again, most teams only have one lead. Some companies stretch that even further: one lead for multiple squads.

You're now measured by what you build and how well your team builds and ships.

📉 The Scarcity Problem

Here's what's often not discussed:

"There are way fewer leadership roles than senior devs."

Statistically, you may be looking at a 1:50 ratio between senior engineers and leadership/principal-level roles. Which means…

Competing for a Lead/Principal role often feels like being a junior again:

Polish your profile
Apply broadly
Get ignored (less often)
Repeat

Except this time, you've already put years into the field. That stings.

✅ So… Is it even worth trying?

Absolutely - yes.

Yes, the road beyond Senior is messy. Yes, there are fewer roles, more ambiguity, and less structure. But if you care about your craft, if you're curious, if you want to shape products - not just features - then:

👉 There's always room for those who go deeper.
👉 There's always demand for devs who can see the bigger picture.
👉 And there's the real opportunity in combining technical strength with product thinking and communication.

It might take time. It might not happen in your current company.
But if you're intentional, you can grow beyond the title.

So keep building. Keep sharing. Keep leveling up - even when it's not obvious what the next level is.

And if you're on this path too, I'd love to hear your story.

😌 And sometimes… You don't want to grow

There's also an honest truth: Not every senior wants to "go up."

Some developers love being experts. They love shipping features. They like solving problems, not managing people or fighting architecture wars.

That's valid. Growth doesn't always mean a new title.
Sometimes, it means deepening mastery or mentoring others.
Sometimes, it means side projects, writing, teaching, or open source.

📌 Post scriptum

In future posts, I'll share more practical tips on:
Finding real growth as a senior
Positioning yourself for Principal/Lead roles
Building a portfolio that signals depth, not just activity

But for now, follow the blog, and let me know: Where do you want to grow from here?

🧑‍🍳 Cooking with Vue 3: Nested (Recursive) component rendering

Dmitrii Zakharov — Fri, 06 Jun 2025 13:33:39 +0000

In one of my earlier posts, I briefly mentioned the concept of nested component rendering in Vue. Despite this technique's usefulness, there aren't many clear examples online showing how and when to use it effectively.

So let's fix that.

The problem

Let's say we're building a dynamic table. The table has rows and columns, and each cell needs to render different content intelligently depending on its data type.

For example:

If the value is a date, it should format it.
If it's a number and marked as a "price", it should be formatted as currency.
If it's a boolean, it should display "yes" or "no".
If it's a nested array of cells, it should recursively render a set of cells inside itself.

We want a single, reusable TableCell component that can handle all these cases on its own.

The goal

Our goal is to create a flexible <TableCell /> component that receives a type and a value as props and renders the content accordingly — even recursively, if needed.

The implementation

We'll use Vue 3's <script setup> syntax and TypeScript for better type safety.

Here's a simplified version of what our component might look like:

<template>
  <div
    :class="`_${data.type}`"
    class="tableCell"
  >
    ...

    <template v-if="data.type === TypesEnum.Boolean">
      {{ data.value ? 'yes' : 'no' }}
    </template>

    <template v-else-if="data.type === TypesEnum.Primitive">
      {{ data.value ?? '-' }}
    </template>

    <template v-else-if="data.type === TypesEnum.Array">
      <!-- Recursive call -->
      <TableCell
        v-for="(item, key) in data.value"
        :key="key"
        :data="item"
      />
    </template>
  </div>
</template>

<script lang="ts" setup>
import { type Component } from 'vue';

/** Important to ensure the component knows where to get component from. */
defineOptions({
  name: 'TableCell',
});

enum TypesEnum {
  Array = 'array',
  Boolean = 'boolean',
  Component = 'component',
  Date = 'date',
  Icon = 'icon',
  Price = 'price',
  Primitive = 'primitive',
}

type PrimitiveValue =
  | { type: TypesEnum.Boolean; value?: boolean }
  | { type: TypesEnum.Component; value: Component }
  | { type: TypesEnum.Date; value: Date }
  | { type: TypesEnum.Icon; value: Component }
  | { type: TypesEnum.Price; value: number }
  | { type: TypesEnum.Primitive; value?: boolean | number | string };

type ComplexValue = {
  type: TypesEnum.Array;
  value: PrimitiveValue[];
};

defineProps<{
  data: ComplexValue | PrimitiveValue;
}>();
</script>

Comments

Parts responsible for formatting were intentionally left out of the example to keep it simple. However, some basic ones were included to give a more complete picture.
It’s also important to ensure the component knows where to get its data from.

When to use it

Recursive components are ideal when:

You're dealing with tree-like or nested data.
You want to minimize repeated boilerplate logic for rendering similar structures.
You need consistent behavior and formatting rules for the same data type, even when nested.

Just be mindful of recursion limits, performance, and base case fallbacks.

🧠 Final thought

I hope you found this useful and maybe even a bit fun to explore.
If it sparked your interest — stay tuned and consider subscribing to my blog!

See you in the comments — and thanks for reading! 🚀

How to Speak Up and Get Promoted

Dmitrii Zakharov — Mon, 02 Jun 2025 06:49:33 +0000

How to Speak Up and Get Promoted in an IT Company

While every company operates differently, the overall mechanics of career growth and salary increases in the IT industry tend to follow similar patterns.

At some point, almost every professional — from junior developers to seasoned tech leads — faces the same question:

How do I speak up and get recognized if I want to grow or earn more?

To move forward successfully, it's important to understand not only your personal goals but also the company's motivations.

📌 What Drives Companies: Why They Hire and Promote

🔹 When Hiring Employees

When a company opens a new position, the primary goal is usually the same: improve business efficiency and profitability. Common reasons include:

Filling a specific team role.
Increasing team productivity and delivery speed.
Reducing pressure on key individuals.
Improving product quality and development processes.
Ultimately — driving revenue growth.

🔹 When Promoting Existing Employees

Promotions are rarely just a "thank you for staying." More often, they're tied to increased scope and impact, such as:

Broader technical or cross-functional skills.
Taking on more complex projects and architecture.
Greater ownership in processes, people, and products.
Mentorship and raising team performance.

These steps are often supported by a growth plan, which outlines your progress and the steps needed to reach the next level.

❗ Promotion isn’t about working more hours — it’s about creating more value through impact and ownership.

🚀 How to Communicate Your Career Ambitions Effectively

To ensure a productive conversation with your manager, it's worth preparing in advance. Here's a step-by-step approach:

Define your growth direction

Decide whether you want to go deeper technically, move into team leadership, architecture, product, etc.
Summarize your current contributions

Highlight your results: what projects you completed, your personal impact, and how the team or product benefited.
State what you want to do next

Be specific about your goals — e.g., leading architecture, mentoring juniors, taking ownership of a product area.
Write a message to your manager

Keep it clear and professional. Avoid emotional appeals. Politely ask for a conversation about your future and development path.

⚠️ Common Challenges You Might Face

After interviewing hundreds of IT professionals, one of the most frequent reasons for leaving a job is the perceived lack of growth opportunities. Let’s explore why that happens.

1. Your manager ignores your request

One of the most frustrating situations:

you hear "not now," "maybe later," or get no response at all.

What to do:

Politely follow up again.
Avoid threats or ultimatums — they rarely help.
Even a clear "not in the next few months" is better than vague promises.

2. Your manager doesn’t know how to help you grow

This is more common than you'd expect, especially at mid to senior levels. Often the company simply lacks a clear development structure.

What to do:

Try initiating a conversation about your growth.
If there’s no support system in place, it’s unlikely to appear soon.
You may need to consider other companies that invest more in employee development.

⏳ If Nothing Changes

If you've taken initiative — had conversations, sent emails, made proposals — and still see no progress, this is a clear signal.

You might have already outgrown your current role.
The company may not be ready or willing to help you grow.
Don’t get stuck waiting endlessly for change that may never come.

Remember: your career growth is your responsibility. Sometimes the right move is to move on.

🔄 Performance Reviews: What to Expect and How to Prepare

Many companies hold biannual or annual performance reviews. These formal check-ins are meant to:

Reevaluate your salary;
Confirm or revise your title;
Discuss accomplishments and areas for growth.

But don’t rely on these moments alone. Don’t wait for the "magic date" to speak up.

If you're serious about growing — initiate the conversation early, ideally 1–2 months before a review cycle begins.

📌 If you want to grow — say it clearly. You might not be noticed, but you can definitely be heard.

✅ In Closing

Career advancement isn't just about being "a good employee." It's about:

Having clarity about your goals;
Communicating your value and achievements;
Taking initiative and leading your own development.

📣 Speak up about your goals. Express what you want. Ask for feedback.

That’s professional. That’s mature. That’s an investment in yourself.

💬 Share your own stories or experiences in the comments — we’d love to hear them.

🧑‍🍳 Cooking with Vue 3: SFC — Features you might not know about

Dmitrii Zakharov — Thu, 29 May 2025 17:22:45 +0000

This is not a "getting started" guide — this is an advanced look at what makes Vue 3's Single File Components (SFCs) truly powerful, especially the underused capabilities that even experienced developers often overlook.

🧠 Why SFCs deserve your attention

Single File Components (.vue) are not just a structural convenience — they're a fundamental paradigm in Vue 3. With the addition of the Composition API and script setup, SFCs evolve into a highly expressive, maintainable, and scalable tool.

Vue 3 SFCs are:

Compile-time optimized with script setup
Type-safe and TS-friendly by design
Modular and reactive, from template to style
Composable at scale, ideal for large codebases

And that’s just scratching the surface.

💎 Underused Vue 3 SFC superpowers

Here's a curated list of advanced and underutilized features that can greatly improve your Vue 3 experience:

🔁 `watchEffect` — Auto-reactive side effects

Unlike watch, this runs immediately and reactively whenever any reactive variable used inside the callback function changes.

<script lang="ts" setup>
/** Reactive variables. */
const userCountry = ref<null | string>(null);
const userRegion = ref<null | string>(null);
const userCity = ref<null | string>(null);
const userAddress = ref<null | string>(null);

/** Validate and save data automatically on change. */
watchEffect(() => {
  /** Assume that the functions `validateLocation`, `showError`,
        and `saveLocation` have been defined earlier.
  */
  const isValid = validateLocation({
    address: userAddress.value,
    country: userCountry.value,
    region: userRegion.value,
    city: userCity.value,
  });

  if (!isValid) {
    showError('Location is not valid!');
    return;
  }

  saveLocation();
});
</script>

✅ Perfect for logging, data processing, syncing with external systems, or immediate derived state.

🧼 `defineExpose` — expose internals to parent

By default, <script setup> hides everything. Use defineExpose() to selectively expose internal functions:

<script lang="ts" setup>
defineExpose({
  innerContainerRef,
  setUserAddress,
});

const userAddress = ref<null | string>(null);
const innerContainerRef = ref<null | HTMLDivElement>(null);

const setUserAddress = (address: string) => {
  userAddress.value = address;
};
</script>

✅ Provides a way to access and interact with a component's internal logic from the outside through its API. For example: custom wrapper components built on top of UI libraries.
⚠️ Use with caution as it is a highly specialized approach that can usually be avoided

🔍 `shallowReactive` and `shallowRef`

Use these for performance when you don’t need deep reactivity:

<script lang="ts" setup>
const config = shallowReactive({
  inner: {
    nonReactiveProperty: true,
  },
  reactiveProperty: 123,
});

watch(() => config.reactiveProperty, (value) => {
  // Will work, as `reactiveProperty` is reactive at the shallow level
});

watch(() => config.inner.nonReactiveProperty, (value) => {
  // Will NOT work, as `nonReactiveProperty` is nested and not reactive in shallowReactive
});
</script>

✅ Improves performance when rendering large data trees at the first object level
⚠️ Use with caution, as it may cause unexpected bugs in the application due to limiting reactivity

🔄 `customRef` — Custom reactive logic

You can intercept .value behavior — great for debouncing, throttling, validation:

<script lang="ts" setup>
const userAddress = customRef((track, trigger) => {
  let value = '';

  return {
    get() {
      track();
      return value;
    },
    set(newVal) {
      /** Assume that the function `validateAddress` is defined elsewhere **/
      const isValid = validateAddress(newVal);

      /** Validate against specific rules **/
      if (!isValid) {
        return;
      }

      value = newVal;

      /** Notify reactivity system **/
      trigger();
    }
  };
});

const validAddress = '1600 Pennsylvania Avenue NW, Washington, DC 20500';
const invalidAddress = '';

// ✅ Will be set because it passes validation
userAddress.value = validAddress;
console.log(userAddress.value === validAddress); // Should be `true`

// ❌ Will not be set because it fails validation rules
userAddress.value = invalidAddress;
console.log(userAddress.value === invalidAddress); // Should be `false`
</script>

🔄 `v-model` in `<script setup>`

Vue 3 offers powerful enhancements to how v-model is used within the <script setup> context — including support for multiple models and modifiers.

⤷ Multiple `v-model` bindings

You can define multiple v-models by naming each model explicitly:

<script lang="ts" setup>
const title = defineModel<string>('title');
const isPublished = defineModel<boolean>('published');
</script>

✅ Eliminates the need to manually declare props and emit events for model binding.

⤷ `v-model` modifiers (built-in & custom)

Modifiers let you transform input data automatically — great for building reusable, format-aware input components.

Built-in modifiers:

.trim — trims whitespace
.number — converts value to a number
.lazy — updates on change instead of input

Example usage:

<input v-model.number.lazy="filterId" type="text" />

In this example:

The input is converted to a number
The update happens on change, not on every keystroke

⤷ Custom modifiers with `defineModel`

You can also define your own modifiers using the [model, modifiers] destructuring pattern:

<template>
  <input v-model.date="filterAge" type="date" />
</template>

<script lang="ts" setup>
const [model, modifiers] = defineModel<string>({
  set(value) {
    if (modifiers.date) {
      return convertDate(value); // Custom conversion logic
    }
    return value;
  }
});
</script>

✅ Pushes formatting logic into the component layer

✅ Keeps templates clean and declarative

✅ Makes base components more reusable and flexible

🧩 `defineOptions` — Compile-time component metadata

Set name, inheritAttrs, and more at compile time:

<script lang="ts" setup>
/**
 * Equivalent to `export default`.
*/
defineOptions({
  name: 'CustomButton',
  inheritAttrs: false
});
</script>

✅ Especially useful when creating wrapper components or building reusable libraries
💡 Can be helpful for components located at CustomButton/index.vue, where the file name doesn’t match the desired component name
ℹ️ Reminder: In SFCs, the component name is automatically inferred from the file name if no explicit name option is set. This can be important when you need to make recursive component calls.

Suspense

Suspense is a built-in Vue 3 component that helps you handle asynchronous operations in your templates gracefully. It allows you to display fallback content (like a loading spinner or message) while waiting for async components or data to load.

Key features

Delays rendering of child components until async operations (e.g., async setup(), async components) complete.
Displays fallback UI during the loading phase.
Supports managing multiple asynchronous dependencies simultaneously.

Usage example

<template>
  <Suspense>
    <template #default>
      <AsyncComponent />
    </template>

    <template #fallback>
      <div>Loading...</div>
    </template>
  </Suspense>
</template>

<script setup lang="ts">
import AsyncComponent from './AsyncComponent.vue';
</script>

When to use

To optimize interface loading by lazy-loading heavy or complex components.
For canvas or WebGL components that asynchronously load models or resources.

🎭 Script Logic and template binding in `<style>`

Use v-bind in styles for fully reactive CSS.

<template>
  <div class="button">
    Button
  </div>
</template>

<script lang="ts" setup>
defineProps<{
  color: string;
}>();
</script>

<style scoped lang="scss">
.button {
  background: #212121;
  color: v-bind(color);
}
</style>

⚠️ Use with caution, as it only supports primitives. The following example will not work.

<template>
  <div class="button">
    Button
  </div>
</template>

<script lang="ts" setup>
defineProps<{
  styles: {
    color: string;
  };
}>();
</script>

<style scoped lang="scss">
.button {
  background: #212121;
  /* ❌ This will not work */
  color: v-bind(styles.color); /* or styles['color'] */
}
</style>

🧠 Final thought

I hope you found this useful and maybe even a bit fun to explore.
If it sparked your interest — stay tuned and consider subscribing to my blog!

I've got a long list of upcoming articles, not only on development and Vue, but also on topics like team leadership, engineering management, and the bigger picture of building great products.

See you in the comments — and thanks for reading! 🚀

DEV Community: Dmitrii Zakharov

Asynchronous Loops in JavaScript

Using atomic design in Vue: The best approach for scalable component architecture

Why Atomic Design?

Applying Atomic Design in a Vue Project

🔹 Atoms

🔹 Molecules

🔹 Organisms

🔹 Pages

Folder Structure Example

Animation vs Transition: Which one will kill your performance first? 🔥

🔥 CSS animation vs transition: Which Performs Better?

🧪 Performance Testing at Scale

⚙️ How We Measured

😱 What We Discovered

🧪 Test Case: opacity

🤔 What About Other CSS Properties?

💡 Additional Insights

💬 Final Thoughts

CapacitorJS: One code base - many platforms

What is CapacitorJS?

⚠️ A Quick Disclaimer

What makes capacitor stand out?

✅ Unified codebase

✅ Native-like flexibility

❌ Native vs. Web logic conflicts

❌ Configuration complexity

❌ Performance

Real-world use case

👉 What do you think?

How we streamlined frontend development with OpenAPI 🚀

🧩 What Is OpenAPI, really?

💡 Why OpenAPI matters

🛠 Setting up OpenAPI in your project

📦 Building the API Client

🔍 What’s under the hood?

⚠️ Limitations (for now)

Senior developers cry too: What's next after you're "Senior"?

🎯 Senior - and Stuck?

🚀 Early career growth feels predictable

🧭 Post-Senior: What are your options?

1. 🧠 The technical track: Becoming a Principal Engineer

2. 🤝 The Management Track: Becoming a Team Lead

📉 The Scarcity Problem

✅ So… Is it even worth trying?

😌 And sometimes… You don't want to grow

📌 Post scriptum

🧑‍🍳 Cooking with Vue 3: Nested (Recursive) component rendering

The problem

The goal

The implementation

Comments

When to use it

🧠 Final thought

How to Speak Up and Get Promoted

How to Speak Up and Get Promoted in an IT Company

📌 What Drives Companies: Why They Hire and Promote

🔹 When Hiring Employees

🔹 When Promoting Existing Employees

🚀 How to Communicate Your Career Ambitions Effectively

⚠️ Common Challenges You Might Face

1. Your manager ignores your request

2. Your manager doesn’t know how to help you grow

⏳ If Nothing Changes

🔄 Performance Reviews: What to Expect and How to Prepare

✅ In Closing

🧑‍🍳 Cooking with Vue 3: SFC — Features you might not know about

🧠 Why SFCs deserve your attention

💎 Underused Vue 3 SFC superpowers

🔁 watchEffect — Auto-reactive side effects

🧼 defineExpose — expose internals to parent

🔍 shallowReactive and shallowRef

🔄 customRef — Custom reactive logic

🔄 v-model in <script setup>

⤷ Multiple v-model bindings

⤷ v-model modifiers (built-in & custom)

⤷ Custom modifiers with defineModel

🧩 defineOptions — Compile-time component metadata

Suspense

Key features

🧪 Test Case: `opacity`

🔁 `watchEffect` — Auto-reactive side effects

🧼 `defineExpose` — expose internals to parent

🔍 `shallowReactive` and `shallowRef`

🔄 `customRef` — Custom reactive logic

🔄 `v-model` in `<script setup>`

⤷ Multiple `v-model` bindings

⤷ `v-model` modifiers (built-in & custom)

⤷ Custom modifiers with `defineModel`

🧩 `defineOptions` — Compile-time component metadata

🎭 Script Logic and template binding in `<style>`