Я бы все же для любых проектов делал акцент на способностях и желании команды. Если есть команда и она знает TS, идите в TS даже с лендинг-пейджем. Если команда не знает ... -- то не идите в TS даже на большом проекте (да, есть достаточно большие проекты и без TS). Мой опыт: -- изначально писал на JS, (когда-то очень давно, еще в универе (1997-2002) бал C++ и Pascal) -- я попробовал Flow -- это было очень больно после JS. Это было в начале 2018 года, когда еще не было хуков в реакте, и я просто повис на типизации ХОКов и собственного редакс-тулкита на Flow -- так, что на статическую типизацию забил, и в последствие из проекта весь флоу выпилил. -- потом я обратил внимание на поддержку в VS Code всего кода, покрытого TS-типами -- это реально. очень удобно. Так, что весь переиспользуемый код стал дополнять .d.ts файлами, хоть сам код писался на TS. Казалось бы, что такое поддержка в IDE? ... А это Dev-Experience. С этим приятно и удобно работать. -- потом появились проекты на nextjs и graphQL. Фронт осложнился бэк-ендом, а именно сервер-сайд рендерингом. Попытки использовать "хитрую"-мемоизацию в замен привычных синглтонов - ES-модулей, вызвали жуткую боль. Особенно при написании тестов. Запахло необходимостью внедрение зависимостей (чтобы фейкать только одну непосредственную зависимость компонента без необходимости мокать кучу модулей и глобальные сущности). Так появилось много слабо зацепленного кода (без прямых импортов). А жить со слабым зацеплением без декларации типов данных -- это боль, да и DI становиться очень болезненным, т.к. ошибки неполного комплектования приложения (когда не все зависимости можно разрешить) отлавилваются только при очень тщательном интеграционном тестсировании (чего вообще хотелсь бы избежать на фронте). -- потом дело дошло и до использования бенефитов от GraphQL -- автогенерация типов и все результаты запросов уже типизированы, и даже без использования аполло или релей в реакте появляется замечательная фозможность проверить корректность отображения данных и вовремя обнаружить необходимость замапить результаты с сервера на данные для представления. -- когда бэк-енда стало заметно больше чем фронта, даже с учетом изоморфных проектов, то там слабое-зацепление стало абсолютной нормой, и как я уже говорил, без типов -- это неподдерживаемо (очень легко сделать ломающее изменение). В общем, на бэк-енде TS -- это уже очень и очень нужная штука. -- финальным выстрелом TS в JS стала обработка ошибок. На GraphQL-ном проекте понадобилось сделать механизм проверки корректности задекларированных возможных ошибок мутаций (т.е. что резолвер мутации никогда не вернет ошибку с кодом, которого нет в схеме), как минимум в момент сборки, а еще лучше сразу в IDE при написании кода. Здесь появляется монада Either (большое спасибо Дмитрию Махнёву и Артему Кобзарю). А вся эта "функциональщина" ... очень любит типы. На столько их любит, что 3/4 кода -- это типы и 1/4 реализация (на правах шутки, хотя если кому интересно -- то посмотрите как типизируется compose). Просто написать конвеер (pipe) в контексте трансформера TaskEither или ReaderTaskEither без поддержки в IDE -- может быть просто нереально. ----- Вместо резюме: Стоит задуматься о TS: 1. если много переиспользуемого кода 2. если много слабо-зацепленного кода (считайте весь бэк-енд и вся бизнес-логика фронта) 3. если хочется "удобно и приятно" 4. если хочется или уже нужно в ФП "по-серьезному" Но, как сказал вначале, главное -- это способности команды. Если может -- то Да, если не может -- то Нет.
@kronatankristof8804
2 жыл бұрын
для 80% проектов по факту не нужен. Увеличивает время разработки + если проект на начальном этапе и контракты меняются по 5 раз на дню, вы только и делаете что контракты меняете. И да, это очень невыгодно. Ибо если в каком-то малозначительном модуле поменялся контракт, то 5 разрабов, которым плевать на этот модуль не должны куковать. А потом окажется что там стринг поменяли на инт, при том что значение и так было числовое, т.е. для javascript это вообще не было проблемой или ошибкой изначально. Когда у вас какой-то проект, который надо быстро вывести на MVP. Недели за 2, например. То тут фанаты TS как правило жидко обделываются - уже несколько раз с этим сталкивался. Я не говорю что TS плох, но как и любой инструмент он должен быть к месту. Можно ли забить микроскопом гвоздь? Да вообще без проблем, только микроскоп дорогой, а молотком сподручнее. Если проект долгий, сроки тоже длинные, народу много и в особенности джунов - то тут можно брать TS без сомнений. Если время - деньги, проект выводится быстро, а пишут его профессионалы, которые не делают тупых ошибок (а если делают, то находят по щелчку пальцев), то тут TS это просто гири на ногах. Плюс фраза "TS выигрывает в долгую на поддержке" конечно имеет место быть. Только если у вас проект долгородящийся, то до поддержки вы может и не доживете вовсе. Профессиональные разработчики JS тупых косяков не делают, плюс где надо, они проверяют типы. TS это как распиаренная вафля про тесты. Давайте все тестами покрывать. Ну давайте! 90% этих тестов никогда не завалится, а 10% можно зафиксить априори, вместо того чтобы писать тупой тест. Те кто долго занимаются разработкой понимают, что всё это, простите, туфта. Подземный бункер на случай ядерной войны. Который стоит очень дорого, а вероятность его сбытия - около нулевая. Бункер вам вообще никак не поможет, но всем можно рассказывать что он у вас есть. По сути это попытка вылечить диарею, вызванную отравлением, парой рулонов туалетной бумаги. Уж простите за неаппетитное сравнение. Вместо того что не устраивать со своего проекта мусорник, где шляется кто попало и может писать любую дичь, которую никто почему-то не валидирует, может стоит не давать писать проект кому попало? А если уж у вас там проходной двор со свалкой, то TS конечно немного поможет, но вылечить этого пациента все равно не удастся. Он будет такой же больной, только обложенный рулонами туалетной бумаги на случай "если рванет".
@АлексейЛоктев-и3я
2 жыл бұрын
Братух, тыщу лайков тебе, но этот ролик для мальчиков и девочек, которые пробуют себя в разработке, хотят куда-то устроится ну и далее по тексту. Касаемо mvp, то диды эти штуки раньше делали в лиспах обычно. Типа запускаем репл и не глушим его пока всё не заработает. Лиспы сейчас у когнитека самые мощные (умные). Как ты наверное догадался я об clojurescript. Что мне нравится там: 1. Скорость разработки. Ну тут я думаю понятно, не выходя из репла решаем все задачи, ленимся до такой степени, что терять на компиляции доли секунд уже кажется великим злом, ощущения как во время полёта, не с чем сравнить, это надо попробовать 2 Under the hood: google closure + closure compiler + лучший interop в истории + immutable by default + Вся (!) clojure либа 3 Абрамов долго дрочил на reagent и наконец-таки ввёл хуки (в clojurescript они называются атомы), ну там отдельная хохма 4 Самое проодвинутое fp на данный момент + пожалуй самое отзывчивое комьюнити итд итп Теперь что касаемо ts. Братух, если сейчас выйти из комы в связи с известными событиями, то можно достаточно явно увидеть несколько слегка непонятных на первый взгляд выражений - "edge computing", "safe threading", "wasm", "wasi". Да, я говорю о rust, как ты уже понял :) Др. словами, а на кой чёрт мне это это ваше микрософтовское г-но, если мы уже в другом мире живем. У нас сейчас по всем основным браузерам wasm даёт threadinig + atomics, они готовы (!). Ещё раз, браузеры готовы, иосы-дроиды готовы к этому по дефолту, кушай ядра не обляпайся:) Я оставлю вот эту ссылку, надеюсь тебе это поможет посмотреть на вещи под другим углом: kerkour.com/rust-functional-programming Спасибо за твой комментариий и удачи тебе!:))
@БатырбекАйгалиев
4 жыл бұрын
Спасибо за видео! Давно ждал от вас тему про TypeScript
@-X-Ray-
4 жыл бұрын
Спасибо за видео)
@Programarium_academy
3 жыл бұрын
Спасибо за видео!) Не вижу проблем использовать TS во всех проектах. Даже маленький проект с простой логикой может вырасти со временем и прикручивать TS потом дороже чем использовать его с самого начала. Да и не так дорого это стоит))
@АлексейЛоскутников-ю4р
3 жыл бұрын
Спасибо за интересные размышления.
@egorovsa
Жыл бұрын
Пишу СиШарп и Пхп, писал на ЖС раньше много много. Только ТС. Идет 23-ий год и ТС еще более мастхев!
@den-rad
Жыл бұрын
Сейчас PHP поддерживает типизированые поля и параметры, и это чертовски удобно! Я двумя руками за TS, но иногда в его типах черт голову сломит.
@yozheeg
3 жыл бұрын
Не понял про модули. Зачем нужна типизация, если поле size вообще убрали? Оно будет отсутствовать при любой типизации.
@it-sin9k
3 жыл бұрын
Часто в проектах делают перед коммитом проверку типов в проекте. И если ты обновил версии либ в package.json. И там пропало поле size, а появилось свойства width, height. Соответственно типизация не даст вам закомитить пока вы не начнете передавать width, height вместо size. Т.е. типизация помогает найти места ошибок автоматически, а не когда уже QA команда нашла баг после обновления версии библиотек
@yozheeg
3 жыл бұрын
@@it-sin9k спасибо, понял
@vladserhiychuk8925
2 жыл бұрын
Thx
@Retruntobase
3 жыл бұрын
Мне в тайпскрипт нравятся только автоимпорты и автодополнения
@ВладиславК-п6э
2 жыл бұрын
В JS тоже можно импортировать cntr +пробел, в VS коде так
@Retruntobase
2 жыл бұрын
@@ВладиславК-п6э это немного другое
@kasepr1678
Жыл бұрын
я работаю не на продакшен, а в одной энергетической компании в Сибири и иногда я возрощаюсь к проекту для добовление какой то маленькой фигни пятелетней давности и как раз если бы не типизация я бы оооочень долго разбирался какую херню я там написал. я всегда удивляюсь своим проектам через года два три, как я такую хрень мог написать но типизация мне подсказывает что я хотел сделать. но может у других по другому, я еще тот программист)))) Я к чему когда полностью типизируешь редакс хоть какой ты был долбоеб года два назад, ты все равно сразу быстро понимаешь что ты тогда хотел.
@it-sin9k
Жыл бұрын
Спасибо что поделились своей историей)
@fl1pp1x
3 жыл бұрын
Typescript как раз таки помогает когда много людей на проекте, и тебе надо сделать какой-то кусок работы затрагивая часть существующего функционала, с тс это будет намного быстрее.
@WebBestMaster
2 жыл бұрын
> когда много людей на проекте то есть - всегда)
@alexblack43
Жыл бұрын
@@WebBestMaster смотря какие у вас проекты. Если упомянутые лендинги и магазинчики букетов, то много людей там не будет никогда.
@DubinArtur
Жыл бұрын
Если после JS лень учить TS, то в разработке вообще нечего делать.
@fz7429
2 жыл бұрын
Попробуйте написать deep merge с неограниченным количеством объектов и вам сразу станет понятно на сколько тайпскрипт лишний оверхед для проекта... Для простых вещей подходит для чего то сложного и динамического это сущий ад. Нужна документация юзайте jsdoc. Чтобы не было ошибок пишите тесты, а если писать говнокод то и тайпскрипт не поможет
@BOCbMOU
Жыл бұрын
Тип для дип мерджа делается на раз-два. ТС - это сущей ад, если ты его не знаешь и не хочешь знать.
@azamatk4302
Жыл бұрын
NPM пакеты с бизнес логикой? =) Любой архитектор скажет, на фронте не должна быть никакая бизнес логика.
@it-sin9k
Жыл бұрын
Вероятно у нас дисонанс, в том что именно подразумевается под фразой: "бизнес логика" :)
@Shad0w5m00h
2 жыл бұрын
Холиварная тема, конечно) Я считаю, что тс поможет, если: 1) контракты постоянно меняются. Тогда типизация нам подскажет, где надо бы изменить части. Специнтерфейс чисто для данных с сервера уже ни раз выручил 2) нужен рефактор кода. Разбиваем на более мелкие сущности и не нужно в голове держать, чего не хватает или что где потерялось 3) нужно удобство перебора массивов ФП методами, получаем подсказки. 4) глупые ошибки не нужны в проде. Билд будет обваливаться. 5) нужно поддерживать код, через некоторое время будет чуть легче вспомнить какие данные передаются/отправляются в коде благодаря соответствующим описаниям заранее Жирный минус: при отсутствии опыта ТС будет большим замедлением. Что, в общем-то, логично. Несмотря ни на что, тс требует особого мышления, которое развивается лишь некоторое время спустя.
@АлександрБадаландабад
3 жыл бұрын
Я так и вижу как сидит ИТ-отдел в банке: - Так, давайте подумаем систему типов - Да ну нахер, отловим ошибки в рантайме - точно, так и поступи ))
@it-sin9k
3 жыл бұрын
Думаю и такое бывает) Вы еще оставляли комментарий про z-index. Но удалили или не прошли проверки от youtube. Я открыл ссылку, что вы бросали, если вы откроете инспектор браузера и посмотрите на html структуру, то увидите, что этот эмулятор браузера, по другому расставил дивы это то почему я тестирую такие вещи только в реальном браузере. Хотя были предложения демки выкидывать в sandbox
@АлександрБадаландабад
3 жыл бұрын
@@it-sin9k Благодарю за ответ. Все верно, был вопрос по z-index. Я тысячекратно ) извиняюсь, но то ли я дурак, то ли лыжи не едут. Проверил в браузере и вопрос остался открытым: первый и второй кейс дают одинаковый результат (снизу красный, потом синий, сверху зеленый), трений даёт снизу красный, потом зеленый, и поверх синий, что не соответствует утверждаемому в видео ( Chrome 90
@it-sin9k
3 жыл бұрын
хмм, странно. Я все вроде проверял, прежде чем опубликовать. Выложите на github pages или еще на каком хостинге рядом 3 варианта. Посмотрим, что там не так
@АлександрБадаландабад
3 жыл бұрын
@@it-sin9k Пардон, только сейчас руки дошли. Вот, собственно, пациент lllep6ajlb.github.io/html-z_index-check/
@NoName-zh7cc
2 жыл бұрын
Я за ТС, мне реально помогает
@alexblack43
Жыл бұрын
В примере с магазином стройматериалов корень ошибок всё-таки не в типах, а в том, что одни разработчики меняют свой код не предупреждая других и не думая о последствиях. Если допустим ширина и длина была в сантиметрах, а завтра решили перейти на другие рынки и измерять их в дюймах. Тип не поменялся, те же number, тайпскрипт не спас нас от ошибок. Вообще тайпскрипт может помочь избегать только ошибок, связанных с типами, а это не самые частые и не самые сложные в обнаружении ошибки.
@parada1se
Жыл бұрын
дружище, зачем ты делаешь этот мерзкий акцент, при произношении английских слов, что бы казаться носителем или что? слышытся не очень, эти слова уже давно адаптированы под наш язык
@tingol_
2 жыл бұрын
Тут все гаразда проще. Приведу простой пример с туалетной бумагой. Да, жизненной необходимости нет, можно продолжать использовать лапух или палец.
@mikesummer670
2 жыл бұрын
А если штаны не снимать то можно и о лопухе с пальцем не беспокоиться. Не понимаю зачем вообще время тратить на снятие штанов когда можно на ходу все дела сделать
@artjomsfomenko757
Жыл бұрын
Это надо в золотую рамку. Этот коментарий ставит точку на всех подобных видео
@artishoo
2 жыл бұрын
Всё решается количеством говнокода. Типы могут быть удобными, но статическая типизация на высокоуровневых языках не то чтоб нужна. Тем более проверки на рантайме
@notrlt
Жыл бұрын
давно уже существует JSDoc
@khmerhan2748
Жыл бұрын
не понимаю, у кого может быть проблема в описании типов? Кто вообще выдумал, что описание тпов данных замедляет написание кода?
@it-sin9k
Жыл бұрын
я видел неоднократные проблемы с описанием типов) Например у людей часто ломается мозг при создании и редактировании чего то. Когда у одного есть id поле обязательное, а у второго его не должно быть. А на стороне бэка еще добавляются дата создания и так далее, и тут людей часто ломает, а как это все правильно описать
@grantorino3465
2 жыл бұрын
помимо TS можно же еще flow использовать
@it-sin9k
2 жыл бұрын
Мне кажется уже закат flow. Они даже отказались от open source насколько я помню. Поэтому очень рискованно использовать flow)
@kyzinatra6391
Жыл бұрын
Ну хз как по мне очень удобен ts. Хоть мой 1 язык и был js, а только потом c++. Я очень люблю typescript. Он помогает мне писать гораздо быстрее и удобнее. Он просто очень удобен. Он не такой сложный, чтобы говорить о том, что он сложный. По факту для меня сейчас это самый лучший вариант и на ваниле я уже почти не пишу
@404piano
3 жыл бұрын
по фактам объяснил :)
@zakiro4277
2 жыл бұрын
лучшее видео по данной теме на ру спасибо большое!
@it-sin9k
2 жыл бұрын
ого) спасибо)
@tih_on8815
Жыл бұрын
Интересен тот факт что когда вы привыкли к строгой типизации т.п. Потом пришли на проект где ее нет, вы будет полный ноль в них. Так как привыкли что за вас думает система можно ли писать тот или иной код. Забудете про try catch и другие приемы отлавливать ошибки, а зачем если есть типизация и она зарешает. Не помню чья цитата, она звучит так: "Чем проще интерфейс тем тупее пользователь" .
@alexperemey6046
Жыл бұрын
Typescript не нужен, если Вы не собираетесь отлаживать Ваш проект. Во всех остальных случаях он нужен
@romanmed9035
2 жыл бұрын
прошло 2 года и как бы оно ни было, сейчас как и ранее на классы, чуть ли не молятся на этот тс. но уже давно снова переходят на функции.
@dmitrysvetlov6001
Жыл бұрын
Коммент для продвижения канала. Спасибо за видео.
@ilikecola378
2 жыл бұрын
На 7:19 в качестве примера лэндинга сайт на тильда, понятно что пример про лэндинг пэйж но всетаки немного странно. Или я не знал что в конструкторе тильда можно использовать react для верстки простого лэндинга. Спасибо за видео
@petraveryanov2572
2 жыл бұрын
Очень странное видео. - Прототип и простенький сайт можно на*реначить на чем угодно -- чего это рассусоливать? И разница там просто в опыте работы - я на angularjs bootstrap и на Angular Material напишу его примерно с одной скоростью. - Ни слова о том, что типизация помогает в написании кода, тем что IDE даёт подсказки. - Типизация в общем не связана с интерфейсами -- в том смысле, что может быть полная типизация без интерфейсов вообще. - Если при получении данных с backend-а вы сразу их трансформируете в другие, то писать отдельные типы для BE не надо. (Если не автоматизирована их создание из скажем java dto или если вы не настроили typescript совсем на жёсткие правила) Да и вообще никто не заставляет типизировать всё и вся. - Поддержка типизации это что-то вообще для меня непонятное. Если у меня классы и типы с полями -- что тут поддерживать.
@StepanChuevYT
2 жыл бұрын
+
@alexup7437
3 жыл бұрын
Изучал тс параллельно с реактом , не так уж и много нужно времени на тс, но это опыт в основном на хуках. С классами там конечно помудрёней
@17u5h
Жыл бұрын
круто! спасибо!
@011101010101001
2 жыл бұрын
Отличное видео, спасибо
@Virass
2 жыл бұрын
Вооооот оно что Петрович. Наконец то, кто то показал и рассказал зачем эта типизация и тайпскрипт нужны. До этого я просто часто слышал отговорку - тайпскрипт сейчас весь энтерпрайз использует потому учи. Как же мне он тяжко давался именно из-за отсутствия понимания зачем он нужен и зачем так усложнять разработку.
@stan_yolo
3 жыл бұрын
сразу пурскрипт
@ДаниярКаби
2 жыл бұрын
Спасибо большое за познавательное видео 👍👍👍
@Napolion4ik
2 жыл бұрын
Не плохо было если бы вы россказали все тонкости TypeScript, я думаю всем будем интересно, а этих важных "тонкостей" много
@it-sin9k
2 жыл бұрын
А можете привести пример тонкостей в ТС, чтобы наши с вашими ожиданиями совпдали)
@АлексейЛоктев-и3я
2 жыл бұрын
мммм, purescipt, не?
@konstantinsurnin855
2 жыл бұрын
зачем нам флекс, и на флоатах верслается нормально)
@it-sin9k
2 жыл бұрын
я пдф недавно верстал на CSS 2.1. Пришлось флоуты вспомнить, ну такое себе))
@konstantinsurnin855
2 жыл бұрын
@@it-sin9k это какой-то особы вид извращения штоле в 2021?))
@it-sin9k
2 жыл бұрын
Это бэкэндщики сэкономили) взяли бесплатный инструмент для генерации pdf, а у нее оказалось ограничение в версии CSS)
@dmitryvab7191
2 жыл бұрын
@@konstantinsurnin855 а как же верстка писем) вот там вообще весело, табличная верстка - жёсткий хардкор)
@konstantinsurnin855
2 жыл бұрын
@@dmitryvab7191 я лишён такого удовольствия на работе))
@vanmihaylovich
Жыл бұрын
1:40 статическую типизацию можно обеспечить правилом не менять тип переменных после их инициализации, как и использовать служебное const для переменных.
@Watozarato
Жыл бұрын
Мне больше другое интересно: обязательно ли было создавать новый язык, вместо создания какого-нибудь consttype
@efim.andrii
2 жыл бұрын
Хорошее видео
@alexfador
2 жыл бұрын
Отличный разбор, без лишней воды. Очень круто, что применение ts/js рассмотрено в нескольких кейсах с их плюсами и минусами! От себя добавлю, что ts помогает не только мыслить интерфейсами, но и принципами ООП. Особенно круто сочетать сторы и di контейнеры. Так, в рабочем проекте у нас используется mobX, как инструмент создания сторов под конкретные разделы вместе с Inversify. Это дает возможность не городить в реакте лишние useState'ы, а инкапсулировать всю нужную логику в специальном сторе. + очень удобно такие сторы покрывать тестами. + можно юзать кучу других паттернов: builder, decorator, adaptor, etc.
@it-sin9k
2 жыл бұрын
маленький вопрос, а как вы нашли это видео?) потому что сегодня у этого видео прям небольшой всплеск по просмотрам)
@alexfador
2 жыл бұрын
@@it-sin9k да в ленте просто появилось) я сам только под конец видео понял, что видео уже не новинка. Возможно, какой-то алгоритм от гугла😁
@it-sin9k
2 жыл бұрын
Спасибо гуглу за его старания))
@alexfador
2 жыл бұрын
@@it-sin9k а тебе спасибо за твои старания👍
@KamilSadekov-q8s
3 жыл бұрын
Спасибо за полезный контент
@jgkdmdevienjjgg8866
2 жыл бұрын
По поводу изучения тайпскрипта - на начальных порах достаточно изучить описание интерефейса, enum и оператор |. Не так там и много, а пропсы в реакт компонентах будут понятными
@ihorpoplawskyi4099
2 жыл бұрын
не забывайте про редакс, там уйма уловок, при чем некоторые фичи меняются и то, что работало 3 месяца назад сейчас может не работать
@MrSmit-jg6ex
Жыл бұрын
@@ihorpoplawskyi4099 забыл и вам советую
@vr4836
2 жыл бұрын
Подписка!
@it-sin9k
2 жыл бұрын
Добро пожаловать!
@GrOm_SG
3 жыл бұрын
Спасибо, подписался.
@it-sin9k
3 жыл бұрын
Добро пожаловать!)
@xcaelestisox7074
2 жыл бұрын
4:00. С этого момента держал свой "аргумент". Я TypeScript по факту боготворю, но аргументов у меня нет). Мне с ним просто удобнее и спокойнее. Для меня JS и TS - не конкуренты, а аналоги. Каждый просто выбирает что ему по вкусу, и всё.
@AlexanderBorshak
3 жыл бұрын
И то правда, в сад этот Тайскрипт! И все тесты тоже - зачем на них тратить время, если можно словить все ошибки в рантайме? Срочно пересматриваю все видео канала, надеюсь почерпнуть еще премудростей и стать таки синьйором! )))
@suslikest3708
3 жыл бұрын
Судя по вакансиям стоит учить, а лучший способ учить это писать код так что по крайней мере на период изучения до уверенного уровня лучше все начать писать на тс))
@olezhonnv3215
2 жыл бұрын
Пишу код по работе на С, PHP, Java, JavaScript. К статической типизации отношусь с уважением. Но TypeScript - он как Windows - маст дай! Было б неплохо нативный тайпинг в JS добавить. Опционально, как на флеше, в ActionScript 3 было. И по проще надо. Они в тайпскрипте капитально заоверинженерили те типы, возможности конструировать типы из типов на типах, и все это приправлено дженериками и декораторами. Ну это на мой взгляд. Эта переизбыточность может привести к тому, что само описание типов в большом проекте разрастется и кратно увеличит сложность кода, что ухудшит его читаемость и понимаемость. Много зависит еще и от писателя.
@it-sin9k
2 жыл бұрын
Я поддерживаю про оверинженеринг) ко по мне тоже сложновато они напилили)
@MfeaR113
2 жыл бұрын
Есть еще JSDoc, отличная штука которая позволяет описать только то что нужно. Например ответы с сервера. А еще в последних версиях популярных редакторов появилась поддержка импорта из TS файла. То есть можно описать все интерфейсы на TypeScrip, а потом через JSDoc импортировать это в JS файлы.
@it-sin9k
2 жыл бұрын
Прикольно :) Но к сожалению не было ни в одном проекте JSDoc :(
@pu4u
2 жыл бұрын
как обычно совершенно не экспертное мнение на хайповую тему.
@it-sin9k
2 жыл бұрын
как обычно)
@aleksprimetv
2 жыл бұрын
тс суррогатный язык отомрет как кофескрипт, большая часть ошибок не из-за типов, нужно писать тесты.
@edocra
3 жыл бұрын
Typescript eto polnaya huyna.
@olezhonnv3215
2 жыл бұрын
Если реально цена ошибки высока - однозначно, должна быть статическая типизация и тесты. Условное "падение самолета" в рантайме не отловишь, чтоб пофиксить по шурику! ТайпСкрипт - в целом нормальный инструмент. Но, правда, они перемудрили по возможностям. Это ведет к потенциальным ошибкам уже в описании самих типов, что в конечном итоге приведет к тем же ошибкам JS, с которыми призван бороться ТайпСкрипт.
Пікірлер: 102