Мысли впервые были оформлены в комментарии к посту Linkedin.
Это субъективное мнение, сложившееся на основе многолетнего опыта разработки. Я не претендую на истину в последней инстанции, но мою точку зрения менять бесполезно.
Бегство из мира Java и строгой типизации с ООП
Мой бэкграунд — это Java и ООП. Строгие типы на уровне компиляции, множество абстракций и полиморфизм достигаемый бесчисленным количеством интерфейсов на контрасте с JS, который по определению весь полиморфный из-за слабой типизации.
Я досконально изучил все боли этой парадигмы: тонны бесполезного бойлерплейта, раздутые кодбейсы, абстракции, которые лишь замедляют и разработку и delivery. Я сбежал от этого в мир фронтенда в поисках свободы, тотального полиморфизма и гибкости. И теперь эту свободу у меня забрал TypeScript под лозунгом: "Мы спасем мир от ошибок, связанных с типами!", навязывая статическую типизацию и всё ту же культуру чрезмерного усложнения, от которой я когда-то ушёл.
Я видел, как очень умные люди, в десятки раз умнее меня, спотыкались о дженерик внутри дженерика, который описывает другой дженерик и просили помощи разобраться у других. Помню даже, как один уважаемый инженер тогда сказал, глядя на этот код: "Что это за заклинание по вызову дьявола?"
А чего можно было ожидать от дизайнера C#, Delphi и Turbo Pascal во фронтенде? Просто на секунду задумайтесь, каков "балласт" в голове человека, который столько лет работал и строил диаметрально противоположные JS языки?
Утрата первоначальной философии JavaScript
JavaScript создавался Бренданом Эйком практически "на коленке" как язык для "непрограммистов" — дизайнеров и верстальщиков, которым нужно было добавить немного интерактивности на страницы.
Эта "инаковость", этот легкий порог входа были его наибольшей силой. Язык должен был оставаться доступным и развиваться в своей парадигме, а не становиться жертвой "высоких инженеров", которые навязали ему привычные им паттерны из других экосистем. TypeScript систематически убивает эту легкость, превращая фронтенд из творческого процесса в рутину инженерных практик.
Типы не принадлежат UI
Типы полностью оправданы для больших корпоративных бэкендов работающих с БД, но точно совсем не для фронтенда. В конечном счёте, какой бы тип у вас ни был, в HTML всё превращается в строку.
Я не тотально за то, чтобы писать год без строгой типизации, но из своего многолетнего опыта именно на фронтенде нужен компромис, потому что строгая типизация убивает кучу классных синтаксических конструкций слабой типизации, которые адепты TypeScript пометили, как "запрещенные" или "нежелательные". Мне гораздо ближе идея рантайм-валидаторов, вроде 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 постепенно вытеснил их, обрекая на стагнацию. Возможно даже внутри самой спецификации ECMAScript произошла бы какая-то революция с типами, появились бы новые механики внутри искомого языка, а не надстройки над ним. Но теперь при доминировании 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 - сначала простой транспилятор, потом монстр с кучей плагинов, и теперь сообщество ищет альтернативы.