Но вернемся к кнопкам, они действительно вызывают много вопросов. Это первое, что вы видите на главной странице, но зачем они там? Вы даже не сможете нажать на них.
Потому что нажать на клавиатуре сразу после ввода текста — гораздо быстрее, чем тянуться к этим кнопкам.
Думаю гугл своими небольшими модификациями пытается «обучить» пользователей быстрее достигать своей цели.
jQuery разумеется, но откуда вдруг первый Angular стал простым? Его наоборот первое время в основном за переусложненность ругали.
Насчет Angular 2 — согласен, далеко не факт что взлетит так же как первый. Дело даже не в гибкости, уже достаточно много конкурентов и альтернативных подходов (React, и т.п.)
соединение с базой данных — состояние, нам уже нужно держать пул соединений и самостоятельно все разруливать
Почему самостоятельно? Для этого всего используются библиотеки. То что в PHP библиотеки встроены прямо в язык — это проблемы PHP. Никто на ноде не работает с базой «напрямую».
stateful сервисы (аунтентификация, сессии) — тут опять же нам нужно держать пул таких сервисов и отчищать после ответа или инициалировать их по новой на каждый запрос.
Зачем очищать или инициализировать по новой?
переменные хранящие состояние и объявленные вне скоупа обработчика запросов. Ну мол типа глобальные в этом контексте.
Ну и как туда может что-то «нечаянно» попасть? Если какие-то данные постоянно обрабатываются напрямую в памяти — то это осознанный выбор архитектуры приложения.
Вот вам код для самого простого модуля обработчика запросов.
Пожалуйста объясните что тут может пойти не так:
# -- my-module.js --
module.exports = (req, res) => {
let foo = 'bar';
// foo будет инициализироваться на каждый запрос
};
# -- EOF --
А еще весело заниматься отладкой проблем возникающих только при конкурентных запросах.
Каких проблем конкурентных запросов? Node однопоточна, что избавляет от проблем конкурентного доступа к данным на корню.
Очень многие начинающие разработчики на node.js которые пришли скажем из фронтэнд комьюнити слишком привыкли к тому что stateful не вызывает проблем, и в итоге на сервере потом возникают весьма причудливые баги как только начинают приходить конкурентные запросы. (ну и тестят они в одиночку, а стало быть и проблем воспроизвести не могут).
Вообще не понял о каких тестах речь. Нагрузочные тесты обычно проводят при помощи специальных программ.
Все то что я перечислил — это все легко и просто обходится. Полно готовых решений которые скрывают эти нюансы и ограничивают возможности разработчика в том что они могут делать.
Чем готовые решения ограничивают возможности? В крайнем случае всегда можно писать на «голом» апи.
Если мне в юнит тесте нужно проверить много одновременных вызовов какого-нибудь модуля — я беру и проверяю, и от того как это делается на фронт-энде это мало отличается.
то есть в этом плане PHP который подчищает за разработчиком после каждого запроса — это несомненно жирный плюс PHP и как по мне тот самый «понижатель пороха вхождения». Можно писать сколь угодно плохой код и он будет работать (до поры до времени). С другой стороны многие PHP разработчики уже перешли от умирающей модели выполнения к более-менее конкурентной на базе reactphp и похожих фреймворков. Конечно до производительности ноды там далеко, но разрыв значительно сокращается.
Ну и потом, в силу «синхронности» мы можем просто увеличить количество воркеров. Да, будет огромный оверхэд особенно в плане времени переключения контекста между процессами, но все же… дешево и сердито. И разработчики дешевые настолько что можно пару лишних серваков докупить на всякий случай. Ибо с дешевыми node.js разработчиками вероятность получить неподдерживаемое ведро макарон намного выше.
Я не понимаю почему все разговоры о производительности PHP сводятся к тому что на нем много дешевых и неопытных разработчиков?
Это факт, но речь же была не об этом…
В сессии у меня лежат какие-то значения, но это лишь файлик (запись в редиске, etc), который можно подсунуть кому угодно.
В сессии у вас именно «состояние», пользователя, приложения, чего угодно.
Так же стоит различать полную инициализацию на стороне ядра и полную инициализацию на стороне языка. Если смотреть со стороны языка и его пользователя — да, на каждый запрос всегда чистые и пустые данные, обнулённые переменные и розовый сферообразный конь в вакууме но если смотреть на способ работы — то висящий демон-процесс php-fpm (или несколько) и nginx, который подключается к нему unix sock — должны вам сказать о том, что вы не всё знаете о схеме работы пыха.
Про кеширование мы речь не ведем, если вы об этом.
«Отсутствие состояния» — это вымышленный плюс, т.к. те данные, которые нужно сохранить между запросами — все равно придется как-то сохранять.
А для всего, что не вписывается в рамки «запрос — ответ» нужны дополнительные телодвижения (настройки в ини и прочее)
То есть PHP не «оберегает» разработчика, а только создает дополнительные неудобства.
Конечно, делает работу с языком менее удобной.
Если какая-то функция станет не актуальной (например как mysql_*) — вам придется переписывать приложение, вместо того чтобы просто обновить библиотеку.
Вообще в подходе «весь функционал языка в виде миллиона глобальных функций» я вижу только минусы.
Плюс от экономии времени (мол, не нужно никаких библиотек подключать, просто фигачишь прямо на языке) — для меня лично сомнителен, больше похоже на «медвежью услугу».
Насчет юникода — прошу прощения, ошибся, действительно в седьмой версии он до сих пор не поддерживается полностью.
В чем заморочки? В том, что например, в той же node — мне вообще никогда не нужно думать об этом. Все строки по умолчанию UTF8 с полной поддержкой юникода. String.length никогда не вернет мне неверную длину.
А трафик на мобиле в основном жрет медиаконтент а не HTML.
А вот это как раз сильно зависит от приложения.
Например, если посмотреть эту страницу (а хабр не является одностраничным приложением), то видно что большая часть трафика — это как раз JS/HTML/CSS
(кликабельно)
И есть еще куча ресурсов где медиа контент не является основным.
по моему вы смутно понимаете изначальный смысл ноды и ее отличие от других вебсервероо.
Нет, по-моему это вы не понимаете, что за 7 лет с тех пор как вышла node в веб-разработке многое изменилось и она применяется для гораздо более широкого круга задач чем просто «чатики»
не помню что бы мы вообще упоминали какой разработчик. Не надо подтасовывать дискусию под свои аргументы.
Я ничего не подтасовываю, зачем вообще обсуждать разработчиков, которые не осилили порог вхождения?
Если вы набираете вчерашних студентов или дешевых фрилансеров — согласен — PHP ваш лучший выбор, но более продвинутых разработчиков, на мой взгляд, не должен останавливать порог вхождения.
в PHP нативно поддерживается 99% процентов того для чего в ноде нужен пакетный менеджер.
Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен.
(А еще там только только появилась нормальная поддержка Юникода)
Кроме того, некоторые вещи, которые в node есть из коробки (сокеты и т.п.) в PHP требуют танцев.
Гораздо более ему бы хотелось чтобы страницы не тупили за каждым телодвижением изза клиентского яваскрипта.
Покажите мне «тупящее» одностраничное приложение, и схожее по функционалу, не «тупящее» классическое.
потому что в этом случае нет никаких преимуществ перед более простым для разработки PHP
Преимущество node — скорость. И пожалуйста, объясните чем PHP «проще» для разработки?
Еще раз повторю, что мы говорим про простоту в использовании для профессионального разработчика, а не для любителя.
(Например, в PHP «нативно» поддерживается работа с MySQL, но зато нету пакетного мэнеджера из коробки и нужны «дополнительные заморочки» если требуется работа с сокетами, и т.д..)
Это даже близко не так. Да, есть мода на SPA. Но SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано. Но SPA однозначно более трудоемкие в разработке. Уж поверьте — как раз приходится сопровождать после любителей модных фишек проект сделаный на Flex.
Простите, но «на слово» не поверю, приводите аргументы. Сам сопровождал как «традиционные» проекты, так и SPA — не могу сказать что трудозатраты сильно отличаются.
С Flex'ом никогда не работал, и это скорее исключение, абсолютное большинство веб приложений пишется на HTML5
Преимущество для пользователя, опять же — скорость. При первоначальной загрузке отдаем только статику, затем по мере надобности подгружаем данные. Никаких перезагрузок страниц и т.д.
текущие тенденции — это тестирование сетей 5G.
Точно, скажите это подальше от центра.
И исходящий от сервера трафик тоже никто не считает…
Повышать стоимость разработки экономя на трафике и перегружая мобильные браузеры яваскриптовыми фреймворками — уж точно ненормально.
А жрать деньги клиента на трафике — это нормально?
Я понимаю, что вам возможно в плане бизнеса пофиг на то, сколько данных туда-сюда ходит, но поверьте это точно не повод для гордости в современной веб-разработке.
Нода изначально заточена на обработку множества мелких сообщений которые обрабатываются в одном потоке.
А веб-сервер — это разве не обработка множества мелких сообщений от клиентов??
Это типа как вордпрес, который изначально заточен на блоги но фанаты умудряются делать на нем интернет-магазины.
Это нифига не как «вордпрес», node отлично подходит для огромного количества типов проектов, в том числе для магазинов и т.п.
Вы забываете что мы говорим про людей, а не про роботов.
Голодным, надо полагать, тоже быть никто не хочет, но посмотрите как «здорово» приживается идея генной инженерии для продуктов питания.
Так «здорово» что ее недавно даже на законодательном уровне запретили в одной большой стране.
то что нода пихает новый запрос в тот же процесс — проблема ее архитектуры. Точнее особенность архитектуры полезная для отправки много мелких сообщений.
Не надо использовать ноду куда она не подходит.
Почему эта архитектура, по-вашему, не подходит для отправки много больших сообщений?
подавляющему большинству сайтов не нужно никакое апи. Кроме того апи не означает что там обязательно мелкие данные. Там и гигабайты могут передаваться зависит от прикладной задачи
«подавляющему большинству небольших сайтов не нужно никакое апи» — так правильнее.
На дворе 2016 год, большинство современных веб проектов движутся в сторону одностраничных приложений.
Т.е. гонять по сети мегабайты ХТМЛ — это не нормальная ситуация для текущих тенденций в разработке.
Если брать абсолютные цифры — то большинство сайтов это обычные блоги на вордпрессе и т.п. где «работой программиста» вообще не пахнет.
Но мы же с вами про профессиональную разработку говорим?
сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.
Мы вроде сравниваем node с php как платформы, а не как языки программирования.
node тоже изначально заточена на серверную разработку, разве не так?
то, что длительную операцию выполняет другой поток или event сути дела не меняет
как это не меняет? Если в этот же процесс придет еще один запрос, то в пхп ему придется ждать пока выполнится первый, до того как он вообще может что-то отправить обратно.
для отправки пары килобайт действительно громоздко. Но таких сайтов — подавляющее меньшинство.
кхм, а большинство REST апи — разве не именно это? Oтправляют всего по несколько килобайт на каждый запрос, и часто вообще ничего кроме заголовков не отправляют.
ИМХО — преимущества ноды сомнительны а трудоемкость разработки очевидно выше (напомню что труд програмиста нынче гораздо дороже железа)
очень спорное утверждение, почему на ноде сложность «очевидно» выше? В чем именно выражаются трудности?
Потому что нажать на клавиатуре сразу после ввода текста — гораздо быстрее, чем тянуться к этим кнопкам.
Думаю гугл своими небольшими модификациями пытается «обучить» пользователей быстрее достигать своей цели.
Насчет Angular 2 — согласен, далеко не факт что взлетит так же как первый. Дело даже не в гибкости, уже достаточно много конкурентов и альтернативных подходов (React, и т.п.)
Почему самостоятельно? Для этого всего используются библиотеки. То что в PHP библиотеки встроены прямо в язык — это проблемы PHP. Никто на ноде не работает с базой «напрямую».
Зачем очищать или инициализировать по новой?
Ну и как туда может что-то «нечаянно» попасть? Если какие-то данные постоянно обрабатываются напрямую в памяти — то это осознанный выбор архитектуры приложения.
Вот вам код для самого простого модуля обработчика запросов.
Пожалуйста объясните что тут может пойти не так:
# -- my-module.js --
module.exports = (req, res) => {
let foo = 'bar';
// foo будет инициализироваться на каждый запрос
};
# -- EOF --
Каких проблем конкурентных запросов? Node однопоточна, что избавляет от проблем конкурентного доступа к данным на корню.
Вообще не понял о каких тестах речь. Нагрузочные тесты обычно проводят при помощи специальных программ.
Чем готовые решения ограничивают возможности? В крайнем случае всегда можно писать на «голом» апи.
Если мне в юнит тесте нужно проверить много одновременных вызовов какого-нибудь модуля — я беру и проверяю, и от того как это делается на фронт-энде это мало отличается.
Я не понимаю почему все разговоры о производительности PHP сводятся к тому что на нем много дешевых и неопытных разработчиков?
Это факт, но речь же была не об этом…
В сессии у вас именно «состояние», пользователя, приложения, чего угодно.
Про кеширование мы речь не ведем, если вы об этом.
«Отсутствие состояния» — это вымышленный плюс, т.к. те данные, которые нужно сохранить между запросами — все равно придется как-то сохранять.
А для всего, что не вписывается в рамки «запрос — ответ» нужны дополнительные телодвижения (настройки в ини и прочее)
То есть PHP не «оберегает» разработчика, а только создает дополнительные неудобства.
Я говорю о том что на каждый запрос все по новой инициализируется, это для вас синоним «Отсутствия состояния»?
В сессии у вас что лежит?
Конечно, делает работу с языком менее удобной.
Если какая-то функция станет не актуальной (например как mysql_*) — вам придется переписывать приложение, вместо того чтобы просто обновить библиотеку.
Вообще в подходе «весь функционал языка в виде миллиона глобальных функций» я вижу только минусы.
Плюс от экономии времени (мол, не нужно никаких библиотек подключать, просто фигачишь прямо на языке) — для меня лично сомнителен, больше похоже на «медвежью услугу».
Насчет юникода — прошу прощения, ошибся, действительно в седьмой версии он до сих пор не поддерживается полностью.
В чем заморочки? В том, что например, в той же node — мне вообще никогда не нужно думать об этом. Все строки по умолчанию UTF8 с полной поддержкой юникода. String.length никогда не вернет мне неверную длину.
А вот это как раз сильно зависит от приложения.
Например, если посмотреть эту страницу (а хабр не является одностраничным приложением), то видно что большая часть трафика — это как раз JS/HTML/CSS
(кликабельно)
И есть еще куча ресурсов где медиа контент не является основным.
Нет, по-моему это вы не понимаете, что за 7 лет с тех пор как вышла node в веб-разработке многое изменилось и она применяется для гораздо более широкого круга задач чем просто «чатики»
Я ничего не подтасовываю, зачем вообще обсуждать разработчиков, которые не осилили порог вхождения?
Если вы набираете вчерашних студентов или дешевых фрилансеров — согласен — PHP ваш лучший выбор, но более продвинутых разработчиков, на мой взгляд, не должен останавливать порог вхождения.
Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен.
(А еще там только только появилась нормальная поддержка Юникода)
Кроме того, некоторые вещи, которые в node есть из коробки (сокеты и т.п.) в PHP требуют танцев.
Покажите мне «тупящее» одностраничное приложение, и схожее по функционалу, не «тупящее» классическое.
Преимущество node — скорость. И пожалуйста, объясните чем PHP «проще» для разработки?
Еще раз повторю, что мы говорим про простоту в использовании для профессионального разработчика, а не для любителя.
(Например, в PHP «нативно» поддерживается работа с MySQL, но зато нету пакетного мэнеджера из коробки и нужны «дополнительные заморочки» если требуется работа с сокетами, и т.д..)
Простите, но «на слово» не поверю, приводите аргументы. Сам сопровождал как «традиционные» проекты, так и SPA — не могу сказать что трудозатраты сильно отличаются.
С Flex'ом никогда не работал, и это скорее исключение, абсолютное большинство веб приложений пишется на HTML5
Преимущество для пользователя, опять же — скорость. При первоначальной загрузке отдаем только статику, затем по мере надобности подгружаем данные. Никаких перезагрузок страниц и т.д.
Точно, скажите это подальше от центра.
И исходящий от сервера трафик тоже никто не считает…
А жрать деньги клиента на трафике — это нормально?
Я понимаю, что вам возможно в плане бизнеса пофиг на то, сколько данных туда-сюда ходит, но поверьте это точно не повод для гордости в современной веб-разработке.
А веб-сервер — это разве не обработка множества мелких сообщений от клиентов??
Это нифига не как «вордпрес», node отлично подходит для огромного количества типов проектов, в том числе для магазинов и т.п.
Голодным, надо полагать, тоже быть никто не хочет, но посмотрите как «здорово» приживается идея генной инженерии для продуктов питания.
Так «здорово» что ее недавно даже на законодательном уровне запретили в одной большой стране.
Почему эта архитектура, по-вашему, не подходит для отправки много больших сообщений?
«подавляющему большинству небольших сайтов не нужно никакое апи» — так правильнее.
На дворе 2016 год, большинство современных веб проектов движутся в сторону одностраничных приложений.
Т.е. гонять по сети мегабайты ХТМЛ — это не нормальная ситуация для текущих тенденций в разработке.
Если брать абсолютные цифры — то большинство сайтов это обычные блоги на вордпрессе и т.п. где «работой программиста» вообще не пахнет.
Но мы же с вами про профессиональную разработку говорим?
Мы вроде сравниваем node с php как платформы, а не как языки программирования.
node тоже изначально заточена на серверную разработку, разве не так?
как это не меняет? Если в этот же процесс придет еще один запрос, то в пхп ему придется ждать пока выполнится первый, до того как он вообще может что-то отправить обратно.
кхм, а большинство REST апи — разве не именно это? Oтправляют всего по несколько килобайт на каждый запрос, и часто вообще ничего кроме заголовков не отправляют.
очень спорное утверждение, почему на ноде сложность «очевидно» выше? В чем именно выражаются трудности?
Какое состояние очищается?
И за каким состоянием в ноде надо следить за которым в пхп не надо? Как это при написании кода проявляется?
То что в пхп при каждом новом запросе все заново инициализируется — это по-моему скорее минус чем плюс.
Почему не выложить урок в текстовом виде помимо видео? С примерами кода и т.д. Тогда будет что обсудить в комментариях.
Хабр, по идее, сделан для чтения, а не для пиара собственного канала на ютюбе.
Вся ветка комментариев — прям собрание Нострадамусов какое-то.
Откуда у вас такая информация?
Когда это «ближайшее» будущее планируется? 10, 20, 100 лет?