Мысли впервые были оформлены в комментарии к посту Linkedin.
Это субъективное мнение, сложившееся на основе многолетнего опыта разработки. Я не претендую на истину в последней инстанции, но мою точку зрения менять бесполезно.
Бегство из мира Java и строгой типизации с ООП
Мой бэкграунд — это Java и ООП. Строгие типы на уровне компиляции, множество абстракций и полиморфизм достигаемый бесчисленным количеством интерфейсов на контрасте с JS, который по определению весь полиморфный из-за слабой типизации.
Я досконально изучил все боли этой парадигмы: тонны бесполезного бойлерплейта, раздутые кодбейсы, абстракции, которые лишь замедляют и разработку и delivery. Я сбежал от этого в мир фронтенда в поисках свободы, тотального полиморфизма и гибкости. И теперь эту свободу у меня забрал TypeScript под лозунгом: "Мы спасем мир от ошибок, связанных с типами!", навязывая статическую типизацию и всё ту же культуру чрезмерного усложнения, от которой я когда-то ушёл.
Я видел, как очень умные люди, в десятки раз умнее меня, спотыкались о дженерик внутри дженерика, который описывает другой дженерик и просили помощи разобраться у других. Помню даже, как один уважаемый инженер тогда сказал, глядя на этот код: "Что это за заклинание по вызову дьявола?"
А чего можно было ожидать от дизайнера C#, Delphi и Turbo Pascal во фронтенде? Просто на секунду задумайтесь, каков "балласт" в голове человека, который столько лет работал и строил диаметрально противоположные JS языки?
Утрата первоначальной философии JavaScript
JavaScript создавался Бренданом Эйком практически "на коленке" как язык для "непрограммистов" — дизайнеров и верстальщиков, которым нужно было добавить немного интерактивности на страницы.
Эта "инаковость", этот легкий порог входа были его наибольшей силой. Язык должен был оставаться доступным и развиваться в своей парадигме, а не становиться жертвой "высоких инженеров", которые навязали ему привычные им паттерны из других экосистем. TypeScript систематически убивает эту легкость, превращая фронтенд из творческого процесса в рутину инженерных практик.
Типы не принадлежат UI
Типы полностью оправданы для больших корпоративных бэкендов работающих с БД, но точно совсем не для фронтенда. В конечном счёте, какой бы тип у вас ни был, в HTML всё превращается в строку.
Мне гораздо ближе идея рантайм-валидаторов, вроде Joi или Zod. На мой взгляд, это правильный путь, потому что они работают тогда, когда ваш код выполняется, а не на этапе компиляции. И давайте не будем забывать, что TypeScript — это просто надстройка, слой поверх языка, который делает статические проверки, и все эти проверки бесследно исчезают в финальном бандле. Очень надеюсь, что он никогда не попадет в нативную сборку браузерных дистрибутивов, хотя к этому все идет.
На самом деле я очень часто спрашивал команды и отдельных разработчиков, как часто в ваших продуктивах ошибки были связаны с типами? Является ли это проблемой, когда дело доходит до бэклога с багами? И всегда мне отвечали, что да, это не частый случай, бывает, но это не "узкое горлышко". Комбинация валидатора и хороших модульных и интеграционных тестов полностью закрывает потребность проверки типов. Это эмпирическое наблюдение, а не доводы.
tsc как чёрный ящик
JavaScript-код, который производит tsc — это чёрный ящик. Это очередная абстракция, которую мы отдаём на откуп разработчикам этого инструмента. Результат может быть далёк от оптимального, в отличие от ситуации, когда я пишу на чистом JavaScript и имею полный контроль над тем, что получается на выходе. Да-да, умники могут сказать чтобы я писал тогда на ассемблере, но я сравниваю два языка высокого уровня, оснащенных одинаково богатыми конструкциями, но с разной философией.
Это как писать на Java, а потом какой-то "умный" инструмент все переведет в Ruby и запустит не глядя в продуктиве.
Ухудшение Developer Experience (DX)
На мой взгляд, DX от TypeScript только проигрывает. Это постоянная возня с новыми конфигами, дополнительная настройка, которая увеличивает сложность фронтенд-операций. И не стоит забывать про бесчисленные пакеты @types, которые сжирают мои CPU-циклы, пока IDE всё это индексирует — это просто плохая инженерия.
Исторический контекст и навязывание
И последнее, но не менее важное — исторический контекст взлёта TypeScript. Его популярность не была органической. Его активно продвигали и навязывали крупные tech-корпорации, вроде Microsoft и Google. Помните документацию по Angular 2 beta? В ней примеры были почти исключительно на Dart и TypeScript, с едва заметными намёками на чистый JS. Очевидно, что все хотят монополии на инструментарий и пытаются оправдать свои инвестиции в разработку. Слава богу, Dart не зашёл во фронтенде. Такое принудительное внедрение отталкивает на человеческом уровне. На тот момент уже были достойные инструменты, вроде propTypes и Flow для React, но TypeScript постепенно вытеснил их, обрекая на стагнацию.
TypeScript, по моему мнению, стал большой ошибкой, которая захватила индустрию и превратилась в де-факто стандарт, с которым уже ничего не поделать. Возможно, настоящим решением было бы просто лучше изучить JavaScript (как говорит всегда Кайл Симпсон), а не накладывать на него ещё один слой абстракции, противоречащий изначальному духу языка.
Помните принцип YAGNI и KISS? Нужно задуматься, мы добавляем сложность потому, что это решает реальные проблемы, или просто следуем тренду?
P.S. Самая яркая ирония во всей этой истории — это то, что сам TypeScript стал настолько медленным и сложным, что сообщество начало массово переписывать инструменты его экосистемы на Rust и Go.
Мы получили абсурдную ситуацию: чтобы использовать TypeScript во фронтенде, нам теперь нужны компиляторы, написанные на других языках — SWC (Rust), esbuild (Go), Oxc (Rust). Создаётся многослойный монстр абстракций: TypeScript → Rust-компилятор → Go-бандлер → JavaScript.
Это идеальное подтверждение того, что изначальная архитектура TypeScript была flawed. Вместо решения проблем JavaScript, мы получили проблемного посредника, для оптимизации которого пришлось задействовать половину языков программирования. Погоня за производительностью привела к тому, что простой инструмент превратился в сложнейший инженерный стек, который требует постоянной настройки и поддержки.
Это напоминает историю с Babel - сначала простой транспилятор, потом монстр с кучей плагинов, и теперь сообщество ищет альтернативы.