Если Node.js и npm установлены, то тогда PHP вообще не очень нужен, ведь можно поверх ставить web-сервер (например, Express.js) и шаблонизатор (например, Handlebars.js) и далее на них сайт подымать. (Я пишу это отчасти иронически — но не более, чем наполовину.)
Я сейчас скажу довольно мрачную и пессимистическую вещь, отрицающую плоды прогресса даже сильнее, чем вышепереведённая мысль отрицает их.
Мне кажется, что спохватываться надо было гораздо раньше: по сравнению с возможностями библиотеки Async даже промисы выглядят шагом назад.
Дело в том, что у промисов есть метод «Promise.all», тогда как у библиотеки Async есть не только ананалогичный ему метод «async.parallel» (а также другой метод «async.waterfall», аналогичный цепному вызову промисов через их «.then»), но и ещё почти шестьдесят других удобных методов. Оговорюсь, что из них лично я использую никак не больше десятка, но, во-первых, даже этот десяток не горю желанием сочинять самостоятельно ради перехода на промисы, а во-вторых, меня радует сознание того, что за пределы этого десятка я всегда смогу (при малейшей необходимости) выйти почти мгновенно, потому что там ждут меня ещё полсотни готовых методов, которые опять же не придётся сочинять самостоятельно.
То есть переход на промисы выглядит как переход на новый (и ещё не обросший возможностями) фреймворк, ради которого отбрасывается история многих лет эволюции библиотеки Async (начиная от первого коммита 13 мая 2010 года) и большинство обретённых ею возможностей, так что теперь промисовая публика будет переизобретать велосипеды (причём, скорее всего, опять же на протяжении нескольких лет кряду) при столкновении с наималейшими проблемами действительности.
То, что новый фреймворк сделали частью языка, в практическом отношении ничего особенного не меняет. (Кроме того только, что процессу переизобретения велосипедов будет сопутствовать не менее увлекательный процесс подпирания костылями-полифиллами всех тех прежних версий, которые останутся в прежних браузерах.)
Поэтому лучшее, что можно сделать с промисом — это сунуть его в «async.asyncify» и дальше коллбекнуть по старинке.
Так как перед нами расшифровка одного из выступлений на конференции FrontendConf, и так как конференция эта проводится летом в начале июня (по крайней мере, так пишут на сайте про нынешний год), то изложенные в выступлении свéдения нуждаются в некотором осовременивании (может быть, на полгода, а может быть, и на полтора года; что-то я нигде не увидел даты этого выступления, честно говоря) для того, чтобы соответствовать положению дел января 2017 года.
Движок NW.js больше не использует движок io.js в качестве средства для поддержки Node API; после того, как io.js влился обратно в Node.js, последующие версии NW.js также возвратились на Node.js. Так, например, стабильная версия NW.js v0.19.5 использует Node.js v7.4.0, и вышедшая сегодня (19 января) предрелизная версия NW.js v0.20.0-rc1 также использует Node.js v7.4.0.
Движок NW.js больше не использует простой нодовский вызов «require(…)», который в браузероподобном контексте создавал пусть и преодолимые, но всё же досадные проблемы совместимости с RequireJS. Теперь используется вызов «nw.require(…)», вынесенный в отдельное пространство имён «nw».
В то же пространство имён вынесены те элементы API NW.js, которые ранее были доступны через вызов «require('nw.gui')»; таким образом, например, вместо «require('nw.gui').Window» теперь пишется попросту «nw.Window», а вместо «require('nw.gui').Shell» теперь пишется попросту «nw.Shell», и так далее.
(В качестве примера изменений, к которым это приводит, можно посмотреть вон те правки, внесённые 26 октября 2015 года в один из моих проектов на Гитхабе.)
Внутрь package.json теперь нет необходимости вписывать «"toolbar": false» для отключения навигационной панели, потому что теперь её нет. Соответственно, нет и шестерёнки на ней, а отладка вызывается по F12, как в Chrome. (Вызывается в SDK-содержащей версии движка NW.js. Сборка приложений для конечных пользователей, как правило, делается без средств отладки.)
Степень того единства контекста Node и контекста окна, о пользе и вреде которого чуть выше рассуждали читатели, теперь можно изменять по мере необходимости (кому нужно, тот использует смешанный контекст).
В остальном вышеизложенное выступление вполне справедливо. Веботехнологическая и притом кросс-платформенная разработка — это залог довольно быстрого создания сайтоподобных GUI-приложений. Как показывал AndyGrom, такие приложения могут иметь и вебсерверную частьна основе Express.js.
Если сделать просто «require('lodash')», но не присвоить присвоить результат «require('lodash')» в явном виде той переменной, имя которой состоит из знака подчёркивания (такое имя переменной чаще всего и используется пользователями lodash), то тогда этот результат присвоится этой переменной автоматически, но не менее автоматически пропадёт (то есть переменная эта переприсвоится) на следующем же шаге REPL — оттого, что в REPL переменная с таким именем имеет особый смысл, что также сказано в документации Node.js.
Может быть, это просто аллюзии друг на друга у них, но может быть, что до специалистов по безопасности (до одного за другим) постепенно добирается Моссад (ну не непременно Моссад — может быть, ЦРУ или какая-нибудь другая гэбэшечка), после чего они испускают вот такой завуалированный крик о помощи — а затем, делать нечего, превращаются в агентов влияния, ретранслирующих внутрь сообщества (и подкрепляющих своим авторитетом) мнение о том, что крипто тягостно и не нужно, люди мы маленькие и незначительные, а преступность и гэбэшечка до нас всё равно, если что, доберётся, крипто не нужно, острой сатиры не нужно, альтернативных СМИ не нужно, Тор не нужен, аниме не нужно, прямые выборы губернаторов не нужны, Викиликс не нужен, короткоствол не нужен, Сноуден не нужен, велосипед не нужен, Крым не нужен, широкий тротуар не нужен, Фидонет не нужен, и так далее.
Там с такою непринуждённостью совершается разделение MVC-фрэймворковна «Sinatra-подобные»и «Rails-подобные», как если бы термины эти могли что-то значить не для одних только программистов на языке Ruby, решившихся потихоньку переходить на JavaScript.
И выглядеть общественное телевидение будет тогда крайне неаппетитно.
Мне кажется, что спохватываться надо было гораздо раньше: по сравнению с возможностями библиотеки Async даже промисы выглядят шагом назад.
Дело в том, что у промисов есть метод
То есть переход на промисы выглядит как переход на новый (и ещё не обросший возможностями) фреймворк, ради которого отбрасывается история многих лет эволюции библиотеки Async (начиная от первого коммита
То, что новый фреймворк сделали частью языка, в практическом отношении ничего особенного не меняет. (Кроме того только, что процессу переизобретения велосипедов будет сопутствовать не менее увлекательный процесс подпирания костылями-полифиллами всех тех прежних версий, которые останутся в прежних браузерах.)
Поэтому лучшее, что можно сделать с промисом — это сунуть его
Your callback hell is my home.
Движок NW.js больше не использует движок io.js в качестве средства для поддержки Node API; после того, как io.js влился обратно в Node.js, последующие версии NW.js также возвратились на Node.js.
Движок NW.js больше не использует простой нодовский вызов
В то же пространство имён вынесены те элементы API NW.js, которые ранее были доступны через вызов
(В качестве примера изменений, к которым это приводит, можно посмотреть вон те правки, внесённые 26 октября 2015 года в один из моих проектов на Гитхабе.)
Внутрь package.json теперь нет необходимости вписывать
Степень того единства контекста Node и контекста окна, о пользе и вреде которого чуть выше рассуждали читатели, теперь можно изменять по мере необходимости (кому нужно, тот использует смешанный контекст).
В остальном вышеизложенное выступление вполне справедливо. Веботехнологическая и притом кросс-платформенная разработка — это залог довольно быстрого создания сайтоподобных
Правда, сторонники доклада скажут, что это не имя собственное, а просто нарицательное для той сюиты, в которой останавливался президент Обама.
Если слово «flash» записывать словом «флеш», то как слово «flesh» записывать тогда?