А что не устроило в Chromium и node.js? Пробовали TypeScript вместо JavaScript? На JavaScript я бы тоже стал писать что-то сложнее одноразовых простых скриптов.
По хорошему если уже решили использовать TypeScript, то проект может быть полностью javascript less, то есть совсем без js файлов. Да, karma конфиг может быть TS файлом. Если ничего не путаю, по моему опыту, karma-typescript не является обязательным.
Также не совсем понятно почему именно karma. Если браузерное окружение для запуска тестов не нужно, то выбор гораздо шире (например ava). Jasmine тоже спорный выбор, предпочитаю когда все зависимости импортируются в явном виде.
Ну и кончено вместо && в скриптах лучше использовать кросспратформенное решение, например модуль npm-run-all или аналоги.
TypeScript тем и хорош что придает коду строгость, а вы это теряете повсеместно используя сырые типы (как any, или просто string). Вместо type-safety на этапе разработки по-прежнему работаете «в стиле JS» делая рантайм проверки (throw new Error). Я бы сказал что подобное использовать в продакешене вреднее чистого JS, тк в случае JS хотябы ясно что это чистая динамика, а здесь может сложится ошибочное мнение о высоком уровне type-safety. Если не получается задизайнить решение на TS с высоким уровнем type-safety, то может быть вообще не стоит это делать на TS.
Напрмер притом что поля с @input биндингом инииализированы только после выполнение ngoninit, а до вызова они undefined, и вот установка strictPropertyInitialization делается такое поведение более явным. Ну и в целом флаг форсирует более предсказуемый код.
Но да, я не сразу заметил что речь идет об прокидвании стостояния через "@output" наверх. Если не нравится использовать подход описанный в официальной доке ангуляра (дерево компонентов которые «общаются» только через "@input/@output"), то почему не использовать глобальный стор (redux / ngrx), в этом случае необходимость использования "@output" будет минимальна.
3. Та же беда, что и в Ангуляре — компонент сначала меняет своё состояние, а потом через биндинги оно начинает подниматься. То есть временно приложение находится в неконсистентном состоянии, что приводит к различным багам.
TypeScript c версии 2.7 получил новый флаг компиляции compilerOptions.strictPropertyInitialization, который ужесточает strict режим. Что-то вроде strictNullChecks, но для полей класса.
Если его включить, и объявлять свойсва Angular компонентов которые не инициализируются до этапа завершения инстанциации класса (отработка конструктора) как someProp?:someType, то неконсистентей станет меньше, но кода придется писать несколько больше (не важно с биндингом или нет, но чаще такое нужно при биндингах конечно).
Если же хочется сохранить прежнее / «классическое» Angular поведение, то прижется явно выставить свойство как someProp!:someType, префикс `!` приехал вместе с флагом strictPropertyInitialization.
Я вот в целом заметил, что к сожалению очень большая часть проектов которые я смотрел на гитхабе использующих TypeScript не используют стрикт режимы (ни группирующий, ни отдельные), или даже явно их отключают. В то время как даже вызов tsc --init генерирутет конфиг c флагом strict установленным в true.
Так все верно, KD функции это разновидность хэш функций, просто более устойчивые к брутфорсу. Точнее с более настраиваемым work factor, в Argon2 наример можно настраивать work factor как по CPU так и по памяти.
Также не совсем понятно почему именно karma. Если браузерное окружение для запуска тестов не нужно, то выбор гораздо шире (например ava). Jasmine тоже спорный выбор, предпочитаю когда все зависимости импортируются в явном виде.
Ну и кончено вместо && в скриптах лучше использовать кросспратформенное решение, например модуль npm-run-all или аналоги.
Но да, я не сразу заметил что речь идет об прокидвании стостояния через "@output" наверх. Если не нравится использовать подход описанный в официальной доке ангуляра (дерево компонентов которые «общаются» только через "@input/@output"), то почему не использовать глобальный стор (redux / ngrx), в этом случае необходимость использования "@output" будет минимальна.
TypeScript c версии 2.7 получил новый флаг компиляции compilerOptions.strictPropertyInitialization, который ужесточает strict режим. Что-то вроде strictNullChecks, но для полей класса.
Если его включить, и объявлять свойсва Angular компонентов которые не инициализируются до этапа завершения инстанциации класса (отработка конструктора) как someProp?:someType, то неконсистентей станет меньше, но кода придется писать несколько больше (не важно с биндингом или нет, но чаще такое нужно при биндингах конечно).
Если же хочется сохранить прежнее / «классическое» Angular поведение, то прижется явно выставить свойство как someProp!:someType, префикс `!` приехал вместе с флагом strictPropertyInitialization.
Я вот в целом заметил, что к сожалению очень большая часть проектов которые я смотрел на гитхабе использующих TypeScript не используют стрикт режимы (ни группирующий, ни отдельные), или даже явно их отключают. В то время как даже вызов tsc --init генерирутет конфиг c флагом strict установленным в true.
Выполняя поиск по киворду TypeScript можно увеличить вероятность найти позиции которые предполагают работу над проектами с долгосрочной перспективой.
Но это очень очень странно что в наше время подобный сервис использует обычное хеширование вместо KD функций.
Вполне возможно что маркетинговый и рекламный профит стоят гораздо дороже.
Конечно есть такие кто не использует Babel, есть ведь TypeScript.