Почему TypeScript, а не es6, Coffeescript, flowtype, Dart

Вопрос-ответ JavaScript
1

Continuing the discussion from Typescript - какие известны проблемы с интеграцией и использованием?:

Мы на текущем проекте (веб трейдинговая платформа) всерьез задумались использовать TypeScript. Отвечая на вопрос, почему не другие доступные транспайлеры, я сначала опишу ситуацию с проектом. Есть большая кодовая база, на es5, упакованная в commonjs модули, построенная на ООП-шных классах поверх цепочки прототипов, платформа развивалась не один год. Планируется дальнейшее развитие платформы, изменение поведения существующих классов и дописывание нового функционала, оптимизации.

Какие проблемы могут быть решены с помощью транспайлера, и при этом вызывают неудобство.

  • Рефакторинг существующего кода сложен и многословен. Поэтому в случае, когда можно срезать угол, программист срезает. JavaScript позволяет с большой легкостью “срезать углы”, запутывая код, или добавляя проблем при отладке. Очень сложно контролировать качество кода программно.
  • Многословность JavaScript-а для реализации общепрограммеских концепций. Одни и те же концепции (интерфейсы, абстрактные классы, обязательные параметры, необязательные параметры, валидация параметров) можно выразить разными образами, и со временем в кодовой базе можно встретить несколько реализаций примесей, или абстрактных классов. Что легкости при чтении не добавляет.
  • jsdoc-и не справляются в должной степени с подсветкой типов и подсказками кто является потребителем какого типа данных.
  • Сложность навигации по классам и их методам. Метод getState имеет почти каждый UI компонент, и если webstorm не смог определить тип свойства component в коде this.component.getState(), то при попытке перехода к методу мы наблюдаем портянку из файлов классов, который этот метод реализуют. Аннотации помогают, но опять таки нет механизмов программно убедиться, что каждый созданный метод - аннотирован, и аннотирован корректно.

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

Теперь пройдем по характеристикам существующих вариантов

es6

Будущий стандарт, устранившийся, с годной поддержкой ide-шками, новым и удобным синтаксическим сахаром (классы, наследование, интерполяция строк), пакетной системой. Есть минимум 2 транспайлера (babeljs и traceour), годно выполняющие свою работу.

Почему нет:
- тянет некоторые проблемы JavaScript-а с собой (типы).
- потребует переделки процесса сборки, (чтобы подружить новые модули с нашими commonjs).
Почему бы и да:
- стандарт, следовательно жить будет долго, не приведет к тому, что через пару лет мы будем завязаны на никем не поддерживаемую технологи.

CoffeeScript

Лаконичный, сахарный-сахарный (в смысле синтаксиса) JavaScript, вдохновленный Ruby. Решал в свое время множество проблем, которые сейчас решены в es6 (классы, наследование, интерполяция строк, arrow-functions). Не является стандартом, имеет поддержку. Чтобы научиться на нем писать, достаточно пары дней. Научиться его читать - сложнее. JavaScript является валидным CoffeeScript кодом.

Почему нет:
- неясно будущее технологии, а преимущества
- сложнее будет найти программистов (или придется тратить время на обучение)
- привносит свои проблемы в связи с новой семантикой
Почему бы и да:
- лаконичный, красивый

flowtype

Фейсбуковое изобретение, достаточно молодое. Из-за медийности компании сложно оценить ценность самой технологии (о технологии говорят потому что технология хороша, или потому что фейсбук ее всячески рекламирует. То же самое с React-ом). Добавляет проверку типов. Не знаю степень интеграции с IDE (подскажет ли несоответствие типов) внутри ide.
Почему нет:
- Решается 1 задача, в то время как проблем много.
Почему бы и да:
- Минимально требуемые изменения. Решается только 1 задача.

Dart

Гугловое изобретение, переходной мост между JavaScript и Java. Отличные доки, опциональные аннотации типов (на рантайм никак не влияют). Совсем другой язык, не несущий проблем javascrpt-а. Интеграция с ide, свой способ определения пакетов. Развивается только гуглом. Были речи о выстраивании dart-vm (интерпретатора) в браузеры, однако другие производители браузеров не сильно поддержали идею. Богатая стандартная библиотека. Язык продолжает эволюционировать достаточно быстро. Компилируется в JavaScript, но выдается много своего лишнего кода.
Почему нет:
- Если проект прекратит свою поддержку, никто не сможет потянуть его развитие. + не так много проектов завязано на Dart-е (несмотря даже на то, что стандарт открыт).
- Сложно использовать существующий код вместе с Dart-ом. Возможно, но сложно.
Почему да:
- Богатая стандартная библиотека.
- Хороший язык, вобравший сильные стороны как java, так и JavaScript.

TypeScript

Надмножество JavaScript, с опциональной типизацией, интерфейсами, и возможностями ES6. Считай, продвинутый Flowtype (так как есть интерфейсы и миксины) + ES6. Майкрософтовое изобретение, тем не менее опенсорсное. JavaScript это валидный TypeScript. Годная поддержка ide-шками. Положительные сигналы от коммьюнити: ангуляр, на который завязаны многие разработчики, собирается ипользовать тайпскрипт во второй своей версии. Типы учитываются только во время написани кода (как и в Dart), компилируемая в чистый (в плане формы) JavaScript.
Почему нет:
- Не стандарт.
Почему бы и да:
- Добавит строгости на уровне синтаксиса языка, позволит использовать возможности ES6.
- Решает больше проблем, чем привносит рисков (майкрософт забьет на проект).

Итого: мы сейчас оцениваем цену перехода, прикидываем сложности при использовании. Пока что всех рассмотренных инструментов, наши проблемы (не все, но немалая их часть) лучше всего решаются TypeScript-ом. Если цена перехода не будет велика, вскоре начнем использовать.

7 лайков
2

Интересное сравнение, хочется продолжения, держи нас в курсе ;)

3

Отличное сравнение! А главное подкрепленно нехилой базой на основе опыта, а это важно.

Хотел бы добавить по CoffeeScript (который сам использовал долгое время и был очень счастлив):

  • Скорей мертв чем жив. Об этом можно судить после новости о выходе версии 2.0, где нет даже и упоминания про ES2015 (ES6) а сами изменения дробные, что означает во-первых, что технология становится не продолжением и улучшением текущего языка, а вырванным из контекста новым хорошо забытым старым языком, а во-вторых синтаксис языка совершенно несовместим с новой версией ES 2015.
  • JS Не совсем валидный CoffeeScript, к примеру ключевое слово function является зарезервированным.
  • Нарушает основую идею препроцессора или надстройки (читай как улучшитель) над основным языком, так как нельзя будет оставить синтаксис как есть и просто выключить препроцессор, что вполне может быть реально в версиях ES2017-2018 с TypeScript и остальными ребятами которые по просту добавляют то чего не хватает пока в языке.
4

Да, после реализации ES6 - CoffeeScript умер :disappointed:

5

Интеграция webpack в существующую систему сборки может решить этотот вопрос.

6

Так и поступили: прикрутили вебпак. И когда стоит выбор между es6 или typescript я выбираю typescript, так как натерпелся проблем с динамичностью языка и “отложенными” проблемами, которые возникают в рантайме через неделю после рефакторинга.

7

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

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

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

8

О, некропост! )

Зачем нам опять называть одно черным, другое – белым? TypeScript был создан для решения определенной задачи, а задача – разработка и поддержка проекта с минимальными затратами для бизнеса. Если он решает этот вопрос для определенный команды – почему нет? Бизнес ничего не знает о мультинаследовании, статической типизации и т.п. Ему интересно только то, как реализовать продукт и легче всего его поддерживать.

Получается, что в жизни не черное и белое, а много (надеюсь не 50 :ъ ) оттенков серого. И для определенной команды и проекта TypeScript может быть маной небесной.

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

Если им так легче писать и поддерживать, это их право. Разве нет? Можно еще раз повторить мантру о том, что бизнесу наплевать на наши идеалы программирования. У него хладнокровный и прагматичный подход к издержкам разработки.

Если внедрение TypeScript’а в конкретном случае создает больше проблем, чем решает, зачем тогда его внедрять?

Это закон наименьшего сопротивления. Когда-то программисты потратили время и энергию на изучение определенных паттернов. Теперь придя в другую сферу они не хотят изучать новые, они хотят использовать давно проверенные старые. Выучить и внедрить новые – это опять (время и энергия) === (деньги), которые бизнес стремиться сократить до необходимого минимума.

Ну и если уж трезво посмотреть на JavaScript, то изобретение TypeScript’а было ожидаемо. В 90-х проектируя стандарт, никто не догадывался, что через 10 лет, его будут использовать в серверной части и для проектирования крупных одностраничных приложений.

1 лайк