Комментарии 14
TypeScript, VSCode и GitHub - это всё продукты Microsoft. Вот поэтому с JS/JSdoc так неудобно работать в VSCode. Я этого в IDEA вообще не чувствовал. А в VSCode - да, там надо писать types.d.ts в проектах, чтобы JSDoc заработал.
А так-то статистика разная бывает - https://innovationgraph.github.com/global-metrics/programming-languages
Работаю в vscode, никаких проблем с jsdoc нет. Причем его использую очень активно. types.d.ts использую для описания интерфейсов и прочего, что не поддерживается в jsdoc, а также есть определенная стратегия для создания бандла типов для пакета. Если интересно, можете глянуть мой гитхаб https://github.com/supercat1337
Зачем js-doc, если есть TS? Есть транспиляторы, есть сурсмапы. Это все выглядит как превозмогания ради мнимой борьбы с корпорацией зла.
А для чего вам нужен TS? Вот всё то же самое делает JS, только без транспиляции и source maps. Вы, когда в консоли браузера код для исполнения вбиваете, вы JS'ом пользуетесь. Ну и зачем вам транспилятор, который в конце-концов переведёт ваш код в JS?
И чем TS лучше Java в этом случае? Я несколько лет кодил на GWT (Java-to-JS). Java вообще очень красивый, инженерный язык. Смысл мне кодить на TS, если я больше десяти лет кодил на Java? Мне можно уже сразу на JS кодить. Без посредников.
А так-то можно и для brainfuck'а свой транспилятор написать, чтобы в JavaScript перекодировалось.
JSDoc работает на основе движка TypeScript и всегда выступает в роли догоняющего. У него менее выразительная система типов, более слабая поддержка IDE, более медленная работа, хуже вывод типов. Код с JSDoc попросту объёмнее (больше потребление токенов LLM).
Теперь приходим к тому, зачем всё это: для отказа от транспиляторов и сурс-мап. Это означает: больший размер бандла (нет минификации и удаления неиспользуемого кода), необходимость тащить node_modules на прод, отсутствие полифилов и невозможность использовать самые свежие фичи.
С TypeScript процесс разработки понятен и предсказуем: один раз настроил — и всё работает, а голый JS — это риск. Что, если потребуется использовать React и JSX? Что, если окажется, что бандл слишком большой? Что, если нужно пошарить код между бэком и фронтом? Кто даст понять, что на фронте нет Buffer, но есть Uint8Array?
Копирование в консоль браузера? Что мешает прогонять код через https://www.typescriptlang.org/play/ . Кстати, даже на голом JS придётся убрать у функций ключевое слово export. Вероятно, юнит-тест может решить 90% задач, для которых захотелось скопировать код в консоль. А ещё есть bun repl и https://www.typecell.org/ .
P.S. А сравнение с Java вообще неуместно, это принципиально разные экосистемы и принципы работы.
P.P.S. Я бы вообще отправил Java на свалку, потому что есть C# (упс, опять корпорация зла), который уже 10 лет (с выхода .NET Core) набирает обороты. У C# единый набор инструментов, а не холивары про Maven vs Gradle vs Ant. У C# есть настоящие Generics и Dynamic Language Runtime. А у Java только заявления про то, что он единственный пригодный язык для Ынтырпрайза.
P.P.P.S. Ну а если всё-таки попробовать сравнить TS и Java, то для backend у TS есть преимущества, такие как быстрый холодный старт (естественно после минификации), devDependencies, позволяющие всем разработчикам пользоваться одинаковыми версиями инструментов, возможность шарить код между фронтом и бэком, более выразительная система типов, меньше бойлерплейта, и, конечно же, отсутствие многопоточности: около нулевая вероятность гонок данных. Да, это минус, когда речь идет о high-load.
JSDoc работает на основе движка TypeScript и всегда выступает в роли догоняющего.
JSDoc появился в 1999-м, TS - в 2012-м.
Не вижу смысла дискутировать. У нас с вами очень разные картины мира. Мне будет неуютно в вашей, а вам - в моей. Останемся при своих.
В моей картине мира JSDoc — это просто инструмент для генерации HTML-документации. А вот проверку типов делает tsc. И тот же WebStorm использует TypeScript Language Server для валидации типов, которые описаны как JSDoc-комментарии.
P.S. Смысл дискуссии в том, чтобы расширять свою картину мира.
Ладно, давайте расширять. Вот JS-код. Во всех исходниках всего пакета (./src/) нет ни одного статического import'а. А там порядка 20 файлов. Тем не менее, пакет рабочий и используется в составе других пакетов (например, github-flows-app).
Это называется "late binding". В таком виде (без статических импортов) JS-код становится изоморфным - может работать и в браузере, и на бэке без изменений. Юнит-тестирование такого кода становится детской игрой, так как можно подменить моком любую зависимость, вплоть до node-библиотек.
Этот подход пришёл из того самого "энтерпрайза", который вы пренебрежительно называете "Ынтырпрайз". В кодовой базе Magento Open Source 2.4.x свыше 2 млн. строк на PHP, а ещё под 0.5 млн - на JavaScript (не TypeScript!). В базовом наборе платформы порядка 200+ модулей, а сторонние разработчик дают возможность доставить в базу ещё свыше 2К модулей и одному Богу известно, сколько там строк кода. И весь этот "зоопарк" способен крутиться согласованно и на фронте, и на бэке, благодаря технологиям "Ынтырпрайза", в том числе и позднему связыванию.
И тот же WebStorm использует TypeScript Language Server для валидации типов
WebStorm появился в 2010 году - за два года до TypeScript'а. В нём есть отдельно настройки для JavaScript и для TypeScript. Да, для валидации типов в TypeScript IDEA может использовать TS Language Server. Но его можно отключить и писать на чистом JS.
Это означает: больший размер бандла (нет минификации и удаления неиспользуемого кода),
Минификации JSDoc не мешает - можно выкинуть все JSDoc'и и код остаётся рабочим. А неиспользуемого кода здесь нет в принципе - связывание идёт в runtime.
Да, для TS есть своя ниша - "галеры". Создаётся ощущение контроля за ситуацией. Типа, мы "натянули типы" на JS. Но - нет, не натянули. Их там как не было, та и нет. Откройте DevTools в браузере по F12 и убедитесь сами. Типы есть только в вашем IDE и лишь до транспиляции.
Я пять лет назад уже публично пояснил, почему я предпочитаю JS. С тех пор не особо что изменилось. Вернее, поводов использовать TS становится всё меньше. А ИИ-агенты - так это вообще повод TS не использовать. Им-то зачем лишний раз код транспилить при рефакторинге? Экономия токенов идёт от понимания моделью контекста задачи, а не от количества символов, и JSDoc здесь как раз к месту.
Все смешалось в кучу. Я так понимаю, ключевая проблема в том, что интерфейсы не существуют в runtime и нельзя сделать DI / “late binding”, что бы зависимость резолвилась по типу-интерфейса, а не по классу-имплементации.
Есть вот такая штука, использует надстройку над компилятором: https://github.com/wessberg/DI
Но и на классическом TS это можно сделать, просто для каждого интерфейса нужно сделать symbol-дескриптор. https://inversify.io/docs/introduction/dependency-inversion/
Ключевая проблема в том, что при разработке приложений вы "думаете" не на том языке, на котором "думает" компьютер при их выполнении.
В природе существуют транспиляторы в JavaScript, как минимум, для следующих языков: CoffeeScript, Dart, Kotlin, Scala, F#, Clojure, Elm, PureScript, Haxe, Go, Java, Python, Ruby, ...
Простую "программу для браузера" можно написать на любом из этих языков, но её придётся транспилировать в JS (или WASM) - браузеры просто не понимают ничего, кроме JavaScript и WASM (но WASM уже плохо понимает человек).
Каждый из перечисленных выше языков обладает какими-то преимуществами и какими-то недостатками, вытекающими из преимуществ. При транспиляции из одного языка в другой недостатки каждого языка суммируются, а преимущества исходного языка просто теряются.
Так вот, чем TypeScript кардинально лучше любого из этих языков? Тем, что похож на JavaScript больше любого другого? Больше любого другого на JS похож сам JS - в нём недостатки только его самого, которые хоть как-то компенсируются его достоинствами.
TS можно и нужно было использовать вместо JS до появления ES6 - c 2012 по 2015 год. А потом качественная разница между ними лишь уменьшалась.
Если вам удобно кодировать "программы для браузера" на TypeScript - пожалуйста, кодируйте на TypeScript. Другим удобно это делать на других языках (я перечислил только часть). Браузер всё равно понимает лишь JavaScript и WASM.
Когда я пишу "программы для браузера", я предпочитаю делать это на максимально близком ему языке, чтобы не привносить в runtime недостатки других ЯП. Только и всего.
TS - это просто вариант линтера для JS, который внутри IDE позволяет подсветить NPE или избавиться от некоторых приколов JS по части сравнения несравнимых типов.
C TS или с JsDoc я примерно понимаю, какие есть у объекта поля и их типы, но в ненастроенном JS ориентация довольно быстро теряется.
Если у кого-то хватает концентрации отслеживать всё это в JS или ему эти проблемы некритичны, то я не вижу для него преимуществ TS.
Количество ошибок 38% - интересно узнать как считали. В моей практике ошибки которые может выявить только TS встречались очень редко.
Данные показывают: JS остаётся шире по охвату, TS всё чаще выбирают для написания кода внутри JS-экосистемы. TypeScript не заменяет JavaScript — он накладывается на него как инструментальный слой.
Что здесь простите вообще написано, кто-нибудь читал перед тем как публиковать?
"TypeScript не заменяет JavaScript" буквально абзацем выше:
около 40% разработчиков пишут исключительно на TypeScript (рост с 28% в 2022). Только 6% используют исключительно чистый JS
Выходит что для 40% заменяет:)
"TS всё чаще выбирают для написания кода внутри JS-экосистемы" - а его еще где-то можно применять за пределами JS-экосистемы?
TypeScript vs JavaScript в 2026: почему TS обогнал JS и что это значит для разработчиков