Стоит ли в 2017 обмазываться JS'ом и его производными?

Кстати, а как во флоу делается ди? Там же нет интерфейсов.

Стоит ли в 2017 обмазываться JS'ом

А в 2017 появилась какая-то альтернатива жаваскрипту?

Устал ждать этого вашего WebAssembly.

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

TypeScript нормально же выглядит?

Ну у него преимущество в том, что любой код на жс автоматически валидный код на тайпскрипте. Учится за 20 минут. Как преимущество в том, что опечатки находятся на этапе компиляции, хотя и в обычном жс находятся линтером. Сама система типов слабая, всеравно от any не получается избавиться. Ковариантность и контрвариантность еще не подвезли. Зато в новой версии появились async & await. Для упертого жаваскриптера даже наоборот создает больше сложностей. Например, к тебе приходит какая-то модель с сервера. На тайпскрипте нужно еще написать класс со всеми свойствами, описывающий эту модель, тогда как на обычном жаваскрипте такого делать не надо.

Еще, если ты совсем нуб и тебе такие слова, как webpack, gulp, grunt и т.п. ни о чем не говорят, то готовься к неимоверной жопной боли. Я вот использовал такое: https://github.com/AngularClass/angular2-webpack-starter

Попробуй подключить буэтсрап к вебпаку и пойдет-поедет. Такое, в общем.

Устал ждать этого вашего WebAssembly. Неизвестно когда из под флага вылезет (на сайте написано «может Q1 2017, а может и нет»), неизвестно сколько лет будут запиливать threads, GC / DOM integration, Coroutines, JIT и прочее.

Зачем его вообще ждать?

TypeScript нормально же выглядит? Статически типизируемый, всё работает уже сегодня, разрабатывается честными людьми из организации, которая не лицемерит.

Да вообще отлично выглядит. Можешь ещё на Kotlin посмотреть, похоже ты не прочь экспериментировать.

Сама система типов слабая, всеравно от any не получается избавиться.

Это неправда, на данный момент any в либах практически отсутствует, при этом типа хорошо отражают семантику и дают очень хорошие гарантии. Когда добавят гварды для mapped типов, то система типов, по факту станет эквивалентна (или даже сильнее) хаскелю.

Ковариантность и контрвариантность еще не подвезли.

И хорошо, если так и не подвезут (разве что вшитую для предопределенных типов вроде ф-й и массивов). Польза от нее - примерно нулевая, а проблем - выше крыши.

Так проставь нужные типы. Ты можешь нормально объяснить, чего ты хочешь, и в чем проблема?

Проблема: хочу в миллион LOC кодобазе начать юзать тайпскрипт, не проверяя в каждом методе undefined, но имея какие то гарантии что его там нет.

Ты же сказал, что фичи ранних стадий использовать нельзя. Потому что они могут быть выпилены/переделаны, а значит, тебе придется переписывать свой код. Именно это ты называл в качестве недостатка тс.

Я могу сапортить бабел трансформеры старых версий бесконечно, я могу автоматически трансформить код который парсится бабелом. Я не могу этого делать с ТС.

Как и асбтрактные классы, как и модификаторы доступа.

Абстрактные классы нельзя выкидывать в них есть(может быть) реализация методов. Модификаторы доступа нельзя положить рядом с файлом.

А тс я чем компилирую?

Тайпскприптом. Кэп.

нет интерфейсов

Есть же https://flowtype.org/docs/syntax.html#interface-declarations

Иван, мы все решили на go переписать, забудь про жабакрипту. (с)
А вообще – ты задаешь странные вопросы.

2017
javascript
web-development

И чем тебе не сочетание?

Вебпак - дерьмище ещё то. Уж лучше самому ручками собирать css фреймверки гульпом и rollup + bubel для es6 модулей.

Проблема: хочу в миллион LOC кодобазе начать юзать тайпскрипт, не проверяя в каждом методе undefined, но имея какие то гарантии что его там нет.

Значит проставляй типы. Как еще?

Я могу сапортить бабел трансформеры старых версий бесконечно, я могу автоматически трансформить код который парсится бабелом. Я не могу этого делать с ТС.

Почему не можешь?

Абстрактные классы нельзя выкидывать в них есть(может быть) реализация методов. Модификаторы доступа нельзя положить рядом с файлом.

Выкидывается «abstract» и, возможно, абстрактные методы (надо смотреть реализацию, тут точно не скажу), сам класс остается. Модификаторы доступа просто выкидываются, зачем их куда-то класть?

Тайпскприптом. Кэп.

А в чем разница между тайпскриптом и плагином для бабела?

Ок, значит, добавили.

Значит проставляй типы. Как еще?

Ок, как мне проставить типы в половине файла в тайпскрипте с noAny и strictNullCheck? Я напоминаю что это тред про то что тайпскрипт на порядок более вирусный и менее удобный для итеративного включения в проект.

Почему не можешь?

Потому что тайпскрипт - не жс. Потому что они не хотят работать с ванилла комьюнити чтобы законвержится на каком то общем парсере.

А в чем разница между тайпскриптом и плагином для бабела?

Тебе все равно нужен бабел, чтобы либо поддержать старые браузеры либо наоборот не шипить то что уже реализовано в твоих таргетах.

Модификаторы доступа просто выкидываются, зачем их куда-то класть?

Еще раз. Imagine: es2018 аннотации типов стандартизированы приблизительно как в питоне, то есть без семантики. Flow можно не компилировать если ты хранишь дефинишны рядом с сорсами. TS все еще нужно компилировать.

Неосилил документацию прочитать чтоле?

Ок, как мне проставить типы в половине файла в тайпскрипте с noAny и strictNullCheck?

Сперва ставишь явные any там, где надо (т.к. объявлений типов в жс нет, то это обычно очень мало мест и проблем не составляет), потом меняешь по частям

хотя я и не могу представить себе ситуацию, при которой может потребоваться типизировать файл по частям

Я напоминаю что это тред про то что тайпскрипт на порядок более вирусный и менее удобный для итеративного включения в проект.

Более удобный за счет:

1. лучше инференс

2. богаче система типов, лучше отражает жс идиомы

3. не sound, нету вариантности и других таких вещей, котоыре сильно мешают

Тебе все равно нужен бабел, чтобы либо поддержать старые браузеры либо наоборот не шипить то что уже реализовано в твоих таргетах.

А при использовании флоу бабел не нужен?

Еще раз. Imagine: es2018 аннотации типов стандартизированы приблизительно как в питоне, то есть без семантики. Flow можно не компилировать если ты хранишь дефинишны рядом с сорсами.

1. Надо быть совсем отбитым, чтобы хранить все дефинишины отдельно. Этот код проинципиалньо не поддерживаем.

2. Компилируешь тс в жс, все аннотации стираются и только они, в остальном код неизменен (ну да, енумы становятся рассахаренными, акей. это уж точно не проблема).

Потому что тайпскрипт - не жс. Потому что они не хотят работать с ванилла комьюнити чтобы законвержится на каком то общем парсере.

Так флоу - тоже не жс, со всеми соответствующими проблемами. В чем разница?

Сперва ставишь явные any там, где надо (т.к. объявлений типов в жс нет, то это обычно очень мало мест и проблем не составляет), потом меняешь по частям

Это очень много мест с noImplicitAny и они потом везде утекают undefined значения см пример.

хотя я и не могу представить себе ситуацию, при которой может потребоваться типизировать файл по частям

Я хочу strictNullChecks, мне надо затипизировать все возможные коллстеки до того места где я хочу иметь тайпскрипт. Но я не хочу типизировать остальные 950 тыщ строк кода которые лежат рядом.

Более удобный за счет:

Эти удобства никак не влияют на возможность привезти тайпскрипт в очень большую кодобазу. Про богаче систему типов и инференс конечно хотелось бы посмотреть примеров.

А при использовании флоу бабел не нужен?

Нужен, но не нужен отдельный компилятор.

1. Надо быть совсем отбитым, чтобы хранить все дефинишины отдельно. Этот код проинципиалньо не поддерживаем.

Увидимся в 2018.

2. Компилируешь тс в жс, все аннотации стираются и только они, в остальном код неизменен (ну да, енумы становятся рассахаренными, акей. это уж точно не проблема).

Не важно что там остается, важно то что я никогда не смогу шипить ts файлы и буду билдить их часами^W минутами на достаточно большой кодобазе.

Так флоу - тоже не жс, со всеми соответствующими проблемами. В чем разница?

Флоу разработчики комитят в бабел парсер. Не делают фичи которые мешают их мусор с реальным кодом (кроме аннотаций, но это будет стандартизировано с большой вероятностью)

Это очень много мест с noImplicitAny и они потом везде утекают undefined значения см пример.

Чтобы не утекали undefined - проставляй типы. Ты хочешь противоречивых вещей.

Я хочу strictNullChecks, мне надо затипизировать все возможные коллстеки до того места где я хочу иметь тайпскрипт. Но я не хочу типизировать остальные 950 тыщ строк кода которые лежат рядом.

Типизируешь то что нужно, в остальных местах ставишь any. Точно так же, как во флоу, короче.

Эти удобства никак не влияют на возможность привезти тайпскрипт в очень большую кодобазу.

Коненчо влияют. Это снижает общие затраты на добавление типов.

Нужен, но не нужен отдельный компилятор.

Как не нужен? А флоу - это что? Отдельный компилятор флоускрипта в джаваскрипт.

Увидимся в 2018.

Жри кактус, ок.

Не важно что там остается, важно то что я никогда не смогу шипить ts файлы

Флоу-файлы тоже никогда не можешь.

и буду билдить их часами^W минутами на достаточно большой кодобазе.

У меня тс компилирует в es6 примерно раза в четыре быстрее, чем бабел потом в es5. ТАк что временем компиляции в тс реально можно пренебречь.

Флоу разработчики комитят в бабел парсер.

И что?

Не делают фичи которые мешают их мусор с реальным кодом

А как же декларации типов, которые неюзабельны, если писать их в комментах или в отдельном файле?

И зачем их писать по отдельности, если можно просто их стереть автоматически потом и получить жсники без деклараций?

(кроме аннотаций, но это будет стандартизировано с большой вероятностью)

Вероятность этого примерно 0 (ноль).

Типизируешь то что нужно, в остальных местах ставишь any. Точно так же, как во флоу, короче.

Нет, в отличии от тайпскрипта флоу работает просто с джаваскриптом. Ему никакие аннотации для анализа дата-флоу и вывода типов не нужны. Остальные места это недели работы чисто на проставление any.

Отдельный компилятор флоускрипта в джаваскрипт.

Флоу это не язык это чекер типов. Он ничего не умеет компилировать.

У меня тс компилирует в es6 примерно раза в четыре быстрее, чем бабел потом в es5. ТАк что временем компиляции в тс реально можно пренебречь.

Если ты процессишь 3rd party зависимости бабелом, то у тебя просто очень мало ts кода. Или много утекающих any которые никак не чекаются.

Флоу-файлы тоже никогда не можешь.

Пока не могу.

Ему никакие аннотации для анализа дата-флоу и вывода типов не нужны.

Ну так тогда не вырубай imlicitany, если урками не хочешь ставить. Получишь то же самое.

Остальные места это недели работы чисто на проставление any.

Проставить два-три десятка any - неделя работы? Серьезно?

Флоу это не язык это чекер типов.

Конечно, язык. Надмножество джаваскрипта. Которое компилируется в джаваскрипт. Если его не скомпилировать - то это не будет джаваскрипт. Запустить код на флоускрипте нельзя без компиляции в жс.

Если ты процессишь 3rd party зависимости бабелом

Конечно нет, ты что? Ну и я не говорю, что тс очень быстр, нет. Это бабел - очень тормозной (архитектура чрезвычайно кривая). В любом случае, если ты используешь бабел - то влияние тс не превысит десятки процентов,

Пока не могу.

И не сможешь. Если декларации и добавят (а этого не будет) - то в синтаксисе тс, потому что кодовая база тс в десятки раз больше, чем у маргинального флоу.

Проставить два-три десятка any - неделя работы? Серьезно?

Я тебе еще раз повторю: представь у тебя 1M LOC кодобаза. Без noimplicitany strictnullchecks бесполезны, ты никогда не знаешь откуда там приедет any.

Если его не скомпилировать - то это не будет джаваскрипт

Ты не правильно про него думаешь, единственная проблема это аннотации, но он может делать чеки и без них. Флоу это не язык, это сбоку такая штука которая умеет выводить и проверять типы.

Если декларации и добавят (а этого не будет) - то в синтаксисе тс

Нет, потому что тс залез в семантику языка. Скорее всего по этой причине мы никогда не получим модификторы доступа в языке, потому что зная наркоманов из tc39 они никогда не захотят просто скопипащеные ото всюду private/protected/public. А сделать другие не получится потому что это сломает ТС.

У меня тс компилирует в es6 примерно раза в четыре быстрее, чем бабел потом в es5.

Правильно я понял, что современные жоэсники пишут на одном языке, транслируют в другой, а потом еще раз в третий? Крутые технологии, чо.

Сделали бы уж тогда на верхнем уровне себе приличный ЯП что ли, а не очередной диалект этого недоразумения.

Он просто не нужен. Есть rollup.

Я тебе еще раз повторю: представь у тебя 1M LOC кодобаза.

Ну? Ты же не собирашеься за раз ее всю переводить?

Без noimplicitany strictnullchecks бесполезны, ты никогда не знаешь откуда там приедет any.

Ну да, не знаешь. Поэтому надо везде проверять на undefined.

Мне непонятны твои претензии. Если ты не хочешь проверок - ставишь any (явно или неявно), если ты хочешь убедиться, что нуллы нигде не пролезли - изволь ставить проверки. Ты видишь какой-то другой вариант?

Ты не правильно про него думаешь, единственная проблема это аннотации

Так и тс отличается от ванильного жса только аннотациями (ну енумы, еще да, но мы же не будем обращать на такюу мелочь внимания?).

но он может делать чеки и без них.

Без них - у него просто нету информации о типах. Допустим, у тебя есть ф-я fun(x, y, z) - поскольку аннотаций типов нет, флоу обязан считать, что все переменные - any. Точно также, как и тс. То есть это чеки очень ограниченные, и не дающие какого-то практического профита (так же как если ты расставишь повсюду any с тс).

Нет, потому что тс залез в семантику языка.

Нет, не залезал. Еще раз, единственное, что есть в тс кроме аннотаций, как мы уже выяснили - енумы. Все. Ничего больше.

Правильно я понял, что современные жоэсники пишут на одном языке, транслируют в другой, а потом еще раз в третий? Крутые технологии, чо.

До последней версии тс не умел компилировать асинки в ес5, только в ес6. Так что рпиходилось компилировать жс в жс (но другой). Сейчас умеет и этот шаг исключен (ускорив общее время на сборку раза в 3).

Приличных языков много. Смысл тса - в обратной совместимости с жсом, как следствие - низком пороге вхождения и возможности постепенной миграции.

Ну? Ты же не собирашеься за раз ее всю переводить?

Нет, но с тс у меня нет выбора. Я не могу ставить типы только там где мне хочется, я не могу включать-выключать файлы из проверки, я не могу сапресить ошибки.

Ты видишь какой-то другой вариант?

Да, я захожу в очень длинный файл и аннотирую одну функцию которая зовет критичный код.

Так и тс отличается от ванильного жса только аннотациями (ну енумы, еще да, но мы же не будем обращать на такюу мелочь внимания?).

Мне тут надоело по кругу ходить. Абстрактные классы, модификаторы доступа. Это не аннотации типов и вот как раз они не факт что когда-либо пролезут в стандарт.

Без них - у него просто нету информации о типах

В этом вся фишка флоу, он инферит типы по юзаджу [далеко от дефинишна].

https://flowtype.org/try/#0GYVwdgxgLglg9mABALwBQEpEG8BQjEBOAplCAUgIwDMOAvjjqJ...

что есть в тс кроме аннотаций

Модификаторы классов и полей это не аннотации типов.

До последней версии тс не умел компилировать асинки в ес5

Это возвращаясь к nih и нежеланию работать с комьюнити. Еще одна фича с нетривиальной трансформацией для обратной совместимости - еще год сидеть и ждать пока они это на коленке реиплиментируют, оно еще потом и в рантайме будет медленнее полгода.

Допустим, у тебя есть ф-я fun(x, y, z) - поскольку аннотаций типов нет, флоу обязан считать, что все переменные - any.

Не обязан. Тип можно вывести по использованию переменных.

Не обязан. Тип можно вывести по использованию переменных.

Это не хаскель. В жс нельзя.

хорош уже чушь нести

Мне тут надоело по кругу ходить. Абстрактные классы, модификаторы доступа. Это не аннотации типов

Это самые что ни на есть аннотации. Они никак не влияют на итоговый код, просто стираются и все.

Нет, но с тс у меня нет выбора. Я не могу ставить типы только там где мне хочется, я не могу включать-выключать файлы из проверки, я не могу сапресить ошибки.

Как нет? Почему все могут, а ты - не можешь?

Да, я захожу в очень длинный файл и аннотирую одну функцию которая зовет критичный код.

Ну и после этого тебе надо аннотировать все места, где эта ф-я используется, иначе там будут ошибки типов (если, конечно, у ф-и аргументы не any)

Нормальный человек не будет вручную конфигурировать всю систему сборку проекта с нуля. Потому приходиться использовать, что уже есть. Для ангуляра второго нормальный стартерпак пока только на вебпаке я нашел. А как начнешь читать, так - «квок-ко-ко-кудах, гульп это слишком 2015, фууу»

Это неправда, на данный момент any в либах практически отсутствует, при этом типа хорошо отражают семантику и дают очень хорошие гарантии.

Иногда бывает такое, что надо всунуть архаичную либу на жквеири и хоть убейся, к сожалению.

И хорошо, если так и не подвезут

Ну не знаю, не сказать, что я пока сильно страдал от отсутствия. Ибо в шарпе они нужны из-за устройства коллекций, всех этих IEnumerable, IQueryable, ICollection, IList и т.д. а для тайпскрипта линкью еще нет. Над шарпом и тайпскриптом работает один и тот же человек - Андерс Хейлсберг.

хорош уже чушь нести

Ну а чо, полтора года имплементировали async/await. Потом еще почти год делали компиляцию в es5.

Ну и после этого тебе надо аннотировать все места, где эта ф-я используется, иначе там будут ошибки типов (если, конечно, у ф-и аргументы не any)

Ты можешь читать что тебе пишут или нет. Если мы не используем strictnullchecks и noimplicitany эти аннотации ничем не лучше линтера. Если используем мне надо править весь файл.

Наоборот, гульп сейчас приколачивают к TypeScript на ура, для тряски дерева. Я решил уйти от angular2 к vue2. И ничуть не жалею.

Ну а чо, полтора года имплементировали async/await.

Ты бредишь

Ты можешь читать что тебе пишут или нет. Если мы не используем strictnullchecks и noimplicitany эти аннотации ничем не лучше линтера. Если используем мне надо править весь файл.

Тебе надо только проставить any, что дело пары минут.

Ты бредишь

https://github.com/Microsoft/TypeScript/issues/5

Тебе надо только проставить any, что дело пары минут.

Пятый раз по кругу пойдем? Проставить у несколько десятков тысяч функций any это не дело пары минут.

Пятый раз по кругу пойдем? Проставить у несколько десятков тысяч функций any это не дело пары минут.

Я хз чо ты по кругу ходишь. Еще раз, варианта (не в тс, а в принципе) только два - либо ты проставляешь нужные типы, либо не проставляешь и пишешь везде проверки на нуллы. Третьего вариант не существует.

Третьего вариант не существует.

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

В третий раз напомнинаю, это все в тред в котором ты почему то думаешь что тс принести в огромную кодобазу проще чем флоу.

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

Он нигде не работает, потому что типы надо ставить не только там? где ты хочешь, а во всех зависимых ф-ях. Иначе - изволь проверять на нуллы.

На тайпскрипте нужно еще написать класс со всеми свойствами, описывающий эту модель, тогда как на обычном жаваскрипте такого делать не надо.

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

а во всех зависимых ф-ях

Я готов это сделать, но мне придется проставить типы во всех файлах с зависимыми функциями из-за noimplicitany и выбраного подхода тс.

Ну там классы не далеко от нативных ушли (вообще никуда не ушли, если мы оставим тайпчек за скобками)

Свойства есть, и то хлеб

Они и в es5 есть, а в es6 есть даже краткий синтаксис. Жаль что автосвойств нет, но с этим жить можно.
Конечно тайпчекинг в тс вещь отличная, хоть и порой порождает некоторые проблемы, но в целом, для крупного проекта я бы выбрал его.

Я готов это сделать, но мне придется проставить типы во всех файлах с зависимыми функциями из-за noimplicitany и выбраного подхода тс.

Проставить any. Это дело 5 минут.

Утомил. Нет это не дело пяти минут. Нет я не хочу потом следить за тем что я вызываю из функций где проставил any.

Нет я не хочу потом следить за тем что я вызываю из функций где проставил any.

Не хочешь следить - ставь нормальные типы. За тебя их никто не поставит.