"TypeScript умер. И это хорошо."

Пока все спорят о Bun vs Node, произошло кое-что интереснее: JavaScript ES2024+ стал настолько хорош, что TypeScript превратился в костыль. Новые фичи (decorators, pattern matching, pipe operator) плюс современные IDE с AI-автодополнением делают типизацию почти избыточной.

Смотрите: крупнейшие проекты потихоньку мигрируют обратно на чистый JS. DHH выкинул TS из Turbo, команда Svelte тоже отказалась. Даже создатель Deno Райан Даль признался, что сожалеет о встроенном TypeScript. Причина проста: overhead от сборки больше не оправдывает выгоды.

Но вот главное: новое поколение разработчиков, выросшее на JSDoc + современных линтерах, вообще не понимает, зачем нужна отдельная система типов. Когда VS Code с GitHub Copilot подсказывает типы лучше любого .d.ts файла, а рантайм-валидация через zod/joi покрывает реальные кейсы — зачем мучиться с tsc?

TypeScript сделал своё дело и может уходить.

Так вот какие посты вызывают реакцию у аудитории😁

Ладно, вот вам еще одно радикальное мнение. Микросервисы — самая дорогая ошибка IT за 10 лет

Netflix: 1000+ микросервисов, армия из 3000+ инженеров, миллиарды на инфраструктуру.
WhatsApp: монолит на Erlang, 50 разработчиков, 2 млрд пользователей, продали за $19 млрд.

Угадайте, кто эффективнее?

Пора признать неудобную правду: 95% проектов выбирают микросервисы не из-за технических требований, а из-за хайпа. Amazon сам говорит, что переход к монолиту сократил их расходы на 90%. Команда Shopify отказалась от микросервисов ради скорости разработки.

Вот что происходит в реальности: каждый новый сервис — это отдельный CI/CD, мониторинг, логи, безопасность, версионирование API. Дебаг распределённой системы превращается в ад. Одна фича теперь требует изменений в 5 репозиториях вместо одного коммита.

А теперь посмотрите на успешные стартапы 2023-2024: Linear, Notion, Figma — все начинали с монолитов и до сих пор ими остаются. Потому что скорость доставки фич важнее теоретической масштабируемости, которая понадобится не скоро.

Монолит-first — это не регресс, а зрелость. Микросервисы нужны 1% проектов, а используют их 80%.

Нужны ваши реакции!

🤔 Нужны ли ещё бэкенд-разработчики в 2026?

BaaS-платформы, serverless, ORM, которые пишут SQL за тебя, AI, который сетапит API быстрее, чем ты наливаешь кофе. Казалось бы — зачем нам бэкенд-разработчики?

Ответ прост: инструменты абстрагируют сложность, но не устраняют её. Когда стартап гордо заявляет «фронтенд напрямую ходит в Supabase, бэкенда нет» — это работает. До первого инцидента. Потому что убрали не бэкенд — убрали человека, который его понимает. Бэкенд-разработчик — это не тот, кто пишет CRUD-эндпоинты. Это тот, кто проектирует модели данных, которые переживут реальную нагрузку, думает о консистентности, отказоустойчивости и edge cases, и знает, куда смотреть, когда в 3 часа ночи всё ломается под нагрузкой.

Serverless не убил бэкендеров — он их трансформировал. Теперь вместо настройки серверов нужно разбираться в распределённых системах, event-driven архитектурах, observability и расходах, которые тихо взрываются за ночь. AI тоже не заменяет — он убирает скучную часть работы, ту, которую мы и так не любили. А вот понимание бизнес-ограничений, принятие решений в условиях неопределённости и дебаг эмерджентного поведения между сервисами — это по-прежнему задача человека. Бэкенд не исчезает. Он становится невидимым. И чем менее он заметен, тем ценнее люди, которые действительно его понимают.

Dependency hell в 2026: npm install займёт больше времени, чем разработка фичи

В прошлом году средний фронтенд-проект набрал 1,200+ зависимостей. Для сравнения — в операционной системе их меньше.

Хотите добавить кнопку? Установите UI-библиотеку. Она тянет 15 утилит для стилей, которые тянут парсеры, которые тянут валидаторы, которые тянут... Поздравляю, ваша кнопка весит 50MB в node_modules.

А потом начинается магия:

• Пакет A требует lodash@4.x
• Пакет B требует lodash@3.x
• Пакет C вообще переписал lodash и назвал его "lodash-pro"
• npm пытается это всё совместить и плачет
В итоге npm audit показывает 847 уязвимостей, половина зависимостей давно не поддерживается, а обновление одного пакета ломает половину проекта.

Что получается: left-pad не научил нас ничему. Мы всё ещё импортируем целую библиотеку ради одной функции и удивляемся, почему бандл раздулся до размеров небольшой ОС.

Может, пора вспомнить, что иногда 10 строк своего кода лучше, чем зависимость от "ultra-mega-helper-utils-v2"?

🤖 Неудобная правда: ИИ делает джунов бесполезными, а сеньоров — незаменимыми

Все говорят, что AI заменит программистов. Реальность жёстче: он заменит плохих программистов и усилит хороших.

Джун 2024 года: гуглит ошибки, копипастит со StackOverflow, тратит 2 часа на то, что Copilot делает за 30 секунд. Его единственное преимущество — дешевизна — больше не преимущество. Зачем платить человеку за работу, которую AI делает быстрее и без выходных?

Сеньор 2024 года: понимает почему код работает, видит архитектурные проблемы, задаёт правильные вопросы AI и критически оценивает ответы. Он не конкурирует с AI — он использует его как множитель своей экспертизы.

Парадокс: Чтобы эффективно использовать AI для кода, нужно уже уметь кодить. Джунам AI не помогает расти — он помогает им не расти, выдавая готовые ответы без понимания.

Раньше путь был: джун → мидл → сеньор. Теперь: джун → ???

Кто будет сеньорами через 10 лет, если джуны не проходят путь боли и ошибок? 🪦

Vibe Coding: программирование перестало быть про код

Раньше разработчик знал каждый символ своей кодовой базы, писал с нуля, гордился элегантными решениями. "Чистый код" был манифестом. Джуны зубрили синтаксис, сеньоры спорили об оптимизациях.

Сейчас происходит сдвиг. Andrej Karpathy назвал это вайбкодингом — ты описываешь намерение, AI пишет реализацию. Cursor, Copilot, Claude Code — уже не автокомплит, а полноценный со-разработчик.

Что изменилось философски:

🔹 От "как" к "что" — важнее понимать архитектуру и бизнес-логику, чем помнить API
🔹 От написания к ревью — читаешь и проверяешь больше, чем пишешь
🔹 От синтаксиса к семантике — правильный промпт важнее знания фреймворка
🔹 От владения к оркестрации — управляешь инструментами, а не молотком сам

Это не "деградация навыков". Когда-то программисты перекладывали данные в регистрах ассемблера - а писать на высокоуровневом языке считалось детской забавой. Когда-то управляли памятью вручную - потом появился garbage collector. Писали SQL руками — появились ORM. Каждый уровень абстракции освобождал для более важных задач.

Это просто следующий этап закономерного развития. Как мы сейчас не утруждаем себя ручным управлением памятью, так и ручное написание синтаксический конструкций, бизнес-логики и оптимизаций рендера страницы станет все больше выходить из моды. Инженер - это теперь тот, кто строит систему на уровне задач, которые она должна решать, а не как правильно реализовать отписку от таймера на Реакте.

Но разве это не всегда было настоящей сутью инженера?

🎭 ООП в JavaScript — карго-культ, который пора похоронить

Когда Java-разработчик приходит в JS, первое что он делает — тащит классы, наследование и паттерны из Gang of Four. И код превращается в это:

class UserRepository extends BaseRepository {
  constructor(database) {
    super(database);
    this.model = UserModel;
  }
  
  async findById(id) {
    return super.findById(id);
  }
}

// 50 строк обёртки ради одного запроса в базу

А можно было так:

const findUser = (db) => (id) => db.query('users', { id });

// Всё. Одна строка. Тестируется за 5 секунд.

Почему это карго-культ:

1. Классы в JS — синтаксический сахар над прототипами. Вы не получаете настоящую инкапсуляцию (private появился вчера и работает костыльно)
2. Наследование — антипаттерн. Даже в Java давно говорят "composition over inheritance". В JS это критично вдвойне
3. this — мина замедленного действия. Половина багов в "классовом" коде — потеря контекста
Функции — first-class citizens в JS. Используй это. Композиция функций > иерархия классов.

🏦 COBOL: код, которому 66 лет, до сих пор управляет деньгами миллионов людей

Когда житель США проводит картой или бронирует авиабилет — за кулисами работает код, написанный до вашего рождения. Миллиарды строк COBOL из 1970-х тихо держат мировую экономику на плаву. COBOL создали в 1959 году по заказу Пентагона. Изначально это была временная заплатка — а потом Минобороны надавило на производителей компьютеров, и язык стал стандартом. «Временное решение» живёт уже 66 лет.

Язык проектировали так, чтобы код читался как английский текст: MOVE SALARY TO TOTAL-PAY. Идея была в том, что даже менеджер поймёт, что происходит. На практике получились программы на сотни тысяч строк, которые понимают только те, кто их писал.

Почему это проблема

Эксперты, которые писали этот код — уходят на пенсию. Университеты перестали преподавать COBOL десятилетия назад. Банки платят бешеные деньги за контракторов и еле держатся.

Во время ковида несколько штатов США столкнулись с коллапсом: системы пособий по безработице были на COBOL, а специалистов не хватало.

В некоторых банках сейчас работает такая цепочка: Java-код генерирует COBOL, который крутится внутри эмулятора, имитирующего старый IBM-мейнфрейм. Сотрудники банков до сих пор видят монохромные зелёные терминалы — прямо как в фильмах про хакеров из 90-х.

Java, которая сейчас заменяет COBOL в тех же банках, через 30 лет станет таким же легаси. Может быть, будущие разработчики будут запускать эмулятор современных систем, внутри которого Java генерирует COBOL, который крутится в эмуляторе IBM.

Приглашаем в новый ИТ-хаб Группы «Т-Технологии» — место, где идеи превращаются в реальные продукты.

Встречаемся 26 марта: вас ждут выступления команды — поговорим о развитии саратовского ИТ-хаба, применении AI в разработке и роли системного аналитика в создании продуктов. А ещё — экскурсия по офису, чтобы увидеть всё изнутри.

После программы — время для общения: знакомьтесь, задавайте вопросы и обсуждайте идеи с теми, кто работает в ИТ каждый день.

Зовите коллег и регистрируйтесь прямо сейчас: количество мест ограничено!

Подробнее о программе и регистрация — https://l.tbank.ru/dod_saratov_26

Дорогие подписчики!
Постов про то, что ИИ всех заменил и больше не надо понимать внутреннего устройство вашего любимого фреймворка - не будет!

Айти Капибара продолжает работу в штатном режиме и публикует интересные инженерные публикация. Админ убежден, что подобные знания будут только ценнее с течением времени, когда вокруг вас останутся только болванчики для промптинга Клода.

Поэтому сегодня на очереди материал о том, как работает тот самый механизм attention в любимых вами ГПТшках, который перевернул все и дал такой мощный буст языковым моделям.

https://t.me/tuzov_ai_lab/95