Comments 49
После TypeScript возвращаться на проект с чистым JS прям совсем не хочется, ощущение что в блокнот вернулся. Ну и конечно с Coffee Script его сравнивать совсем не уместно.
Развейте мысль, пожалуйста.
TypeScript обеспечивает статическую типизацию и полную совместимость с JavaScript, в то время как CoffeeScript ориентирован на уменьшение количества кода и улучшение его читаемости.
нет, я имел в виду про то, что так понравилось в TS, что к JS обратно не захотелось
TypeScript обеспечивает статическую типизацию
и этим всё сказано)))
Сколько человек в твоей команде и какого размера проект? Насколько критично чтобы не падал прод из-за "Can't get property X of undefined"? Приходилось ли писать тесты на отлавливание возможных undefined в коде? Приходилось ли на ревью пропускать ошибки такого типа? Приходилось ли лезть разбираться в какой-то кусок логики с мыслью "Что за хрень этот код пытается сделать? А какие аргументы должна принимать эта функция? А точно только с такими её вызывают или кто-то особо одаренный поменял внутреннюю логику, но не прошёлся по местам использования?"
И вот об этих вопросах на 98% можно забыть с TS - этим он оправдывает свою избыточность. Остальные 2% Это случаи возвращения к "заветам предков", т.е. наплевательства на type safety.
При использовании Typescript в IDE начинают нормально работать контекстные подсказки, позволяющие, к примеру, писать только несколько первых букв каждого идентификатора. А также такие фичи как переход к определению, поиск использований и прочее.
В чистом JavaScript подсказки работают куда хуже, отчего и появляется ощущение что их вовсе нет. А отсутствие подсказок — это уровень блокнота.
Хм, ну я вообще громоздкими IDE не особо пользуюсь: sublime, nvim. Есть что-то помимо подсказок, что оправдывает избыточность кода TS по сравнению с JS?
IDE, давая подсказки по кодовой базе, толкает в сторону экстенсивного развития кода, то есть увеличения его объема. Взамен интенсивного - то есть, углубления абстракции.
У меня сложилось совсем другое впечатление. Пытался перевести на него один проект и бросил. Он все время хватает тебя за руку и требует переделок отлично работающих, правильных и совершенно прозрачных мест на JS. Вот не нравится ему, как в JS делаются дела и даются гарантии - сделайте по-моему.
Например, каких?
Самое банальное:
let a = a || ""
Нет, вы убедите меня, что "a" не undefined
Вообще-то Typescript эту штуку давным-давно поддерживает: ссылка
let foo : { a?: string } = {}
let bar : string = foo.a // Type 'string | undefined' is not assignable to type 'string'.
let baz : string = foo.a || "" // УспехМожете привести более подробный пример если вам кажется что оно где-то не работает?
Наглядный аргумент против тех, кто говорит, что TS и JS — это один и тот же язык)
О технологии мало кто знает и её используют лишь некоторые энтузиасты;
Технология внезапно или постепенно становится крайне популярной;
Ну вот прямо так ВНЕЗАПНО. Тут не хватает весьма жирного пункта посередине.
Большинство технологий, получивших быстрое и значительное распространение, решали вполне конкретные задачи и боли, потому и захватили быстро рынок. Т.е. не мода тому виной (хоть фактор моды исключать глупо, но не на начальных этапах).
он является лишь технологической надстройкой и не умеет делать ничего такого, чего бы не умел делать JavaScript
А вот это вот неправда: TypeScript умеет не компилировать неправильный код, JS на это неспособен. Языки программирования - это не только рантайм.
Здесь сложно поспорить, но, чисто теоретически, какой шанс есть написать неправильный код и не понять этого при проверке? Думаю, смысл этого преимущества несколько переоценен.
Преимущество тут в том, что многие ручные проверки можно не делать.
Пожалуй, это главный довод всех сторонников TS. Хотя лично мой опыт говорит, что подобные проверки нужны крайне редко; чаще всего для кода, который "смотрит наружу"
Редко, но метко: если рефакторить какую-то широко используемую сквозную функциональность в крупной кодобазе, то можно очень долго стабилизироваться уже лишь по причине лояльности JS к типам и количеству аргументов функций.
Вы уж определитесь, либо они нужны крайне редко, либо ошибка будет отловлена на первой же проверке.
"Паразитические" технологии или технологии надстройки — не новы.
Разве развитая экосистема костылей вокруг JS и веб-фронтенда в общем (Java Applets, Silverlight, Adobe Flash, теперь WASM-фреймворки) на протяжении всей истории не достаточно красноречиво говорит о наличии каких-то нерешенных проблем? Ведь эти "надстройки" никогда еще не умирали в пользу нативного JS, а всегда — в пользу других, более совершенных "надстроек". Под этим углом ситуация выглядит, как параллельные ветки развития: "технологии-надстройки" и целевой платформы, JS-рантайма.
он [TypeScript] является лишь технологической надстройкой и не умеет делать ничего такого, чего бы не умел делать JavaScript
JS не умеет самостоятельно статически контролировать контакты. Лопата умеет все то же, что экскаватор, но делает ли это ее ультимативным выбором?
Ну, вы как раз подтверждаете идею: развитие HTML5 выбило все вышеперечисленные технологии (кроме WASM - эта технология, если судить по вакансиям, пока сильного распространения не получила).
JS не умеет самостоятельно статически контролировать контакты
Не совсем понял, о каких контактах идёт речь.
кроме WASM — эта технология, если судить по вакансиям, пока сильного распространения не получила
На этой штуке работает браузерная версия Unity.
развитие HTML5 выбило все вышеперечисленные технологии
Выбивались они волевым решением хозяев платформ. Знаю истории про то, как конторы кастомили свои версии браузеров, для поддержки фронта на Flash.
HTML5 — это скорее консенсус-болеутоляющее, все проблемы это не решило. Потом история пошла по пути надстроек над JS: React/Angular/Vue и прочее.
WASM — эта технология, если судить по вакансиям, пока сильного распространения не получила
Незаметным ее существание тоже сложно назвать. Пусть пока это больше нишевой инструмент для числодробления. Но удочки в сторону фронта все чаще забрасываются как энтузиастами, так и крупными корпорациями.
Это альтернативная реализация все того же запроса, который никуда не пропадал.
Не совсем понял, о каких контактах идёт речь.
О контрактах, пардон.
Кто участвовал в командной и относительно длительной (не за неделю/месяц что-то наклепать и забыть) разработке ПО - понимает зачем нужны языки со строгой типизацией
Это очевидно - сгрузить часть неявной информации из головы разработчиков в код. Только боюсь, что эта часть не такая и большая.
Я не просто так добавил слово "длительная". Во время длительной разработки какие-то части проекта можно не трогать месяцами/годами. И в голове разработчика не остается ничего, кроме "ну там было как-то вот так".
А потом надо идти в код и разбираться, какой контракт у каждого метода - он принимает примитив, объект, или массив? А может быть вообще все три обработает? А обработает ли он null и undefined корректно? Какого формата возвращается результат? И т.д.
Кстати новым колегам в проекте со статической типизацией будет разобраться значительно проще и быстрее.
Я очень хорошо прочувствоал этот эффект на одном из своих pet-проектов, который был написан на JS и я не трогал его год, прежде чем вернулся к нему. Хоть я и помнил архитектуру, пришлось разбираться в каждом методе заново. В итоге я переписал его на TS и с тех пор для всех серьезных проектов выбираю TS вместо JS.
Я так понимаю вариант с документированием кода не рассматривается?
Этот вариант возможен, и до Typescript код на Javascript успешно "типизировали" в том числе используя jsdoc.
Только вот в чём проблема — без информации о типах данных документация не полна, а если такую информацию туда добавлять — почему бы не воспользоваться для этой цели специально разработанным языком (т.е. Typescript)?
Например, потому, что TS избыточен. В проекте, в котором я работаю, есть файлы, где на 34 строчки кода 19 строчек импортов интерфейсов. При этом, строгая типизация практически нигде не даёт явного преимущества. Зато совершенно не спасает от ошибок, когда код, вроде бы, собирается, а функциональность работает неверно (рабочий случай).
А в файле, на который я смотрел совсем недавно, на 20 строчек кода 500 строк документации.
Вот серьёзно, я не понимаю как один и тот же человек может писать о пользе документирования кода, и в то же время обвинять статическую типизацию в избыточности.
В проекте, в котором я работаю, есть файлы, где на 34 строчки кода 19 строчек импортов интерфейсов
Обычно нет никакой нужды смореть на импорты и IDE сворачивает их в одну строчку, так что ни один пиксель монитора не пострадает
При этом, строгая типизация практически нигде не даёт явного преимущества
Ну давайте я добавлю парочку:
Нормально работающие подсказки и автокомплит в IDE
Отлов глупых ошибок вроде присвоения строки к объекту
Код проще поддерживать (например обновить какую-нибудь библиотеку и быть уверенным, что контракт методов не изменился. Или наоборот изменился и нужно поменять код)
Ну и если мы говорим не только про TS/JS, то строгая типизация имеет позитивный эффект на проихводительность кода
Зато совершенно не спасает от ошибок, когда код, вроде бы, собирается, а функциональность работает неверно (рабочий случай)
Еще не придумали решения, которое полностью спасало бы от ошибок (ну ладно, есть формальная верификация, но это для крайне специфических случаев)
А я еще раз скажу - TS не скомпилирует код, который не соответствует объявленным типам. А JS - выполнит код, который не соответствует документации.
1) Не надо смешивать два разных явления - моду и развитие. Развитие в программном обеспечении идёт так быстро, что языки, фреймворки, парадигмы могут легко и неоднократно меняться даже в течение карьеры одного разработчика. Что не отменяет и некоторых модных вывихов развития.
2) Если автор не понимает преимуществ строгой типизации, то никак не могу назвать его опытным программистом.
Забавно, фронтендеры до сих пор спорят о необходимости строгой типизации (в больших проектах), хотя, надо признать, что любителей "свободы" все меньше, и все больше людей понимают то, что поймать ошибку в рантайме стоит намного дороже чем при компиляции кода. Все остальные плюшки вроде "более лучшей" поддержки кода IDE, или наглядное и строгое представления контракта функций, это уже приятные, хоть и достаточно важные бонусы, самое важное это все-же то, что масса проблем кода ловится еще на этапе его компиляции.
Мода в технических вопросах говорит нам лишь об одном, но очень красноречивом факте - уровень интеллекта в среднем по больнице соответствует уровню известной в узких кругах (вне гораздо большего круга почитателей моды) Эллочики-Людоедки
Если рассуждать в общих абстрактных терминах, то тут напрашиваются метафоры из других сфер экономики. Разработка ПО относительно молодая индустрия, и все эти явления скорее способ системы найти энергетический оптимум. Примерно так же было практически со всеми технологиями и видами деятельности человека.
Взять медицину. Есть базовые принципы, а есть временные технологические надстройки, актуальные для текущего этапа развития. Ну, скажем, базовым принципом является анатомическая целостность организма, затем руководствуемся принципом целостности отдельных систем ну и далее можно рассуждать об отдельных органах и методах лечения болезней связанных с конкретными подсистемами и органами. Технологически в какой-то момент преобладает колдовство, траволечение, хирургия, фармацевтика, трансплантология, генетика и пр. Внутри каждой есть свои еще более специфические технологии и инструменты.
Или взять строительство. Тоже есть общее понимание геологического основания, фундамента, архитектуры. А дальше предлагаются различные строительные материалы начиная от камней и палок до 3D печати. Каждая предполагает свои нюансы и особенности технологического процесса.
Таким образом, мне кажется, что разработка ПО просто находится на стадии когда пока не очень понято где в данном случае основа, а где технологическая надстройка. Особенно учитывая, что в отличии от медицины и строительства появилось почти одновременно несколько парадигм и подходов. Индустрия переживает некий период стресса, как, скажем, медицина в военное время, или строительство после появления механической паровой тяги. Всё со временем, думаю, устаканится и успокоится. Единственное не понятно когда.
Я сами полностью согласен. Несколько лет фрилансил на upwork'е, насмотрелся там вакансий: мы хотим переписать фронтенд с Angular на Vue, с Angular на React, c Vue на Vue2, с React на Ember и во всевозможных других комбинациях. Зачем? Затем, что в команде нет квалифицированных специалистов и думая, что притащив в проект ещё одную модную технологию, о которой прочитали в бложике, смогут тем самым решить все свои проблемы. Ан нет.
Устаревший фреймворк - это все-же проблема, в том смысле проблема, что для работы с проектом становится сложно нанимать разработчиков, никто не хочет копаться в этом, потому что опыт работы с устаревшими технологиями с каждым годом становится все дешевле оплачиваемым, да и чем старее код, тем больше в нем боли и тлена, как правило, и упоминание какого-то древнего фреймворка в вакансии, отпугивает многих потенциальных сотрудников, мало кому нравится копаться в легаси.
Мне нравится доклад Алексея Симоненко с HolyJS 2016. Хоть он и старый по меркам IT, но мысли актуальны и сейчас на мой взгляд.
Насчет Java – это такая же модная технология в контексте времени её появления. Sun также пиарила её, как современные компании пиарят свои языки/фреймворки.
Нет в неё ничего особо фундаментально отличного от современных вариантов. Разница лишь в том, что Java выжил. Маркетологи победили. Платформа выстрелила и стала достаточно популярной, чтобы закрепиться на рынке, не смотря на свои минусы.
Сейчас называть её "основополагающей технологией" конечно можно. Но это постзнание. В 90-е это был лишь один из возможных вариантов.
---
jQuery - не просто "модный фреймворк". В свое время он решал вполне конкретные задачи - кроссбраузерное управление DOM-ом. Некоторые из его фишек вошли в стандарт языка. Он оказал большое влияние на сферу веб-разработки.
Со временем он был вытеснен библиотеками и фреймворками более высокого уровня, который инкапсулируют работу с DOM, и обеспечивающие реактивность (KnockoutJS, AngularJS)
CoffeeScript - поделие бекендеров-рубистов, как и SASS, Jade (Pug)/Haml. Кто хотел писать фронты с привычным синтаксисом.
TS почти с рождения позиционировался как надстройка над JS, обеспечивающая типизацию, не меняя сам язык. (Самые чужеродные сейчас его места: namespaces, enums - были еще до этого). Сейчас его синтаксические фишки также просачиваются в стандарт, что не может не радовать.
Это я к чему... Каждая из технологий/платформ решает какую-то боль, занимает свободную нишу. Такой плюрализм - благо, есть что выбрать, есть конкуренция между идеями/подходами, выживет сильнейший.
Я сопровождая огромную территориально-распределенную систему и в ней такой зоопарк программного обеспечения, написанного в начале 2000-х. Когда глубже смотришь там использовался Delphi, Java, python, c#, c++ и может еще какой-нибудь язык программирования. Сегодня 2023 год и это до сих пор работает и переписать все это довольно сложно, а иногда почти невозможно. Система работает 24/7 по всей территории России. Естественно исходя из этого всегда будут востребованы специалисты по этим языкам программирования.
А есть технологии вроде Typescript. Если коротко, то JavaSctipt отлично себя чувствует без TypeScript, а вот TypeSctipt без JavaSctipt не существует. Вероятней всего, спустя какое‑то время его постигнет судьба Delphi (примечательно, что у них и создатель один и тот же), поскольку если опустить все словесные реверансы, то он является лишь технологической надстройкой и не умеет делать ничего такого, чего бы не умел делать JavaScript, а вот возможности JavaScript сильно шире.
Простите, но практически все что привносит TS не может сделать JS. Как раз TS может все что может JS и даже больше.
Модная разработка ПО