DEV Community: azabroflovski

Why Virtual DOM Is No Longer Needed

azabroflovski — Sat, 22 Mar 2025 15:57:29 +0000

The Virtual DOM (VDOM) is no longer necessary. The web isn’t stagnant, and neither are browsers. Yet, I still see people praising it as something cutting-edge and relevant without understanding what it actually is or why it was needed in the first place.

It’s Overhead

To understand why VDOM become overhead, let’s go back to a time when it was actually a useful hack.

We all remember that manipulating the DOM tree is an "expensive" operation, requiring re-rendering/recalculating what the user sees. The core idea was to minimize direct DOM operations.

Here’s how it worked: create an in memory copy of the DOM (the virtual DOM), calculate the diff between the current and new state, then apply only the necessary changes to the real DOM. Additionally, these changes are batched and executed in one go.

Sounds cool? Right? But today, it’s serious overhead, especially when the DOM is huge. Don’t forget: we’re creating a full copy of the DOM in memory, two copies (not one), to then compute diffs, which itself takes time.

Browsers Have Evolved

Browsers aren’t stuck in 2010. Directly updating the DOM is simpler and far less costly than it was 10–15 years ago. Your browser has long since optimized this process, and hardware has improved drastically. Yet, we’re still clinging to the VDOM ritual on top of these optimizations.

If you genuinely believe your JavaScript ritual is faster than C/C++ (which powers browsers), you’re deeply mistaken. You’re just forcing the browser to perform a bunch of extra operations instead of letting it update the DOM directly.

Look at Svelte, Solid, or Angular, they don’t use VDOM and they can still update only the necessary parts of the UI.

Soon, Vue will join their club by ditching VDOM (hello Vue Vapor).

A Note on Vue Vapor

This is a version of Vue that offers rendering without VDOM.

They’ve already merged Vapor into vue/core repository, and judging by the commits, active development is underway. In the near future, they’ll drop the VDOM.

The results speak for themselves:

When asked about the Virtual DOM in your next interview, confidently state that it’s outdated and pointless. Directly updating the DOM is now simpler and cheaper, and the era when it was "expensive" is long gone.

My Journey into Elixir/Erlang (Part One)

azabroflovski — Sat, 15 Mar 2025 19:53:15 +0000

Recently, I started diving into the world of Elixir and Erlang/OTP. If, like me, you thought these technologies were just "hipster stuff," this post might change your mind.

Why Did I Start Learning It?

I had heard about Elixir before. It occasionally popped up in my feed, but without much impact. It just seemed like another "hipster" language to me.

The turning point came when our tech director at work (shoutout to Dima if you're reading this) launched a full scale campaign promoting the language. He gave such an inspiring speech that I was ready to storm Berlin a second time.

A Bit of Context

Before this, I had been writing servers in go, php, and nodejs. I had a solid understanding of concurrency and how to write parallel code. In go, I had goroutines; in nodejs, threads/libuv; and in php... well, either the nightmare of pthreads or the newer fibers, which made things a bit better. It all worked fine, this was how people wrote concurrent code, and that was that.

And then BEAM (the virtual machine that runs Elixir/Erlang code) kicked down the door and shattered everything I thought I knew about concurrency. This isn’t some shabby setup like on the JVM; (sorry, i'm jvm hater).

I started getting excited about Elixir. Flashbacks hit me of all the things I could have done better in my past projects. It was a night-and-day difference, and I regretted not jumping into this ecosystem sooner.

Learning Curve

It's true that there aren't as many learning resources compared to the languages I was used to, and the community is much smaller. But honestly, that wasn’t a big issue for me. Elixir has excellent documentation, well structured and clear, so that’s where I started.

The syntax was easy to pick up. My muscle memory kicked in since I had played around with Ruby years ago (purely for Rails). Getting used to it wasn't hard, and the reward was massive the joy of pattern matching alone made it worth it. Of course, this is just my personal experience; your mileage may vary.

I started by writing small scripts, and my colleagues at work threw some Elixir tasks my way. My hands quickly got used to it. Of course, I understood the power of Elixir; as I mentioned earlier, I was swayed by a powerful speech about BEAM and Elixir.

When I finally got to Erlang/OTP and really explored BEAM, that's when things got truly exciting.

Where Are the Threads?

I asked myself... just kidding. That’s not how things work here. Out of habit, I Googled "Elixir threads," looking for something like spawn_thread() or async do. But in Elixir, things are built differently.

Elixir doesn’t have threads in the traditional sense. Everything here is based on processes (hello, Actor Model).

Processes

These aren’t OS processes, they're super lightweight and run inside BEAM. They don’t share memory, don’t block each other, and operate independently.

You can spawn hundreds of thousands of processes at the same time hell, even a million (and I’m not just throwing around big numbers; we’ll come back to that). More importantly, they use very little memory and switch context in milliseconds.

What If a Process Crashes?

Now, this is where things get interesting. Elixir has a completely different philosophy: no recover(), no try/catch. If something goes wrong? Let it crash! (Yes, "let it crash" is an actual design principle.)

To understand how cool this is, imagine this:

You spin up an HTTP server in Node.js, and it crashes because of an error in a single request. Instead of a full system crash, it just restarts itself without your intervention. Or imagine a worker goroutine in Go dies, but the system automatically brings it back to life.

Sounds good? Well, in Elixir, you don’t have to imagine it, it’s built-in by default. The entire architecture is designed around BEAM and supervisors, which restart crashed processes automatically. You don’t need to do much just trust BEAM.

I feel like someone who spent their whole life tightening screws by hand, and then someone handed me a power drill. Joking aside, I’m not saying Node.js or Go is bad, it’s just that Elixir plays by completely different rules, and I love it.

About BEAM

Why does all this work so amazingly well? Because Elixir runs on BEAM (the virtual machine), which was originally developed for telecommunications (hi, Erlang).

Back when people had to worry about:

Avoiding thread-related disasters
Handling failures
Preventing memory leaks

In Elixir, you just trust BEAM. This VM comes from the telecom world, where downtime means lost revenue. It does things I could only dream of in Go/Node/PHP.

Imagine your code isn’t running as one big process but as millions of tiny processes, each living its own life. If one crashes, who cares? The others won’t even notice. If the load increases, BEAM automatically distributes tasks across CPU cores. If memory gets cluttered, the garbage collector cleans it up without stopping your app.

In other languages, you need complex frameworks, message brokers, and DevOps wizardry to achieve this. In Elixir, it’s just part of the platform.

Where else can you hot-swap code in a running application without stopping or restarting it? While handling thousands of concurrent requests? That’s BEAM for you.

One Million Processes

Here’s a simple example, let’s spawn some processes:

spawn(fn -> IO.puts("My name is Jeff") end)  
spawn(fn -> IO.puts("JVM started with 8GB RAM") end)

And it’s not just a neat syntax trick. As I said before, these processes don’t share memory, don’t block each other, no mutexes, no race conditions.

You can spawn hundreds of thousands, even a million:

for _ <- 1..1_000_000, do: spawn(fn -> receive do _ -> :ok end end)

My m1 macbook air didn’t even break a sweat...

A better example:

defmodule MyWorker do  
  use GenServer  

  def init(_), do: {:ok, %{count: 0}}  
  def handle_call(:fail, _, _), do: raise("I crashed")  
end  

Supervisor.start_link([{MyWorker, []}], strategy: :one_for_one)

Process crashed? It gets restarted. Crashed a million times? It gets restarted a million times.

In other languages, you’d need a whole DevOps setup with monitoring, restart policies, and tools like systemd or Docker restart strategies to achieve this.

Is It Worth Learning?

Yes.

P.S. That’s the shortest H2 title in the Wild West.

What’s Next?

There will be a part two, about distributed systems and more on OTP. I’m still new to all of this, but there’s a lot of cool stuff I want to write about.

Why you should know Lua

azabroflovski — Thu, 13 Feb 2025 23:47:51 +0000

Okay, maybe you don’t have to, but it’s definitely useful. People who know me well might be surprised here. They’re aware that my first programming language was PHP, but they don’t know that my second wasn’t JavaScript, it was Lua. I bet even my friends are confused now, and you probably are too. We’ll circle back to this at the end.

Why Should I Care?

That’s a fair question, especially if you already know other scripting languages. Sure, you can live without Lua. But it’s lurking in places you’d never expect.

It’s popular, even if you rarely hear about it. Not as hyped as those Python devs who import every single letter, or Java folks in suits at banks, but Lua has an active community and plenty of great resources.

It’s Simple. Too simple

Lua is a minimalist language with clean, straightforward syntax. It avoids unnecessary complexity, so you can learn it in a couple of hours. And here’s the classic example:

print('Hello, everyone! Except Java folks.')

if you.crazy() then
  learnJava()
end

Lua isn’t usually used solo. It’s often embedded in game engines, other software, or paired with C/C++. I could list endless examples of where it’s used, but check this out if you’re curious.

It’s fast

Lua is one of the fastest interpreted languages. It compiles to bytecode and runs on a virtual machine, giving it a significant speed advantage over other scripting languages. That’s why it’s used in game engines and paired with C/C++ it’s easy to integrate and lightweight. Lua itself is tiny.

Gaming

Ever played World of Warcraft? Or maybe you still do? (RIP your social life.) If so, you’ve heard of addons like browser extensions, but for games. Those addons are written in Lua. Back in school, I wrote and tweaked them myself. Magical times. As you might have guessed, yes, I did this before diving into client side web technologies. Oddly, I already knew PHP by then. If anyone’s interested, I could write a separate post about that.

Lua isn’t limited to WoW, though. It’s in game engines like:

Godot (Lua support via GDScript wrappers)
Love2D (a Lua-first engine)
Defold (Lua as the main language)
Gideros (mobile game engine)
Cocos2d-x (supports Lua alongside C++ and JavaScript)
Solar2D (formerly Corona SDK, Lua-centric for 2D games)
OpenMW (Morrowind engine with Lua modding)

Honestly, I have no idea what most of these engines are, except Love2D it’s awesome. I’m no game engine expert, but clearly, Lua is everywhere.

According to Google, here are more games using Lua:

Garry’s Mod—Lua drives most modding and gameplay.
Roblox—uses a Lua dialect called Luau.
Angry Birds—core logic is Lua.
Terraria (tModLoader)—modding via Lua.
Don't Starve—Lua for modding and game logic.
Dark Souls series—Lua scripts some AI.
The Sims 4—powers game mechanics.
Far Cry series (pre-Far Cry 3)—heavily scripted with Lua.
RimWorld (partially via Harmony modding).
Payday 2—mods are Lua-based.
Teardown—Lua for modding.

DevOps & Systems programming

Lua isn’t just for games. It’s also in sysadmin tools:

Nginx—uses Lua for dynamic configurations.
Redis—supports Lua server-side scripting.
Tarantool—in-memory database.
AwesomeWM—a Lua-based window manager.
Syslog-ng—logging with Lua.
HAProxy—Lua scripting.
OpenWrt—router firmware.

Lua doesn’t replace Python, Bash, or Go in DevOps, but it fits where speed, embeddability, and a tiny footprint matter.

C’s Best Friend

Lua was built to be embedded. If you’re writing BlAzInG FaSt apps in C/C++, Lua adds flexibility without sacrificing BlAzInG FaSt.

Should You Learn It?

Don’t forget, even though Lua is super small, it’s still a different language. For broadening your horizons it’s an interesting, if you have time, why not? There’s also Nelua, an interesting project, but it’s not nearly as widespread as Lua.

If you’re a default web monkey shuffling JSONs on the server and happy with that, Lua won’t make you better or worse. But exploring it might just spark some joy. Or at least make you the “Lua person” at parties.

How good is DeepSeek?

azabroflovski — Tue, 28 Jan 2025 23:15:07 +0000

Everyone has already heard about the AI from China. I know, there are countless articles about it, but let’s start with a few words about it.

DeepSeek is a Chinese company specializing in artificial intelligence and the creator of a family of large language models.

In January 2025, the release of DeepSeek-R1 caused a sharp drop in stock prices for OpenAI, Microsoft, NVIDIA, and other industry giants. This sparked discussions about reassessing AI investments.

Most importantly, DeepSeek released its models as open-source. We’ll get back to this point later.

Why It Matters

At the very least, companies using ChatGPT now have a strong reason to consider alternatives. Why? Because it’s cheaper and faster. DeepSeek can significantly reduce costs for medium and large businesses.

The main issue for startups and small companies is that using APIs for powerful models like OpenAI's o1 or GPT can be quite expensive. DeepSeek offers much more affordable rates, making LLMs accessible to budget-conscious companies.

Let’s take a closer look at DeepSeek’s pricing:

Cached input tokens: $0.14 per million.
Non-cached input tokens: $0.55 per million.
Output tokens: $2.19 per million.

To understand what tokens are, think of them as chunks of text. Input tokens are the text you send to the model for processing (e.g., a user’s query), while output tokens are the responses you receive. One token is approximately four characters of text.

For small businesses processing a high volume of requests, the price difference between DeepSeek and other models can be substantial. DeepSeek can save companies up to 10–30 times more, allowing them to reinvest those funds into other crucial areas such as marketing or product development.

The low cost of cached input tokens is especially advantageous. If your users frequently ask the same questions, DeepSeek allows you to significantly cut expenses. This makes it an ideal solution for chatbots, online assistants, and other systems handling repetitive queries.

Take a look yourself: the low price for cached input tokens ($0.14) is a game-changer for tasks involving recurring requests. It’s particularly useful for chatbots, virtual assistants, or analytical tools dealing with repetitive data. This lets companies not only reduce costs but also reinvest the savings into other areas, such as marketing, new product development, or improving user experience.

In my opinion, DeepSeek is not just another buzzword in the AI market, it’s a powerful competitor with serious advantages. If you’re building something with AI, be sure to try DeepSeek. You might find it better suited for your needs.

Comparison with ChatGPT

I decided to put DeepSeek to the test with a simple yet tricky question: “How can you parse HTML natively in Node.js?” Spoiler: you can’t. It can only be done with third-party libraries. Both AIs managed the task, but DeepSeek was pleasantly surprising.

I won’t write too much about it; just compare for yourself:

This is a conversation with ChatGPT. Unfortunately, sharing a DeepSeek conversation isn’t possible, so I’ve attached a video instead:

sorry, prompt in Russian language, because my original post in ru lang

Notice how DeepSeek pointed out the lack of a native method and suggested the lowest-level solution for the task: the parse5 library.

ChatGPT also noted the absence of a native solution but suggested an overhead approach with jQuery-like syntax (cheerio) as its primary recommendation.

When it comes to coding, DeepSeek seems to think more deeply and offers more optimized solutions.

p.s. personally, I’ve replaced ChatGPT with DeepSeek in my pet project, for me the transition was easy: my code’s interface allows for quick switching between AI providers. All I had to do was add a new provider implementing the AI interface with methods like prompt, and so on.

Why JSX/TSX Isn't Cool

azabroflovski — Mon, 13 Jan 2025 08:11:13 +0000

At first glance, JSX and TSX seem like innovative tools: JavaScript and TypeScript suddenly become more than just programming languages—they are now almost full-fledged markup tools. However, a deeper look reveals that this approach is far from as ideal as it seems.

Mixing Logic and Presentation

One of the main criticisms of JSX/TSX is the mixing of logic and presentation. Unlike Vue or Angular, where the template structure (HTML) is clearly separated from the logic (JavaScript/TypeScript), in JSX everything is intertwined.

Yes, React allows splitting components into smaller pieces, but in practice, this rarely saves from increasing cognitive load. For example:

function App() {
  // ... another stuff

  return (
    <div>
      {items.map((item) => (
        <button onClick={() => handleClick(item)}>{item.name}</button>
      ))}
    </div>
  );
}

When reading such code, the brain has to simultaneously keep in mind the context of two worlds: presentation and actions. Vue and Angular solve this problem through declarative templates and directives:

Vue

<script lang="ts" setup>
// ... another stuff 

function handleClick(item) {
  console.log(item)
}
</script>

<template>
  <div>
    <button v-for="item in items" @click="handleClick(item)">
      {{ item.name }}
    </button>
  </div>
</template>

This approach makes the code more readable and obvious.

Problems with Syntactic Sugar

JSX looks like HTML, but it's not HTML. Small differences (for example, className instead of class, the need for self-closing tags like , explicit use of curly braces for interpolation) constantly confuse, especially beginners. Moreover, such solutions introduce additional complexity in code perception.

Vue or Angular templates are usually compiled into highly optimized JavaScript code suitable for the virtual DOM or other rendering approaches. JSX requires transformation through Babel or TypeScript. This imposes additional requirements on the build and slows down the development process.

Moreover, any project with JSX becomes practically unusable without a complex build chain.

Limited Ecosystem

JSX/TSX was created for React, and its use outside of this ecosystem raises many questions. For example, Vue offers the use of its templates in other tools—they can be easily adapted for Nuxt.js, which supports server-side rendering.

Angular integrates with various platforms, be it mobile applications or PWAs. JSX outside of React is more of an exception than a rule.

Why is JSX/TSX still popular?

Its popularity is based on React's powerful marketing strategy. The idea of "UI as a function of state," supported by declarativeness, sounds attractive.

Developers gravitate towards concise and flexible solutions, and JSX offers exactly that—a superficially convenient and fast tool for working with components. The high popularity of React and support from large companies such as Facebook and Airbnb also play a role.

Many like JSX/TSX for its conciseness in simple cases, but problems begin to accumulate as the project grows.

Conclusion

JSX/TSX has certainly revolutionized the world of web development, but it is a tool with clear drawbacks. The mixing of logic and presentation, syntactic subtleties, and a limited ecosystem make it less suitable for large and long-term projects.

Vue and Angular demonstrate how templates can be made more intuitive and readable. Therefore, if maintainability is important to you, don't rush to rely solely on JSX.

Vike - Next.js & Nuxt alternative for unprecedented flexibility and dependability

azabroflovski — Sat, 04 Jan 2025 05:10:29 +0000

Vike.dev (formerly vite-plugin-ssr) is an SSR framework for Vue and React that presents an interesting alternative to Nuxt and Next.js. Its key feature is a low-level approach, which gives developers more control over the project.

Instead of imposing a strict architecture or hiding complexity behind "magic," Vike.dev allows you to independently implement typical tasks. This provides flexibility both in project setup and in adapting to unique needs.

Key advantages of Vike.dev:

Control: You decide how to organize the project architecture.
Speed: Integration with Vite ensures fast builds and hot reloading.
Versatility: Support for Vue and React makes the tool flexible for any task.
Minimalism: Nothing superfluous, only what is really needed.
Vike is suitable for those who appreciate the balance between flexibility and performance and are ready to independently develop architectural solutions.

Here are some additional details that might be helpful for someone learning about Vike.dev:

Why choose Vike.dev over Nuxt/Next.js?

While Nuxt and Next.js offer a more "batteries-included" experience with pre-configured features, Vike.dev provides more fine-grained control. This can be beneficial for complex projects with specific requirements or for developers who prefer to understand and manage every aspect of their application.

What is SSR?

SSR stands for Server-Side Rendering. It's a technique where the HTML for a web page is generated on the server before being sent to the client's browser. This improves initial load times and SEO.

Vite Integration

Vike.dev leverages Vite, a next-generation frontend tooling that provides extremely fast development experience with features like instant server start and lightning-fast hot module replacement (HMR).

Focus on Flexibility: Vike.dev aims to be unopinionated, allowing developers to choose their preferred tools and libraries. This makes it highly adaptable to different project needs.

Migration from vite-plugin-ssr: If you're familiar with vite-plugin-ssr, it's important to know that it has been renamed to Vike. The functionality remains the same, so migration should be straightforward. You can find more information about the migration process in the Vike documentation.

Read my tech posts: https://broflovski.dev/posts

Драма вокруг WordPress продолжается

azabroflovski — Tue, 26 Nov 2024 23:36:22 +0000

Плагин Secure Custom Fields теперь идет с про фичами из ACF PRO (да, которая платная). Wordpress начал активнее вмешиваться в экосистему плагинов.

Ссылка на тред из скринов. Если вы ещё не в курсе о происходящей "драме", вам сюда https://habr.com/ru/news/849678/

Мой телеграм канал:
https://t.me/dev_txt

Быть тим лидом — вам это нужно?

azabroflovski — Tue, 26 Nov 2024 23:34:25 +0000

Классная статья на хабре, абсолютно согласен с тем что написано, на своем опыте заметил интересный момент: есть еще так называемые "псевдо лиды". Это люди, которым повесили ярлык тимлида, но по факту они продолжают выполнять ту же работу, что и раньше (ну почти), + взяв на себя больше ответственности. При этом зарплата повышается совсем символически, либо остается без изменений. Полномочий, чтобы реально управлять командой или принимать стратегические решения, им тоже не дают. Получается, ты вроде бы "лид", но на деле — просто разраб с дополнительной нагрузкой и громким титулом на которого удобно сваливать просроченные сроки :)

ИМХО, я сделал вывод, что такое происходит, когда компания хочет закрыть дыры в управлении, но не готова вкладываться в рост или пересматривать свои процессы. По итогу это вызывает выгорание, ощущение несправедливости и желание уйти, что, собственно, я и сделал.

p.s не знал, как лучше выразиться, колебался между "лид имитатор" и "лид понарошку", псевдо-лид более технически получилось, так и знал, что стоило остановиться на лид имитаторе

Мой телеграм канал:
https://t.me/dev_txt

Встречаем Vite 6 ⚡️

azabroflovski — Tue, 26 Nov 2024 23:26:58 +0000

Рост популярности Vite, количество скачиваний в неделю выросло с 7,5 до 17 миллионов за год. Vite используется такими компаниями, как OpenAI, Google, Apple, Microsoft, NASA, Shopify и другими.

Развитие экосистемы, Vitest активно развивается, формируя собственную экосистему. Например, Storybook теперь поддерживает тестирование с помощью Vitest.

Новые фреймворки, такие как TanStack Start, One, Ember, стали частью экосистемы Vite.

Ключевые анонсы ViteConf 2024, запуск VoidZero — компании, создающей высокопроизводительные инструменты разработки для экосистемы JavaScript. Новый React-фреймворк One для веба и нативных приложений. Обновленная стартовая страница проекта на новом домене vite.dev.

Новые возможности в Vite, API окружения (Environment API) упрощает разработку фреймворков, обеспечивая опыт, ближе к продакшену. Environment API находится в стадии тестирования. Сообщество активно участвует в её разработке.

Улучшения для разработчиков:

Поддержка Node.js 18, 20 и 22+, прекращение поддержки Node.js 21.
Расширенная поддержка ссылок на ассеты в HTML.
Построение CSS-выходного файла с пользовательскими именами в режиме библиотеки.
Новый resolve.conditions, изменения в работе с Sass и JSON.
Инструменты для быстрого старта:
Используйте pnpm create vite для создания приложений с разными фреймворками.
Новые шаблоны в vite-extra для поддержки Solid, Deno, SSR и библиотек.

Более 1000 участников уже внесли вклад в Vite Core. Команда призывает разработчиков присоединяться к сообществу, помогать с triage, PR и дискуссиями на форуме.

Vite 6 сохраняет совместимость с предыдущими версиями для SPA и большинства кастомных SSR приложений.

Фулл анонс тут по ссылке
https://vite.dev/blog/announcing-vite6.html

Мой телеграм канал
https://t.me/dev_txt