В чем преимущества TS?

Question

[Spaceoddity]

И в целом, не надумана ли проблема "динамической типизации"?
Объясню своё видение (почему не нужна строгая типизация в вебе).
Обычно всегда кивают на какие-то пресловутые ошибки из-за несовпадения типов данных и якобы более простой дебаг.
Во-первых, откуда вдруг на клиенте должны появиться огромные объёмы данных, которые будут генерировать эти ошибки и затруднять их поиск? Вы собрались логику на клиенте считать? Тогда у нас уже тут принципиальное несовпадение по вопросам "соответствующих инструментов". Клиент в вебе нужен только для представления. Ну ещё какой-то интерактив - формы, события... Всё. Объём данных тут относительно небольшой. Зато большой зоопарк их типов. Ты заранее не можешь быть уверен какой тип тебе прилетит из пользовательской формы. Поэтому по дефолту большинство данных и так надо самостоятельно приводить к необходимому типу. А ещё динамическая типизация сильно экономит время на написание кода - это очень нехилая оптимизация рабочего процесса.
И вот хотелось бы реальных примеров из практики о том, как был нужен TS.
Я в свою очередь могу рассказать о своём опыте - когда как мартышка ковыряешься с проставлением типов (а иногда это и не особо очевидно), а потом оказывается что какой-нибудь популярный плагин (условный слайдер) в твоей экосистеме - не типизирован. Ручками писать? Потрошить внутренности плагина? Искать аналог? Бац, а оказывается львиная часть плагинов экосистемы написана на ES6... А главное - преимущества-то в чём?

Или это "системщики" ломанулись в веб и начали наводить тут свои порядки? Вместо того чтобы выбрать наиболее подходящий ЯП из уже существующих - придумывают каких-то кадавров...

Answer 1

[Алексей Ярков]

Во-первых, откуда вдруг на клиенте должны появиться огромные объёмы данных, которые будут генерировать эти ошибки и затруднять их поиск? Вы собрались логику на клиенте считать? Тогда у нас уже тут принципиальное несовпадение по вопросам "соответствующих инструментов". Клиент в вебе нужен только для представления. Ну ещё какой-то интерактив - формы, события... Всё.

Как там в 2010?

как мартышка ковыряешься с проставлением типов (а иногда это и не особо очевидно), а потом оказывается что какой-нибудь популярный плагин (условный слайдер) в твоей экосистеме - не типизирован. Ручками писать? Потрошить внутренности плагина? Искать аналог?

Это уж как вам удобно. Вам в большинстве случаев понадобится типизировать от стороннего плагина несколько, а то и один метод и пару аргументов. Не хотите ручками? Идём на https://www.typescriptlang.org/dt/search/ и ищем готовое. А в большинстве случаев достаточно создать файлик типа modules.d.ts и там прописать строчку declare module 'ldapjs-type-parsers';, где подставить имя пакета, для которого нет типов.

Вопрос звучит как "уговорите меня использовать TypeScript". В общем вас никто не заставляет. Если лично вам неудобно, то пишите на JS.
P.S. Я уже молчу про удобство рефакторинга ))

Comments

[Alexandroppolus]

2010

Надо заметить, что в 2010 году озвученное автором мнение о роли и размерах фронта уже было устаревшим.

[Spaceoddity]

Как там в 2010?

Как там массовый китайский андроид с гигабайтом оперативы на борту?

Ну и в очередной раз подчеркну - можно примеров на пальцах? Вот что такое "удобство рефакторинга"? После TS надо рефакторить?

[WbICHA]

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

[Дмитрий]

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

Так же в больших проектах много разработчиков, и типизация + линтер позволяет еще на этапе коммита снять какую то долю косяков.

А примеры на пальцах вам какие? Команда Ц тратит на разработку функционала в тайпскрипт 10 минут на фичу, а команда Б в чистом джс - 2 дня?

[Yagher]

Дмитрий, а если поменять команды местами?

[Дмитрий]

Yagher, будет 2 дня нытья у тех и у других?

[Yagher]

Дмитрий, если так, то нужно будет обратиться к команде А.

Answer 2

[Aetae]

А ещё динамическая типизация сильно экономит время на написание кода - это очень нехилая оптимизация рабочего процесса.

Это утверждение верно относительно языков с изначально статической типизацией против языков с динамической, но не верно для TS как такового. Если не использовать маньячные правила типа обязательного ручного проставления типов, то в 80% случаев TS сам прекрасно выводит тип, без лишних телодвижений.
Огромное ускорение от типизированого автокомплита в IDE и отсутствия возможности, например, случайно кинуть в функцию объект вместо строки, с лихвой перекрывает оставшиеся 20%.
Редкие случаи когда TS писал мне "какую-то хрень" и отказывался что-то делать, заставляя сидеть и разбираться - на поверку оказывались сильно неочевидными косяками в моём коде, которые могли бы привести к реальным багам.

Answer 3

[Сергей Горностаев]

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

Comments

[Spaceoddity]

Я просил конкретных примеров, а не вот этой пафосной абстракции. На больших проектах что - киш-миш с организацией кода? Тогда дело вовсе не в типизации.

[Vamp]

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