Gulp это ведь таск раннер, его не только для сборки можно использовать. В целом информация уже не слишком актуальна, тк существуют более продвинутые решения для сборки если речь идет о вебе (но как таск раннер gulp все еще может быть актуален). Тоже самое касается упомянутого browserify. То есть года 3 назад подобный материал был бы более актуален, сейчас время можно потратить на изучение чего-то более современного. В целом вот здесь можно полазить кто не вкурсе трендов stateofjs.com/2017/introduction
Смотря с чем сравнивать. Очевидно я сравнивал с одной строны — состряпать что-то по-быстрому допустим на JS + JQuery (с ES6 синтаксисом или без — разницы никакой), веб модуль это или Node.js модуль, не суть. Или сделать это используя Angular + TypeScript, при этом не только написать непосредственную реализацию, но еще подумать над структурами данных, над сигнатурами методов/функций и тд. Очевидно второй варинт отпугнет некоторую часть случайных людей в профессии.
К тому же простота старта не всегда прямо коррелирует с простотой разработки реальных проектов. Например с TS часто бывают случаи когда TS все еще не в состоянии полностью решить нужную задачу — сделать type safe все что хочется и при этом по минимуму использовать грязные хаки. На гитхабе уйма workaround/хаков для разных не совсем очевидных еще не поддержанных случаев, и также много пулл реквестов которые пока не смержены. Я бы не сказал что собрать все нужные хаки из гитхаба, или придумать их самому, это прямо как 2 копейки.
Я бы сказал что странно несколько другое, то что Angular и TypeScript вообще попали в топ тренда. Все таки это вещи с не самым низким порогом вхождения, которые более нацелены на крупные проекты с долгой стадией развития (которыми например большая часть модулей обубликованных в npm репозитории не является). Получается если указанный тренд действительно присутствует, то в веб и Node.js разработке становится меньше откровенных code monkeys / script kiddie.
Я вас умоляю. Это может на Западе, и первые две-три компании, кто внедрил эту практику
IBM, a Pioneer of Remote Work, Calls Workers Back to the Office (May 18, 2017 8:00 a.m. ET) У них там много всяких практик, все сводиться к уменьшению издержек компании, вот в примере вроде как хотели экономить нанимая удаленщиков, а оказалось по итогам не особенно и выгодно.
Ну вот я никогда не считал риакт серебрянной пулей, и часто тролил народ в этом плане и получал минусы здесь, а вот оказывается даже авторитетные и заинтересованные товарищи склонны критически мыслить по поводу риакта.
Разумеется нет. Код подбирается выразительный и не объемный, то есть такой чтобы управится в час максимум при очной встрече или удаленном общении с код шарингом, но скорее пол часа максимум. Интересует ведь именно как человек рассуждает, а не как кто-то там где-то пишет ответы.
Я просто к тому что MobX тем и хорош что он предсказуем если использовать его как синхронный стор. А вот если в сам стор запихивать асинхронные геттеры, то это будет уже не совсем просто стор, но некий самомодифицируемый и не всегда прдскауемым образом гибрид. Так вот просто вариант когда в самом сторе храним только стейт асинхронного эффекта/реакции/экшены, а сами асинхронные эфекты живут отдельно от стора. Ну то есть мы не делаем например «get users.then()» в сторе, но работаем со стором только синхронным образом, а асинхронщину вешаем как реакции на изменение в упрощении счетчиков/флагов на которые можно реактнуться (а по сути стейтов эффектов асинхронных). То есть то что я называю счетчиком, это по сути редакс экшен, реакцией на который будет асинхронное действие которое в итоге модифицирует стор. То есть в упрощении в сторе делаем массив actions, в который засылаем экшены с payload если требуется, далее вешаем MobX reaction на этот массив, и эта реакция и есть эффект. Это я написал наверно запутанно, но на самом деле это банальная идея.
Я с MobX пока плотно не работает, но трогал. А если сделать что-то вроде side effects подхода? Допустим имеем некое простое observable поле — в упрощении счетчик или просто флаг, а вообще в этом поле хранить состояние/прогресс асинхронного метода допустим (влючае состяние ошибки), чтобы если что допустим его отменить или навинтить тротлинг/denouncing, тогда это наверно массив будет. Изменяя это поле (выполняя action в понятиях MobX, а по аналогии с Redux диспатчим экшен) мы тригаем некий effect, который есть reaction в понятих MobX. Эта реакция (которая может быть асинхронной) в итоге меняет некий стейт, можно если нужно придумать как сделать соответствие меняемого стейта и счетчика который тригает реакцию.
Мне на интервью важно понять может ли человек думать. С этим считаю типовые задачи не слишком помогают. А вот например задания на рефакторинг куска кода уже другое дело. Это менее стрессово для кандидатов, любой сможет хоть что-то да улушить в коде. Можно подобрать такой код что его будет строк 10-15 всего, но при этом он будет напичкан всякими проблемами, в том числе не слишком явными. И вот лучшие кандидаты не просто улучшают код, но пытаются догадаться каково назначение код (что он делает, часть какой системы является), и это ведет к еще более продуктивной беседе.
Это не только Chromium ограничение, но всех современных бразуеров тк это ограничение безопасности которое очень логично. В cross-window/cross-origin взаимодействии через window.postMessage ничего нового нет. Касательно использование postMessage(sO, "*") возможно стоит подумать об ограничении получателя, то есть вместо "*" указывать что-то конкретное из доверенного списка.
Да ничего не измениться по сути, просто не все понимают как происходит планировка подобных «отложенных» задач в JS, а там тоже есть что обсудить. И вот как раз воркеры были бы к месту в обсуждении.
Вопрос был бы чуть более хитрым если бы в setTimeout таймаут было не 3000, а 0 (значение по умолчанию). Хитрость ведь не только в области видимости и замыканиях, а еще в понимании того что JS однопоточный и event loop блокировать очень нежелательно.
Это каким образом размер пакета с программой коррелирует со скоростью ее работы?
вы считаете что об оптимальности думать не надо если ресурсы позволяют?
Я считаю что оптимальный размер программы это далеко не всегда приоритет. По ссылке выше речь идет о мобильных апликухак, например для десктопа как правило размер пакета с программой не так критичен.
К тому же простота старта не всегда прямо коррелирует с простотой разработки реальных проектов. Например с TS часто бывают случаи когда TS все еще не в состоянии полностью решить нужную задачу — сделать type safe все что хочется и при этом по минимуму использовать грязные хаки. На гитхабе уйма workaround/хаков для разных не совсем очевидных еще не поддержанных случаев, и также много пулл реквестов которые пока не смержены. Я бы не сказал что собрать все нужные хаки из гитхаба, или придумать их самому, это прямо как 2 копейки.
IBM, a Pioneer of Remote Work, Calls Workers Back to the Office (May 18, 2017 8:00 a.m. ET) У них там много всяких практик, все сводиться к уменьшению издержек компании, вот в примере вроде как хотели экономить нанимая удаленщиков, а оказалось по итогам не особенно и выгодно.
А еще на TypeScript пишут например, и там уже дело не только в красоте (синтаксическом сахаре).
Если быть чуть более конструктивным, вместо такого лучше использовать алиасы (в Webpack это будет блок resolve.alias).
Эпично, согласен, привет индусам.
Это каким образом размер пакета с программой коррелирует со скоростью ее работы?
Я считаю что оптимальный размер программы это далеко не всегда приоритет. По ссылке выше речь идет о мобильных апликухак, например для десктопа как правило размер пакета с программой не так критичен.