Как стать автором
Обновить

Комментарии 89

Зачем вы пересаживаетесь на новый ЯП не разобравшись с PHP? И после этого пишете статью диплом (с литром воды). Такое ощущение возникло, когда решение проблемы нагугливается легко. Хоть я и любитель в пхп программировании и новичок в JS, но:

В PHP все эти запросы выполнялись синхронно — один за другим. Среднее время ответа API по одному запросу — 150-200 миллисекунд. Умножаем 200 на 5 и получаем в среднем секунду только на выполнение запросов к серверу с данными. В NodeJS есть замечательная функция Promise.all, которая выполняет все запросы параллельно, но записывает результат поочерёдно. Например, так выглядел бы код выполнения всех пяти выше описанных запросов:

php.net/curl_multi_init

В NodeJS заложена асинхронность на фундаментальном уровне

callbackhell.com

Я подозреваю, что количество hell-ов в PHP просто может зашкаливать ;)
Зачем вы пересаживаетесь на новый ЯП не разобравшись с PHP?

Потому что php модно закидывать говном ;)
Ну про callbackhell модно было говорить лет 5 назад. Это подмножество лапшевидного кода, который может состоять из простых и вложненных условий `if {} else {}`, которые присущи любому языку. Как и в случае с вложенными условными операторами, callbackhell можно упрощать.

В целом, от статьи действительно сложилось впечатление: не разобрался с ЯП1 перехожу на ЯП2, всем советую.

Но человек учится, делится опытом, комментарии появляются, энтропия растет. Всем хорошо.
callbackhell.com

Похоже, что вы совсем не знакомы с async/await :)


php.net/curl_multi_init

Сами http-запросы можно выполнить параллельно, но с данными все равно придётся работать поочерёдно. В Node с помощью Promise.all() можно вызывать асинхронные функции, которые обратятся к кэшу, при необходимости сделают запрос и вернут уже готовый результат целого ряда действий, а не просто массив данных с ответом от удалённого сервера.

Похоже, что вы совсем не знакомы с async/await

похоже вы не знакомы с отладкой и трейсами которые он порождает :-)

Я сам все пишу уже на async/await, но на бою осознать где именно упало не всегда является тривиальной задачей
Обычно же достаточно завернуть потенциально опасный блок в try catch и в catch сделать console.trace()

Особенно когда падает неизвестно где

Занятно, что вы набросились на человека за то, что он «пересаживается на новый ЯП не разобравшись с PHP», при этом пишете про callbackhell, которого уже много лет как нет в ноде.
Статья и серии «Я не освоил PHP + CI/CD поэтому пересел на ноду».
Проблемы с даунтаймом при апргрейде сайта на php решаются парой строк sh-скрипта + git.
Есть сторонние инструменты, типа того же jenkins.
По поводу асинхронности, если не путаю, reactphp.
Композер да, иногда упирается в оперативу. Но никто не запрещает в тестовом окружении установить пакеты и зааплоадить вместе с автолоадером на сервак, хоть это и не очень правильно. Да и NPM не безгрешен.

Дело в том, что все вышеперечисленные проблемы в PHP так или иначе решаются с помощью различных надстроек, на изучение которых нужно тратить время. Лучше потратить это драгоценное время написание кода с использованием нативных инструментов.

Лучше потратить это драгоценное время написание кода с использованием нативных инструментов.

Знание о которых вы впитали в себя с молоком матери или что?
Драгоценное время вы потратили на написание этой статьи например…
Документация по нативным инструментам собрана в одном месте — на сайте NodeJS, где приведены исчерпывающие примеры. На PHP.net есть полным-полно примеров, которые заминусили и которые однозначно нельзя использовать в теперешнее время. Большинство проблем в PHP решается с помощью поиска ответов на StackOverflow, где тоже нужно вчитываться в текст и переводить его с английского, что, опять-таки, для меня совершенно не проблема, но для новичков без знания английского от этого станет больно.
Большинство проблем в PHP решается с помощью поиска ответов на StackOverflow

Так решается большинство проблем независимо от ЯП – хоть PHP, хоть JS. И ничего плохого, в этом, кстати, нет. Вполне себе такой нормальный кейс: не знаешь/не понимаешь как решить проблему, гуглишь, и с большой долей вероятности попадаешь на stackoverflow с решением проблемы, PHP тут не при чём от слова совсем.

Причём в JS можно ещё и сократить зазор во времени между поломкой кода и поиском решения :-)

try {
myBusinessLogic();
} catch (e) {
window.open('https://stackoverflow.com/?q=[js] '+e.message);
}

С консолью линукса/юникса знакомы? Команда mv вам известна? А git pull? Эти сторонние инструменты вы в разработке не используете?

С консольными инструментами не всегда удобно работать. Например, на 13-дюймовом ноутбуке. Для этого больше подходят решения с визуальным интерфейсом, например GitLab, который можно установить на свой виртуальный сервер и создать там закрытый репозиторий. Я бы так и сделал, но меня вполне устраивает текущий вариант деплоя. Учитывая, что я один единственный разработчик в этом проекте :)

Так в консоли то деплой можно заскриптовать на один алиас, что вам, как единственному разработчику на проекте сильно упростит жизнь)

С консольными инструментами не всегда удобно работать. Например, на 13-дюймовом ноутбуке.

Чем вам мешает небольшая диагональ? Это GUI обычно грешат тем, что кнопки то не вмещаются, то сжимаются так, что нажать невозможно. А текст — есть текст, CLI пришел к нам из тех времен, когда 13" с разрешением хотя бы в 1024х768 было мечтой. Лишь бы адекватная клавиатура была.
С консольными инструментами не всегда удобно работать. Например, на 13-дюймовом ноутбуке.

Замечу, что консольные инструменты обычно намного проще и дешевле автоматизировать (и контролировать), что в продакшене дает экономию средств и ресурсов. Удобство деплоя через GUI очень быстро затирается неудобством поддержки и автоматизации дальнейшей эксплуатации (тестирования, обновлений, итп), и наоборот. А если вам неудобен 13-дюймовый экран (мне кстати тоже) — купите 15-дюймовый. В долгосрочном плане техника не должна быть основным критерием того, насколько эффективно вы будете решать проблемы клиентов / работодателя.
13" неудобно для консоли? Вы Gitkraken через elinks открыть пытаетесь что ли?

На печально известном 7-дюймовом EEE PC 701 как раз наоборот в чисто консольном режиме только и было можно работать, иначе слишком мало места получалось.

И причём тут гитлаб, который к командам консоли вообще никаким местом не связан?
С консольными инструментами не всегда удобно работать. Например, на 13-дюймовом ноутбуке.

Удобная консоль с дозированным выводом менее удобна, чем визуальный интерфейс, где то разъезжается, то не влезает из-за размера? Вот это сюрприз.
Не удивительно что подобный разработчик не осили деплой в копию и переключение рабочего каталога сервера запуском одного скрипта (которое ещё и прозрачно для пользователя). Мышкой тыкать, конечно, удобнее (с возможностью что-то забыть или ошибиться).

По поводу асинхронности, если не путаю, reactphp.


Лучше всё же AMP или Swoole.

Возможно. Необходимости пока не было, но спасибо за наводку.

Вернёмся к тому проекту, где вылетала установка зависимостей. Это был проект, написанный в 2015 году на Laravel 4 с PHP 5.6. Казалось, прошло же всего 4 года, ан-нет — куча deprecation-предупреждений, устаревшие модули, невозможность нормально обновиться до Laravel 5 из-за кучи корневых обновлений движка.

Вот поэтому я не люблю фреймворки и вот это все.
P.S> свой велосипед, написанный еще под 5.3 пережил переезд через 5.6 до 7.2 без deprecation/warning
Laravel 4 тоже полностью совместим с 7.0+. То, что автор поста нашёл какие-то проблемы — это результат создания этих проблем, либо самим автором, либо кем-либо ещё. Да и вообще я могу вспомнить только одну ошибку, связанную с OS библиотеками и версиями языка — это где-то в недрах доктрины switсh + continue использовался.
свой велосипед, написанный еще под 5.3 пережил переезд через 5.6 до 7.2 без deprecation/warning

Так часто бывает, если велосипед писался с умом и пониманием. Вот только это не отменяет проблем, связанных с безопасностью, масштабируемостью, итп — на небольших проектах это не проблема, но как только проект растет, велосипеды начинают падать. Не все, но статистика не в их пользу. P.S. Говорю с позиции «опытного» велосипедиста.
Это огромный плюс. У меня всё устроено так, что на сервере параллельно и независимо друг от друга существуют два отдельных сайта — версия для разработчика и production-версия. Представим, что я сделал какие-то изменения в PHP-файлы на сайте для разработки и мне нужно выкатить эти изменения на production. Для этого нужно останавливать сервер или ставить заглушку «извините, тех. работы» и в это время копировать файлы по отдельности из папки developer в папку production. Это вызывает какой-никакой простой и может вылиться в потерю конверсий.

Я прям представил картину, как вы пишите код в «ide» хостинга:), потом руками переносите все измененные файлы на продакшен, предварительно записывая в блокноте измененные файлы, что бы ничего не забыть. Хотя раз вы от php плюетесь, git наверное вам не стоит предлагать
Я прям представил картину, как вы пишите код в «ide» хостинга:), потом руками переносите все измененные файлы на продакшен

На самом деле, все примерно так и происходит :)


Я хотел использовать git, но так сложилось, что я немножечко параноик и опасаюсь загружать код в удалённый доступ. Смотрел в сторону GitLab, но он не понравился мне вот совсем. Да и держать 4 разных репозитория на двух машинах тоже может быть затратно.

Вы гит можете хостить сами, необязательно заливать на gitlab или ещё куда.

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

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

На самом деле, это не было бы придиркой и я бы не отнёс это к причинам моего ухода от PHP, если бы написанные мной проекты на PHP 7.0.* уже сейчас не вызывали deprecation warning при открытии.

У нас некоторые проекты написанные на php 4.0 (на 4-ке, не на 5, не на 7) до сих пор работают без проблем. Многие (Не все) проблемы с совместимостью в php были вызваны использованием того, чего использовать не стоило. Самый простой пример с magic quotes и global variables — ах они стали deprecated, какой ужас. Но это проблема правильного программирования, а не языка пхп.

Попробуйте взять любое приложение на PHP, написанное во времена активной поддержки первых версий PHP 7.0 и будьте готовы потратить свой вечер на поиск решений проблем, возникших в устаревших модулях PHP
Как мы уже упомянули выше — крайне мало вещей стали deprecated из тех, которые был разумно использовать. Тем не менее для поиска остальных вещей и их исправления — много времени не потребуется, есть анализаторы php проектов указывающих на проблемы и их решения.

Дальше, шаблонизаторы. Не будем трогать аргументацию по поводу «нативный пхп ад», с которой мы не согласны. но это слишком холиварно. Ответим лишь на это
Использовать шаблонизатор. Наиболее удобный вариант, но не в PHP. Просто посмотрите синтаксис, предлагаемый в Twig или Blade с фигурными скобками и процентами.
Во-первых, для php есть смарти. Который до кучи компилирует шаблоны, из-за чего получается отличный симбиоз скорости и удобства (при правильном использовании). И при чем считается почти стандартом, как можно было о нем не знать?
Во-вторых, Вы пожаловавшись на «фигурные скобки и проценты», тут же приводите в качестве эталона пример шаблонизатора с «фигурными скобками и решеткой» #{current_year} — о_О?!

Дальше «NodeJS держит своё приложение в оперативной памяти» и особенно
Представим, что я сделал какие-то изменения в PHP-файлы на сайте для разработки и мне нужно выкатить эти изменения на production. Для этого нужно останавливать сервер или ставить заглушку «извините, тех. работы» и в это время копировать файлы по отдельности из папки developer в папку production
Тут Вы дважды не правы.
Во-первых, так как Вы выкатывали проекты проекты на пхп — так не делает вообще никто. никто не ставит заглушку и не копирует файлы по отдельности, Вы выбрали крайне кривой способ деплоя, а ругаете почему-то за это язык.
Во-вторых, на пхп тоже по сути возможно " in-memory application ", достаточно включить опкэш без проверки таймстампов файлов и вуаля — без принудительного рефреша будет работать тот пхп который закэшировался в памяти, при чем уже из скомпилированного байт-кода.

Дальше по поводу «Кластеризация NodeJS-приложения».
Во-первых в пхп есть варианты ограничений — Вы просто с ними не знакомы, т.е. опять же, проблема не в пхп, проблема в Вашем знании вопроса.
Во-вторых называть это ограничение NodeJS (если оно есть) преимуществом " приложение не может потребить более чем 1,5 гигабайта оперативной памяти. " это что-то из твиттерофилии с его 160 знаками. А если хочется обработать в памяти 2гб данных? Мы же не в нулевых, что бы «1.5гб достаточно для каждого».

В целом как итог.
Мы безусловно не спорим с тем, что NodeJS в чем-то лучше PHP.
Но Ваша критика на 80% проистекает из неглубокого знания пхп и практик работы с ними.

p.s.: Черт, пока писали телегу, сверху уже выразили то же самое, но намного короче «Статья и серии Я не освоил PHP + CI/CD поэтому пересел на ноду»© и «вы пересаживаетесь на новый ЯП не разобравшись с PHP»© Надо обновлять перед отправкой комментов:\
Классный ответ, было интересно почитать и обновить свои познания в php. Спасибо!
P/S: Плюсы ставить не могу.

Осторожнее с опкешем, это все ж не волшебная палочка ;)

Дело в том, что PHP сам по себе — это не плохой инструмент. Он очень прост на этапе освоения. Его проблема заключается в том, что когда вы начинаете хоть сколь-нибудь углубляться в его познании, вам постоянно приходится устанавливать какие-то вспомогательные инструменты. В итоге проект становится сравним с панельной многоэтажкой с кучей пристроек и хаотично застеклённых/утеплённых балконов, разного цвета и формы кондиционеров и спутниковых тарелок".

анализаторы php проектов указывающих на проблемы и их решения

включить опкэш без проверки таймстампов файлов и вуаля

в пхп есть варианты ограничений — Вы просто с ними не знакомы


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

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

Но Ваша аргументация против php имеет тот недостаток, что она основывается на поверхностном знании php


Если подытожить, то, в моём случае, это незнание обусловлено не ленью (даже осознавая тот факт, что я ленивый), а нежеланием проводить целые вечера за чтением литературы и в попытках заставить работать то, что должно было бы работать «из коробки», вместо того, чтобы заниматься тем, что действительно интересно — писать код и реализовывать алгоритмы.
чтобы заниматься тем, что действительно интересно — писать код и реализовывать алгоритмы.

Дело в том, что если говорить о «писать код и реализовывать алгоритмы», то никаких «надстроек» и «вспомогательных инструментов» для PHP не требуется.
Ну вы уж что-то совсем утрируете. При написании кода очень часто возникает необходимость что-то установить, но в NodeJS эта необходимость возникает значительно реже. И на PHP чаще всего вы не сможете решить проблему самостоятельно и будете именно вынуждены обратиться к вспомогательным инструментам.
При написании кода очень часто возникает необходимость что-то установить

Вы что-то делаете не так.

Извините, не буду приводить цитаты из вашего комментария, отвечу кратко. Вы IDE пользуетесь при разработке на ноде? Я вот пользуюсь phpstorm, и он из коробки поддерживает и базовый анализ кода, а если поставить плагин(из настроек самого шторма), так ещё и статанализ будет.
Опкеш — не сторонний инструмент, это часть пхп, при этом описана в документации.
Для беспроблемной разработки на php достаточно официальной документации и понимания основ ООП(да и то не обязательно, можно и в процедурном стиле шпарить).

Ну вот опять. Мне для работы с Node достаточно VS Code без каких-либо плагинов вообще. Для работы с PHP нужно ещё устанавливать целую IDE.
VSCode в среднем не более и не менее IDE, чем PHPStorm. И вообще, не использовать IDE с мало-мальским анализом кода на данный момент (при ее наличии и доступности) в серьезной работе — ИМХО стоит где-то между чрезвычайной самоуверенностью и профессиональным саботажем. Мы не роботы, и делаем ошибки, которые машине легко подсветить, и в результате сделать наш продукт лучше.

Для работы с php не нужно устанавливать целую IDE. Есть же sublime, notepad++, far+colorer… Мой коллега вон пишет на пыхе в vim, при этом в макоси. Но мне лично комфортнее работать в IDE.

Ну вот опять. Мне для работы с Node достаточно VS Code без каких-либо плагинов вообще. Для работы с PHP нужно ещё устанавливать целую IDE.


Это предложение звучит как: «Ну вот опять. Мне для написания HTML достаточно блокнота без каких-либо редакторов и интерпретаторов вообще. А для работы с нодой нужно устанавливать целую ноду и vs code».

На такой тезис можно ответить, либо грубо, вроде «вырастешь — поймёшь зачем нужны серверные ЯП (в вашем случае IDE)», либо пройти мимо, заметив, что «это всё не обязательно, только ничего кроме хоумпейджей на голом HTML не запилить».
В NodeJS вы просто садитесь писать код и пишете его без оглядки, исправляя выявленные проблемы уже на этапе тестирования. И решаете вы их быстро потому, что пишете код с использованием нативных инструментов, которые просто работают.


Это даже не смешно. Нода — эта та платформа, где надо установить гигабайты всякого софта, чтобы просто начать работать, начиная с cygwin и конфигурирования mingw g++/gcc для компиляции какого-нибудь sass, заканчивая установкой тех же самых линтеров и какого-нибудь puppeteer для тестов, а потом резко влетаем в компиляцию ассетов и начинаются конфиги вебпака (потому что стандарт), скрещенные с ужом поверх гулпа (потому что тогда вебпака не было), с инклудами на бауере (ладно, тут я перегибаю, простите), которые через одно место собирают TypeScript (так сейчас модно), вмерживая туда Coffee (так было модно), и параллельно прогоняя остатки JS через babel со stage-0 (ну мы думали эти декораторы зарелизятся...).

Хм, кажется я перечислил дефолтный стек среднестатистического проекта на JS, да?

Нода — это чёртов хаос из конфигов и настроек. На ней невозможно просто так взять и начать писать. Да блин, тот же express поставить надо же… А там зависимости подсасываются, а там какой-нибудь, наверняка, задепрекейченный vanilla stream… И всё заново, начинается скачки по жёсткому захардкоживанию версий в package.json.

Ну вы уж совсем утрируете.


чтобы просто начать работать, начиная с cygwin и конфигурирования mingw g++/gcc

Издержки windows – на юникс системах просто ставишь nodeJS и уже можно работать.
Да и когда я в последний раз устанавливал ноду на win, то всё ограничилось запуском установщика.


влетаем в компиляцию ассетов и начинаются конфиги вебпака

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


Нода — это чёртов хаос из конфигов и настроек

Но да, npm install очень частая команда, но это даже не необходимость а удобство – зачем изобретать велосипеды, если оно уже есть в npm?


В общем, если этим часто пользоваться и привыкнуть, то не так уж всё и плохо.

Ну в общем-то да, я утрировал и довольно сильно. С другой стороны по сравнению с PHP, где ничего вообще делать не надо и даже сервер из коробки идёт — оно так и выглядит.
Из которой коробки? Помню для разработки на пхп под виндой обычно ставился целый wamp в котором частенько жил тот же cygwin, отдельный веб сервер, и база данных поселяющаяся в сервисах.
В версии 5.4 добавлен веб-сервер.
Всё бы хорошо, но вы перечислили проблемы работы с frontend. А статья как раз о серверной разработке и никакие SASS и WebPack здесь совершенно ни при чём. Если говорить именно о сервере, то всё предельно просто — npm i dependency --save и работаете по документации.

Если говорить о frontend, то здесь уже проблема не самой Node, а того, во что превратили frontend-разработку. Препроцессоры, транспиляторы, сборщики и целая куча фреймворков — всё это напоминает ту самую панельку с кучей пристроек и хаотично утеплённых фасадов.
Всё бы хорошо, но вы перечислили проблемы работы с frontend. А статья как раз о серверной разработке и никакие SASS и WebPack здесь совершенно ни при чём. Если говорить именно о сервере, то всё предельно просто — npm i dependency --save и работаете по документации.


Согласен, да. Но с другой стороны — это на порядки проще `composer i dependency`?
НЛО прилетело и опубликовало эту надпись здесь

В ваш комментарий вместо php можно поставить ноду и он будет точно так же выглядеть. Все вроде недовольство возникло только из-за "такого себе" уровня, как программиста.

Не могу отредактировать — "Всё ваше", а не "все вроде".

Еще есть twig который легче Smarty. Есть Blade.

p.s. Привет :)
Во-первых, для php есть смарти. Который до кучи компилирует шаблоны, из-за чего получается отличный симбиоз скорости и удобства (при правильном использовании).

Twig и Blade тоже компилируют шаблоны. Плюсом они умеют наследование шаблонов из коробки (не знаю, как в Smarty с этим сейчас, но раньше реализовывалось только расширениями)

PHP уже окончательно ушёл в закат и уступил своё место NodeJS

Да никуда PHP не ушёл и никому своё место не уступал – у каждого своя ниша. И долго ещё не уйдёт.
Как уже писали выше, вы не смогли в PHP, но вам зашёл nodeJS. Могу добавить ещё один стандартный комментарий к подобным постам: ЯП/фреймворк/платформа/etc – это инструмент, какие-то инструменты подходят лучше для одних задач, что-то лучше для других задач. В этом свете слова "окончательно ушёл в закат" звучат несколько громко.


А в NodeJS есть свой собственный менеджер пакетов — npm

npm такой же собственный для nodeJS, как и composer для PHP. Оба просто стали стандартным пакетным менеджером для своего языка. npm просто устанавливается сразу с nodeJS.

НЛО прилетело и опубликовало эту надпись здесь
Автор, я даже немножко рад, что вы ушли с PHP. Заранее приготовьте ЯП, в который вы пойдете после очередного разочарования. И да, хреновый с вас программист, вы уж простите за прямоту.
Я уже присматриваю себе Go :) Возможно, через несколько лет Google приведёт его в порядок (что очень вероятно) и если я поборю нетерпимость к ООП (что находится за рамками возможного) — уйду в Golang.
если я поборю нетерпимость к ООП

В Go нет ООП в классическом понимании (с наследованием через классы). Там нет классов, только структуры и интерфейсы. Почитайте про подход Favor composition over inheritance, он в JS очень популярен. Ну и хорошее видео для понимания www.youtube.com/watch?v=wfMtDGfHWpA
Я вам настоятельно рекомендую изучить ООП и все современные практики, которые используют его. В нем заключается колоссальная гибкость. Жаль, что вы опубликовали эту статью так и не разобравшись в языке и теперь она будет сбивать с толку других новичков.
поборю нетерпимость к ООП

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

Вот тут вы мне сломали мозг. У вас нетерпимость к ООП, но вы пересели на ноду, в которой почти всё — объект, то бишь там волей-неволей будешь применять какие-нибудь ОО паттерны. Немного иначе чем в других ОО-ЯП, но всё же.

возможно, через несколько лет Google приведёт его в порядок

А что, по-Вашему, не в порядке с go?
Очень часто встречаю от Golang программистов возмущения в адрес управления зависимостями. Нет конструкторов, неудобное управление ошибками. Это только то, что смог вспомнить.
и я сделал выбор в пользу Jade (PugJS). Просто оцените простоту его синтаксиса

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

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

Простота не всегда хорошо. Может наступить момент (и он наступит), когда эта простота не даст реализовать нечто очень нужное. И что тогда — очередной вопль "jade sucks!"?
А вообще — во всем проглядывает юношеский максимализм. Осталось набраться опыта и прийти к пониманию, что и php хорош и нода хороша. Просто для кручения гаек отвертка плохо приспособлена, хотя зачастую и лежит рядом с гаечным ключом. Каждому инструменту свое применение.

Зато шаринг хостинги кругом с PHP, а вот с Node нет (хотя может и есть, специально не искал).

Дык кому охота заморачиваться? Это ж головняки какие будут у саппорта) Я бы не рискнул "даже за сто тыщ мильенов" (с) )))

Ждем статью — «Как я переписывал поисковик авиабилетов с NodeJS на Python» и конечно потом будет
«Как я переписывал поисковик авиабилетов с Python на GoLang» и на последок
«Как я переписывал поисковик авиабилетов с GoLang на Rust» ))))
В конце 2018 года… заказчик предоставил сервер с 1 ядром и 512 мегабайтами оперативной памяти
Ну я бы с таким «щедрым» заказчиком работать не стал, если ему жалко пару копеек на нормальное железо, на секундочку, аж под целый «поисковик авиабилетов», то вполне логично, что его жаба давила и по оплате работы. В итоге был нанят студент. Так что тут проблема скорее всего в заказчике, а не в авторе статьи, хотя и автору все-таки стоило бы быть немного скромнее, чтобы не демонстрировать публично свою некомпетентность.
Я конечно извиняюсь, но я могу написать такую статью про любой язык программирования потратив день на его изучение и потом переключившись на любой другой язык — само собой оба языка должны подходить под задачу в целом.
Вы бы хоть кому-то опытному на обзор дали бы прочитать прежде чем публиковать — в данной статье «прекрасно» всё — отсуствие опыта, отсуствие желания учится и разбираться, отсуствие оценки рисков и следование хайпу, самоуверенность, которой даже я позавидую со своими 14 годами в PHP разработке.
У вас подход какой-то дилетантский, не программисткий. По вашей статье видно, что вы не разобрались с элементарными вещами не только в PHP, но и в разработке в целом. Статья однозначно вредная, особенно для новичков. Пример того, как не нужно делать.

NPM и Composer.


NPM много крови может попить, когда будет тянуть бинарные пакеты, а ещё может и начать собирать их у вас на виртуалочке.


LTS


Вы правильно написали, что и то и то поддерживается по 3 года и, если заметите, то LTS релизов ровно столько же, сколько у PHP, не LTS версии не используют в более-менее нормальных продашенах, они лишь для того чтобы посмотреть на функционал, пощупать его перед тем как выпустят нормальную LTS.


Шаблонизатор


Нравится вам лаконичный стиль, поискали бы на https://packagist.org/ нужный вам шаблонизатор. Вот 2, которые 1 в 1 как ваш Jade:



"По моим ощущениям" — один из ужасных аргументов на хабре. Далее вы описываете всё время загрузки страницы, вместо сравнения шаблонизаторов.
Вот как выглядит компиляция шаблонов в Twig:


$loader = new \Twig\Loader\FilesystemLoader('/path/to/templates');
$twig = new \Twig\Environment($loader, [
    'cache' => '/path/to/compilation_cache',
]);

Не сложнее чем ваше.


Про подключение JS я так и не понял, но это в вашем проекте всё просто и надо всего 2 файла загрузить сначала. Такую же функцию грабера всех JS файлов и функцию сортировки можно на любом ЯП сделать. Но вообще в фреймворках были средства, которые позволяют правильно подключать JS/CSS файлы.


Деплой


Про деплой — вы всё распаковываете в соседнюю директорию с вашим проектом, меняете конфиг в nginx и делаете его reload. Это один из способов, вообще есть и более правильные, но это тема отдельных статей, и вроде бы, когда-то давно на хабре проскакивали такие.


Оперативная память


С PHP-FPM всё так же просто. Вы ведите сколько памяти занимает 1 PHP-FPM (после нескольких заходов на разные страницы сайта), делите память, которую вам не жалко, на то, сколько занимает 1 процесс и получаете max_children, выше которого процессы размножаться не будут. Кстати, memory_limit и max_execution_time в PHP вам помогут не положить сервер, если вы накосячите в коде с временем выполнения и памятью.


Швейцарский нож


Я пишу разные консольные утилиты на PHP, писал грабберы, которые тоже в несколько потоков могут грабить сайты, асинхронно работать. Хотите Headless Chrome, его тоже можно запустить и управлять через PHP, слава богу API едино и слабо меняется от одного ЯП к другому. Вот вам и nesk/puphpeteer


Асинхронность


Тут, действительно, на JS изначально пишут асинхронно, поэтому у него больше пакетов. Но на PHP, так же есть возможность писать асинхронно. Вот хорошая подборка: https://github.com/elazar/asynchronous-php


Пожелания


Хотите что-то сравнить, разберитесь в каждом инструменте, либо найдите хорошего оппонента, который сможет на ваши выпады найти аргументы. Node.JS не плохой и не хороший, он просто другой с другой парадигмой. А вам желаю не терять огонь, с которым вы берётесь за работу, и больше углубляться в инструменты, которые помогут вам в будущем стать хорошим разработчиком. Читайте больше, ведь написание кода — это меньшая часть времени. Большая часть — это его отладка, изучение новых знаний, освоение новых инструментов и подходов.

Про деплой — вы всё распаковываете в соседнюю директорию с вашим проектом, меняете конфиг в nginx и делаете его reload. Это один из способов, вообще есть и более правильные, но это тема отдельных статей, и вроде бы, когда-то давно на хабре проскакивали такие.


Zero downtime deployment:
1. Делаете директорию release-v1, в ней текущий релиз
2. Делаете симлинк current на директорию release-v1
3. Нужно выкатить новый релиз? Ок, делаете директорию release-v2
4. Меняете симлинк current на release-v2
5. Вуаля! Новый релиз задеплоился без остановки работы и троганья nginx.

В случае проблем можно очень легко откатиться на предыдущую версию — просто обновить симлинк =)
собственно так и работает deployer
И если используется nginx, то не лишним будет использовать realpath_root, дабы избежать проблем с opcache.
Разберитесь сначала с PHP, а потом уже пишите обличительные статьи. Абсолютно всё что написано в статье связано только с тем, что вы не разобрались «как его готовить». А уж не использовать систему управления версий (кстати, не обязательно git, хотя это и мейнстрим) скатывает вас на уровень самого начинающего джуниора, который только делает первые шаги в программировании.
НЛО прилетело и опубликовало эту надпись здесь
О том, что от не знания одного языка программирования переходите на другой уже много написали.

Без контроля версий, настроенного деплоя, линтера, фиксера и анализатора могут быть проблемы в не зависимости от языка.
А так же из-за того, что вы никому не показываете свой код. Ревью — такой же инструмент для написания хорошего кода.
Казалось, прошло же всего 4 года, ан-нет — куча deprecation-предупреждений, устаревшие модули, невозможность нормально обновиться до Laravel 5 из-за кучи корневых обновлений движка.

Вы серьезно? Посмотрите в ту же nodeJS, там все еще быстрее устаревает.

Для PHP это большой плюс, что язык обновляется при этом, стараясь не ломать обратную совместимость.
Вы серьезно? Посмотрите в ту же nodeJS, там все еще быстрее устаревает.


Самое весёлое — это когда ~год назад поломали синтаксис
class A {
   *async a() { yield x; }
}


Заменив его на
class A {
   async *a() { yield x; }
}


У меня тогда пол кода отвалилась после апдейта ноды. И при этом и в документации пустота, и гугл девственно чист.
Что говорить о комптентности если приводится пример асинхронной функции где используются те же then и status.err
async function saveSnapshot() {
    getSnapshot().then((res) => {
        db.saveSnapshot().then((status) => {
            if(status.err) console.error(err)
        })
    })
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории