Стоит ли Typescript усилий?

image
Typescript — это скриптовый язык, компилируемый в JavaScript. Разработка Microsoft, которая, на сегодняшний день, успела завоевать и фанатов и недоброжелателей. Главный вопрос для начинающих, и не только: «Зачем он мне нужен?».

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

Начнем с основных плюсов:

  1. Строгая типизация
  2. Читабельность кода
  3. Более легкий переход из мира строгой типизации, нежели на JavaScript напрямую, в котором правит бал Динамика
  4. Обратная совместимость с JavaScript
  5. Широкая поддержка IDE

Строгая типизация


Позволяет более полно описывать свойства и методы обьектов и классов, из-за чего пропадает необходимость, которая, лично меня, дико раздражала, делать проверку всех, входящих в метод или функцию, аргументов:
function checkAllMyArgsAgain(check, me, please) {
    if(check && me && please) {
        if(check instanceof CheckObject){
            console.log('Урааааа!');
        } else {
            console.log('И снова исключение...')
        }
        if(me){ } // И так далее.......
    }
}

В любом случае, TypeScript сильно упрощает этот процесс:
function checkAllMyArgsAgain(check: CheckObject, me: MeObject, please: string): string {
    return 'Какая проверка аргументов? Вы о чем? ';
}

И мы плавно перейдем ко второму пункту, которому первый сильно способствует:

Читабельность кода


Из примера выше, очевидно, что читать код на TypeScript будет проще, ввиду отсутствия нагромождений кода, характерные Javascript.

Можно представить, во что превратится код, написанный на JavaScript, спустя какое-то время…


function checkMe(check, me) {
     if(check && me) {
         if(check){ ... }
         if(me){ ... }
     }
}

function andCheckMe(check, me) {
     if(check && me) {
         if(check){ ... }
         if(me){ ... }
     }
}

function andCheckMeToo(check, me) {
     if(check && me) {
         if(check){ ... }
         if(me){ ... }
     }
}

Против:

function checkMe(check: CheckObject, me: MeObject) {
     console.log('Ну круто же!');
}
function andCheckMe(check: CheckObject, me: MeObject) {
     console.log('Просто песня');
}
function andCheckMeToo(check: CheckObject, me: MeObject) {
     console.log('Писать легко и с удовольствием');
}

В некоторых случаях, в JS, можно уменьшить ущерб путем абстракций, но в целом, TS сильно впереди по данному вопросу.

Более легкий переход в мир JS из мира статики


Многие проявляют интерес к JS, но их отпугивает некая хаотичность и непредсказуемость языка. Здесь Вам сильно поможет TS, который позволяет писать JS, более привычным и понятным путем.

Обратная совместимость с JS


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

Широкая поддержка IDE


TypeScript, на данный момент, имеет поддержку в любой популярной IDE, включая IDEA, WebStorm, Sublime, Atom, и так далее. Соответственно, менять любимую среду разработки не придется.

Теперь опишем основные минусы:

  1. Строгая типизация
  2. Компилятор
  3. Debug
  4. А вдруг помрет?

Строгая типизация


Этот пункт работает как во благо, так и во вред, потому что необходимо описывать все типы для всех обьектов, классов, переменных, и иже с ними, что было не свойственно JavaScript ранее.

Но куда большее зло — миграция существующих популярных JS решений на TS. Видите ли, для каждой портированной либы необходимо описать .d.ts файл, в котором и хранятся все возвращаемые типы и описание всех методов. Уверен, что портирование таких монстров, как jQuery, потребовало немало приседаний.

Компилятор


Он существенно уменьшает вероятность «тупой» ошибки, типа пропущенных запятых и неправильно написанных имен переменных, но, также, убивает всю прелесть JS, когда большую часть решений можно было написать на коленках и проверить в консоли браузера.

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

Debug


Естественно, любому разработчику необходимо понимать, как, быстро и эффективно, проверять код на ошибки, ловить и исправлять баги. И, первым делом, надо разобраться, как это процесс наладить в TypeScript. Существует множество гайдов для различных IDE: WebStorm и Visual Studio о том, как все это дело настроить в редакторах кода и эффективно работать, но с JS этого делать не надо было, потому как, можно было запустить код, наставить точек останова внутри редактора или браузера и спокойно дебажить. С TS придется немного попотеть.

А вдруг помрет?


Это интересный и серьйозный вопрос, потому как стандарты JS идут в ногу со временем и интегрируют в сам язык многое, что было полезно в TS: классы, стрелочные функции, и так далее. Рано или поздно, все полезные функции TS будет так или иначе перенесены в стандарт языка и TS повесит бутсы на гвоздь. А если ребята из Microsoft решат, что им это не нужно и полностью оставят TS на волю open-source? Понятно, что являясь открытым продуктом, TS не лишиться поддержки совсем — всегда найдутся энтузиасты, но поддержка такого гиганта, как Microsoft, никогда не помешает.

Опять же сам Microsoft, как основного разработчика, многие относят к минусу, потому как репутация у гиганта весьма спорная: Skype, Nokia, Windows Phone, Windows Vista, и так далее.

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

Всем спасибо, все свободны!

Комментарии (33)

  • 23 августа 2016 в 23:03 (комментарий был изменён)

    +4

    Видите ли, для каждой портированной либы необходимо описать .d.ts файл, в котором и хранятся все возвращаемые типы и описание всех методов.

    Можно просто тип any использовать
    declare var $: any;
    
    • 24 августа 2016 в 00:27

      0

      Верно, типизация в TypeScript опциональна и не причиняет больших не удобств, даже наоборот!)
      Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.

      TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.

  • 23 августа 2016 в 23:15 (комментарий был изменён)

    0

    Согласен, но если смотреть с этой точки зрения, то это полумера, так как все можно описать через any и использовать TS в некоторых частях кода, а не везде. Но я являюсь поклонником фразы: «Если используешь что-то, то используй это на 100%».

    Можете глянуть — jQuery.d.ts, если будет интересно.

    Но в целом — Вы правы.

    • 23 августа 2016 в 23:18

      +2

      Вся прелесть TS именно в том, что я могу взять свой проект на javascript, перенести его в .ts и добавлять типы по мере необходимости.
      Аннерс Хейлсберг именно это и задумывал.
      • 23 августа 2016 в 23:30

        0

        Крайне интересная мысль, не рассматривал этот вопрос под таким углом.
        • 24 августа 2016 в 00:07

          +1

          Это работающий подход, я в одном из проектов так и делал.
  • 23 августа 2016 в 23:25

    0

    Отличный язык, с одной стороны позволяет все затипизировать и иметь проверки на уровне компилятора, с другой стороны позволяет очень быстро сделать прототип решения (почти как в JS) и потом уже провести рефакторинг.
    В общем нравится мне за гибкость.
  • 23 августа 2016 в 23:46 (комментарий был изменён)

    +1

    Стоит также взглянуть на flow
    • 24 августа 2016 в 03:20

      0

      А еще на соответствующий плагин для Babel. Очень выручает с типами, тем более что Babel сейчас юзается повсеместно.
    • 24 августа 2016 в 09:13

      +1

      Это полумера, TypeScript больше чем просто типы. В любом случае на переход тратятся усилия, так лучше потратить их разумно чем хвататься за сомнительные поделки.
  • 23 августа 2016 в 23:49

    –1

    С TS придется немного попотеть.

    Развернёте мысль?

    • 23 августа 2016 в 23:56

      +2

      Можно я разверну? Не придётся)) Компилированный JS дебажится без проблем
    • 24 августа 2016 в 00:01

      0

      Без проблем! Несмотря на обьемное количество информации, у меня заняло некоторое время настроить окружение, чтобы нормально дебажить TS.
      1. Надо было поставить плагины в среду разработки, чтобы редактор начал адекватно реагировать на TS (что нормально, поскольку это касается любой надстройки на нативным языком)
      2. Надо было изменить конфигурацию дебаггера внутри IDE, потому как теперь нужно сначала скомпилить ts, а потом дебажить скомпиленный код
      3. Вначале были проблемы с бандлерами типа Webpack или загрузчиками типа SystemJS, потому что их нужно было расширять дополнительно для работы с TS.

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

      • 24 августа 2016 в 00:24

        0

        Вы сейчас про какую среду разработки-то?

        • 24 августа 2016 в 00:26

          0

          vintage Имеется ввиду IDE — IDEA, WebStorm, Sublime, Atom…
          • 24 августа 2016 в 00:28

            0

            WebStorm поддерживает TS из коробки уже давно.

            • 24 августа 2016 в 00:29

              0

              vintage Да, но не все же на WebStorm работают, верно?
              • 24 августа 2016 в 08:53

                0

                Но и не все обобщают опыт работы с одной IDE сразу на все, преподнося это как минус языка.

              • 24 августа 2016 в 09:07

                0

                А какие IDE для веб-разработки ещё есть с сопоставимыми возможностями? (конструкторы на базе редакторов не учитываем)
                Получается, что выбора IDE нет, так что рассматривать это как минус не стоит.
      • 24 августа 2016 в 00:43

        0

        С окружением все нормально, поднимается без проблем — этот пункт не стоит брать во внимание в вопросе о нужности/ненужности typescript.
        В целом же, сабж — штука, конечно, прикольная, но писанины субъективно где-то на треть больше выходит. На мой взгляд, для мелких/средних проектов не особо целесообразно, для крупных же — вполне может оправдать себя.
      • 24 августа 2016 в 09:21

        0

        Выше перечислены простые вещи, которые делаются один раз и это много времени не занимают. Гораздо более сложный вопрос с переходом может возникнуть если команда не готова работать с типами и ООП вообще (например елси в команде фанбои функциональщины, или просто не инженеры которые не привыкли писать поддерживаемый код).
  • 23 августа 2016 в 23:55

    +1

    Использовал TS в продакшне. Мне понравилось прямо очень. Минусы на мой взгляд притянуты за уши. Контраргументы по пунктам
    1. Сама по себе строгая типизация является в TS опциональной. Не хотите — пишете any, и всё, что вас там напрягало, проходит мимо. Да, вы не получите соответствующих плюсов, но это же ваш выбор был. А .d.ts файлы считаю вообще прекраснейшим решением, которое позволяет подключить любой посторонний код и сделать его типизированным. Опять же: если не хотите — не делайте, это ваш выбор, но жаловаться на то, что библиотеки требуют дополнительного описания для того, чтобы они были типизированными — довольно нелогично.
    2. Если надо быстренько поговнокодить через консоль, а потом вкинуть решение в продакшн, то вроде как никто этого сделать не мешает. По крайней мере у меня бывала парочка костылей такого плана, и компилятор никак не помешал
    3. Дебажу прямо чистый JS в хроме. Учитывая, насколько он вообще читабельный на выходе — не понимаю, какие у вас с этим проблемы? Плюс при использовании Sourcemaps хром позволяет дебажить TS прямо в браузере, без всяких там штормов и студий. Хоть в саблайме пишите.
    4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.
    • 24 августа 2016 в 00:05

      0

      Starche Не лишены логики первые три пункта, но:
      4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.

      Я заметил, что многие относят это к минусу, но я не имел ввиду, что это всегда плохо. Если это непонятно из контекста, исправим.

      • 24 августа 2016 в 01:50

        0

        да, вы правы, простите, я слишком утрировал)
    • 24 августа 2016 в 00:26

      –2

      Только вот ng2 далеко не факт, что долго проживёт.

      • 24 августа 2016 в 02:08 (комментарий был изменён)

        +1

        Я считаю в кругу .NET разработчиков должен взлететь, особенно тех, кто веб-разработкой занимается (я сам кстати из этих).
        Я когда начал писать на TS даже доки не читал, т.е. порог входа для тех кто знает JS + C# просто нулевой (понятно, что уже через пару часов полез на форумы). Думаю тоже касается и Java разработчиков.
        Плюс он заточен как раз для больших проектов, это нравится энтерпрайзу.
        Даже сейчас есть отличный тулинг, например отличная поддержка в WebStorm и обещают поддержку в новой VS, а также вполне уже для пет-проджектов можно использовать Angular-cli.
        Да и за спиной у него стоит влиятельная корпорация которой доверяют.

        Учитывая эти факты, я предполагаю, жить он будет долго.

        Мне вот интересно, почему вы считаете, что «не факт»?

        • 24 августа 2016 в 08:50

          0

          Эта влиятельная корпорация уже похоронила GWT и вот-вот похоронит Polymer. Основная причина смерти — излишняя сложность и недостаточная гибкость, не дающая технологии обрести популярность. jQuery и Angular взлетели именно за счёт простоты, можно было на коленке сваять что-то работающее и отправить в продакшен. A2 же — это сложно и громоздко.

  • 24 августа 2016 в 00:24

    –2

    Для меня главный минус — отсутствие обратного компилятора. Чтобы те члены команды, которые хотят ТС могли легко интегрировать изменения, которые я сделал в сгенерированном ими ДжС.
    • 24 августа 2016 в 00:27

      +2

      С экзешниками вы тоже так балуетесь? :-)

    • 24 августа 2016 в 01:03 (комментарий был изменён)

      0

      Есть инструменты ES5 → ES6, например lebab. Возможно есть подобия и для TS.
      Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
      Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
      Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
    • 24 августа 2016 в 01:52

      0

      Cуровая у вас практика.
      Я мог бы понять такой аргумент при работе с SCSS/LESS: из браузера CSS реально в разы удобнее писать, чем каждый раз перегенеривать. Это меня часто останавливает от использования CSS-препроцессоров.
      Но вносить изменения прямо в JS… Что вас побуждает к таким действиям? почему в тайпскрипте не поправить?
      А если вам надо отдельный файл подключить JS-ный, то это как раз никто не помешает сделать.
  • 24 августа 2016 в 08:47 (комментарий был изменён)

    0

    серьйозный
    Вы серьёзно?!
  • 24 августа 2016 в 09:16 (комментарий был изменён)

    0

    Рано или поздно, все полезные функции TS будет так или иначе перенесены в стандарт языка и TS повесит бутсы на гвоздь.

    Очень мало вероятно. TS сделан инженерами для инженеров, а ES хипстерами. Если бы ES делали инженеры то типы бы уже там появились, но они просто добавляют синтаксического сахара, это говорит об их приоритетах.

© Habrahabr.ru