Как стать автором
Обновить

Комментарии 53

Уважаемые разработчики! А как вы относитесь к средствам статической типизации в JavaScript? Если бы вы решили переработать большой JS-проект, что бы вы выбрали?
Предлагаю добавить опрос к статье, чтобы вопрос не был риторическим.
Сколько времени у вас длится компиляция с TypeScript в JavaScript, раз уж речь идет о 250,000 строках кода? По личному опыту наблюдений на слабеньких машинках (например, Macbook Pro 13 2012 года) средний эдакий проект размером с 1000-1500 файлов компилируется около 20-30 секунд, а на мощных десктопах (как то Core i7-6700) от 8 до 15 секунд.

В принципе, эти цифры не такие и страшные, но не ропщут ли ваши разработчики, что раньше ждать ничего было не надо (если писать на ES5, скажем чисто для примера), а теперь на каждое изменение нужно сколько-то еще и ждать?

Конечно же, TypeScript со своей стороны предлагает пару-тройку вариантов ускорения сборки, но интересно, какие методики вы у себя в проекте используете дабы не ждать подолгу завершения компиляции?
Я верю в С++ и Вы оскорбляете мои чувства!

Схожий проект, файлов под 1000


Единственное что существенно помогло — компиляция в гранте через модуль concurrent.


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


В целом на air 15го года в 5 секунд влаживаеться


Были попытки также паралельно компайлить на сервере с xeon, но подружить с ядрами / потоками как-то не получилось и прирост не был таким большим.


Если есть какие-то другие идеи / варианты тоже рад был бы услышать.

Для меня в тайпскрипте был бы смысл, если бы благодаря строгой типизации он был быстрее обычного жс. Да и после выхода es6 код стал намного более читаем. Идеальным для жс кажется то, что сейчас имеется в 6м перле — строгой типизации нет, но если добаляешь типы то все работает быстрее.

TypeScript ровно это и делает, типизация опциональна. Но в ней достаточно смысла.

Как Typescript может сделать ваш код быстрее если бы вы писали обычный JS?
Можете привести примеры?

Я про опциональность типизации.

Хотя, в теории, можете использовать этот забавный toolchain из StackOverflow :)

Typescript to Haxe: https://github.com/jeremyfa/node-ts2hx
Haxe to C++: http://old.haxe.org/doc/start/cpp
C++ to LLVM: http://llvm.org/
LLVM to ASM: https://github.com/kripken/emscripten

Good luck =)
Потрясающе! Я даже всерьёз задумался об этом.
Вот сегодняшний кейс. Пишу на TypeScript, кода много, пишу на нормально типизированном языке, со всем современными фишками, при этом спокойно выбираю таргет. Всегда сидел на es3 таргете, потому что нужно было кое что для ie8 поддержать.
Скомпилил свои тесты из es3 в котором обычно сидел в es6, так протестить. Билжусь в один файл, никаких webPack и Babel нет.
Абсолютно идентичный код, просто много регулярок и много вызовов функций (парсер юзер агентов)
image
внимание на скорость в ms. Chrome 56.

Так у вас тут идет сравнение двух настроек Typescript, которые генерируют разный код.


Изначально топик был о том, чтобы неплохо использовать аннотации типа и в рантайме. Например, чтобы можно было добавить аннотацию типа items: Array<string> и код стал работать оптимальнее и быстрее. Этого пока, к сожалению, в движках нет.

Да, только я смотрю на то что он генерит. И он генерит примерно то что я бы сам написал. И на es6 он использует нативные классы. А в es3 сделает тоже самое через прототипы.
Вот я прямо сейчас запрашиваю у какого-то сервиса в ангуляре, он мне возвращает промис, я подцепляю then. В код этот не лез очень давно, что этот res собой представляет — массив? объект? что за свойства у него вообще?

SciGraph.getParents(nodeUri, 20, relationship)
          .then(function (res) {
// блин, что же там мой сервис должен был возвращать
 }


Не типизировал, теперь пойду в дебаггер смотреть, что же там приходит. Был бы тип — я сразу в IDE бы обратился к нужным свойствам.
Прошу простить, плохо прочитал вопрос и подумал, что он про скорость разработки, а не скорость результирующего кода.
Ну кстати в некоторых ситуациях он может быть быстрее.
JS хоть и безтиповый сам по себе, но внутри JS-движков (V8 в частности) типы есть. А степень оптимизации функций сильно зависит от разнообразия типом параметров, которые она может принимать.
Он и подталкивает. Советую посмотреть. Оно не про TS, а про JS. Но многое о чём там говорится проще писать на TS.



Код код полученный из ts будет не медленней аналогичного кода на js. Но, так как интерпретаторы js устроены так, что оптимизируют код, который часто исполняется и там где типы переменных не меняются, то получается что код ts в 100% случаев может быть оптимизирован интерпритатором. А вот про js код так строго сказать нельзя, смотря как он написан.
Так что можно сказать довольно уверенно, что на больших проектах ts даст прирост по скорости исполнения.

Что-то похожее умеет делать Google closure compiler. В нем если код хорошо увешан типами, то можно включить дополнительные оптимизации и компилятор выдаст сминифицированный код который на 5-15% меньше чем без этих опций. Это конечно не значит, что он будет выполняться быстрее, но размер самого js файла тоже важен.
Говоря о производительности, была надежда на Dart, пока Google не объявил об отказе от поддержки виртуальной машины. В тот же день я принял решение отказаться от Dart в пользу TypeScript, т.к. прочих преимуществ у Dart не было. Теперь остается надежда только на WebAssembly, но его релиз будет еще ох как нескоро. Так что на следующие пару лет TypeScript прочно занял место лидера статической типизации в фронт-енд разработке.
У WebAssembly нет, и как я понимаю, на планируется Garbage Collector, соответственно туда джаваскриптеры не прибегут.
Пока нету реальных 250K строк кода, смысла в TS нету, походу. JSDoc+инспекция кода+эпизодическая компиляция в closure compiler — это меньшая головная боль чем постоянная компиляция и подключений библиотек через одно место
  1. Когда уже есть 250к строк кода, переписать будет довольно долго.
  2. По опыту, TS полезен на проектах любого размера, поскольку позволяет крайне быстро рефакторить, что важно на ранних стадиях проэктировки, и поскольку напоминает про корнер кейсы и особенности JS.

TS не мешает сразу писать на нем, просто можно отключить проверки типов.

Вы пишете про typescript и говорите только про типизацию. Как-будто там ничего другого нет :) Вот тот же вытекающий type inference чего стоит. Много другого полезного (хотя в ES6 тоже вещей вкусных в своё время завезли).
а что type inference не относится к типизации?
Можно я верну вам ваш вопрос в виде трех, раз уж он почти риторический. Что об этом в статье написано? Что у меня в комменте об этом написано? Что еще в комменте у меня написано?
Я не понял вашего ответа на вполне логичный вопрос dark_ruby.
Как печально-то, сочувствую. В качестве рецепта, попишите на С.
А я и ответ dark_ruby не понял, и этот ответ тоже.
И на с, и на с++, и даже на с# писал, если что.
Как перетащить все на typescript? Перетаскиваем один модуль, перетаскиваем все остальное.
У меня один небольшой вопросик к знатокам typescript. Есть такая директива module. Как я понял, она позволяет создавать один модуль из нескольких ts-файлов. В итоге, в пределах данного модуля я могу спокойно обращаться к классу, находящемуся в другом файле, не импортируя его. Компилятор хорошо понимает, что я хочу сделать. Но webpack — нет. Уже в браузере мне выдается сообщение об ошибке, что класс не найден. Кто-нибудь знает, как побороть данную проблему?
webpack не умеет в modules/namespaces ибо ts изначально транспайлился кучкой, ну т.е. все файлы в общем скоупе. Позже появились es6-модули, импорты которых завязаны на файлы, а не на неймспейсы/пакеты (имхо крайне неповоротливое решение, ибо почти во всех взрослых языках все на пакетах). Вебпак у нас работает именно с файлами-модулями, отсюда он и не может понять без прямого референса в каком из файлов лежит «добавка» к текущему модулю.
Отсюда совет — либо не используйте вебпак для транспайлинга TS, либо не используйте modules/namespaces, учитывая, что даже офф-доки TS все на ES6-модулях.

Дело в том, что мы в проекте используем Typewriter для того, чтобы сгенерить типы данных Typescript по уже имеющимся типам C#. Так как Typewriter не умеет ссылаться на другой автосгенеринный тип данных автоматически, я это сделал следующим образом: все сгенерированные типы я экспортирую в одном файле all.ts и в шаблоне Typewriter я импортирую этот файл как: import * as Models from './all'. Думал, что как-то можно заюзать директиву module, но из ваших слов я понял, что это сделать не получится. От текущего решения я как-то не в восторге, поэтому надо искать что-то другое....

Просто добавьте еще один шаг сборки всей кучи нагенеренных классов в один js-файл с флагом генерации .d.ts по нему. У вас получится своего рода библиотечка из одного модуля вместе с декларацией типов, из который вы сможете удобно все нужное импортировать. Нам так коллеги с бэка генерят апи с джавы.

Это идея. Надо будет попробовать. Спасибо.

+1 к комментарию выше. Встроенные Typescript-модули были актуальны раньше, а сейчас уступают место стандартным JS-импортам. Все это неплохо описано на этой странице документации TS

Она же deprecated, нет?

См. мой коммент выше

Flow бы выбрал. Потому что он не компилятор.
Опять вы за свое ;)
При работе с TypeScript 1.8 для того, чтобы добавить новый файл объявлений, нужно установить отдельные npm-пакеты глобально, найти файлы объявлений для конкретной библиотеки и сохранить все файлы описаний библиотек в папке «typings». Честно говоря, решение это было не самое элегантное.

Есть такой npm модуль, Typings, он дейтсвует по принципу npm — создаёться конфиг файл typings.json, в него заносяться зависимости и сами засовываються в папочку typings.
ЗЫ практически все тайпинги можно найти тут
Это означает, что он не только поддерживает проверку типов, но и позволит работать с будущими возможностями ES6 и ES7.

Время от времени вижу эти термины что они значат? ES6 — это старое название ES2015, ок. А что значит ES7?
ES2016? Судя потому, что упоминается в контексте "будущих возможностей", то нет. ES2017? Все будущие спецификации? Все фичи, которые находятся на Stage 0 — 3? Что это?

Ещё ES2015 до конца не поддерживается в популярных браузерах и, кажется, в NodeJS, так, что, например, рассчитывать на оптимизацию хвостовой рекурсии в продакшене несколько опрометчиво.

Переводили на typescript с модулями и нормальными es6 импортами? Мы в проекте столкнулись с тем, что перевести на typescript без модулей не сложно, берёшь и потихонечку переписываешь. А вот теперь перевести на модули и импорты проблематично, потому что половина кодовой базы уже на typescript без модулей и невозможно нормально ссылаться из новых модульных файлов в старые не модульные. Думаем как-то автоматически сгенерировать импорты, хочется использовать webpack. Наверное, сразу переводить на модульный typescript было бы проще.

Больше года уже использую Typescript в связке с create-react-app и кастомным react-scripts-typescript-scss на проектах любого размера. Идеальная поддержка в VS Code, возвращаться на Babel нет никакого желания)

Интересно узнать сколько багов было найдено и какое покрытие тестами было до перехода.

и сколько багов появилось после перехода
3 года назад переводил свой проект (тогда ещё около 10к строк было) на тайпскрипт. Ушло несколько недель, но разработка после этого — сказка. Не даёт сделать совсем глупые ошибки, следит за типами, и в случае чего, выдаёт предупреждения.

На чистом JS такие ошибки только в рантайме отлавливать, что долго и тяжело.

Мне тоже Flow понравился, только я использую grunt-flow, он позволяет избавиться от кучи глупых опечаток и, на первый взгляд, невидимых проблем.

Google — GWT помните? А Kotlin пока очень экзотичен, спецов под него не найдёшь, и если помет — вы застряли с приложением на нем написанным.
У TS тут два основных преимущества:
— готовые спецы уже есть, да и прочие хорошие программисты JS легко осваивают, ибо суперсет;
— в самом худшем случае «TS помер», у вас на руках остался странспиленный JS, который легко читается человеком.

Я выбираю Flow, т.к. волен выбирать вкусные babel-плагины.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.