TypeScript явился в мир разработки подобно рыцарю в сияющих доспехах. Он обещал более безопасный код, меньшее количество ошибок во время выполнения и улучшение опыта разработчика. В течение многих лет выход TypeScript называли переломным моментом, позволяющим специалистам писать код на строго типизированном JavaScript. Многие компании и проекты с открытым исходным кодом приняли его с энтузиазмом, стремясь использовать его возможности. Однако по мере того, как проходил первоначальный восторг, некоторые известные команды стали отказываться от TypeScript, ссылаясь на такие причины, как сложность, скорость разработки и конфликт инструментов.
Эта смена настроений вызвала жаркие споры среди разработчиков. Почему некоторые проекты, которые раньше всем сердцем принимали TypeScript, теперь возвращаются к простому JavaScript?
Рассмотрим эту тенденцию на реальных примерах и узнаем, почему простота может оказаться предпочтительнее безопасности типов.
Важное решение: Svelte как альтернатива TypeScript
Одним из самых обсуждаемых моментов стало решение Рича Харриса, создателя популярного JavaScript-фреймворка Svelte, отойти от TypeScript. Харрис наделал шуму в сообществе разработчиков, когда сообщил, что ядро Svelte, а также его сопутствующий проект SvelteKit, перейдут на JavaScript с аннотациями JSDoc.
В чем причина этого решения? Харрис обнаружил, что, хотя TypeScript и дает ценные преимущества, накладные расходы на инструментарий и конфликты, которые он создает, не стоят того, чтобы идти на компромиссы. Используя JSDoc, команда Svelte смогла сохранить безопасность типов, упростив при этом свой рабочий процесс. Харрис объяснил причину перехода в интервью: «Мы обеспечиваем безопасность типов, но при этом не сталкиваемся с изъянами». Переход позволил ускорить итерации и избежать бремени постоянного управления конфигурацией и инструментарием TypeScript.
Этот поворот говорит о том, что для некоторых команд, особенно для создающих фреймворки и библиотеки, а не полноценные приложения, простота и скорость перевешивают преимущества более строгой структуры TypeScript.
Turbo 8: отказ от TypeScript
Еще один громкий случай — пример создателей Turbo 8, фреймворка для современных веб-приложений. Они также решили отказаться от TypeScript в пользу JavaScript. Разработчик Дэвид Хайнемайер Ханссон (DHH), известный своим опытом работы с Ruby on Rails, открыто заявлял, что предпочитает гибкость JavaScript. В своей статье DHH пояснил, что, хотя TypeScript обещал меньшее количество ошибок, реальный опыт разработки не всегда соответствовал этим обещаниям.
Вместо того чтобы тратить время на распутывание сложной «гимнастики типов» и брожение по лабиринтам инструментария TypeScript, команда Turbo 8 стремилась сосредоточиться на написании более быстрого и чистого кода. По мнению этих специалистов, JavaScript предлагал им свободу разработки, которой они жаждали, освобождая от необходимости управлять сложным инструментарием или определениями типов. По словам DHH, TypeScript по праву занимает свое место, но командам, ориентированным на быструю итерацию и гибкость, он часто кажется слишком сложным с инженерной точки зрения.
Привлекательность современного инструментария JavaScript
Современный JavaScript прошел долгий путь, и появление новых инструментов позволило обеспечить достойное качество кода без TypeScript. Такие инструменты, как ESLint и Prettier, стали основными для многих команд разработчиков, обеспечивая последовательный и безошибочный код. Учитывая улучшения в JSDoc, позволяющие разработчикам включать необязательные аннотации типов непосредственно в файлы JavaScript, многие команды считают, что могут достичь правильного баланса между гибкостью и безопасностью типов без полного перехода на TypeScript.
Именно так обстояли дела с фреймворком Svelte. Перейдя на JSDoc, команда Svelte нашла золотую середину, обеспечив определенную безопасность типов и одновременно упростив процесс разработки. Снижение накладных расходов на управление файлами и конфигурациями TypeScript позволило сосредоточиться на более быстрых итерациях и чистых рабочих процессах. Такая схема становится все более распространенной по мере совершенствования инструментария JavaScript.
Необязательная типизация в JavaScript: взгляд в будущее
Привлекательность JavaScript по сравнению с TypeScript все более повышается благодаря распространению в сообществе JavaScript обсуждений, касающихся необязательной аннотации типов. Это предложение, которое в настоящее время изучается разработчиками и органами по стандартизации, потенциально может сделать возможным добавление типов непосредственно в JavaScript без полного принятия TypeScript. Если это произойдет, границы между JavaScript и TypeScript станут еще более размытыми и разработчики получат лучшее от обоих языков — безопасность типов, когда это необходимо, и гибкость в ином случае.
Сама возможность такого перехода заставляет разработчиков задуматься о необходимости TypeScript для их проектов. Если в будущем JavaScript сможет нативно поддерживать необязательную типизацию, аргументы в пользу перехода на TypeScript могут существенно потерять в силе. Для многих команд это уже стало причиной переоценки необходимости строгой типизации, особенно когда важны скорость и гибкость.
Золотая середина: когда TypeScript реально полезен
Итак, мы привели примеры проектов, отказывающихся от TypeScript. Тем не менее важно отметить, что у TypeScript все еще есть свои сторонники, и особенно это касается разработчиков больших приложений. Сила TypeScript заключается в его способности масштабироваться и поддерживать большие, сложные кодовые базы. Такие компании, как Microsoft, разработавшая TypeScript, и Google, продолжают в значительной степени полагаться на этот язык. Для корпоративных приложений, где поддержание чистоты и отсутствие ошибок в кодовой базе имеют решающее значение, безопасность типов и надежные инструменты, предоставляемые TypeScript, могут оказаться бесценными.
TypeScript гарантирует, что по мере роста команд и проектов новые разработчики смогут быстро освоить и понять код, не нанося вреда функциональности. Строгая система типов TypeScript позволяет выявлять ошибки на ранних этапах разработки, что делает его незаменимым инструментом для команд, которые ставят во главу угла долгосрочную сопровождаемость, а не быструю итерацию.
Поиск баланса между простотой и безопасностью
В основе дебатов о TypeScript лежит вечный спор о том, как достичь равновесия между простотой и безопасностью. Такие проекты, как Svelte и Turbo 8, выбрали простоту, отказавшись от слоев сложности, присущих TypeScript, в пользу более быстрых итераций и более оптимизированного инструментария. Но для больших команд, управляющих обширными и сложными кодовыми базами, безопасность типов и экосистема TypeScript по-прежнему представляют огромную ценность.
По мере развития JavaScript и появления современных инструментов все больше команд приходят к выводу, что они могут достичь нужного баланса и без TypeScript. Выбор TypeScript зависит от потребностей проекта. Что важнее для команды — гибкость и скорость или защита, которую обеспечивает TypeScript? В конечном счете речь идет о выборе подходящего рабочего инструмента.
Споры продолжаются
Нет окончательного решения насчет того, использовать ли TypeScript или вернуться к JavaScript. В сообществе разработчиков не утихают споры. Для таких проектов, как Svelte и Turbo 8, простота, скорость и гибкость оказались предпочтительнее обещаний TypeScript, касающихся безопасности типов и сокращения количества ошибок. Однако при работе с большими и сложными приложениями TypeScript все еще остается мощным инструментом для управления качеством кода на должном уровне.
Поскольку JavaScript продолжает развиваться, а на горизонте маячит возможность появления необязательных аннотаций типов, вопрос о том, принимать TypeScript или нет, может стать еще более сложным.
Как и в случае с большинством решений в области разработки программного обеспечения, ответ таков: все зависит от ситуации.
Однако на данный момент в определенных кругах маятник, похоже, качнулся в сторону предпочтения простого JavaScript.
А на чьей стороне вы? Вы в команде TypeScript или в команде JavaScript?
Читайте также:
- TypeScript: расширение возможностей JavaScript
- Zod — гарант безопасности кода TypeScript
- Encore.ts — в 9 раз быстрее Express.js и в 3 раза быстрее Bun + Zod
Читайте нас в Telegram, VK и Дзен
Перевод статьи Ferid Brković: Why Some Major Projects are Ditching TypeScript
