Comments 53
Уважаемые разработчики! А как вы относитесь к средствам статической типизации в JavaScript? Если бы вы решили переработать большой JS-проект, что бы вы выбрали?Предлагаю добавить опрос к статье, чтобы вопрос не был риторическим.
В принципе, эти цифры не такие и страшные, но не ропщут ли ваши разработчики, что раньше ждать ничего было не надо (если писать на ES5, скажем чисто для примера), а теперь на каждое изменение нужно сколько-то еще и ждать?
Конечно же, TypeScript со своей стороны предлагает пару-тройку вариантов ускорения сборки, но интересно, какие методики вы у себя в проекте используете дабы не ждать подолгу завершения компиляции?
Схожий проект, файлов под 1000
Единственное что существенно помогло — компиляция в гранте через модуль concurrent.
С помощью него комбайним необходимые таски и они компайляться паралельно. В случае с одним таком — единственное что нашли — разбить его на саб-таски и компайлить паралельно.
В целом на air 15го года в 5 секунд влаживаеться
Были попытки также паралельно компайлить на сервере с xeon, но подружить с ядрами / потоками как-то не получилось и прирост не был таким большим.
Если есть какие-то другие идеи / варианты тоже рад был бы услышать.
Для меня в тайпскрипте был бы смысл, если бы благодаря строгой типизации он был быстрее обычного жс. Да и после выхода es6 код стал намного более читаем. Идеальным для жс кажется то, что сейчас имеется в 6м перле — строгой типизации нет, но если добаляешь типы то все работает быстрее.
Как 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 =)
Скомпилил свои тесты из es3 в котором обычно сидел в es6, так протестить. Билжусь в один файл, никаких webPack и Babel нет.
Абсолютно идентичный код, просто много регулярок и много вызовов функций (парсер юзер агентов)
внимание на скорость в ms. Chrome 56.
Так у вас тут идет сравнение двух настроек Typescript, которые генерируют разный код.
Изначально топик был о том, чтобы неплохо использовать аннотации типа и в рантайме. Например, чтобы можно было добавить аннотацию типа items: Array<string> и код стал работать оптимальнее и быстрее. Этого пока, к сожалению, в движках нет.
SciGraph.getParents(nodeUri, 20, relationship)
.then(function (res) {
// блин, что же там мой сервис должен был возвращать
}
Не типизировал, теперь пойду в дебаггер смотреть, что же там приходит. Был бы тип — я сразу в IDE бы обратился к нужным свойствам.
JS хоть и безтиповый сам по себе, но внутри JS-движков (V8 в частности) типы есть. А степень оптимизации функций сильно зависит от разнообразия типом параметров, которые она может принимать.
Код код полученный из ts будет не медленней аналогичного кода на js. Но, так как интерпретаторы js устроены так, что оптимизируют код, который часто исполняется и там где типы переменных не меняются, то получается что код ts в 100% случаев может быть оптимизирован интерпритатором. А вот про js код так строго сказать нельзя, смотря как он написан.
Так что можно сказать довольно уверенно, что на больших проектах ts даст прирост по скорости исполнения.
- Когда уже есть 250к строк кода, переписать будет довольно долго.
- По опыту, TS полезен на проектах любого размера, поскольку позволяет крайне быстро рефакторить, что важно на ранних стадиях проэктировки, и поскольку напоминает про корнер кейсы и особенности JS.
TS не мешает сразу писать на нем, просто можно отключить проверки типов.
Отсюда совет — либо не используйте вебпак для транспайлинга TS, либо не используйте modules/namespaces, учитывая, что даже офф-доки TS все на ES6-модулях.
Дело в том, что мы в проекте используем Typewriter для того, чтобы сгенерить типы данных Typescript по уже имеющимся типам C#. Так как Typewriter не умеет ссылаться на другой автосгенеринный тип данных автоматически, я это сделал следующим образом: все сгенерированные типы я экспортирую в одном файле all.ts и в шаблоне Typewriter я импортирую этот файл как: import * as Models from './all'. Думал, что как-то можно заюзать директиву module, но из ваших слов я понял, что это сделать не получится. От текущего решения я как-то не в восторге, поэтому надо искать что-то другое....
+1 к комментарию выше. Встроенные Typescript-модули были актуальны раньше, а сейчас уступают место стандартным JS-импортам. Все это неплохо описано на этой странице документации TS
Она же deprecated, нет?
При работе с TypeScript 1.8 для того, чтобы добавить новый файл объявлений, нужно установить отдельные npm-пакеты глобально, найти файлы объявлений для конкретной библиотеки и сохранить все файлы описаний библиотек в папке «typings». Честно говоря, решение это было не самое элегантное.
Есть такой npm модуль, Typings, он дейтсвует по принципу npm — создаёться конфиг файл typings.json, в него заносяться зависимости и сами засовываються в папочку typings.
ЗЫ практически все тайпинги можно найти тут
Это означает, что он не только поддерживает проверку типов, но и позволит работать с будущими возможностями ES6 и ES7.
Время от времени вижу эти термины что они значат? ES6 — это старое название ES2015, ок. А что значит ES7?
ES2016? Судя потому, что упоминается в контексте "будущих возможностей", то нет. ES2017? Все будущие спецификации? Все фичи, которые находятся на Stage 0 — 3? Что это?
Переводили на typescript с модулями и нормальными es6 импортами? Мы в проекте столкнулись с тем, что перевести на typescript без модулей не сложно, берёшь и потихонечку переписываешь. А вот теперь перевести на модули и импорты проблематично, потому что половина кодовой базы уже на typescript без модулей и невозможно нормально ссылаться из новых модульных файлов в старые не модульные. Думаем как-то автоматически сгенерировать импорты, хочется использовать webpack. Наверное, сразу переводить на модульный typescript было бы проще.
Интересно узнать сколько багов было найдено и какое покрытие тестами было до перехода.
На чистом JS такие ошибки только в рантайме отлавливать, что долго и тяжело.
Мне тоже Flow понравился, только я использую grunt-flow, он позволяет избавиться от кучи глупых опечаток и, на первый взгляд, невидимых проблем.
У TS тут два основных преимущества:
— готовые спецы уже есть, да и прочие хорошие программисты JS легко осваивают, ибо суперсет;
— в самом худшем случае «TS помер», у вас на руках остался странспиленный JS, который легко читается человеком.
Я выбираю Flow, т.к. волен выбирать вкусные babel-плагины.
Нашёл способ кастомизировать: 10 шагов настройки Create React App + TypeScript + Ant-Design.
История о том, как мы перевели проект в почти четверть миллиона строк на TypeScript и остались в живых