В общем, весь доклад можно свести к одной мысли - "Typescript не панацея, и не заменит ни юнит-тестирования, ни ревью кода." В общем-то, это и так было понятно. Но вот только не понятно одно: Как это должно говорить в пользу отказа от TS. О дальнейшем рефакторинге в докладе вообще ни слова. О временых затратах на всю цепочку QR\DR\CR также ни слова, хотя заставить команду с нуля заниматься этим на достойном уровне - Занятие довольно не быстрое. Единственная здравая мысль во всём этом - Это то, что нельзя условным TS покрыть все проблемные места. Но даже это выглядит так, как будто мы начинаем винить язык даже за архитектуру приложения, а не мясную прослойку между стулом и клавиатурой. Илья молодец, сколько времени уже прошло, а бесить не перестаёт.
TS - немного мерзок и ужасен. За все 16 лет своего скромного опыта я досих пор так и не понял от чего все так тащатся? Время разработки увеличенно, решение тривальных ошибок ценой удобства и гибкости... ахаха))) ну да ну да.
@@macgera хз что вы там разрабатывали, но в проектах средней сложности и выше тайпскрипт просто нереально спасает, особенно при рефакторинге, огромное количество ошибок отсекается тупо на этапе компиляции.
@@bobr3468 Много сложных проектов. Какие блин ошибки при каком блин рефакторе? :) В видео все довольно хорошо объяснили. Недавно работал над проектом, нужно было добавить фичеров, TS. Там файлы по 2000+ строк. Тайп скрипт не то что помог, там вообще что бы понять нужно было потратить уйму времени. Миф. Дурацкий миф - созданный Java разработчиками пришедшими во фронт по причине не хватки кадров во времена расцвета JS (когда он из странного и убого стал вдруг супер востребованным) и людей которые не понимает как он работает. TS избавляет от триваиальных ошибок, функция прими число верни булевое. Все. Генерики - это вообще ужас и что бы простые, иногда казалось бы, вещи имплементировать нужно 100500 доп. кода написать. Приславутые obj?.something работает коряво. Там все работает коряво. Если пишут глупо - то как не крути будет плохо, хоть TS хоть JS. Но даже Java приятнее чем TS для меня.
Нормальному, более менее опытному с TS разработчику, тайпскрипт никак не мешает и ничего не замедляет. А если даже не отлавливает все проблемы, то как минимум помогает с подсказами в IDE и защищает от глупых ошибок.
Перечитал научное исследование, которое приведено автором в докладе, и пришел к выводу, что автор извлек неправильные трактовки. 1. В докладе было сказано, что системы статической типизации помогаю предотвратить около 20% багов, но в научном исследовании сказано: "we found that using Flow or TypeScript could have prevented 15% of the public bugs for public projects". 2. Ошибки спецификации (SpecErrors) составляют 55%, а не 80%, и не от общего количества багов, а от количества багов, которые не отловила система статической типизации. А вот ошибки имплементации спецификации (как группа) действительно составляют 78%.
Илья рассуждает как физик из анекдота про сферического коня в вакууме. В машинах тоже совсем не нужны ни ремни безопасности, ни воздушные подушки, ни многомиллиардные исследования о том как сберечь жизнь людей на дорогах. Всё это можно сэкономить, если все будут ездить по правилам.
Заметил фактор который мог негативно повлиять на выводы из эксперимента. Разрабы изначально писали на тс а не на js. Т.е уход на js убрал тс из кода, но не полностью убрал его из головы разработчиков. Привычка следить за типами осталась. Т.е то что уход с ts на js не дал значительного ухудшения производительности, это еще не значит что переход с js на ts не даст значительного прироста после обучения. пс. тс мне тоже не особо нравится, просматривается вечная сырость продуктов майкрософта
Факты перечислены все верно, но выводы ошибочны :) Я вот тоже не люблю ТС, там иногда три раза три раза три раза одно и то же приходится писать, НО! Ценность ТС для коммьюнити неоценима. Типизированные библиотеки прям дважды ценнее нетипизированных. ТС подмял все, но за это у нас есть единообразие. Поэтому используйте ТС, переписывайте старые либы на ТС и своевременно обновляйте их. Только Open Source, только вместе мы сделаем что-то стоящее. И чем проще будет понимать чужой код и его использовать - тем лучше. А галеры пусть тонут :)
@@ni55an а потом при апгрейде версии весь код руками перелопатить на новые контракты. С тс при обновлении версии не скомпилится и укажет, где контракты не совпадают.
При всем уважении к Илье Но TS это всего лишь инструмент на котором проще и приятнее писать, особенно для людей пришедших из языков со строгой типизацией, хотя бы что-то Тесты это не про отлов багов, а про фиксацию поведения программы, а в большей степени про декомпозицию задачи на независимые модули, компонент, пакеты, юниты помогают разработчикам не писать откровенную ересь, это еще при условии что разработчик понимает что такое хорошие юнит тесты, часто бывает что лучше бы не было тестов совсем, чем такие как на проекте Для частоты эксперимента, нужно было еще создать одну группу которая никогда не писала на TS, а только на JS и посмотреть что получилось TS в большей степень еще про поддержку кода, чтобы снять когнитивную нагрузку с разработчика и чтобы когда разработчик использует код или редактирует, он понимал что функция требующая к примеру аргумент money это было число или строка и еще какой другой тип, а не прыгать между функциями и тестами
@@ni55an , я таке часто бачу коли вимагають якийсь високий відсоток по coverage - ну просто щоб "було як в кращих домах". Розробники звісно потім займаються тупим затиканням замість нормальних тестів. Ходя іноді краще було зовсім не написати ніякого тесту щоб місце в тому самому coverage поки явно не було зеленим.
Т.е. с нормальными практиками разработки "замедление" составило 6.4% (1.4 -> 1.31). Всего лишь 6%! И это на коротеньких проектах в ~4 месяца, где до серьезного рефакторинга ещё и не доходило. Дайте проектам пожить хотя бы годик и результаты будут совсем другие. Про юнит-тесты и рефакторинг. Юнит-тесты не дают такую же скорость рефакторинга как TS. С TS ты во время рефакторинга видишь места требующие правки *мгновенно* в IDE. С юнит-тестами - только спустя N минут, пока они отработают. И вот эти многократные ожидания тестов и просаживают скорость разработки очень сильно. Но доклад хороший - учит необходимости применять нормальные практики разработки. А выводы про typescript очень сомнительные :)
Вот, именно, TS направлен на помощь разработчику во время разработки. Но почему-то одни часто позиционируют его как инструмент для решения различных проблем касаемо качества и надежности, а другие делают доклады о том, почему он плохо решает эти проблемы, а потом в выводах человеческим языком для бизнеса говорят, что TS не выгодно использовать 😂
В контексте доклада code review, design review, TS и и.д это все инструменты для одной цели - успешного завершения проекта с минимальными затратами. В этом смысле, на мой взгляд, вполне уместно трактовать TS как один из элементов пазла, который можно убирать у некоторых команд при проведении исследования на производительность разработки.
А что делали команды на которых проводились исследования: 1) новый продукт с НУЛЯ или 2) поддержка/переписывание старого? У команды которая работала с проектом уже есть контракты и тонкости проекта "в голове", поэтому TypeScript будет менее профитный. А если это проект с нуля или у проекта новая комманда, то гипотетически TypeScript будет более профитный.
Как раз наоборот Новые проекты можно быстро написать на js, потому что пока пишешь новое, можно держать все в голове Потом, при последующем развитии проекта и поддержки, польза от TS максимальная - считай, это автоматические интеграционные тесты, тебе не нужно держать в голове все контракты
Снова натягивание совы на глобус. Взять TS, рассказать о проблемах, которые он плохо решает (хотя в принципе и не должен), это еще нужно постараться. В последующем сравнив теплое с мягким. Или я здесь один считаю, что TS это инструмент, который повышает качество работы программиста, а не продукта, над которым он работает?
К сожалению, Илья просто любит накидывать на вентилятор. Это фишка его докладов. Большинство опять восхитится и согласится, критическому анализу всей инфы, что предоставлена никто не будет.
Илье спасибо за доклад, как всегда очень интересно. Однако, по-моему, в экспериментах с командами кое-чего не хватало. А именно: после того, как проект написан - сменить разработчиков и отдать код на доработку другой команде. Очень было бы интересно узнать результаты такого эксперимента
где то в архивах MoscowJS есть выступление на счет TS. Так вот там было сказано что когда проект находится в фазе активной разработке то не надо применять TS, но как только жизнеспособность становится очевидной, то нужно сразу его подключать для его дальнейшего сопровождения.
Спасибо Илье за доклад. Очень классно демонстрируется значимость налаженных процессов в команде и что они (особенно тесты) выгодны бизнесу. Даже можно ссылаться на него в вопросах продвижения подобных идей в команду. Но критика тс - не убедила. Аргументы были больше против статической типизации, нежели против typescript.
На мой взгляд, основной промах в эксперименте в том, что все команды писали на максимально строгом TS. На определенном уровне строгости на TS становится писать очень утомительно: без any и с очень капризным линтером. Плюс, вопреки маркетинговой компании m$, я отказываюсь воспринимать TS как новый язык. Это по прежнему всё тот же js с прикрученной к нему типизацией, которой получается легко злоупотреблять.
Очевидно, что в TypeScript есть проблемы. Но сейчас же он же не только про статическую типизацию кода. В TS огромное количество деклараций типов (d.ts) на внешние библиотеки, супер поддержка от IDE (все подсказки, автовыводы типов), что сильно ускоряет разработку и улучшает DX
Краткая суть доклада: TypeScript не для галер, где платят за скорость разработки, а не качество кода и будущую долговременную поддержку/развитие проекта
Сразу видно, кто не смотрел доклад. Про долговременную поддержку/развитие проекта - это design-ревью и тесты. На Тайпскрипте точно так же бывает, что пишут неподдерживаемый говнокод.
@@levsonc Чтобы не было попо-боли при поддержки нетленок с внесением изменений, должна быть арихтектура, SOLID и далее по списку, и, естественно, типизация
@@levsonc Мы видим, что для зарабатывания бабла лабари даже не проверяют код джунов. Единственный критерий - наваять по быстрячку, а что будет потом с сопровождением, никого не волнует. С этим нужно тихо молчать в тряпочку и не отсвечивать с докладами
Spec review - это этап, когда бизнес-аналитики(в команде с разработчиками) общаются с продактами и выясняют точные технические требования для конкретной задачи (описание всех случаев использования, описание поведения системы при возникновении ошибок и т.д.). Spec review отвечает на вопрос "Что?" Design review - это когда все требования уже определены, разработчик взял задачу и решает как ее реализовать с архитектурной точки зрения(может быть задача потребует добавления новых сервисов/компонентов или рефакторинга существующих и т.д.). Design review отвечает на вопрос "Как?" Runtime контракты - это означает наличие кода, выполняющегося во "времени выполнения", который валидирует входящие данные перед тем как использовать их. Например ты принимаешь json от другого сервиса, ожидая что в нем будет поле username типа string. Вместо того, чтобы "верить", что тебе пришли верные данные, ты проверяешь, что структура совпадает с твоими ожиданиями и если она не совпадает - выкидываешь исключения или обрабатываешь ошибки.
Спасибо! как и все доклады Ильи - этот был хорош! Могу согласиться только с тем что TS замедляет тебя в работе особенно если все фалги строгости на максимум (работал уже с таким однажды) - писать приходиться много лишнего. Но с другой стороны, интерфейсы очень помогают. Особенно перед тем как написать часть программы; пишешь интерфейс и вы ревюите это командой. На данном этапе можно понять то ли это что нужно сейчас.
В Netflix 100% никто не пишет :) Но вообще я в своих проектах больше не буду использовать. Это настолько увеличивает время разработки, что смысла в нем нет чисто экономически.
к сожалению, я тоже со временем начал скептически относиться к инфе от Ильи, который просто находит какие-то холиварные темы, извращает факты и накидывает на вентилятор
@@StupidLova В полне. NodeJS хорошая игрушка, и к сожалению безальтернативаня сегодня в плане интсрументов для Frontdev (ну там сборщики разные и т.д.) но в качестве серверной части это ужас. Я работал и с Python и c Ruby и с приславутым Go, и даже с Java, прости господи. B все лучше NodeJS. А особенно в плане цены :) Хотя, конечно Java сегодня уже дороже, но такое...
Почитайте книгу по тс на офф сайте. Поизучайте его. Закидывать технологию только потому, что не получилось с первого раза взять нахрапом, это же не тру вей javascript мастера, так ведь?
"Все правильно. Имел опыт сравнения в деньгах покраски одного и того же деревянного забора с обработкой антисептиком и без, и повторюсь: больше обрабатывать антисептиком не буду"
![Маленький большой проект. С нуля в прод за 2 недели силами трёх фронтендеров. [ru] / Андрей Мелихов](http://i.ytimg.com/vi/1AOSKYPveyA/mqdefault.jpg)
![Маленький большой проект. С нуля в прод за 2 недели силами трёх фронтендеров. [ru] / Андрей Мелихов](/img/tr.png)
![Почему я отошел от TypeScript в своих React-проектах и куда [ru] / Илья Климов](http://i.ytimg.com/vi/jnSHRPCTFPc/mqdefault.jpg)
![Выкидываем ReactJS [ru] / Александр Соловьев](http://i.ytimg.com/vi/47q_yLxsfOU/mqdefault.jpg)
![F.HERO Ft. JSPKK x ลำไย ไหทองคำ x M-PEE - ไม่สนิทบิดหมด (Thai Riders Anthem) [Official MV]](http://i.ytimg.com/vi/kPJZ0UihBfk/mqdefault.jpg)
В общем, весь доклад можно свести к одной мысли - "Typescript не панацея, и не заменит ни юнит-тестирования, ни ревью кода."
В общем-то, это и так было понятно. Но вот только не понятно одно: Как это должно говорить в пользу отказа от TS. О дальнейшем рефакторинге в докладе вообще ни слова. О временых затратах на всю цепочку QR\DR\CR также ни слова, хотя заставить команду с нуля заниматься этим на достойном уровне - Занятие довольно не быстрое. Единственная здравая мысль во всём этом - Это то, что нельзя условным TS покрыть все проблемные места. Но даже это выглядит так, как будто мы начинаем винить язык даже за архитектуру приложения, а не мясную прослойку между стулом и клавиатурой.
Илья молодец, сколько времени уже прошло, а бесить не перестаёт.
TS - немного мерзок и ужасен. За все 16 лет своего скромного опыта я досих пор так и не понял от чего все так тащатся? Время разработки увеличенно, решение тривальных ошибок ценой удобства и гибкости... ахаха))) ну да ну да.
@@macgera Иногда тривиальные ошибки забирают больше всего времени при дебагинге
@@macgera хз что вы там разрабатывали, но в проектах средней сложности и выше тайпскрипт просто нереально спасает, особенно при рефакторинге, огромное количество ошибок отсекается тупо на этапе компиляции.
@@bobr3468 Много сложных проектов. Какие блин ошибки при каком блин рефакторе? :) В видео все довольно хорошо объяснили. Недавно работал над проектом, нужно было добавить фичеров, TS. Там файлы по 2000+ строк. Тайп скрипт не то что помог, там вообще что бы понять нужно было потратить уйму времени. Миф. Дурацкий миф - созданный Java разработчиками пришедшими во фронт по причине не хватки кадров во времена расцвета JS (когда он из странного и убого стал вдруг супер востребованным) и людей которые не понимает как он работает.
TS избавляет от триваиальных ошибок, функция прими число верни булевое. Все. Генерики - это вообще ужас и что бы простые, иногда казалось бы, вещи имплементировать нужно 100500 доп. кода написать. Приславутые obj?.something работает коряво. Там все работает коряво.
Если пишут глупо - то как не крути будет плохо, хоть TS хоть JS. Но даже Java приятнее чем TS для меня.
@@leetaipe Ну то есть люди дебажить не умеют? Не ясно куда смотреть? Иногда и с ТС не ясно откуда у бага ноги растут.
Нормальному, более менее опытному с TS разработчику, тайпскрипт никак не мешает и ничего не замедляет.
А если даже не отлавливает все проблемы, то как минимум помогает с подсказами в IDE и защищает от глупых ошибок.
Перечитал научное исследование, которое приведено автором в докладе, и пришел к выводу, что автор извлек неправильные трактовки.
1. В докладе было сказано, что системы статической типизации помогаю предотвратить около 20% багов, но в научном исследовании сказано: "we found that using Flow or TypeScript could have prevented 15% of the public bugs for public projects".
2. Ошибки спецификации (SpecErrors) составляют 55%, а не 80%, и не от общего количества багов, а от количества багов, которые не отловила система статической типизации. А вот ошибки имплементации спецификации (как группа) действительно составляют 78%.
Очень смело в качестве консультанта предлагать аутсорс-компаниям проводить эксперименты по отмене TS в некоторых командах, респект.
Илья рассуждает как физик из анекдота про сферического коня в вакууме. В машинах тоже совсем не нужны ни ремни безопасности, ни воздушные подушки, ни многомиллиардные исследования о том как сберечь жизнь людей на дорогах. Всё это можно сэкономить, если все будут ездить по правилам.
Почему все кто упоминает каргу-культ, они непременно ошибочно расскажут об первоисотчниках карго культа )
Это такой карго-культ. Они думают, что если повторять слова "карго-культ", то этого достаточно, чтобы рассказать о его смысле :)
Толковый доклад, есть о чем подумать. спасибо !
Прийти на конфу технарей, выбрать кликбейт название и сделать доклад для владельцев галер -- гениально.
Каннибализировал конфу :)
Заметил фактор который мог негативно повлиять на выводы из эксперимента. Разрабы изначально писали на тс а не на js. Т.е уход на js убрал тс из кода, но не полностью убрал его из головы разработчиков. Привычка следить за типами осталась. Т.е то что уход с ts на js не дал значительного ухудшения производительности, это еще не значит что переход с js на ts не даст значительного прироста после обучения. пс. тс мне тоже не особо нравится, просматривается вечная сырость продуктов майкрософта
Факты перечислены все верно, но выводы ошибочны :) Я вот тоже не люблю ТС, там иногда три раза три раза три раза одно и то же приходится писать, НО! Ценность ТС для коммьюнити неоценима. Типизированные библиотеки прям дважды ценнее нетипизированных. ТС подмял все, но за это у нас есть единообразие. Поэтому используйте ТС, переписывайте старые либы на ТС и своевременно обновляйте их. Только Open Source, только вместе мы сделаем что-то стоящее. И чем проще будет понимать чужой код и его использовать - тем лучше. А галеры пусть тонут :)
С чего это они ценнее?
Как-то ты заявления заявляешь, а ни фактов ни пруфов не даешь)
@@ROTOFFLOLKA что проще - получить доку не отходя от строки кода, или каждый раз свитчиться браузер, а потом на вкладку с документацией?
@@ni55an а потом при апгрейде версии весь код руками перелопатить на новые контракты. С тс при обновлении версии не скомпилится и укажет, где контракты не совпадают.
@@locSob +, в большинстве случаев да
При всем уважении к Илье
Но TS это всего лишь инструмент на котором проще и приятнее писать, особенно для людей пришедших из языков со строгой типизацией, хотя бы что-то
Тесты это не про отлов багов, а про фиксацию поведения программы, а в большей степени про декомпозицию задачи на независимые модули, компонент, пакеты, юниты помогают разработчикам не писать откровенную ересь, это еще при условии что разработчик понимает что такое хорошие юнит тесты, часто бывает что лучше бы не было тестов совсем, чем такие как на проекте
Для частоты эксперимента, нужно было еще создать одну группу которая никогда не писала на TS, а только на JS и посмотреть что получилось
TS в большей степень еще про поддержку кода, чтобы снять когнитивную нагрузку с разработчика и чтобы когда разработчик использует код или редактирует, он понимал что функция требующая к примеру аргумент money это было число или строка и еще какой другой тип, а не прыгать между функциями и тестами
про юнит тесты прям отдельная боль, когда пишут тесты ради тестов, чтобы code coverage показал все зеленым
@@ni55an , я таке часто бачу коли вимагають якийсь високий відсоток по coverage - ну просто щоб "було як в кращих домах".
Розробники звісно потім займаються тупим затиканням замість нормальних тестів.
Ходя іноді краще було зовсім не написати ніякого тесту щоб місце в тому самому coverage поки явно не було зеленим.
Т.е. с нормальными практиками разработки "замедление" составило 6.4% (1.4 -> 1.31). Всего лишь 6%! И это на коротеньких проектах в ~4 месяца, где до серьезного рефакторинга ещё и не доходило. Дайте проектам пожить хотя бы годик и результаты будут совсем другие.
Про юнит-тесты и рефакторинг. Юнит-тесты не дают такую же скорость рефакторинга как TS. С TS ты во время рефакторинга видишь места требующие правки *мгновенно* в IDE. С юнит-тестами - только спустя N минут, пока они отработают. И вот эти многократные ожидания тестов и просаживают скорость разработки очень сильно.
Но доклад хороший - учит необходимости применять нормальные практики разработки. А выводы про typescript очень сомнительные :)
Вот, именно, TS направлен на помощь разработчику во время разработки. Но почему-то одни часто позиционируют его как инструмент для решения различных проблем касаемо качества и надежности, а другие делают доклады о том, почему он плохо решает эти проблемы, а потом в выводах человеческим языком для бизнеса говорят, что TS не выгодно использовать 😂
Это если считать от операционной прибыли. А если от чистой?
Мне одному кажется, что сравнение ts и инженерных практик больше выглядит как сравнение горячего с мягким?
В контексте доклада code review, design review, TS и и.д это все инструменты для одной цели - успешного завершения проекта с минимальными затратами.
В этом смысле, на мой взгляд, вполне уместно трактовать TS как один из элементов пазла, который можно убирать у некоторых команд при проведении исследования на производительность разработки.
А что делали команды на которых проводились исследования: 1) новый продукт с НУЛЯ или 2) поддержка/переписывание старого?
У команды которая работала с проектом уже есть контракты и тонкости проекта "в голове", поэтому TypeScript будет менее профитный.
А если это проект с нуля или у проекта новая комманда, то гипотетически TypeScript будет более профитный.
Как раз наоборот
Новые проекты можно быстро написать на js, потому что пока пишешь новое, можно держать все в голове
Потом, при последующем развитии проекта и поддержки, польза от TS максимальная - считай, это автоматические интеграционные тесты, тебе не нужно держать в голове все контракты
Снова натягивание совы на глобус. Взять TS, рассказать о проблемах, которые он плохо решает (хотя в принципе и не должен), это еще нужно постараться. В последующем сравнив теплое с мягким.
Или я здесь один считаю, что TS это инструмент, который повышает качество работы программиста, а не продукта, над которым он работает?
К сожалению, Илья просто любит накидывать на вентилятор. Это фишка его докладов. Большинство опять восхитится и согласится, критическому анализу всей инфы, что предоставлена никто не будет.
Илье спасибо за доклад, как всегда очень интересно. Однако, по-моему, в экспериментах с командами кое-чего не хватало. А именно: после того, как проект написан - сменить разработчиков и отдать код на доработку другой команде. Очень было бы интересно узнать результаты такого эксперимента
вот там то и зарыта собака))
где то в архивах MoscowJS есть выступление на счет TS. Так вот там было сказано что когда проект находится в фазе активной разработке то не надо применять TS, но как только жизнеспособность становится очевидной, то нужно сразу его подключать для его дальнейшего сопровождения.
Выглядит так, будто Илья рисует с закрытыми глазами))))
Спасибо Илье за доклад.
Очень классно демонстрируется значимость налаженных процессов в команде и что они (особенно тесты) выгодны бизнесу. Даже можно ссылаться на него в вопросах продвижения подобных идей в команду.
Но критика тс - не убедила. Аргументы были больше против статической типизации, нежели против typescript.
Крутой доклад, прям на одном дыхании выслушал
Интересно, изменил ли Илья свое мнение касательно TS, спустя пару лет?
Классный доклад, но последний ответ всё убил. Оказывается, написать свой рантайм-TS дешевле и надёжней, чем взять готовый с тулингом. Ну-ну
На мой взгляд, основной промах в эксперименте в том, что все команды писали на максимально строгом TS. На определенном уровне строгости на TS становится писать очень утомительно: без any и с очень капризным линтером. Плюс, вопреки маркетинговой компании m$, я отказываюсь воспринимать TS как новый язык. Это по прежнему всё тот же js с прикрученной к нему типизацией, которой получается легко злоупотреблять.
Слежу за развитием js как за сериалом аля война престолов все время что-то появляется потом умирает😅😂🤣
Очевидно, что в TypeScript есть проблемы. Но сейчас же он же не только про статическую типизацию кода. В TS огромное количество деклараций типов (d.ts) на внешние библиотеки, супер поддержка от IDE (все подсказки, автовыводы типов), что сильно ускоряет разработку и улучшает DX
Краткая суть доклада: TypeScript не для галер, где платят за скорость разработки, а не качество кода и будущую долговременную поддержку/развитие проекта
Да, как объяснял разработчик ТS, основная причина его появления - на js можно напИсать, но невозможно поддерживать
Сразу видно, кто не смотрел доклад. Про долговременную поддержку/развитие проекта - это design-ревью и тесты. На Тайпскрипте точно так же бывает, что пишут неподдерживаемый говнокод.
@@levsonc Чтобы не было попо-боли при поддержки нетленок с внесением изменений, должна быть арихтектура, SOLID и далее по списку, и, естественно, типизация
@@СергейИванов-ы7ч5ы Как мы видим, когда всё есть, типизация уже не играет значимой роли (кроме увеличения времени на описание уже работающего кода).
@@levsonc Мы видим, что для зарабатывания бабла лабари даже не проверяют код джунов. Единственный критерий - наваять по быстрячку, а что будет потом с сопровождением, никого не волнует. С этим нужно тихо молчать в тряпочку и не отсвечивать с докладами
Огонь! Есть над чем подумать. Но все равно TS не брошу, потому что он хороший :)
Илья, а на каком транспилируемом языке вы сейчас пишете? elm, scala, kotlin,... ?
В другом докладе он упоминал ReScript
так то вообще он на flowjs пишет, и уроки по флоу у него есть на ютубе
голосовали те кто не юзают тайпскрипт :D
Спасибо. Отличный доклад, то о чем я думал Илья озвучил и подкрепил цифрами.
Благодарю за доклад. Прошу пояснить, что вкладывается в понятия spec review, design review, runtime контракты
Spec review - это этап, когда бизнес-аналитики(в команде с разработчиками) общаются с продактами и выясняют точные технические требования для конкретной задачи (описание всех случаев использования, описание поведения системы при возникновении ошибок и т.д.). Spec review отвечает на вопрос "Что?"
Design review - это когда все требования уже определены, разработчик взял задачу и решает как ее реализовать с архитектурной точки зрения(может быть задача потребует добавления новых сервисов/компонентов или рефакторинга существующих и т.д.). Design review отвечает на вопрос "Как?"
Runtime контракты - это означает наличие кода, выполняющегося во "времени выполнения", который валидирует входящие данные перед тем как использовать их. Например ты принимаешь json от другого сервиса, ожидая что в нем будет поле username типа string. Вместо того, чтобы "верить", что тебе пришли верные данные, ты проверяешь, что структура совпадает с твоими ожиданиями и если она не совпадает - выкидываешь исключения или обрабатываешь ошибки.
Илья, спасибо. Познавательно, но слишком много вопросов
Спасибо! как и все доклады Ильи - этот был хорош!
Могу согласиться только с тем что TS замедляет тебя в работе особенно если все фалги строгости на максимум (работал уже с таким однажды) - писать приходиться много лишнего.
Но с другой стороны, интерфейсы очень помогают. Особенно перед тем как написать часть программы; пишешь интерфейс и вы ревюите это командой. На данном этапе можно понять то ли это что нужно сейчас.
Тайпскрипт хорош на «длинной дистанции»
Подскажите, пожалуйста, запись дискуссионной зоны будет выложена в дальнейшем в общий доступ?
Нет, на то и дискуссионная зона :)
Оч круто. Но похоже это на донкихота воюещего с ветряной мельницей. Или на какого то условного рэмбо)
Слышал неоднократно что в США за ТС так же много топят, но там же процент продуктовок разительно выше, мб из-за этого
Очень интересный доклад, спасибо
Все верно, берите рескрипт))) потом переписывание его, когда его задеприкейтят )
Из дерьма при любых ухищрениях не получится конфеты. И дальше можно не слушать после фразы : Бодишопы и аутсорсеры не заинтересованы в качестве
Не могу вспомнить музыку на старте.
th-cam.com/video/B4dnPVZ2MV0/w-d-xo.html
не в, а у ))
спасибо за исследование, спасибо )
Как ты рисуешь на ноутбуке?
Thumb
Microsoft Whiteboard + планшет со стилусом
Тачскрин
Если не используешь TypeScript прямо - то используешь его косвенно.
Очень крутой доклад, спасибо
Дякую за контент, Іллю завжди цікаво слухати, але скоріше всього все не так однозначно.
В Netflix 100% никто не пишет :) Но вообще я в своих проектах больше не буду использовать. Это настолько увеличивает время разработки, что смысла в нем нет чисто экономически.
Да, плюс тайпскрипта, он официально дает работу для обалдуев ))
Ничего не понятно,но очень интересно.
Я человек простой вижу Илью ставлю дизлайк
в этом случае не прогадал
к сожалению, я тоже со временем начал скептически относиться к инфе от Ильи, который просто находит какие-то холиварные темы, извращает факты и накидывает на вентилятор
Лол, зашёл в документацию TypeScript через час после того, как выложили стрим и о чудо… есть документация для версии 4+…
Вы путаете документацию и спецификацию, это разные вещи
В спецификации целые разделы с «TODO». По большей части там пересказ частей JS с новым синтаксисом.
Оо как он пожирнел)
По поводу бэкэнда, если кто-то использует NodeJS для бэка, это страшный человек :)
Очень громкое неаргументированное заявление
@@StupidLova В полне. NodeJS хорошая игрушка, и к сожалению безальтернативаня сегодня в плане интсрументов для Frontdev (ну там сборщики разные и т.д.) но в качестве серверной части это ужас. Я работал и с Python и c Ruby и с приславутым Go, и даже с Java, прости господи. B все лучше NodeJS. А особенно в плане цены :) Хотя, конечно Java сегодня уже дороже, но такое...
@@StupidLova А какие собственно аргументы нужны? Собрать что-то на коленке, может и ок, а серьезные вещи... то цифры округляет само, то еще что.. :)
@@macgera ясненько. Спасибо за экспертное мнение.
@@StupidLova Какой вопрос, такой ответ. Покеда, супер эксперт ;)
Все правильно. Имел опыт сравнения в деньгах разработку одного и того же продукта с TS и без, и повторюсь: больше TS использовать не буду.
Почитайте книгу по тс на офф сайте. Поизучайте его. Закидывать технологию только потому, что не получилось с первого раза взять нахрапом, это же не тру вей javascript мастера, так ведь?
"Все правильно. Имел опыт сравнения в деньгах покраски одного и того же деревянного забора с обработкой антисептиком и без, и повторюсь: больше обрабатывать антисептиком не буду"
@@ievgenk.8991 ну как нахрапом, даже не помню сколько лет уже с ним работаю. В этом году решил прекратить. Так что все норм у меня с "тру вэй".
@@ni55an ой, простите сеньор разработчик! Куда там мне...
@@macgera вот именно 🤷