Комментарии 30
Про JSDoc вводите в заблуждение немного, сам же тайпскрипт умеет проверять по нему код. Собственно, он вывел в подсказке типы из комментария потому что прочитал его. Достаточно включить allowJs/checkJs или написать // @ts-check и оно будет ругаться.
Я бы сказал даже много. JSDoc спокойно работает если насроена экосистема - можно JSDoc'ом полностью покрыть тайпчекинг(если использовать только простые типы конечно, до TS ему далеко). И выше описаный пример показал бы ошибку если бы мы в функцию передали стринг. Тут же скорее придирка к VSCode, но автор похоще не до конца разобрался в теме
Мне кажется, что сила в простоте. И с JSDoc все решается. Если типы слишком сложно вычисляются - это знак, что код надо рефакторить.
если использовать только простые типы конечно, до TS ему далеко
Ну смотря чем чекать. Обычно это делает TS и там используется та же самая система типов только с другим синтаксисом, все фичи буквально 1к1. Есть даже некоторые годные фичи в жсдоке которых нет в тс синтаксисе, такие как возможность вешать @type на функции и методы.
Typescript это, возможно, самый "врущий" язык, с которым мне приходилось работать.
Во-первых, типизация, она как бы есть, но её как бы и нет. То есть, любой может случайно изменить объект за пределами тайпскрипта, и это с удовольствием проглотиться системой.
Во-вторых, сама по себе типизация, особенно в ORM системах и более-менее продвинутых скриптах приводит к тому, что ты часами сидишь в этих ошибках с Omit и пытаешься выяснить, каким был базовый тип, сообщение о том, что у тебя поле является строкой вместо числа не прокатит, потому что оно скрыто за бесконечными сообщениями от всякой мишуры, которая должна работать с типами.
В TS тебе приходится тратить больше времени на мороку с типами передаваемых переменных, и в три раза больше времени на мороку с типами стандартных переменных.
В итоге весь код обрастает тайпгардами и функциями, которые сравнивают значения.
При этом, в скорости это нифига не выигрывает, и просто добавляет ложку мёда в цистёрну дёгдя йаваскрипта.
Решение для типизации было следующим - сервер, написаный на golang, который возвращал объект нужного типа. (40 строк кода). Смысл TS быстро попадает, когда в мире столько других замечательных языков программирования.
Тайпскрипт и придуман для того чтобы занять большое количество разработчиков. Все при деле, все заняты делом — дебажат типы.
Смысл TS быстро попадает, когда в мире столько других замечательных языков программирования.
К сожалению, замечательного языка программирования для браузеров со сравнимым тулингом и экосистемой (что не менее важно) ещё не придумали, хотя пытались много раз. А типизация в браузере всё ещё нужна.
Я называю TS языком-тамагочи - постоянно требует внимания и обслуживания его жизнедеятельности.
Если есть типы с кучей Omit, Pick, Partial и т.п. - скорее всего, стоит на проекте стоит навести порядок в архитектуре. Независимо от размера проекта.
У меня есть проект в полсотни микросервисов с микрофронтами, легаси и оркестратором использование всех этих модификаторов скорее всего не превышает 20 штук в корнер кейсах. Всегда есть внешние модели - ДТО с АПИ или внешних либ и внутренние сущности, которые реально отображаются и отражают семантику конкретного экрана, и слой маппинга между ними. Омитам при таком варианте взяться неоткуда, всегда есть только один понятный тип, без обрезков.
Омит-ы это наследие попыток писать на ts так же как на js. И вот от этого как раз ts и спасает. В легаси js регулярно сталкиваюсь с тем, что функция принимает объект, модифицирует его и возвращает другой объект. "Ну там всего одно поле добавить/удалить надо было, не менять же весь объект из-за этого". В итоге, объект, пройдя пару таких функций становится неузнаваемым, так что понять, с чем же ты работаешь можно только про-реверс-инжинирив весь код через который этот объект может проходить - а это может быть от дня работы просто выкинутых. TS же дисциплинирует. Никаких случайных мутаций, сказано - верни 3 поля - значит верни 3 поля или расширяй интферейс и учитывай все нужные кейсы, никаких "костылей".
любой может случайно изменить объект за пределами тайпскрипта
Я это в любом языке программирования могу сделать - в рантайме поменять значения. Достаю из широких штанин CheatEngine и меняю память. Ни C++, ни Rust, ни C - никто не устоит перед критическим отвалом по причине смены типа переменной.
Все остальные претензии есть и в других ЯП. Или вы не делаете проверку типов в условном C#? Просто рассчитываете, что вылетит исключение и полностью положит всю программу?
Решение для типизации было следующим - сервер, написаный на golang, который возвращал объект нужного типа. (40 строк кода).
Что-то похожее есть в подходе tRPC - когда есть tRPC-сервер и он шарит типы в бекенд и фронтенд сразу. Кстати, а где юридические гарантии, что ваш сервер вернёт корректный объект-тип в 100% случаев?
Вывод: нельзя ожидать от TS чуда, он не лучше других, он просто подтягивает JS до уровня нормальных ЯП как умеет.
типизация, она как бы есть, но её как бы и нет. То есть, любой может случайно изменить объект за пределами тайпскрипта, и это с удовольствием проглотиться системой.
Эта участь ждёт любой язык, если тип, используется для получения данных из внешней системы (файл, база данных, сетевой запрос). В чём эта проблема специфична именно для тайпскрипт?
Плагины вроде того же Tabnine AI очень сильно спасают, когда дело приходится иметь со сложными типами (например, когда используешь стороннюю библиотеку и видишь в ней дикие дженерики, которые, подобно матрёшке, содержат в себе хер пойми что; и попробуй ещё этот клубок распутать)
Инструменты вроде Tabnine AI или вроде редактора Cursor AI позволяют вообще не прикасаться к этой срани (я про дженерики с глубоким уровнем вложенности)
90% работы (устранение конфликтов с типами) берёт на себя сам редактор или его плагины
Недавно была статья на Хабре где недоавтор обсуждал covariant в Dart будучи нулевым в ООП. Теперь эта статья где недоавтор обсуждает TypeScript будучи столь же нулевым в структурном программировании и, я бы на это поставил баночку икры, ООП тоже.
TypeScript, как и всё (при встрече я бы пинками затолкал вам это в глотку - ВСЁ) новомодное, создан с единственной целью - продать корпорациям ещё одну идею как сэкономить на программистах и навариться. При появлении идеи n, где n > 1, любому математику (существу, которому дозволено размышлять вне системы джун - мидл - тестер и вот этого всего) понятно, что идеи с 1 по n-1 провалились, если в бинарной логике. А TypeScript - далеко не последняя идея…
Это было введение. Теперь по тексту.
С какого перепугу функция square или power2 называется double? Это важно, потому что имелись рекомендации - называть функцию понятным именем и писать так, чтобы её можно было быстро прочитать и понять. Никакие подсказки IDE не нужны… но умеющие придумывать и писать программисты точно не самые дешёвые.
С какого перепугу человек написал double( и ждёт подсказок от IDE? Слышал гром и не знает где он? Аналогично user - у проекта есть данные, у данных есть структура, в структуре решено что есть id и name, структура документирована, можно посмотреть (нужно если хочется понимать чего делаешь) и средства языка вообще без надобности.
TypeScript создавался на идеях ООП а у ООП обнаружилась ограниченная область применения. Хорошо легло на элементы GUI. При попытке натягивать на глобус дальше, выяснилось - есть фундаментальные проблемы. Писать статьи подающие TypeScript как панацею - как минимум возврат в прошлое лет на двадцать, а то и то, против чего сами боги бороться бессильны.
Кстати, с какого перепугу функция возведения во вторую степень обязана генерировать ошибку при вызове без аргументов?
Кстати, с какого перепугу при наличии WebAssembly TypeScript незаменимый? Есть же модный Rust…
Раньше я был молодой и дерзкий и писал без TypeScript. Потом попробовал - заметил как компилятор в процессе редактирования поймал несколько ошибок и обратно на JS не хочется.
Можно писать на js так же: с подсветкой ошибок и выводом их в консоль, + подсказки работают в ide, только не будет крашиться приложение, если тип ошибочен.
Это достигается связкой Ts + jsdock + включенная валидация js в vs code
Но! При этом мы пишем js, а не ts и не имеем той массы условностей и многословности, которые заставляет нас делать ts
Ts установлен в dev dep и служит для того для чего и нужен: сопоставляет типы
так любой JS код это валидный TS. TS не заставляет вас ничего делать кроме транспайлинга. Есть вероятность что могут возникнуть ошибки компиляции, но они отключаются 1й строчкой в конфиге и вся ответственность ложится на разработчика
так любой JS код это валидный TS
Далеко не любой:
const a = 1
const b = 2
console.log(a < b, b > (a + 1))
error TS2349: This expression is not callable.
Type 'Number' has no call signatures.
console.log(a < b, b > (a + 1))
~
error TS2749: 'b' refers to a value, but is being used as a type here. Did you mean 'typeof b'?
console.log(a < b, b > (a + 1))
~
error TS2749: 'b' refers to a value, but is being used as a type here. Did you mean 'typeof b'?
console.log(a < b, b > (a + 1))
~
Перефразирую - в 99.999% кейсов реальный JS код - валидный TS. Такой конструкт в реальной жизни не имеет права на существования и руки должны быть вырваны тем кто так пишет, совершенно нечитаемо :D. Зато отличный пример почему TS нужен - в данном случаем абсолютно нечитаемый код должен быть отформатирован хоть немного.
Однако даже так - дополнительные скобки - не есть `масса условностей и многословности, которые заставляет нас делать ts`
интересные голословные заявления. возможно товарищ "высокоранговый" аналитег покажет пруфы где, в каких конкретно кейсах, на ts наварились microsoft? или пруфы что идеи ts провалились?
Много лет пишу большие проекты на js. У меня нет описанных проблем - что я делаю не так, помогите
В свете развития ИИ думаю типы отомрут
Пока что ИИ с прописанными типами работает заметно лучше, чем без них. Во втором случае он очень полагается на имена переменных. То есть, если он увидит let number_of_people = "пять"; то спокойно напишет number_of_people += 1 потому что это number;
Так я и не про сейчас. То что сейчас это подражание словно попугаи. Вы смотрите как рисуют с использованием ИИ , что-то подобное будет и с кодом
Кстати это хороший пример почему еще не нравится js. Давно заметил что джуны (ну и мидлы) порой пытаются сделать задачу наугад ровно как сейчас делает ИИ - лишь бы было похоже на нужный результат. Так вот в js такая халтура видна лучше чем в ts
Автору фронтенд-разработчику необходимо почитать https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html. Будет крайне познавательно. Уже давно можно в JavaScript с типизацией. Плюс не забывайте о d.ts (если не хватило jsdoc).
Вопрос в том, что вы ещё используете в работе. Если все инструменты требуют ts, то оно и понятно, что с ts не слезете, даже если разлюбите его.
TypeScript
Надежное программирование
Распространённое заблуждение.
Трижды проверил дату статьи. Очень своевременно, для чего нужна - загадка :D
Тайпскрипт уже лет 10, стандарт де-факто(рыночек зарешал). Современный фронтендер без ts - нормальной работы не найдет.
Если честно, мне статья показалась слишком обезжиренной. Получилась такая простая todo-шка по тс. Разумеется в этом ничего плохого нет, но, на мой взгляд, поднять пару тем о подводных камнях все таки стоило.
А то у вас все получилось просто замечательно, типа, дерзайте. Но при этом:
Правда если вы решили внедрять TS на проект, что работает долгие годы и уже на поддержке, то, возможно, не стоит тратить ресурсы на то, чтобы добавить TypeScript. Здесь уже бизнес будет решать, выгодно это или нет. А разработчики могут использовать например JSDoc.
Что из статьи должно было подвести к такому выводу? Например, взять и не включать strict, тогда и ваши примеры с any не будут вызывать ошибок на тс. Что это за "ресурсы" такие и каким образом они на самом деле влияют на обозначенные вами 4 положительных стороны?
А то получается у нас "Введение в мир надежного программирования" через тс, но один из выводов - это не использовать тс, а использовать JSDOC.
Может не все так радужно, и по "тудушке" как раз и не заметно какие трудности будут на пути к надежному программированию на тс.
По сути, вы привели ссылку на статью "Практическое руководство по ТС для разработчиков" и там как заключение:
Надеюсь, данная статья позволила вам получить общее предствления о возможностях, предоставляемых TypeScript, а также о том, почему использование TypeScript в дополнение к JavaScript в настоящее время фактически является стандартом веб-разработки.
Обратите внимание обе статьи по сути это введение в мир надежного программирования. Но у вас в выводах на порядок больше информации, чем во всем содержании статьи.
Просто пробежимся по форме:
Как фронтенд-разработчик я глубоко убежден в том, что TypeScript — незаменимый инструмент для создания масштабируемых, надёжных и легко поддерживаемых веб-приложений.
Легко поддерживаемых? Никакой тс не компенсирует использование антишаблонов, которые приведут к неподдерживаемому коду.
Потенциальные ошибки видно сразу — на этапе написания кода. Это, естественно, значительно сокращает время (почти полностью в некоторых кейсах) на отладку. Например, если я попытаюсь присвоить строку числовой переменной, компилятор TypeScript сразу же сообщит об ошибке.
В комментариях это уже подмечали, что система типов сама по себе тоже требует обслуживания. Вы сократите время на отладку исходного кода, но как отлаживать типы? Сколько времени на это уйдет? Что делать если тип плохо написан вашим коллегой, вы его так и оставите или будете переписывать?
Написание типов - это такой же исходный код как и чистый js код, а это значит, что на тс просто по определению исходного кода больше. А мы все знаем, это означает и пространства для ошибок тоже становится больше. Насколько легко отлаживать типы в тс? Какие для этого использовать приемы? Например, я сегодня узнал как на тс использовать счетчики внутри типов для создания нужного уровня вложенности получаемого типа. А сколько таких вещей нужно знать, что бы действительно эффективно использовать тс?
Читаемость кода. Чётко определенные типы данных делают код более понятным как для меня, так и для других разработчиков, работающих над проектом. Это особенно важно при работе в команде или над долгосрочными проектами. Становится проще погрузиться в проект и понять, какой здесь поток данных, что мы с ними делаем. В большие проекты на JS довольно трудно быстро «въехать», но TS помогает и с этим — ты видишь, какие данные какой компонент принимает, и можешь построить логическую цепочку. На «чистом» JS всё витает где-то в воздухе.
К этому отрезку тоже можно применить большую часть вопросов выше. Но у меня тут дополнение другого плана. На "чистом" js все не витает в воздухе. У вас будет и качественный нейминг. И документация в свагере. А если есть тесты с библиотекой тестовых утилит и генераторов данных, то просто читая spec файлы вы можете узнать даже больше, чем знакомясь посредством исходного кода на ts (разумеется не всегда, просто для примера сказал)
Более надежные API. TypeScript помогает создавать более надежные и предсказуемые API, как внутри компонента, так и между компонентами. Например, я могу точно определить тип данных, которые принимает и возвращает функция, что минимизирует риск возникновения непредвиденных ошибок, и другие разработчики так же быстро смогут понять, что возвращается на сервер и что с этим можно сделать.
Я тут тоже только недавно опубликовал заметку, которая как раз показывает какие трудности и настройки нужно контролировать, что бы тс выполнял то, что описано в данном разделе. Т.е. с одной стороны пример показательный, а с другой стороны не включит новичок strict или наоборот выключит его и бонусы тс уже будут не такими очевидными.
Поймите меня правильно, тс действительно нужен, но у него есть определенный порог вхождения. И познакомиться именно с этим порогом - это действительно путь к надежному программированию.
Когда нужен TypeScript: введение в мир надежного программирования