Как стать автором
Обновить

Комментарии 50

Я называю «жертвы фреймворков» тех, кто бросается в высокоуровневые инструменты, проигнорировав изучение основ. Сложение строк в JS — это такие азы, которые впитываются в подкорку через неделю практики, и забыть уже невозможно.
Это нельзя отнести к достоинствам языка, но строить всю аргументацию на такой малозначительной коллизии — смешно.
Сколько пафоса от специалиста по основам. А то, что в большом проекте, где голова забита другими сложностями, человек может элементарно ошибиться, нельзя понять?
Интересно, dom1n1k, имея в подкорке впитанные азы, вы не нуждаетесь в TypeScript? На чистом JS пишете? Наверняка нет. Добрее надо быть.
Конечно можно ошибиться, все мы люди. Но когда ошибка настолько элементарная, достаточно просто хмыкнуть «блин, точно» и продолжить. А не расписывать, что JS устроил «The Storm» и дал «strong reason» для перехода на TS. Автор либо делает из мухи слона, либо (если он не опечатался, а реально не знал) — жертва фреймворков. Мой комментарий был об авторе и его статье, а не о TS.
Да это же всего лишь статья. Мы даже не знаем, реальный ли это случай, или воображаемый. Возможно пример со сложением строк слишком тривиален. Но это не повод для уничижительных ярлыков. Все мы находимся на разных ступеньках на лестнице познания.
Нечего делать в большом проекте тому, кто даже не работал с типизированными языкми и не принял за привычку объявлять переменые и принудительно подтверждать типы.
Я осуждаю даже тех, кто работая с типизированным языком, отключает опцию IDE, требующую явных объявлений и типизации.

Преобразование типов, замену разделителей дробной части, локальной денежной единицы, просто должно врасти в организм на уровне инстинктов. И выбирать мертвый язык вместо развивающегося, именно из-за своей проблемы, а не проблемы языка — это моветон.

золотые слова

Чушь собачья в первом абзаце, простите. Люди делали много лет до появления TypeScript, делают и будут делать качественные продукты для веба на JavaScript. Если вы на постоянной основе успешно используете JavaScript, то должны были ощущать, что TypeScript — это никому не нужные оковы, которыми так нравится в последнее время увешивать как минимум фронт. Господа, никакие шестнадцатиэтажные конструкции с дюжинами треугольных скобок на фронте не упрощают жизнь, это вас кто-то обманул ). Имеющихся типов вполне достаточно, чтобы работать с любыми данными вашего апи, которое в принципе содержит в себе все структуры нужные вам. Единственный полезный момент для тайпскрипта видится в автоматичекой генерации типизированных обёрток для запросов, чтобы поудобнее было в ИДЕшечке. В остальном оно — лютый тормоз любого проекта )

Согласен, тоже смутило:


Эта ошибка какое-то время оставалась незамеченной, а позже довела нас до неприятностей.

Во первых, незнание основ. Во вторых, как без элементарной проверки и простого теста — прямо в работу? И в третьих — сразу переходим на другое и тоже без освоения основ и анализа? А если в TypeScript тоже вылезет специфичная проблема — то снова всё поменяем?
Лучше если проект в самом начале, то потратить немного больше времени на выбор фундамента проекта и когда обоснованный выбор сделан, еще немного на освоение основ этого фундамента, чтобы учесть его специфику, тогда в середине и на финише не будет разных сюпризов "вот этот ЯП нам всё поломал".

AsyncStorage позволяет хранить лишь строковые данные.

Так, а причём тут проблема JS, если изначально хранилище только для строк?
Тут проблема невнимательности разработчика.
Каким образом ЯП должен угадать намерение хранить числа в строковом типе?
Ровные пацаны хранят там JSON
Как хранение в JSON убережет от сложения строк?
Тем что в JSON будет записано число, а не строка. И обратно будет прочитано число.

Обратно из JSON будет прочитано any, которое надо еще как-то провалидировать перед кастованием типа. А этого уже Typescript из коробки не даёт.

Точно. А потом решили отрефакторить название переменной, и вот уже у Беспокойного Энди, который уже месяц медитирует каждый день стало nan сессий или undefined сессий… А у Нервного Джо, который скачал приложение только сегодня, все нормально работает. Разбирайтесь теперь с этим. И как там TS, сильно помог? До сих пор спокойно спится?
Если что, это не критика в сторону TS (обожаю его). Просто по статье так прямо он все проблемы решает и можно расслабиться…

Так это проблема js, почему он позволяет передавать строку в функцию которая ожидает только nunber?

Он-то позволяет передать что угодно, потому что функция не ожидает чего-то конкретного, у неё указания типов, как даже в PHP. Проверка через typeof и ожидаемый тип — это дополнительные условия, которые не добавили, и тут претензия не к языку, а к тому разработчику, кто знал про тип данных, основываясь на начальном значении, но не стал его сохранять и проверять.

А язык такой, какой есть, странно винить его за это.

Эм. По вашей логике язык C не виноват в том что в коде на С встречаются ошибки выхода за пределы массива? Тут претензия к разработчикам которые знают что у массива есть размер и за его пределы писать нельзя, нужно делать проверку через strlen или хранить размер массива в отдельной переменной.

"А язык такой, какой есть, странно винить его за это."

Все верно?

Полагаю, что да. Тут два варианта: или при разработке языка это зачем-то было нужно, или разработчик языка был настолько недалёким, что не предвидел такой вариант. И раз это не исправили в последующих стандартах, значит нужна обратная совместимость. Но совместимость с ошибкой вместо её исправления — это дурость. Получается, есть какие-то случаи, когда это не ошибка?
в чем виноват C?, в том что разраб «идиот»? тогда все яп виноваты что на них в том числе и не самые хорошие программисты пишут, ни когда не задумывался почему C до си пор жив, почему яп со слабой типизацией все еще востребован, может у него есть какая то ниша где именно такое его поведение оправдано и дает свои плюшки, или ты из тех у кого всегда кто то виноват, но только не ты
Каким образом ЯП должен угадать намерение хранить числа в строковом типе?

Type checker может дать по рукам, если вы будете обращаться со строкой как с числом. IDE может подсказать тип переменной, что также снизить вероятность ошибки.

я могу спать немного спокойнее, зная о том, что переменные в моём проекте не могут совершенно неожиданно менять свои типы.

Я вот не могу спать спокойно, потому что теперь у меня куча забот чтобы правильно все это хозяйство типизировать.
Когда сидишь и разбираешься, почему tsc выдает ошибку там, где все правильно и на js код в этом месте работает без проблем, иногда очень жалко времени.

Это время, которое вы потом сэкономите на отладке и поддержке.

И еще на документировании. Всякие массивы ключ — значение теперь описаны в виде типов. Очень удобно.

И на автокомплите. Вебшторм реально тащит в подсказках, когда TS.

Тестировать не пробовали?

Кроме того, вы сами преобразовывали число в строку перед помещением в хранилище. Что побудило вас не делать обратное преобразование?
Тестировать не пробовали?

Действительно, зачем полагаться на тайпчекер, если можно написать свой маленький частный случай тайпчекера самому?


Что побудило вас не делать обратное преобразование?

Забыли после рефакторинга. Или код по считыванию писал другой человек. Или просто не выспался и ошибся.

Рефакторинг — изменение кода с сохранением функциональности. Что поддерживается или тестами или инструментами для рефакторинга, следящими за сохранением функциональности.

Типизация — это форма авансового платежа. Вы платите заранее, не будучи уверенным пригодится вам или нет.

Тестирование — тоже плата вперед. Только все мы видели большие системы без типов, и никто не видел больших систем без тестов.

Только вот ROI у этих вещей сильно разный.


И потребные тесты в зависимости от типизации тоже сильно разные. Уверяю вас, что тесты в компиляторе ghc, написанном на хаскеле, отличаются по смыслу и целям от тестов для кода на JS. Или был у меня проект, немаленький — там тесты были только интеграционные, «на этом входе вся система даёт вот такой выход», и каждый раз после рефакторинга тесты были сразу зелёные, как только тайпчекер был доволен. Или вот другой мой проект сейчас — там тестов вообще нет, одни типы, но доверяю я ему куда больше, чем любому проекту с тестами, что я видел.

Так ведь фокус в том, что преобразование в строку частенько делает какая-нибудь библиотека, если не рантайм.

Скажите а как сейчас дела с типами? Нету рассинхрона между последними версиями библиотек и их типами?

Если тайпинги поставляются вместе с библиотекой — то откуда рассинхрону взяться? А вот если они внешние — то да, от рассинхронов не избавиться.

Говорят yarn-2 автоматически разруливает @types-зависимости.

Рассинхрон редко прям очень, но бывает что не сильно заморачиваются с дженериками и просто ставят any, скажем, как возможный ключ. Но тоже редко и обычно хорошо локализируется. Рассинхрон типов с бэкэндом более частая проблема, и для неё пока особо нет стандартного решения, хотя можно накрутить поверх свагера.

Swagger+io-ts. И будет вам счастье

Шедеврально конечно )))

Немного непонятно, зачем использовать ts в react. Как по мне, проще взять сразу angular, а когда предпочтительнее использовать react - оставить js. Может быть я не прав, но мне кажется, что лучше использовать языки в их родной среде(хоть ts и является по сути js,но все же)

Почему вы считаете, что Typescript для React не является "родной средой"? Вообще-то, поддержка Typescript в React является более полной, нежели в Ангуляре.

TS — это статический типизатор (static type checker) для JS, причем, далеко не первый и, возможно, не последний, поэтому правильнее говорить об использовании TS в дополнение к JS, а не вместо него. Плохое знание JS является недостатком разработчика, а не языка: const newSessionCount = +prev + 1 и проблема решена. Либо, если приходится часто работать с хранилищем, можно создать такую утилиту (на примере LocalStorage):
export const storage = ((s) => ({
  set: (key, value) => s.setItem(key, JSON.stringify(value)),
  get: (key) => JSON.parse(s.getItem(key)),
  key: (n) => s.key(n),
  remove: (key) => s.removeItem(key),
  clear: () => s.clear()
}))(window.localStorage)
К тому же, автор традиционно не перечислил в статье инструменты, которые необходимо установить для работы с TS.

Хотел упомянуть, что есть программисты разной квалификации и не всегда есть поставленный процесс отбора тех кто «привык не совершать ошибки». Даже обычный спеллчекер в ide уже отсекает определенное количество грамматических ошибок (которые имеют место быть). Если расценивать тс как спеллчекер для грамматики языка, то грех не пользоваться, даже если ты умеешь не совершать ошибки в js без надстроек.

Интересно, что в комментариях все-равно защищают типизацию is словами о том, что автор плохо знает язык и делает из мухи слона. Может автор и плохо знает, может и передергивает, но типизация то все-равно отвратительная, особенно все, что касается неявного приведения типов. И нет, это не проблема автора, это откровенно плохой изначальный дизайн языка, который сделали за неделю.

Думаю все таки нужно делать поправку, что это скриптовый язык, а они часто идут с приведением типов. Скорей для тех задач которые ставились перед языком в те годы он отлично подходил, но сейчас требования изменились.

Рассказ о том, почему в 2021 году лучше выбирать TypeScript, а не JavaScript

Так себе аргументация "за". Типа, в 2019 таких проблем не стояло?

Если человек не знает язык и пишет о его недостатках, то это плохая аргументация. Это как: не буду использовать английский, т. к. в нём нет падежей.

TS похож на C# что делает его более менее сносным на клиенте, но проблема в том что добавляется дополнительный шаг сборки, и теперь вместо нажатия зелёной кнопочки play в visual studio нужно запускать какие-то сборки и ждать дополнительного шага компиляции... гемор который не всегда стоит свеч

Погодите, а что случилось с зелёной кнопочкой в visual studio?

Когда речь заходит о фронтенде/реакт нейтиве то в 99% случаев транспиллинг уже используется, так что разница незаметна. А вот для маленьких проектов под node.js замечание справедливо.

Стартанули проект на тайпскрипте, до этого пять лет поддерживал проект на чистом js. Конечно тайпскрипт не решает проблему дизайна приложения, но значительно снижает человеческий фактор. Код минимум стал потдатлив к элементарному рефакторингу. В прошлом проекте браться рефакторить старую часть было почти что табу, потому как ничто не гарантировало минимальной работоспособности. Если можно снизить влияние человеческого фактора, то почему бы и нет?

Немного не в тему…
Для вычислений использую Big.js. Это конечно еще одна библиотека, но она дает понять при чтении кода «здесь что-то вычисляется» и строже в арифметических действиях, что лишний раз защищает от нелепых багов.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.