Комментарии 13
Получается, если компилятор указывает на какое-то проблемное место — это можно считать как указание, что следует проанализировать поток данных и добавить необходимую валидацию. Если же проблемное место «закрывается» небезопасным приведением типа (в TypeScript такое тоже есть), или небезопасной инициализацией, как в случае с
Number(val), то разработчик сам переносит проблему обратно на стадию исполнения и лишает себя преимуществ строгой типизации.
any, но тогда смысл в использовании TS пропадает. Так можно только в крайних случаях.
При строгой типизации, когда вы создаёте переменную, нужно сначала сказать, какого типа будет эта переменная.
Уважаемый автор, нет, это не так называется. То, что вы описываете — это «явная + статическая» типизация, а вовсе не «строгая».
см. habrahabr.ru/post/161205
Если вы делаете небольшой одностраничный лендинг, где почти нет JS и важна скорость загрузки, то лишняя сложность может только навредить.
Если ts может и вставлять какие-то вещи в рантайм (но он так не делает), то наличие того же flow вообще не повлият на выходной размер файла. В чем проблема? Да и сейчас такие лендинги пошли — видео на всю страницу на фоне, а они заморачиваются на 4кб бейбелевского рантайма.
все эти языки и компиляторы делают ваш проект сложнее в поддержке
Все эти языки и компиляторы делают ваш проект проще в поддержке. Для этого они и придуманы, а то как-то странно: сложнее разрабатывать, сложнее поддерживать, какой прок тогда?
Эффективная работа с памятью в случае с TS неактуальна, потому он в любом случае будет скомпилирован в слабо типизированный JavaScript.
И да и нет. JIT не очень любит, когда функцию вызывают с какими попало типами одних и тех же аргументов, TS провоцирует подумать лишний раз чем делать функцию, принимающую и null и object и number и string. Но не запрещает.
Тот же Elm — он подойдёт вам гораздо лучше, если вам функциональный подход ближе объектно-ориентированного.
Elm слишком сильно "втирает" свою архитектуру. Это вообще компилятор-язык-раект-редукс в одном флаконе, что может оттолкнуть.
А о чем вообще статья? Что бывает javascript, а еще бывают языки, компилируемые в js? И дальше то что, это и так все знают.
А вот это шедевр: «В любом случае помните: все эти языки и компиляторы делают ваш проект сложнее в поддержке и настройке, да и кода меньше не становится». Ребята, которые используют TypeScript, знайте — вы глупы, зачем-то делаете свой проект сложнее в поддержке и настройке :)
Мне импонируют Coffeescript и… jQuery (кстати, я с Coffeescript познакомился после года работы с TS). Импонирует по одной простой причине — мне кажется код должен быть как можно проще, декларативный стиль понятнее чем императивный. И вот в как раз в этом Coffeescript даёт 100 очков вперёд ES6…
Ещё удалось попробовать Elm, чуть дальше чем простой Hello world. Но ощущения очень крутые.
много другого в ES забрали из Coffeescript
Почему все обожатели кофе так уверены, что разработчики ES6 смотрят именно на него (кофескрипт)? По сути в кофескрипте я не увидел ничего такого чего не было во всяких питонах, руби и тд., так какого спрашивается вы всюду пихаете это чудо как что-то принципиально новое?
Вы вообще видели систему типов OCaml? Заявлять, что система типов для типизации существующего кода на динамическом языке может быть похожа на систему типов языка изначально статического — это нонсенс. Эти системы типов решают совершенно разные задачи и, как следствие, разный дизайн.
Flow (а также тайспскрипт и другие подобные вещи) — про subtyping (опционально — структурный), occurence typing (для того чтобы типизировать динамический код), отсутствует ad-hoc полиморфизм (не выражается в семантике динамических языков), прямые суммы заменены объединениями (но могут быть сэмулированы кривым костылем).
В окамле — полноценные алгебраики с GADT, ad-hoc полиморфизм, глубокая система модулей (характерная особенность для семейства ML'ей), отсутствие динамических костылей в виде объединений и occurence typing'а
Сахарный JavaScript