Комментарии 17
Интересно, что бы было, если бы вы скомпилировали на Linux или включив на Маке case-sensitive file system.
Из-за пары нюансов, не использовать node-ts, что за вредные советы…
Пока в web assembly нет сборки мусора туда нереально портировать популярные языки. На Rust не то чтобы хочется писать для веб.
Для вас возможно будет открытием тот факт, что ts проходит через промежуточный этап в виде js, а не трансформируется в машинные команды напрямую. И с этим js уже можно делать все что угодно — об ошибках вы узнаете только на проде. Исключить это можно только если все поголовно будут писать только на ts, что явно из раздела фантастики. Ну или самостоятельно дописывать типы для всех используемых js библиотек, что явно лишняя работа. Лучше уж потратить это время на написание тестов, которые действительно будут что-то гарантировать.
Думаю, с текущей скоростью развития веба, лет через десять в самом js появятся типы и тогда уже наступит рай для фронтендеров. Примерно как было с coffeescript.
Вы удивитесь, но Typescript тоже даёт определённые гарантии на этапе компиляции. Разница лишь в том, что компилируется он не в машинные коды или байткод, а в JavaScript.
Я уже понял, что по холиварным вопросам никто не пытается осмыслить сообщение собеседника. Попробую повторить еще раз, более внятно:
После компиляции раста вы в дальнейшем не изменяете получившийся ассемблер. Вы лишь используете получившуюся программу.
После компиляции ts в js, вы продолжаете работать с js. Что-то изменять, добавлять, подключать какие-то либы и тд. На этом этапе тайпскрипта уже нет, остался лишь js, который не дает гарантий. Вы же не будете спорить, что можно взять кусок кода на ts, скомпилить его в js, а потом изменить этот js так, чтобы он падал? Где тогда будут все эти гарантии? Или, к примеру, когда вам нужно будет что-то дебажить — вы будете дебажить js (либо увеличивать размер бандла через доп инфу в соурс мапах). Всё это означает двойную работу.
Я понимаю, когда используют scss поверх css — он в разы, если не на порядки, ускоряет разработку и поддержку большого проекта. Но ts не дает подобных ощутимых преимуществ, чтобы его использовать. В js есть много проблем, но если не писать код в стиле вопроса для собеседований «угадай, что выведет компилятор на эту дичь», то все будет нормально. А раз нет никакой разницы, то зачем
После компиляции ts в js, вы продолжаете работать с js. Что-то изменять, добавлять, подключать какие-то либы и тд. На этом этапе тайпскрипта уже нет, остался лишь js, который не дает гарантий.
Нет, я всё это делаю на этапе работы с TS. Все библиотеки, все изменения происходят лишь в тайпскрипт-коде. Затем управление отдаётся бандлеру — webpack или rollup, — который уже компилирует, модифицирует, минифицирует конечный вариант. В общем-то, всё то же самое, что делает, например, LLVM. Разве кто-то сейчас делает по-другому? Зачем усложнять кодовую базу, влезая руками в скомпилированный JS, когда у тебя сорцы на TS? Поэтому-то TS и сравнивают с Rust — оба этих языка являются в первую очередь статическими анализаторами, которые дают гарантии именно на этапе компиляции. Да, ввиду изначально корректной архитектуры Rust даёт больше гарантий, в то время как TS создавался поверх уже существующего JS, что накладывает свой отпечаток. Но это не значит, что TS ничего не привносит — ещё как. Он делает то, что в Rust является одним из краеугольных камней дизайна языка: делает неявное явным. Explicit лучше чем implicit.
Или, к примеру, когда вам нужно будет что-то дебажить — вы будете дебажить js (либо увеличивать размер бандла через доп инфу в соурс мапах). Всё это означает двойную работу.
Я как-то дебажил Rust через GDB, и скажу вам, source maps или JavaScript — это очень удобно в сравнении :D
— ts-node супермегатормоз при рестарте приложения от примерно 50K+ LOC. Плюс он поддерживает только сабсет фич из tsconfig.json.
— ts-jest работает раза в 3 медленнее jest и имеет те же проблемы с tsconfig.
— ts-loader для webpack никак не может догнать tsc по производительности (что неудивительно), а также у него проблемы с watch-режимом.
Также все эти ребята просто пасуют при попытке сделать человеческое monorepo-окружение.
При этом tsc, как ни странно, очень быстр:
— tsc -b компилирует супербыстро, если изменений мало;
— tsc —watch на удивление не глючит практически никогда (привет вотчерам вебпака и nodemon-у);
— даже использование ttypescript с плагинами не особенно-то его замедляют.
Но настроить все эти вотчеры и монорепо билд пайплайн, когда для всего-всего (велючая разработку) используется tsc, не так-то просто.
На костыльности утилит с префоксом ts-, кстати, пробует сейчас deno выезжать. Что-то не очень только у него выходит, но вдруг все же выедет.
А Babel весьма быстро работает, что с Jest, что в вебпаке. В принципе, логично, с учётом того, что всё, что он делает для TS — просто вырезает типы из AST. А проверку правильности типов можно и отдельно от компиляции делать.
Babel в 2020-м году (при условии, что основной код пишется в проекте на TS) — это анахронизм и еще больший костыль. TS сам отъел у него значительный кусок пирога и вряд отъест назад.
Хмм, в первый раз слышу такую точку зрения, если честно. И, пожалуй, с ней не соглашусь. Начиная с того, что у tsc невозможно выключить проверку типов при компиляции (ну, по крайней мере было невозможно на тот момент, когда я проверял в последний раз) и заканчивая тем, что tsc не поддерживает плагины, а значит огромные возможности по трансформации кода при компиляции оказываются отрезаны. Я бы сказал, что, скорее, пользоваться tsc — анахронизм с тех пор, как Babel ввёл поддержку Typescript.
P.S. Я не один так считаю, кстати. Самый популярный на данный момент стартер — create-react-app, — использует для трансформации Typescript именно Babel, а не tsc.
Почему лучше заранее компилировать TS в JS