Zed, Sublime Text, Atom-подобные и новая волна редакторов

В предыдущей статье мы разобрали редактор, который забрал себе рынок. Логичный вопрос: если VS Code настолько хорош, зачем в 2026 году вообще существуют другие редакторы — и почему новые продолжают появляться?

Ответ не сводится к «на вкус и цвет». За последние пятнадцать лет индустрия прошла полный цикл: нативные редакторы на C++ (Sublime Text), затем веб-стек ради расширяемости (Atom, VS Code), затем возврат к нативному коду ради задержки (Zed, Helix, Lapce), а поверх всего этого — волна форков VS Code, продающих не редактор, а AI-агента внутри него. Каждый виток решал реальную боль предыдущего и заводил собственную.

Эта статья — про то, какие инженерные решения стоят за новой волной, чем за них платят и когда переход окупается. Много конфигов, немного истории и очень мало восторгов: у каждого героя здесь есть раздел «где он проигрывает», и он не декоративный.

Часть 1. Четыре поколения и что двигало каждым

Сначала карта. Она объясняет, почему одни и те же идеи всплывают заново под новыми именами.

Из этой карты видно главное: новая волна выросла из двух конкретных технических сдвигов, а не из моды.

Первый сдвиг — LSP и DAP. Пока язык понимал только сам редактор, новый редактор был обречён: он стартовал с нулевой поддержкой языков, и никто им не пользовался, потому что там нет автодополнения для TypeScript, и никто не писал автодополнение, потому что там нет пользователей. LSP разорвал этот круг. Сегодня любой редактор получает приличную поддержку двадцати языков за неделю работы: запусти gopls, rust-analyzer, tsserver — и всё. Порог входа для нового редактора упал на порядок.

Второй сдвиг — Tree-sitter. Раньше подсветка синтаксиса писалась регулярками (TextMate-грамматики), работала плохо на больших файлах и не давала структуры. Tree-sitter даёт настоящее дерево разбора, обновляемое инкрементально за время, пропорциональное размеру правки, а не файла. Из дерева бесплатно получаются: подсветка, сворачивание блоков, структурные текстовые объекты, «умное» выделение, навигация по символам без языкового сервера. Ещё один кусок работы, который новому редактору больше не надо делать самому.

Третий, менее технический: у людей появились мониторы 120 Гц и привычка к отзывчивости. Задержка, которую в 2015 году никто не замечал, в 2026 воспринимается как «редактор тупит».

Часть 2. Про задержку — без религии

«Быстрый редактор» — самый заезженный маркетинговый тезис новой волны. Разберёмся, что за ним стоит физически, и где он честен.

Ключевое наблюдение: редактор контролирует не всю цепочку, а её середину. Клавиатура, ядро ОС и матрица монитора съедают десятки миллисекунд независимо от того, на чём написан редактор. Поэтому заявления вида «мы в 10 раз быстрее» почти всегда касаются одного звена, а воспринимаемая разница получается заметно скромнее.

Но есть свойство важнее среднего значения: предсказуемость. Редактор, который отвечает за стабильные 20 мс, ощущается лучше редактора со средними 15 мс и регулярными выбросами до 150 мс. Именно поэтому GC-паузы и синхронные плагины — главные враги: они бьют по хвосту распределения (p99), а не по среднему. Если вы измеряете отзывчивость, смотрите на p95/p99, среднее почти бесполезно.

Как замерить самому, а не верить блогам

Инструмент, ставший стандартом де-факто, — Typometer Павла Фатина, вместе с его статьёй Typing with Pleasure: он снимает экран, находит момент появления символа и строит распределение задержек. Читать её стоит целиком — там же разобрана психофизика восприятия задержки.

Быстрая проверка «на коленке», которая ловит 80 % проблем:

# 1. Найти реально тяжёлый файл в проекте — на маленьких разница не видна
find . -name '*.ts' -size +500k -o -name '*.json' -size +5M | head

# 2. Сгенерировать заведомо тяжёлый случай: одна строка на 5 МБ ломает
#    почти любой наивный алгоритм переноса и подсветки
python3 -c "print('x' * 5_000_000)" > /tmp/one-long-line.txt

# 3. Файл с очень большим числом строк — проверяет структуру буфера
seq 1 3000000 | awk '{print \"line \" $1 \" :: value=\" $1*7}' > /tmp/many-lines.txt

Открывайте эти файлы в кандидатах и смотрите три вещи: время открытия, задержку при наборе в середине файла и поведение при Ctrl+End. Результат обычно сильно расходится с рекламой в обе стороны.

Где скорость правда решает, а где это фетиш

Честный список, по опыту:

Если ваш рабочий день — это чтение чужого кода и вдумчивые правки по два десятка строк, выигрыш от смены редактора ради 15 мс будет околонулевым. Это нормально признать.

Часть 3. Zed — главный представитель новой волны

Zed делают выходцы из команды Atom (Натан Собо, Макс Брансфилд — автор Tree-sitter, Антонио Скандурра). Это важно: они уже один раз построили расширяемый редактор на веб-стеке, получили обратную связь про производительность и сознательно пошли другим путём.

Хронология на сегодня: исходники открыты в январе 2024 (анонс), редактор дошёл до версии 1.0 в конце апреля 2026, Windows стал полноценно поддерживаемой платформой, появился встроенный отладчик по DAP.

Архитектура: что именно сделано иначе

Три решения здесь принципиальны.

Собственный UI-фреймворк. GPUI не использует ни системные виджеты, ни браузерный движок: весь интерфейс — это прямоугольники и глифы, отправляемые на видеокарту. Плюс — полный контроль над кадром и отсутствие слоя DOM между нажатием и пикселем. Минус, который надо называть вслух: всё приходится писать самому. Доступность (screen readers), методы ввода для иероглифических языков, поведение выделения по правилам ОС, контекстные меню — то, что в Electron приходит бесплатно, здесь годами доводится руками. Часть претензий к Zed от пользователей вспомогательных технологий и от людей, пишущих на CJK-языках, растёт именно отсюда.

Rope на SumTree. Текст хранится не как массив строк, а как дерево кусков с агрегатами в узлах. Правка не мутирует структуру, а создаёт новую версию, переиспользуя всё, кроме пути от корня до изменённого листа.

Стоимость операций при n байт текста:

Последние две строки важнее скорости вставки. Именно бесплатные снапшоты позволяют Zed считать подсветку, поиск, автоформатирование и синхронизацию с языковым сервером в фоне и без блокировок, зная, что текст под руками не изменится. Это архитектурная причина низкого p99, а не микрооптимизации.

Расширения в WebAssembly. Zed не даёт расширениям доступ к процессу UI. Расширение — это wasm-модуль с узким API: объявить язык, подтянуть грамматику Tree-sitter, скачать и запустить языковой сервер или отладчик, добавить тему или slash-команду для агента. Плюс — расширение почти не может подвесить редактор и не может незаметно читать что попало. Минус — потолок возможностей заметно ниже, чем у VS Code: полноценно нарисовать собственную панель или переопределить поведение редактора расширением, как правило, нельзя. Это осознанный размен «мощность плагинов ↔ гарантия отзывчивости», и он ровно противоположен выбору Emacs, который мы разбирали в статье про Emacs.

Конфигурация Zed: рабочий settings.json

Конфиг живёт в ~/.config/zed/settings.json (на macOS там же), проектный — в <проект>/.zed/settings.json и мержится поверх пользовательского. Формат — JSON с комментариями, как в VS Code, что сильно облегчает миграцию.

{
  // ── Внешний вид и текст ─────────────────────────────────────────────
  "theme": { "mode": "system", "light": "One Light", "dark": "One Dark" },
  "buffer_font_family": "JetBrains Mono",
  "buffer_font_size": 14,
  "buffer_line_height": { "custom": 1.6 },
  "ui_font_size": 15,

  // Вертикальные направляющие вместо «догадайся, где 100 символов»
  "wrap_guides": [88, 120],
  "show_wrap_guides": true,
  "relative_line_numbers": true,   // осмысленно только вместе с vim_mode

  // ── Модальное редактирование ────────────────────────────────────────
  // Vim-режим в Zed встроен, а не является расширением: он знает про
  // мультикурсоры и панели, чего эмуляторы обычно не умеют.
  "vim_mode": true,
  "cursor_blink": false,

  // ── Поведение при сохранении ────────────────────────────────────────
  "format_on_save": "on",
  "remove_trailing_whitespace_on_save": true,
  "ensure_final_newline_on_save": true,
  "autosave": { "after_delay": { "milliseconds": 2000 } },

  // ── Терминал ────────────────────────────────────────────────────────
  "terminal": {
    "font_family": "JetBrains Mono",
    "font_size": 13,
    "shell": { "program": "/bin/zsh" },
    "working_directory": "current_project_directory",
    "env": { "EDITOR": "zed --wait" }   // git commit откроется в Zed
  },

  // ── Языки: настройки точечно, а не глобально ────────────────────────
  "languages": {
    "Rust": {
      "tab_size": 4,
      "language_servers": ["rust-analyzer"]
    },
    "Go": {
      "tab_size": 4,
      "hard_tabs": true,
      "format_on_save": "on",
      "code_actions_on_format": { "source.organizeImports": true }
    },
    "TypeScript": {
      "tab_size": 2,
      "formatter": {
        // Внешний форматтер: prettier из node_modules проекта
        "external": {
          "command": "npx",
          "arguments": ["prettier", "--stdin-filepath", "{buffer_path}"]
        }
      }
    },
    "Markdown": { "soft_wrap": "editor_width", "format_on_save": "off" }
  },

  // ── Настройки языковых серверов ─────────────────────────────────────
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "check": { "command": "clippy" },
        "cargo": { "features": "all" },
        "inlayHints": { "parameterHints": { "enable": false } }
      }
    },
    "gopls": {
      "initialization_options": {
        "staticcheck": true,
        "usePlaceholders": true
      }
    }
  },

  // ── Что не индексировать и не показывать ────────────────────────────
  "file_scan_exclusions": [
    "**/.git", "**/node_modules", "**/target", "**/dist",
    "**/.venv", "**/__pycache__", "**/.terraform"
  ],

  // ── Телеметрия: решение принимает пользователь, а не умолчание ──────
  "telemetry": { "diagnostics": false, "metrics": false }
}

Проектный оверрайд — отдельный файл в репозитории, который стоит коммитить:

// .zed/settings.json — едет вместе с проектом
{
  "languages": {
    "Python": {
      "language_servers": ["pyright", "ruff"],
      "format_on_save": "on",
      "formatter": [{ "language_server": { "name": "ruff" } }]
    }
  },
  // Монорепозиторий: не сканируем чужие поддеревья
  "file_scan_exclusions": ["**/vendor", "**/generated", "**/.next"]
}

Клавиши — ~/.config/zed/keymap.json. Механика похожа на VS Code, но контекст пишется выражением, а не строкой when со своим синтаксисом:

[
  {
    // Действует везде
    "bindings": {
      "cmd-p": "file_finder::Toggle",
      "cmd-shift-p": "command_palette::Toggle",
      "cmd-shift-f": "pane::DeploySearch"
    }
  },
  {
    // Только в редакторе и только в normal-режиме Vim
    "context": "Editor && vim_mode == normal",
    "bindings": {
      "space g s": "git_panel::ToggleFocus",
      "space e": "project_panel::ToggleFocus",
      "space t": "terminal_panel::ToggleFocus",
      "] d": "editor::GoToDiagnostic",
      "[ d": "editor::GoToPreviousDiagnostic",
      // Многоклавишные последовательности пишутся через пробел —
      // это полноценные аккорды, как leader-мэппинги в Neovim
      "space c a": "editor::ToggleCodeActions"
    }
  },
  {
    "context": "Terminal",
    "bindings": { "cmd-k": "terminal::Clear" }
  }
]

Задачи (~/.config/zed/tasks.json или .zed/tasks.json) — аналог tasks.json из VS Code, но заметно проще:

[
  {
    "label": "test: текущий файл",
    "command": "cargo",
    "args": ["test", "--", "$ZED_FILE_STEM"],
    "use_new_terminal": false,
    "allow_concurrent_runs": false
  },
  {
    "label": "test: символ под курсором",
    // ZED_SYMBOL подставляется из дерева Tree-sitter — не из регулярки
    "command": "go",
    "args": ["test", "-run", "$ZED_SYMBOL", "./..."],
    "tags": ["go-test"]
  }
]

Что в Zed действительно сделано хорошо

Мультибуфер. Результаты поиска по проекту, список диагностик, все места использования символа открываются как один редактируемый буфер из фрагментов разных файлов. Правите прямо там, сохраняете — изменения расходятся по исходникам. Это заметно удобнее, чем переходить по списку найденного, и ближе всего к тому, что в Vim делают через quickfix и :cdo (см. продвинутый Vim), только без ритуала.

Совместное редактирование. CRDT не прикручен сбоку, а лежит в основе буфера, поэтому парное программирование в Zed работает без отдельного «режима» — с общим терминалом и звуком. За это, впрочем, платят серверной инфраструктурой и аккаунтом.

AI как слой, а не как продукт. Помимо встроенной панели агента Zed продвигает Agent Client Protocol — попытку сделать для агентов то, что LSP сделал для языков: агент живёт отдельным процессом и говорит с редактором по открытому протоколу. Через ACP в Zed подключаются внешние агенты (Claude Code, Gemini CLI и другие). Это архитектурно честнее, чем зашивать одного вендора внутрь редактора, — и, что важнее для нас, это тот же принцип «редактор как оболочка вокруг протоколов», которым выиграл VS Code.

Где Zed проигрывает — без смягчений

• Экосистема расширений на порядки меньше. Специфический линтер, редкий фреймворк, корпоративный внутренний плагин — скорее всего, их просто нет, и написать аналог сложнее из-за узкого wasm-API.
• Доступность. Работа со screen reader в собственном UI-фреймворке — это годы работы, которые в Electron и нативных тулкитах уже сделаны кем-то другим.
• Аккаунт и облако. Часть функциональности (коллаборация, AI) завязана на сервисы Zed Industries. Для закрытых контуров это блокер, который надо проверять до миграции, а не после.
• Молодость. Даже после 1.0 частота изменений высокая; конфиги и названия действий иногда меняются между версиями. Для команды это означает регулярную правку общих dotfiles.
• Не «просто редактор». Zed весит как IDE и стартует как IDE. Для git commit и правки /etc/hosts он не быстрее Vim и не легче.

Часть 4. Sublime Text — редактор, который просто продолжает работать

Sublime Text — контрпример ко всей моде. Разработка ведётся крошечной командой, продукт закрытый, платный, релизы редкие. И при этом он остаётся эталоном по одному параметру: он открывает и редактирует то, что остальные не открывают вообще.

Философия: C++ снизу, Python сверху

Ядро — нативный C++ с собственным рендерингом (в четвёртой версии добавили аппаратное ускорение, включаемое настройкой). Расширения — Python, исполняющийся в отдельном plugin host процессе. Это ровно та же идея изоляции, что у VS Code, только на пятнадцать лет раньше и без Electron.

Актуальная линия — Sublime Text 4. В сборке 4200 объявлен план миграции с Python 3.3 на 3.8 и далее (разбор от Sublime HQ), в dev-ветке идёт переход на более свежий Python. Ценообразование простое и старомодное: единовременные 99 $ за лицензию с тремя годами обновлений, лицензия на человека, работает на всех трёх ОС. Пробный период неограничен по времени, но с периодическим напоминанием о покупке.

Что стоит взять на вооружение даже не переходя

Три идеи Sublime разошлись по всей индустрии, но в оригинале они по-прежнему сделаны лучше:

1. Goto Anything (Ctrl+P) с составным синтаксисом. Не просто фаззи-поиск файла: src/mod@parse — файл плюс символ внутри, :180 — строка, #todo — поиск по содержимому, @ без файла — символы в текущем. Все команды комбинируются в одной строке.
2. Мультикурсор как основной способ массового редактирования. Ctrl+D добавляет следующее вхождение слова, Alt+F3 — все сразу, Ctrl+Shift+L разбивает выделение на курсоры по строкам. Для перекладывания CSV, правки конфигов и переписывания списков это быстрее регулярок и точно нагляднее.
3. .sublime-syntax — YAML-описание грамматики со стековым автоматом. Формат, который заменил регулярочные .tmLanguage и до сих пор остаётся образцом читаемости.

Конфигурация: всё это просто JSON-файлы

Настройки — Packages/User/Preferences.sublime-settings (открывается через Preferences → Settings):

{
  "font_face": "JetBrains Mono",
  "font_size": 13,
  "line_padding_bottom": 2,

  // Хардварный рендер — по умолчанию выключен, на многих машинах даёт заметный прирост
  "hardware_acceleration": "opengl",

  "rulers": [88, 120],
  "highlight_line": true,
  "draw_white_space": ["selection", "trailing"],
  "trim_trailing_white_space_on_save": "not_on_caret",
  "ensure_newline_at_eof_on_save": true,
  "translate_tabs_to_spaces": true,
  "tab_size": 4,

  // Не индексировать мусор — прямое влияние на скорость Goto Anything
  "index_exclude_patterns": ["*.log", "*.min.js", "*.map"],
  "folder_exclude_patterns": [".git", "node_modules", "target", "dist", ".venv"],
  "binary_file_patterns": ["*.png", "*.jpg", "*.pdf", "*.zip", "*.woff2"],

  // Мелочь, экономящая часы: не создавать «...» файлы рядом с исходниками
  "atomic_save": false,
  "hot_exit": "always",
  "remember_open_files": true
}

Проект — файл .sublime-project, который стоит коммитить в репозиторий:

{
  "folders": [
    {
      "path": "backend",
      "folder_exclude_patterns": ["target", ".pytest_cache"]
    },
    {
      "path": "frontend",
      "file_exclude_patterns": ["*.lock"],
      "folder_exclude_patterns": ["node_modules", ".next"]
    }
  ],
  "settings": {
    "tab_size": 2,
    "LSP": {
      "pyright": { "enabled": true },
      "rust-analyzer": { "enabled": true }
    }
  },
  "build_systems": [
    {
      "name": "Тесты проекта",
      "shell_cmd": "make test",
      "working_dir": "$project_path",
      // Парсер вывода: клик по ошибке открывает нужную строку
      "file_regex": "^(...*?):([0-9]*):?([0-9]*)",
      "variants": [
        { "name": "Только текущий файл", "shell_cmd": "pytest $file -q" }
      ]
    }
  ]
}

Современная поддержка языков ставится пакетом LSP через Package Control плюс пакеты-обёртки (LSP-pyright, LSP-rust-analyzer, LSP-typescript). Работает это добротно, но честно: на пару лет отстаёт от VS Code по полноте — inlay hints, некоторые code actions и свежие возможности протокола появляются позже.

Плагин на Python за 20 строк

Здесь Sublime до сих пор приятнее всех: API синхронный, документация короткая, цикл правки — сохранил файл, плагин перезагрузился. Никакой сборки, package.json и активационных событий.

# Packages/User/copy_github_link.py
# Копирует ссылку на текущую строку в GitHub — то, ради чего обычно ставят расширение.
import subprocess
import sublime
import sublime_plugin


class CopyGithubLinkCommand(sublime_plugin.TextCommand):
    """Команда уровня текста: имеет доступ к буферу, выделению и курсорам."""

    def run(self, edit):
        path = self.view.file_name()
        if not path:
            sublime.status_message("Файл не сохранён на диск")
            return

        folders = self.view.window().folders()
        root = next((f for f in folders if path.startswith(f)), None)
        if root is None:
            sublime.status_message("Файл вне открытых папок проекта")
            return

        def git(*args: str) -> str:
            # cwd=root — важно: иначе git отработает в каталоге запуска Sublime
            return subprocess.check_output(("git",) + args, cwd=root).decode().strip()

        try:
            remote = git("remote", "get-url", "origin")
            commit = git("rev-parse", "HEAD")
        except subprocess.CalledProcessError:
            sublime.status_message("Это не git-репозиторий")
            return

        # git@github.com:org/repo.git  →  https://github.com/org/repo
        repo = remote.replace("git@github.com:", "https://github.com/")
        repo = repo.removesuffix(".git")

        rel = path[len(root):].lstrip("/")
        # row() возвращает индекс с нуля, GitHub нумерует с единицы
        row = self.view.rowcol(self.view.sel()[0].begin())[0] + 1

        sublime.set_clipboard(f"{repo}/blob/{commit}/{rel}#L{row}")
        sublime.status_message(f"Скопировано: {rel}#L{row}")

    def is_enabled(self) -> bool:
        # Пункт в меню будет серым, если условие ложно
        return self.view.file_name() is not None

Привязка — в Packages/User/Default.sublime-keymap:

[
  { "keys": ["ctrl+alt+g"], "command": "copy_github_link" },
  {
    "keys": ["ctrl+shift+r"],
    "command": "show_overlay",
    "args": { "overlay": "goto", "text": "@" }
  }
]

Обратите внимание на имя команды: класс CopyGithubLinkCommand автоматически становится командой copy_github_link. Эта конвенция — весь «фреймворк», который нужно выучить.

Честно о минусах Sublime

• Закрытые исходники и единственная точка отказа — крошечная команда. Если разработка остановится, форкнуть будет нечего.
• Темп релизов. Между значимыми версиями проходят годы. Свежие возможности LSP, интеграция с AI, поддержка новых форматов приезжают заметно позже.
• Экосистема сжалась. Package Control жив, но многие пакеты не обновлялись с эпохи Sublime Text 3; часть авторов ушла в VS Code.
• Нет встроенной отладки. Есть сторонние обёртки, но опыт несравним с VS Code или JetBrains.
• Платно в мире, где два главных конкурента бесплатны. 99 $ — небольшая сумма для профессионала, но в компании это ещё и процедура закупки.

Практический вывод: Sublime Text сегодня чаще держат вторым редактором — для гигантских файлов, быстрых массовых правок и «просто посмотреть». Как основной он отлично работает у тех, кто ценит стабильность инструмента выше свежести возможностей.

Часть 5. Atom: что он дал миру и почему умер

Atom объявили «hackable text editor for the 21st Century» в 2014-м, а 15 декабря 2022 года GitHub его выключил. История поучительна не как некролог, а как разбор архитектурной ошибки.

Наследие Atom больше, чем сам Atom:

• Electron родился как Atom Shell — и стал стандартом для десктопных приложений на вебе, включая VS Code, Slack, Discord, Figma Desktop.
• Tree-sitter написан Максом Брансфилдом в команде Atom. Сегодня им пользуются Neovim, Helix, Zed, GitHub, Emacs.
• Teletype — совместное редактирование на CRDT — прямой предок того, что делает Zed.
• Сама идея «редактор — это платформа, а не программа» вошла в мейнстрим именно оттуда.

Pulsar — общественный форк, pulsar-edit.dev. Команда сняла проект с мёртвой инфраструктуры: свой реестр пакетов (ppm вместо отключённого apm), обновление устаревших нативных модулей Node, современный Electron. Проект жив и выпускает релизы. Когда его стоит рассматривать: у вас есть выстраданный набор Atom-пакетов или внутренний плагин, переписывать который дороже, чем поддерживать форк. Во всех остальных случаях это исторический интерес, а не инструмент выбора.

Что забирать из этой истории: производительность — свойство архитектуры, а не результат оптимизаций. Atom невозможно было «ускорить патчами», потому что модель исполнения плагинов была заложена в фундамент. Ровно этот же аргумент объясняет ставку Zed на wasm-песочницу и ставку VS Code на extension host.

Часть 6. Остальная новая волна: кто ещё есть и зачем

Помимо Zed и Sublime существует россыпь проектов, каждый со своей гипотезой.

Про два проекта стоит сказать подробнее, потому что они показательны.

Helix — самый интересный из модальных «новой школы». Главное отличие от Vim — обратный порядок: сначала выделяешь, потом действуешь. В Vim вы пишете d2w («удали два слова») и не видите, что удалится, пока не нажмёте. В Helix — 2wd: выделение подсвечивается, и только потом вы решаете, что с ним сделать. Для новичка это заметно понятнее, а мультикурсор становится естественным продолжением модели, а не отдельной механикой. Взамен: мышечная память Vim не переносится, а системы плагинов до сих пор нет — она разрабатывается на основе Scheme-подобного языка Steel силами энтузиастов и не имеет обещанных сроков. Всё, что не встроено, дописать нельзя. Для одних это дисциплина, для других — блокер.

JetBrains Fleet — самый полезный отрицательный кейс. Лёгкий редактор с возможностью «включить умный режим» и получить бэкенд IntelliJ. Идея красивая, реализация — годы в превью, а в декабре 2025 JetBrains объявила о закрытии Fleet: две универсальные линейки IDE размывали фокус, а воспроизвести возможности IntelliJ внутри Fleet не удалось создать достаточной ценности. Платформа переиспользована в новом агентном продукте Air. Вывод для нас практический: редактор без ясной ниши и без экосистемы закрывается даже у компании с ресурсами JetBrains. Это стоит держать в голове, когда очередной проект обещает «заменить всё» — риск переноса рабочего процесса на молодой инструмент реален и измерим.

Часть 7. AI-волна: форки VS Code как отдельный класс

Отдельно стоит новый класс: Cursor, Windsurf, Trae и подобные. Технически это форки VS Code с переписанным AI-слоем; редакторская часть у них общая с оригиналом, конкуренция идёт по качеству агента и модели.

Как устроен цикл автодополнения-по-намерению («что вы будете править дальше»), который отличает их от классического автокомплита:

Что здесь важно понимать инженерно, без хайпа:

• Задержка и приватность — один и тот же вопрос. Хорошее предсказание требует контекста; контекст — это ваш код, уезжающий на чужие серверы. Локальные модели снимают вопрос приватности, но качество и скорость на ноутбуке заметно ниже. Компромисс выбирается политикой компании, а не вкусом разработчика.
• Форк — это долг. Форк VS Code обязан вечно подтягивать изменения upstream. Отставание копится, а доступ к официальному Marketplace для сторонних сборок ограничен условиями Microsoft — форки живут на Open VSX, где часть расширений отсутствует или отстаёт по версиям. Проверяйте наличие критичных для вас расширений до миграции.
• Цены живые и меняются. На середину 2026 года типичный индивидуальный тариф у Cursor и Windsurf — около 20 $ в месяц, у Zed — дешевле, но с лимитом токенов; везде есть бесплатные уровни разной щедрости. Любые конкретные цифры в статьях устаревают за квартал — сверяйтесь с прайсом вендора.
• Альтернатива форку — протокол. ACP и обычные расширения-агенты позволяют получить тот же результат, не меняя редактор. Если ваша команда уже стандартизована на VS Code или JetBrains, это дешевле, чем переезд.

Честный итог по классу: AI-возможности перестали быть причиной менять редактор. В 2023-м они были эксклюзивом форков, к 2026-му они есть у всех — встроенные, через расширения или через протокол. Меняйте редактор ради редактора, а агента подбирайте отдельно.

Часть 8. Сравнение: где что уместно

Сводная таблица по критериям, которые реально влияют на работу. Оценки — по опыту практического использования, а не по бенчмаркам вендоров.

Тот же выбор в осях «сколько получаешь из коробки» и «насколько можно достроить под себя» — именно здесь видно, что редакторы не конкуренты, а разные точки компромисса:

Часть 9. Стоимость перехода — считаем честно

Самая частая ошибка при смене редактора — считать только приобретения. Считать надо баланс.

Что вы теряете при переходе на молодой редактор:

Проверка, экономящая недели, — недельный пилот по правилам:

# 1. Не мигрируйте конфиг. Соберите новый с нуля — 80 % старых настроек были компенсацией
#    проблем старого редактора и в новом не нужны.

# 2. Заведите отдельный профиль/каталог конфигурации, чтобы откат был мгновенным
cp -r ~/.config/zed ~/.config/zed.backup

# 3. Целую неделю работайте только в новом редакторе — включая неприятные задачи:
#    ребейз с конфликтами, отладка падающего теста, правка YAML на 4000 строк,
#    работа по SSH на стенде, разбор 200-мегабайтного лога.

# 4. Ведите файл-дневник. Ровно два столбца, без эмоций.
$EDITOR ~/editor-trial.md   # "что стало лучше" / "что стало хуже или невозможно"

Решение принимайте по столбцу «невозможно», а не по ощущению новизны: приятность спадает за две недели, а отсутствующий отладчик остаётся навсегда.

Когда переход на новую волну оправдан:

• вы упираетесь в отзывчивость на конкретных задачах и это подтверждено замерами, а не ощущением;
• ваш набор расширений маленький и легко воспроизводимый;
• вы много работаете с большими файлами;
• вам нужна конкретная возможность, которой у текущего инструмента нет (например, совместное редактирование без сервисов Microsoft).

Когда не оправдан:

• вы много отлаживаете и рефакторите — здесь связка JetBrains/VS Code пока сильнее (см. статью о JetBrains);
• у команды общая конфигурация редактора и devcontainer’ы;
• вы работаете в закрытом контуре и не можете проверить сетевую активность инструмента;
• вам нужны вспомогательные технологии доступности;
• вы просто устали от текущего инструмента — тогда сначала попробуйте вычистить его конфиг и снести половину расширений, это дешевле и часто помогает.

Часть 10. Практика: как это выглядит у людей в проде

Три работающие схемы, которые встречаются чаще всего.

Схема «два редактора». Основной — тот, где отладчик и рефакторинги (VS Code или JetBrains). Второй — быстрый, для чтения, логов и массовых правок (Zed, Sublime, Helix). Это не признак нерешительности, а разделение задач: одна программа не обязана быть лучшей во всём. Ключ к тому, чтобы схема не превратилась в мучение, — единый набор внешних инструментов: линтеры, форматтеры и языковые серверы конфигурируются файлами в репозитории (.editorconfig, rustfmt.toml, .prettierrc, ruff.toml), а не настройками редактора. Тогда любой редактор форматирует код одинаково, и в pull request не приезжает шум.

# Минимальный общий знаменатель, который понимают все редакторы этой статьи
cat > .editorconfig <<'EOF'
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 4

[*.{js,ts,tsx,json,yml,yaml}]
indent_size = 2

[*.go]
indent_style = tab

[Makefile]
indent_style = tab
EOF

Схема «редактор как клиент к окружению». Всё тяжёлое — сборка, тесты, языковые серверы — живёт на удалённой машине или в контейнере, локально остаётся только интерфейс. VS Code делает это через Remote, Zed — через свой удалённый режим, Helix и Neovim — просто через SSH, потому что живут в терминале. Побочный, но крайне ценный эффект: ноутбук перестаёт быть узким местом, а окружение становится воспроизводимым.

Схема «редактор-невидимка». Конфигурация целиком в dotfiles под git, новая машина поднимается одной командой, редактор перестаёт быть местом, где живут ваши настройки. Как это устроено на практике — тема следующей статьи.

Типичные ошибки

1. Мигрировать конфиг один-в-один. Перенос всех 200 настроек VS Code в Zed воспроизводит старые компромиссы в новом месте. Начинайте с пустого файла.
2. Судить редактор по первому дню. Первый день — это борьба с клавишами. Судить надо по третьей неделе, когда клавиши уже в пальцах.
3. Верить бенчмаркам вендора. Замеряйте на своих файлах и своём железе; разница между «в 10 раз быстрее» на демо и «на 20 % отзывчивее» на вашем монорепозитории — обычное дело.
4. Игнорировать сетевую активность. Молодые редакторы охотно ходят в сеть: телеметрия, обновления, AI, синхронизация. В закрытом контуре это проверяется до установки — lsof -i, прокси-лог или сетевые правила.
5. Ставить всё подряд из каталога расширений. Все уроки VS Code про цену расширений применимы и здесь: каждое расширение — это чужой код в вашем цикле правки.
6. Менять инструмент вместо изменения процесса. Если больно от долгой сборки и плохих тестов, новый редактор не поможет ни на минуту.
7. Переводить команду волевым решением. Редактор — личный инструмент. Стандартизируйте форматтеры, линтеры и devcontainer’ы, а не редакторы.

Мини-итог

• Новая волна выросла не из моды, а из двух сдвигов: LSP снял барьер входа для новых редакторов, Tree-sitter решил задачу разбора. Всё остальное — конкуренция на уровне интерфейса и производительности.
• Zed — самая цельная попытка сделать быстрый редактор с нуля: Rust, собственный GPU-рендер, rope на SumTree, CRDT в основе буфера, расширения в wasm-песочнице. Платит за это малой экосистемой, слабой доступностью и молодостью.
• Sublime Text — доказательство, что нативный редактор с изолированными Python-плагинами живёт десятилетиями. Лучший в классе на огромных файлах, отстаёт по свежим возможностям и стоит 99 $.
• Atom умер не из-за веб-стека, а из-за отсутствия границы между чужим кодом и вводом пользователя. Его наследие — Electron, Tree-sitter и сама идея редактора-платформы — живёт в конкурентах. Pulsar поддерживает код для тех, кому нужна совместимость.
• Helix, Lapce, Lite XL, Nova — разные точки компромисса; закрытие Fleet напоминает, что молодой редактор без ниши и экосистемы — реальный риск.
• AI-форки VS Code перестали быть отдельной причиной менять редактор: агенты стали слоем поверх любого инструмента, в том числе по открытым протоколам.
• Производительность — свойство архитектуры, и она измеряется хвостом распределения (p95/p99), а не средним. Замеряйте на своих задачах.
• Стоимость перехода считается в неделях мышечной памяти и в отсутствующих возможностях, а не только в приобретениях. Недельный пилот с дневником отвечает на вопрос надёжнее любого обзора.

Источники

• Zed: официальная документация — настройки, keymap, задачи, расширения, удалённая работа
• Zed is now open source — объяснение лицензионной модели: GPL для редактора, AGPL для серверной части, Apache-2.0 для GPUI
• zed-industries/zed — монорепозиторий; отдельные крейты gpui, rope, sum_tree полезно читать как учебник по структурам данных
• Zed Decoded — серия разборов внутреннего устройства от авторов
• Agent Client Protocol — протокол связи редактора с внешними AI-агентами
• Sublime Text: документация и API Reference
• Sublime Text 4200 и будущее плагинов — план миграции на новые версии Python
• LSP для Sublime Text — как получить современную поддержку языков
• Sunsetting Atom — официальное объяснение от GitHub
• Pulsar Edit — форк Atom и его реестр пакетов
• Tree-sitter — документация и список грамматик
• Typing with Pleasure, Павел Фатин — измерение задержки ввода, психофизика и Typometer
• Xi-editor: Rope science — серия заметок Рафа Левина о структурах данных для текста; проект закрыт, тексты по-прежнему лучшие в теме
• Helix — документация; модель «выделение → действие»
• The Future of Fleet — объяснение JetBrains, почему проект закрыт
• Open VSX Registry — реестр расширений для сборок, не имеющих доступа к Marketplace
• EditorConfig — общий знаменатель настроек для команды с разными редакторами

Что дальше

Мы прошли по редакторам как по отдельным программам. Но настоящий рабочий инструмент программиста — это не окно с текстом, а связка: оболочка, мультиплексор, история команд, навигация по файловой системе и конфигурация, которая переживает смену машины. Следующая статья — про то, как собрать это окружение так, чтобы редактор внутри него можно было менять без боли.

Терминальный рабочий процесс: tmux, оболочка, dotfiles, синхронизация окружения