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

можно назвать значительные архитектурные ошибки.

Да, было бы интересно.

Мы, вроде, обсуждаем то, что сейчас. Чего там будет в светлом будущем - не особо важно.

Кому как. Мне это даже важнее.

«Был у меня один друг, программировал на JS и бекенд и фронтенд, рассказывал, что всё круто, быстро, удобно, многопоточно. Сейчас он рехнулся, разумеется» (С) LOR

В js нет многопоточности

Быть джаваскриптизёром - самая стыдная работа, даже стыднее, чем «делать сайты», не уточняя, на чём именно. Обмазывайся в 2017 году НАСТОЯЩИМ языком программирования, любым, и ищи работу настоящим программистом.

В 2017 все так или иначе связано с сетевым программировванием и в частности с веб.

Да, было бы интересно.

При дизайне системы типов в тс и flowtype исходили из разных целей. Смысл тс - возможность (и удобство) типизации существующего кода на жс, и часто используемых в жс паттернов. В flowtype же первична soundness. Если рассматривать инструмент именно как система типов поверх существующего языка - подход тс безусловно более оптимален. С другой тсороны, конечно, если рассматривать их как отдельные языки вне контекста жс и кода на жс, то тот же самый фактор может оказаться преимуществом как раз flowType.

Кому как. Мне это даже важнее.

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

Оно станет «дохлое, месяц не обонвлялось!» и все убегут учить NIH-WebAssembly-NG 2.0

В js нет многопоточности

Есть.

тс без аннотаций (например если их стандартизируют когда-нибудь) - это не жс, как минимум изза енамов.

Смысл тс - возможность (и удобство) типизации существующего кода на жс, и часто используемых в жс паттернов

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

А кто-то утверждал обратное? жс - подмножество тс (то есть любой жс является тсом), а не наоборот.

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

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

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

Есть.

Нету.

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

Flow без аннотаций - это js. ТС без аннотаций - нет. Что в общем важно если его перестанут развивать или ты его захочешь выкинуть.

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

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

А тайпскрипт это такой язык где каждый тип по умолчанию может быть null или undefined, карл. Натяп-ляпали не подумав сначала, а теперь героически преодолевают, имея в каждом втором тикете 'это будет очень сложно заимплементировать с нашим подходом'.

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

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

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

Точнее, джаваскрипт - язык, где каждый тип по умолчанию может быть null/undefined. А поскольку тс дизайнится с целью типизации существующего жс-кода, то это вполне естественное решение, во флоу написание типов для существующих библиотек из-за nonnulable становится на порядок сложнее.

Flow без аннотаций - это js. ТС без аннотаций - нет. Что в общем важно если его перестанут развивать или ты его захочешь выкинуть.

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

Так это все и в тс есть

Вот тут поподробнее. Есть у меня какой-то мишн критикл кусок из 1к строк в проекте на 100к строк, как мне его затайпчекать в тс не типизируя все его зависимости.

Точнее, джаваскрипт - язык, где каждый тип по умолчанию может быть null/undefined. А поскольку тс дизайнится с целью типизации существующего жс-кода, то это вполне естественное решение, во флоу написание типов для существующих библиотек из-за nonnulable становится на порядок сложнее.

Честно я не понимаю какой выхлоп от тайпчекера для языка с самой популряной ошибкой undefined is not a function, если он везде утекает нулы и андефайнед.

чтобы выкинуть flow придется весь этот код прошерстить

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

Есть у меня какой-то мишн критикл кусок из 1к строк в проекте на 100к строк, как мне его затайпчекать в тс не типизируя все его зависимости.

Точно также, как и в typeflow, проставить везде any.

Честно я не понимаю какой выхлоп от тайпчекера для языка с самой популряной ошибкой undefined is not a function, если он везде утекает нулы и андефайнед.

Так 99% ошибок с нуллами никак не связаны.

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

Ничего ломающего язык они не придумывают, вообще-то. Просто реализуют наперед вещи из es.

Не путаем с асинхронностью и многопроцессностью?

А мы не путаем язык с окружением?

Многопоточность реализуется окружением, а не языком. Будь то vm или ос. Браузер тебе, например, предоставляет многопоточность по средствам webworker'ов.

Когда изучишь азу, тогда приходи.

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

Вебвеборкеры и прочие кластеры это полноценные изолированные процессы со своей кучей, пространством имён и тд. Взаимодействие осуществляется через посыл сообщений, а не прямой доступ к объектам. Тут и все вытекающие накладные расходы на передачу. Жабка же, как и С и С++ и много других языков даёт обычную многопоточность с прямым доступом и необходимостью использовать средства синхронизации.

Можно конечно порассуждать на тему что такое поток, что бывает поток изолированный от соседнего, но работает по прежнему в рамках одного процесса и тд и тп. Но это сильно плавает в зависимости от платформы. Но в общем случае webworkerы и прочие механизмы - это механизмы многопроцессные.

Вебворкеры это не нодовские кластеры. Это именно потоки процеса. У них есть общая память. Учите матчасть.

проставить везде any

Не, во флоу мне нигде ничего ставить не надо. И я могу сказать любому файлу - я тут еще не закончил аннотации - не тайпчекайся.

Так 99% ошибок с нуллами никак не связаны.

Не, если я сделаю как ты мне советуешь в #1 у меня вообще везде в этой 1k мишон критикол куске может быть undefined. Вообще везде. Даже в аннотированных функциях внутри этого модуля.

Просто реализуют наперед вещи из es.

Они даже не поддерживают то что уже работает в хроме (привет rest spread).

Не, во флоу мне нигде ничего ставить не надо. И я могу сказать любому файлу - я тут еще не закончил аннотации - не тайпчекайся.

Всмысле не руками ставить, он выводится. Ставишь --allowJs (js файлы теперь будут собираться, но не будут тайпчекаться), дальше в своем .ts файле (который ты переписываешь) загружаешь зависимости как var x = require("./module.js"), тип х - any, вызывай спокойно любые методы на нем.

Не, если я сделаю как ты мне советуешь в #1 у меня вообще везде в этой 1k мишон критикол куске может быть undefined. Вообще везде. Даже в аннотированных функциях внутри этого модуля.

Ну так он по факту у тебя везде есть. Сам жс код так написан. Хочешь переписать и уточнить типы - не вижу проблем, ставишь --strictNullChecks.

Они даже не поддерживают то что уже работает в хроме (привет rest spread).

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

Опять двадцать пять, это я знаю, однако это не делает их полноценными потоками потому, что у каждого из этих потоков своя gc и своя память на уровне js. Да, они разделяют ресурсы, но не переменные!. Но в сравнении с прямым доступом - это не то совершенно.

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

И если уж любите по дискутировать, то вот выдержка из mdn - «Данные передаются между worker-ами и главным потоком через систему сообщений — обе стороны передают свои сообщения используя метод postMessage(), и отвечают на сообщения при помощи обработчика событий onmessage (сообщение хранится в аттрибуте data события Message.) Данные при этом копируются, а не делятся.»

Взято отсюда https://developer.mozilla.org/ru/docs/DOM/Using_web_workers .

Опять двадцать пять, это я знаю, однако это не делает их полноценными потоками потому, что у каждого из этих потоков своя gc и своя память на уровне js.

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

Ставишь --allowJs

Опять таки не решает проблему с незакончеными аннотациями.

Ну так он по факту у тебя везде есть.

Нет по факту его там нигде нет. По крайней мере по задумке.

ставишь --strictNullChecks

Который не так давно появился, Карл. И который тебя заставляет по сто раз проверять тип в ситуациях когда там гарантированно не может быть null/undefined.

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

Просумировав это все - тс это не жс. Там есть конструкции которых нет в модном js, ты не можешь использовать все то к чему привык в ванила жс. Навелосипедили свой парсер и сборщик который хочет видеть весь мир, чтобы это было очень трудно препроцессить добавляя esX фичи. Технологически/архитектурно тс серьезно уступает flow. Единственная выгода - есть много дефенишнов (часть из которых кстати flow умеет понимать).

Ещё один ыксперт, который знает только один механизм управления памяти и сборки мусора? Тут я могу только добавить, что везде, где используются общие ресурсы есть куча мест синхронизации и да, это делает параллельный код не параллельным. Какая же это новость! Нужно это зачастую для снижения стоимости потоков и их взаимодействия. Чем меньше нужно выделять памяти на поток, чем ниже стоимость передачи данных из потока в поток, тем, в ряде случаев, будет эффективнее работать код, независимо от того насколько там будет много мест, где потоки зафризятся. Естественно это нужно не всегда и не везде и поэтому процессы живут и здравствуют.

Вы не знаете что такое общая память?

Да, вебворкеры не делят объекты. Они делят память. Без копирования онной. окружение само котролирует и синхронизиует доступ к ней.

Гуглите типизированные массиивы и шаренные типизированные массивы.

не делает их полноценными потоками

Теперь мы будем судить о полноценности? На уровне ОС это потоки. На этом можно заканчивать дискурс.

Взято отсюда https://developer.mozilla.org/ru/docs/DOM/Using_web_workers .

На той самой странице, вы как-то умело пропустили Передача данных с помощью передачи владения (передаваемые объекты)

Transferable objects are transferred from one context to another with a zero-copy operation

И это о простых блоках памяти. А вот вам полноценная шаренная https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...

Это не отменяет того факта, что тс тут напорядок более удобен

http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html#/2

http://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html#/

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

Что до шареных, особенных массивов, то оно стоит особняком, как дополнение и опять же говорит нам о том, что js однопоточен сам по себе. Плюс реализация шареных массивов может быть какой угодно, например через shared memory.

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

Естественно это нужно не всегда и не везде и поэтому процессы живут и здравствуют.

Они живут и здравствуют в языках без гц.

Нет по факту его там нигде нет.

В подавляющем большинстве жс-кода - есть. Ну ок, допустим в твоем - нету. --strictNullChecks и проблемы нет.

И который тебя заставляет по сто раз проверять тип в ситуациях когда там гарантированно не может быть null/undefined.

Если гарантированно не может быть null/undefined, то тип будет nonnullable и проверять ничего не надо. А если тип nullable, то null/undefined там может быть. И какие, собственно, варианты? В typeflow как-то не так?

Просумировав это все - тс это не жс.

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

Там есть конструкции которых нет в модном js,

Конкретнее. Какие конструкции?

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

Не могу использовать что?

Технологически/архитектурно тс серьезно уступает flow.

Можно узнать, в чем уступает? Кроме того, что тс удобнее, более развит, в нем больше фич и лучше поддержка?

Навелосипедили свой парсер и сборщик который хочет видеть весь мир

Кажется, ты бредишь.

Как паз то про что я говоорю. Тс - для удобства использования, флоу - для ненужных выебонов про корректность.

А я вот в одно рыло вебсервис и приложения. И чтоб на android 2.3 и iphone 4 работало. Babel к чертям съест память, и тот же input file отвалится. А мои клиенты - люди консервативные.

Какая разница, реализована асинхронномть тредами или как в жс?

И какие, собственно, варианты? В typeflow как-то не так?

function foo(test: string) {
  test.toLowerCase()
}

let bar;

if (bar) {
	foo(bar)  
}

foo(bar)

http://www.typescriptlang.org/play/

https://flowtype.org/try/

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

Не могу использовать что?

/0

Конкретнее. Какие конструкции?

Rest spread. Который все хипсторы уже года полтора юзают.

Можно узнать, в чем уступает?

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

Кажется, ты бредишь.

Бредят люди которым для сборки файла нужно все дерево зависимостей в памяти.

в возможности распределения нагрузки по ядрам процессора.

Выше уже написали, что это от синтаксиса не зависит. У питона полный фарш с тредами на уровне синтаксиса (можно прототип c++ программы с тредами наваять), но по сути в одном потоке выполняется.

надо возвращаться к истокам, только VB script

http://www.typescriptlang.org/play/
https://flowtype.org/try/

С strictNullCheck это код в тс и флоу абсолютно одинаково себя ведет. Что сказать-то хотел?

/0

И где деление на ноль тут?

Rest spread. Который все хипсторы уже года полтора юзают.

Ну так он уже есть.

То что во флоу бесплатно изза выбранного подхода (непосредственно анализ дата-флоу/вывод типов)

Что именно бесплатно? Пока что практика показывает, что бесплатно как раз в тс - благодаря грамотно подобранной системе типов. А дата-флоу анализ и вывод типов там практически эквивалентен (в тс по-лучше, но ненамного, так что можно считать что одинаково все)

Бредят люди которым для сборки файла нужно все дерево зависимостей в памяти.

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

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

Выше уже написали, что это от синтаксиса не зависит.

Я про синтаксис ничего и не говорил. И там же выше написали что на текущий момент ни в браузерах ни в ноде нету многопоточности.

С strictNullCheck это код в тс и флоу абсолютно одинаково себя ведет. Что сказать-то хотел?

Эээ? Ты в options включи strictNullCheck и посмотри как он себя реально ведет.

И где деление на ноль тут?

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

Ну так он уже есть.

Он есть месяц. У тех у кого не достаточно работы, дай только пообновлять тайпскрипт. Завтра появится еще какой-нибудь пропосал который будет долго попадать в stage3 и мы опять будем год писать на недожс.

Что именно бесплатно?

Пример проверь по факту а не глазами, если ты не знаешь как работает тайпскрипт.

Во-первых, тс не занимается сборкой файлов.

Я прямо ts шипаю в браузер?

Эээ? Ты в options включи strictNullCheck и посмотри как он себя реально ведет.

И реально выдаст ошибку в последнем вызове foo.

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

А до этого ты говорил, что реализация пропозалов - это зло, ведь они могут отмениться/переделаться и тебе придется рефакторить код. А теперь оказывается, что так и надо. Среди самого себя уж определись, а?

Он есть месяц. У тех у кого не достаточно работы, дай только пообновлять тайпскрипт. Завтра появится еще какой-нибудь пропосал который будет долго попадать в stage3 и мы опять будем год писать на недожс.

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

Я прямо ts шипаю в браузер?

А ты прямо флоу шипаешь в браузер?

Пример проверь по факту а не глазами, если ты не знаешь как работает тайпскрипт.

Я прекрасно знаю, как работает тайпскрипт. А ты, видимо, не отключил noImplicitAny. Впрочем, ожидаемо от не разбирающегося в теме кукаретика.

не отключил noImplicitAny

Не включил

Не включил

Но ты же мне предлагаешь явно сделать мои импорты any.

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

Это был не я. Я говорил что реализация того что не умеет компилировать/парсить бабел (и как следствие оно не в tc39) - зло.

А ты прямо флоу шипаешь в браузер?

Шипинг с флоу ничем не отличается от шипинга без флоу, для все тех кто использует бабел (~99% всех хипстеров)

Но ты же мне предлагаешь явно сделать мои импорты any.

И что мешает?

Я говорил что реализация того что не умеет компилировать/парсить бабел (и как следствие оно не в tc39) - зло.

А кого волнует бабел? Есть комитет, есть пропозалы, есть их стейт.

И ты так и не назвал конкретные примеры «зла» в тс. Можно их увидеть?

Шипинг с флоу ничем не отличается от шипинга без флоу, для все тех кто использует бабел (~99% всех хипстеров)

А шипинг с тс чем отличается?

И что мешает?

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

А кого волнует бабел? Есть комитет, есть пропозалы, есть их стейт.

Бабел волнует всех кто хочет пользоваться модными фичами и таргетить что-то кроме evergreen браузеров. Тех кто хочет давать фидбек в tc39 по ранним стадий пропосалам. Тех кто хочет что-то делать с AST.

И ты так и не назвал конкретные примеры «зла» в тс. Можно их увидеть?

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

А шипинг с тс чем отличается?

Ножно компилить ts.

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

Ну так в чем проблема?

Бабел волнует всех кто хочет пользоваться модными фичами и таргетить что-то кроме evergreen браузеров. Тех кто хочет давать фидбек в tc39 по ранним стадий пропосалам. Тех кто хочет что-то делать с AST.

Нет, не волнует. Все плевать на то, что там в бабеле, на него никто не ориентируется.

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

Абстрактные классы (так же точно как и интерфейсы) и модификаторы доступа - это просто часть деклараций, которые просто исчезают (точно так же как они исчезают во flow), не оказывая никакого влияния на скомпилированный код. Остаются только енумы - но они тривиально рассахариваются.

Ножно компилить ts.

Флоу тоже так же надо компилить в жс (да, есть возможность писать декларации в комментах, но это вырвиглаз и абсолютно неюзабельно).

Ну так в чем проблема?

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

Все плевать на то, что там в бабеле, на него никто не ориентируется.

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

Абстрактные классы (так же точно как и интерфейсы)

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

Флоу тоже так же надо компилить в жс

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

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

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

юзают фичи ранних стадий

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

Но ты уже компилируешь жс теми же тулзами которыми можно стрипить флоу.

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

Не, интерфейсы можно просто выкинуть и все будет работать.

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

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

Ну вот енумы придется рассахарить, единственный пример. Все остальное точно так же как во flow просто стрипается.