Комментарии 43
Зачем использовать статические типы в JavaScript?
ну и зачем?
В вашей цитате описано отличие (которое и ежу понятно в чем заключается), но таки не написано зачем оно в JavaScript.
Я не то, чтобы похливарить собрался, просто в статье с названием "Зачем использовать статические типы в JavaScript?" хотелось бы увидеть это "зачем".
Это был просто комментарий о несоответствии заголовка и самой статьи, если еще не поняли. Ну и насчет "проще программировать" — существуют и иные точки зрения, причем также вполне обоснованные.
Ну вроде как иметь дополнительную информацию о типах — это лучше, чем не иметь ее вообще, разве нет? Тем более, что она опциональна и, при необходимости, легко обходится.
Иметь эту информацию можно и не прибегая к использованию Flow или TS. И еще раз хочу уточнить: я тут не защищаю какую-то конкретную позицию относительно подхода к типизации или инструментов для работы с типами (позиция у меня есть, но, повторюсь, не хочу холиварить). Почему это не понятно после уже двух уточняющих комментов — для меня загадка.
Каким образом? Мне тоже было бы интересно убрать стадию транспиляции из джаваскрипта.
Я знаю единственный вариант — это использование JSDoc комментариев, однако их функционал — это 1% от функционала Тайпскрипта (насчет Флоу не знаю). Плюс JSDoc не дружит с ES6+.
На самом деле это удобно.
Я очень долго скептически относился к белкам-истеричкам из лагеря Java и ей подобных (потому что там это действительно ужасно), но по факту с современными инструментами очень удобно писать (и читать чужой) явно типизированный JS.
Как раз венгерская нотация — самая вредная и бесполезная хрень в этом деле. Кое-где можно встретить JS с ней, это ужасно.
Венгерская нотация сильно затрудняет читаемость кода, однако, если "ужасные" классические односимвольные префиксы заменить на постфиксы-сокращения (типа Arr, Str, Num), и использовать их только там, где необходимо сделать акцент на типе — вполне рабочая штука.
Классическими я назвал те самые майкрософтовские префиксы, с которых все пошло. И мы ведь говорили о применении венгерской нотации именно в контексте типов. Ничего не вижу плохого в обозначении единиц измерения, но лично мне гораздо проще разбираться с кодом, если вся эта метадата существует в виде суффиксов и постфиксов — так оно как-то логичнее и ближе к естественному человеческому языку.
если вся эта метадата существует в виде суффиксов и постфиксов — так оно как-то логичнее и ближе к естественному человеческому языку.
Венгерский — не человеческий? :)
А по сути — я с Вами скорее согласен, чем нет. В конце концов это частный случай lowerCamelCase.
Не совсем правильно называть это "статическими типами", это скорее аннотации типов. Статическая типизация гарантирует (ну или пытается) отсутствие ошибок типов в рантайме. Ни флоу, ни тайпскрипт этого не гарантируют.
В статье и говорится, что это compile-time проверка, а не run-time.
Вся ваша типизация ломается ровно тогда когда вы начинаете колбэки использовать
Видно, что вы даже не пробовали.
А решается эта типизация простым человеческим наименованием переменных.
Почитайте что Спольски пишет про венгерскую нотацию.
ну так поправьте меня. Да, я даже не стал смотреть на документацию после того как я посмотрел в песочнице во что он преобразует код.
document.addEventListener('DOMContentLoaded', this.contentLoadedHandler);
Разве TypeScript сможет на этапе компиляции проверить что придет в аргументах функции «contentLoadedHandler»? Я ведь туда ничего явно не передаю.
Для этого существуют .d.ts файлы, которые описывают сигнатуры библиотечных классов/методов.
Допустим, вот описание для document.addEventListener.
Здесь утверждается, что сигнатура коллбэка будет EventListenerOrEventListenerObject, который в свою очередь ссылается на EventListener:
interface EventListener {
(evt: Event): void;
}Отсюда видно, что придет в аргументах функции: это объект типа Event
Вот скрин http://take.ms/pIYE4.
Вы не поверите...
А могли с самого начала ActionScript внедрить в браузеры. Как вариант.
Ruby, Python — нет статической типизации. Все пишут и вроде никто не топит за нее.
И IDE для этих языков есть и работают они хорошо.
PS пробовал и кофескрипт и тайпскрипт — не пошло.
возможность compile-time проверки типов с помощью аннотаций, поддерживаемых языком — один из больших плюсов третьей версии.
PS если я где ошибся, приведите линк. Так как больше полутора лет уже не пишу на питоне.
Вы правы, никто не заставляет типизировать код, тем не менее по моему опыту существуют проекты, где типизация сократила бы (и уже сокращает!) нужду в количестве юнит тестов, читаемость кода.
Да, возможно типичному джанго-сайту тайп хинтинг не нужен, а вот специализированному фреймворку поверх джанго (таких за мою карьеру пришлось писать 3 штуки) или большому вики-проекту с десятками тысяч LOC и тысячами тестов — весьма.
Естественно это лишь мой личный опыт, но даже он показывает что своя аудитория у этой фичи есть, как и TypeScript в js (к слову на последнем месте работы большой фронтендовый проект как раз на TypeScript переводили и в целом остались довольны).
Также, не совсем понимаю пассаж про «основные фреймворки написаны таки на питоне» — mypy это лишь статический анализатор, который работает с тайп хинтами python 3.5, это не отдельный интерпретатор. Вы можете встроить его в свой CI пайплайн, как тот же flake8 и он будет
Если тот же Python не устраивает из-за отсутствия статической типизации, можно просто выбрать другой язык. А если нужно исполнять код в браузере, альтернатив JavaScript нет, вот и приходится жевать кактус. Вполне естественно желание некоторых разработчиков сделать его не таким колючим.
WebAssembly — не панацея, поскольку неспособен работать с DOM, так что писать обвязку на JavaScript всё равно придётся.
Части 2 и 3. Преимущества и недостатки статических типов (с детальным примерами).
Часть 4. Нужно ли использовать статические типы в JavaScript или нет?
Объедините их, чтобы не сбивать с толку, что что-то пропущено. Я долго искала часть 4, пока не прочла всё)
Или разбейте статью, как в оригинале.
Зачем использовать статические типы в JavaScript? (Пример статической типизации на Flow)