Комментарии 115
планируете ли переходить на JavaScript?
Планируем нанять 10 js разработчиков с зп не менее 100$ час и чтобы каждому приходилось менять пакеты по 5 раз в день. Надеюсь за пару лет экономии с перехода c композера на yarn на однушку в подмосковье накоплю. Других полезных откровений в статье не нашел
npm@5.4+ работает почти также быстро как и yarn. После обновления почувствовался огромный прирост, поэтому вернулся в npm i
Это хорошо, что появился yarn и дал пинок npm, но теперь лучше бы про yarn все как-то забыли, потому что ситуация с тем, чтобы иметь второй пакетный менеджер, который точно такой же, но умеет emoji (ну и может чуть быстрее), это просто какая-то карикатура от javascript экосистемы на саму себя.
Работаю в команде над проектом написанным на ZF2, с его бизнес логикой не представляю как это все будет работать на ноде с ее асинхронностью. Если и будет переход, то на Go. Он и по производительности лучше выглядит.
Сам Райан Дал пишет об этом
So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
НЛО прилетело и опубликовало эту надпись здесь
А производительность PHP 7.1 и последнего Node.js сравнивали?
Я может не совсем в теме, но мне кажется, что у JS с производительностью будет намного хуже.
Я может не совсем в теме, но мне кажется, что у JS с производительностью будет намного хуже.
При рендере страниц вероятнее всего будет хуже. API на nodejs должна быть быстрее.
Но все описано в стиле — страны фей и розовых пони, не указывая недостатки новой платформы. Что не есть хорошо.
Но все описано в стиле — страны фей и розовых пони, не указывая недостатки новой платформы. Что не есть хорошо.
JS с производительностью будет намного хуже
Судя по тестам, node.js уделывает php 7.1.
benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=php
Ага, а если глянуть код бенчмарков — можно долго смеяться. js-ники писали бенчмарки для php?)
НЛО прилетело и опубликовало эту надпись здесь
Не нужна, но и лишней не будет ;)
НЛО прилетело и опубликовало эту надпись здесь
Раз за вас, а мы вот часть проекта переписали на go ради производительности. И это не хотелка разрабов, а требования бизнеса ;)
Конечно, есть особо «узкие» места, где даже 10% прирост производительности — играет роль, но в большинстве случаев жертвуют производительностью программы для повышения производительности программистов. Потому основная масса кода пишется на JS/C#/PHP, а не на C, C++
вот мне нужна, в данный момент бек берет данные из бд и потом их обрабатывает, там простейщие математические операции, средняя скорость обработки запроса около 30 секунд, это без учёта чтения из бд. некоторые особо жирные запросы могут обрабатываться и по 5 минут. есть ли смысл переходить на ноду?
Только если разбивать обработку на секции и работать через генераторы / тики процесса, ну или спаунить новый инстанс ноды на каждую тяжелую операцию. Главное правило — нельзя блокировать поток ноды, в котором идет основной ввод / вывод.
Интересно что у ас там происходит, что аж пол минуты что-то обрабатывается. Может стоит это делать на уровне БД или вообще выносить отдельным модулем на более приспособленные к мат вычислениям языки?
там простейщие математические операции
В простейшие математические операции неплохо умеет и сам сервер СУБД, да и в любом случае нагружать интерпретируемые нетипизированные языки ими — нонсенс, расширение для php на си или консольное приложение для js может быть в десятки раз быстрее.
Никто и не претендовал на истину в последней инстанции)
Non-motivation: We are profoundly uninterested in claims that these measurements, of a few tiny programs, somehow define the relative performance of programming languages.
Позабавило выделение результатов, где js быстрее и игнорирование тех, где быстрее PHP
В статье не написано о том что nodejs в отличие от php не запускается при каждом запросе, от стартует и обрабатывает события. Это существенно меняет разсклад как по производительности так и по архитектуре приложений.
Многим известна ситуация «Too many connections» при работе с MySQL. Корень проблемы в том что на каждый запуск PHP скрипта устанавливается новый connection (по-другому никак). Если запросов привалило много, база уходит «в задумчивость» и это заканчивается ошибкой «Too many connections». Нода же позволяет выделить небольшой пул соединений, например, 10. И драйвер MySQL на своем уровне будет обеспечивать работу с базой приложения используя эти 10 конекшнов. При большой нагрузке, запросы будут становиться в очередь и разгребаться медленее, но приложение будет остатваться рабочим и «живым».
Многим известна ситуация «Too many connections» при работе с MySQL. Корень проблемы в том что на каждый запуск PHP скрипта устанавливается новый connection (по-другому никак). Если запросов привалило много, база уходит «в задумчивость» и это заканчивается ошибкой «Too many connections». Нода же позволяет выделить небольшой пул соединений, например, 10. И драйвер MySQL на своем уровне будет обеспечивать работу с базой приложения используя эти 10 конекшнов. При большой нагрузке, запросы будут становиться в очередь и разгребаться медленее, но приложение будет остатваться рабочим и «живым».
А мы на fpm настроим 10 обработчиков, а остальные клиенты подождут на nginx… тоже же решение. Странный вы кейс придумали для демонстрации различия.
Я правильно вас понял, что в ноде при 15 "одновременных" запросах и 10 соединениях к базе в пуле не вместившиеся в 10ку не зависнут намертво на первом же запросе до возврата кем-то из 10ки соединения в пул, а запросы чудесным образом будут исполняться по какой-то очереди с нескольких обработчиков в одном соединении?
Если нет, то в чем выгода от такой "живости"?
Все разруливается не на уровне соединений а на уровне запросов. Приложению нужно выполнить запрос он обращается к модулю mysql, тот свою очередь смотрит есть ли у него свободный конекшн. Если есть по нему проходит запрос, если нет, запрос ожидает освобождения конекшна. Для приложения эта все выглядит как обычный запрос к базе (неважно побывал он в очереди или нет).
Кроме того, ресурсы приложения, которое делает запрос используются намного оптимальнее чем при роботе с php, т.к. все запросы проходят ассинхронно, другими словами пока не возникнет событие «пришел ответ на запрос», ресурсы не заблокированы, как в случае с mysql. Для php же ожидание губительно, так как и процессорные и память, выделенная на исполнения кода, заблокированы до ответа MySQL. Поэтому nodejs-приложение, как правило, может обрабатывать намного больше одновременных соединений чем аналогичное php-приложение.
Кроме того, ресурсы приложения, которое делает запрос используются намного оптимальнее чем при роботе с php, т.к. все запросы проходят ассинхронно, другими словами пока не возникнет событие «пришел ответ на запрос», ресурсы не заблокированы, как в случае с mysql. Для php же ожидание губительно, так как и процессорные и память, выделенная на исполнения кода, заблокированы до ответа MySQL. Поэтому nodejs-приложение, как правило, может обрабатывать намного больше одновременных соединений чем аналогичное php-приложение.
все запросы проходят ассинхронно, другими словами пока не возникнет событие «пришел ответ на запрос», ресурсы не заблокированы, как в случае с mysql
Для пользователя нет никакой разницы, заблокированы ресурсы или нет, если он не получает данные из БД. Потому с его точки зрения, что php, что nodejs: «нет коннекта к базе или она занята — нет результата, нет живости, бекенд завис».
Или вы предлагаете, чтобы какой нибудь метод REST вида GET /my/feeds при ожидании коннекта к базе занимался обработкой очереди тасков, чтоб не терять время попусту?
вы искренне уверены, что асинхронность это какой-то эксклюзив для js?
на пхп оно тоже есть, только зачем? sql-запрос все равно выполнится ровно за то же время, следующий sql-запрос в том же обработчике пойдет после выполнения предыдущего. А в наличие в среднестатистическом приложении огромного куска логики, который будет выполняться во время ожидания ответов от базы и при этом не зависеть от нее чет не верится.
Поэтому nodejs-приложение, как правило, может обрабатывать намного больше одновременных соединений чем аналогичное php-приложение.
да, если nodejs-приложение умеет обрабатывать больше одного соединения. ибо пхп приложение скорее всего будет обрабатывать одно соединение (если там не reactphp)
вы искренне уверены, что асинхронность это какой-то эксклюзив для js?
Вы перекручиваете мои слова. Просто в PHP нету ассинхронной организации кода, а в ноде это основной вид программирования. Это дает ряд преимуществ, которые описаны в несметном числе статей.
А про экслюзив это уже вы дофантазировали.
А в наличие в среднестатистическом приложении огромного куска логики, который будет выполняться во время ожидания ответов от базы и при этом не зависеть от нее чет не верится.
Например у вас 10 сервисов и одна база, в ноде можно обратиться одновременно ко всем и к базе и обработать ответы или ошибки от сервисов ПАРАЛЕЛЬНО, одновременно. Суммарное время выполнения будет ровняться самому тормознутому сервису или долгому ответу от базы а не сумме обращений ко всем сервисам. Разницу чувствуете?
да, если nodejs-приложение умеет обрабатывать больше одного соединения. ибо пхп приложение скорее всего будет обрабатывать одно соединение (если там не reactphp)
nodejs однопоточный. нода будет обрабатывать абсолютно все соединения в одном потоке, при этом все обработчики могут взаимодействовать между собой. Это делает элементармым такю задачу как написание чата, например.
Суммарное время будет равняться… суммарному последовательному времени. Он же однопоточный. Разве нет?
А вообще интересно было бы привести реальную задачу, которую вы решили таким способом. Вот правда, ни разу еще не видел, чтобы в ветке про Ноду кто-то сказал: Асинхронность ноды помогла мне решить вот-эту-вот-ресурсоемкую-мега-задачу, и это не чатик.
А вообще интересно было бы привести реальную задачу, которую вы решили таким способом. Вот правда, ни разу еще не видел, чтобы в ветке про Ноду кто-то сказал: Асинхронность ноды помогла мне решить вот-эту-вот-ресурсоемкую-мега-задачу, и это не чатик.
Суммарное время будет равняться… суммарному последовательному времени. Он же однопоточный. Разве нет?
Конечно же нет. Инициировать запросы нода, в так называемом event loop будет последовательно, но далее будет ждать события «пришел ответ» и запускать обработчик на это событие.
Redis тоже однопоточный, как вы считаете с редисом можно работать паралельно?
А вообще интересно было бы привести реальную задачу, которую вы решили таким способом. Вот правда, ни разу еще не видел, чтобы в ветке про Ноду кто-то сказал: Асинхронность ноды помогла мне решить вот-эту-вот-ресурсоемкую-мега-задачу, и это не чатик.
Я вам привел конкретный пример, где очевидно преимущество ассинхронного программирования.
У нас, в компании, используется микросервисная архитектура, большинство микросервисов на nodejs.
На основном нашем проекте полмиллиона уникальных посетителей в день auto.ria.com. И вначале мы программировали на PHP, и это было нелекгое время.
Допустим, что "ассинхронной организации кода" это такая интересная особенность, ровно как и наследование через прототипы. Допустим.
Так объясните, в чем выгода "асинхронной организации кода"? Все примеры, которые вы приводите это банальные асинхронные запросы к хранилищу/микросервисам и т.д. И вот тут я действительно не понимаю, как выразить вашу мысль, чтобы не "дофантазировать".
Вы уверены, что на php нельзя сделать асинхронный запрос к базе / кэшу? нельзя сделать банальный http-запрос (либо каким либо еще протоколом, благо сокеты доступны и для всего более менее стандартного есть реализации) и не дожидаться его исполнения? в php не существует callbackов и из них нельзя себе построить маленький адок? http://docs.guzzlephp.org/en/stable/quickstart.html#async-requests
и используйте себе 10 микросервисов и подключение к базе на здоровье, не ожидая ответа (только зачем).
кстати, а микросервисы вы на чем пишите? на ноде? надеюсь они не занимаются только тем, что запрашивают другие микросервисы и хоть где-то вылезет код, который нельзя "однопоточно распаралелить"?
Вы уверены, что на php нельзя сделать асинхронный запрос к базе / кэшу? нельзя сделать банальный http-запрос (либо каким либо еще протоколом, благо сокеты доступны и для всего более менее стандартного есть реализации) и не дожидаться его исполнения?
Напришите пример кода на PHP ассинхронного запроса к MySQL
ну очевидно же, что пример из документации по той же mysqli_query вас не устраивает. там же не так, как "надо"
напишите тогда чтоли требования, что вы хотите от этого примера, попробую вам помочь
Он даже в документации к PHP есть.
Вы сами то пример смотрели? Вечный цикл в котором инициируются «асинхронные» запросы и тут же постоянно идет проверка синхронным кодом или они все выполнились. Тут нету самого главного, события о том что что-то произошло. Надо постоянно синхронно что-то опрашивать. Конечно же это лучше чем ничего, но до полноценной асинхронной модели программирования еще очень далеко.
Это все равно что на машине кузов мерседеса с двигателем от таврии.
Это все равно что на машине кузов мерседеса с двигателем от таврии.
Вы такие древности пишете. Как будто не слышали о php-fpm.
Дайте человеку поглумиться над ПХП-сообществом, ну чего вы :)
А вообще да, сколько с ПХП работаю всегда удивляли доводы в пользу Node, особенно после выхода PHP 7+. Как будто у каждого второго разработчика домашний сайт на пару миллионов пользователей в час.
Да у меня даже демон на пхп есть написанный. Форкает себя для каждой задачи, память не жрет от слова совсем, работает шустро, но поскольку демон для парсинга, то на скорость языка ему плевать, ибо 99% времени — другие задачи.
А вообще да, сколько с ПХП работаю всегда удивляли доводы в пользу Node, особенно после выхода PHP 7+. Как будто у каждого второго разработчика домашний сайт на пару миллионов пользователей в час.
Да у меня даже демон на пхп есть написанный. Форкает себя для каждой задачи, память не жрет от слова совсем, работает шустро, но поскольку демон для парсинга, то на скорость языка ему плевать, ибо 99% времени — другие задачи.
Корень проблемы в том что на каждый запуск PHP скрипта устанавливается новый connection (по-другому никак).Разве persistent connections не решают эту проблему?
Это два языка с абсолютно разными принципами работы. Как вообще можно разумно их сравнивать. Это как сравнивать php и c#
Каждый язык просто подходит под конкретные задачи.
Каждый язык просто подходит под конкретные задачи.
Не спорю с тем, что Zend Framework 2 обладает гораздо большими возможностями, чем Express. Но Express оказался экономичным и простым решением, которого было достаточно для всех наших нужд. При переходе на него нам не пришлось от чего-либо отказываться.
Возможно вы изначально выбрали не тот фреймворк, если от фреймворка вам нужна была только реализация PSR-7 и PSR-15 и при переходе на Express вам не пришлось ни от чего отказываться.
Пишу на PHP, пару раз использовал ноду, штука прикольная но для больших проектов как по мне не подходит.
(10 разработчиков + 3 окружения) * 2 установки в день * 60 дней * 3 минуты на установку = 78 часов.
Программисты работают без выходных, по 30 дней в месяц?
Странно у программиста, в вычислениях, видеть такие ошибки.
И что такое 78 часов для 10 программистов за 2 месяца? Это ни о чем. Посчитайте, сколько эти же 10 программистов тратят время на туалет и перекуры — цифра будет значительно выше.
Composer — отличный, но медленный инструмент. У NPM есть тот же недостаток, поэтому мы, вместо него, выбрали Yarn. Это — самая быстрая альтернатива NPM.
Ложь. В разных ситуациях они по-разному себя показывают. На clean install npm просто в клочья разрывает yarn, в то время, когда есть lockfile в обоих менеджерах — yarn работает немного быстрее. Нельзя их ставить выше друг друга, у каждого есть плюсы и минусы, которые надо учитывать при разработке проекта. Я бы их назвал эквивалентными.
Почему не Java/C#/Go да даже Python, какие именно преимущества и недостатки по вашему вы принесли в проект вместе с Node.js?
Один язык для фулл-стек разработки
Ну если с этой точки зрения смотреть то да, плюс.
Кстати, постоянно вижу кучу вакансий на фулстеков — таки проблема специализированного Angular/Vue/React и т.п. разработчика найти? Понятное дело на JQuery + Bootstrap что — то простенькое любой сможет по быстрому сверстать покурив доки и тут еще отдельного человека для этого нанимать не комильфо но блин, когда речь идет о полноценном SPA приложении на отдельном фреймворке вроде Angular это уже ИМХО перебор.
а разве js для фронт и js для бэкенда — это все ещё один и тот же язык?
абсолютно. А если рассматривать фронт в хроме — то еще и один и тот же движок. Если конечно вы не считаете доступ к файловой системе расширением языка. А вообще в статье, на мой взгляд незаслуженно обошли вниманием typescript, он реально хорош. С тайпингами беда, да, но для долгосрочного использования пакета в проекте можно и свои сваять. А вот с flow натыкался на возможность на его основе генерить проверки типов в runtime но не видел отзывов реального использование в бою, было бы интересно почитать.
Меня, лично, PHP вполне устраивает. Дело в том, что я в PHP запрыгнул вперед JS и наверное «проникся» архитектурой и особенностями PHP, и код на PHP мне всегда более понятен чем например JS. Не могу утверждать что PHP лучше или хуже какого бы то ни было другого языка программирования. По моему мнению у каждого языка есть свои сильные/слабые стороны в большей или меньшей мере, в той или иной области. Попытался однажды написать приложение с использованием MEAN-стэка. Приложение вроде бы и получилось, вроде бы и работает, но процесс разработки мне не особо понравился. Может потому что кодил не с использованием IDE а в Sublime. Может кодер из меня никудышный)))такой вариант тоже может иметь место быть. Короче, не доверие у меня к JS на стороне сервера, а почему — объяснить трудно.
А чувствуется какой-нибудь прирост в производительности системы, скорости написания кода и т.д после перехода на другой стек?
И самый главный вопрос для меня, почувствует ли клиент этот переход (дольше загрузка страницы, ошибки в консоли, скорость обработки данных и т.д.).
Об этом ничего ненаписано…
И самый главный вопрос для меня, почувствует ли клиент этот переход (дольше загрузка страницы, ошибки в консоли, скорость обработки данных и т.д.).
Об этом ничего ненаписано…
А вы заметите разницу между скоростью генерации страницы в 100мс на ПХП и 70мс на Ноде? :) Я лично на глаз не различу их.
Единственное, на мой взгляд, существенное отличие — асинхронность. А это вебсокеты всякие. К ПХП их тоже можно прикрутить конечно, но там архитектура приложения изначально для них не задумана.
Единственное, на мой взгляд, существенное отличие — асинхронность. А это вебсокеты всякие. К ПХП их тоже можно прикрутить конечно, но там архитектура приложения изначально для них не задумана.
Да не так уж их и сложно приделать. Я пробовал добавлять их в php приложение изначально не задуманное для вебсокетов. Всё свелось к простому правилу «Отправлять данные в вебсокет клиенту, сразу после сохранения этих же данных в бд» я для этого использовал свой опенсорс проект github.com/CppComet/comet-server и все правки по добавлению уведомлений заняли от силы строчек 20 в php. И на фронтенде примерно столько же.
Было бы интересно наглядно посмотреть проект «до» и «после» для сравнения.
Переписывание софта под NodeJS передвинуто в будущее. Пока переписываешь всю массу, законодательство и требования бизнеса могут поменяться — проще доработать имеющееся. А вот новые фичи, например интеграция онлайн-кассы с базой данных нашей системы, реализуются уже на ноде.
Здесь мне очень нравится возможность задавать то, какие плагины использовать в проекте, и делиться конфигурациями. Благодаря ей можно подготовить рабочее место программиста буквально за пару кликов//
Как это сделать?
Как это сделать?
Итоги
Рассмотрим плюсы и минусы, с которыми мы столкнулись при переходе с PHP на JS:
Будьте добры, напишите на основе какого временного отрезка сделаны эти итоги. Потому что, частности ради, нужно понимать, что за полгода использования какого-то продукта о нем может сложиться одно впечатление, а за 5 лет — совершенно другое.
Вначале вы лишь упоминаете
но недавно перешёл на JavaScript
Напишите точные сроки. Для объективности.
Начиная изучать JavaScript, я воспринимал его как второсортный язык, без которого «к сожалению, не обойтись» при создании динамических веб-сайтов.
так и есть
Странный выбор, особенно в 2017 году, когда мода на nodejs, как ядро для backend давно уже прошла ничем особо хорошим себя не зарекомендовав
А на что пришла мода?
Сейчас кажется что на Go.
Не воспринимайте агрессивно, я тоже писал в свое время сайты на nodejs, в том числе и микросервисные проекты, последний раз в 2015 и сразу после готовности его переписал на laravel.
Потому как:
1) абсолютно все фреймворки nodejs на 2015 год проигрывали тем инструментам, которые имелись для php.
2) Асинхронность добавляла массу ненужных проблем не предлагая никаких плюсов в замен
3) Полное отсутствие возможностей реализации SOLID, для крупных, сеьезных проектов может лечь очень тяжким бременем на живучесть и вообще на турдозатраты и финзатраты разработки проекта
Да, был typescript — но это все не серьезно, пока вы буете набирать профессиональную команду тайпскриптеров, на том же Laravel, Symphony или других подобных инструментах, уже во всю бы шла разработка
Не воспринимайте агрессивно, я тоже писал в свое время сайты на nodejs, в том числе и микросервисные проекты, последний раз в 2015 и сразу после готовности его переписал на laravel.
Потому как:
1) абсолютно все фреймворки nodejs на 2015 год проигрывали тем инструментам, которые имелись для php.
2) Асинхронность добавляла массу ненужных проблем не предлагая никаких плюсов в замен
3) Полное отсутствие возможностей реализации SOLID, для крупных, сеьезных проектов может лечь очень тяжким бременем на живучесть и вообще на турдозатраты и финзатраты разработки проекта
Да, был typescript — но это все не серьезно, пока вы буете набирать профессиональную команду тайпскриптеров, на том же Laravel, Symphony или других подобных инструментах, уже во всю бы шла разработка
Да я не агрессивно. Просто по трендам фронтенда обзоров и статей много, а вот по бэку все в тени, тяжело узнать, что перспективно, что — нет.
НЛО прилетело и опубликовало эту надпись здесь
На 2015 год каких-то адекватных способов, кроме извращения с прототипированием не было.
Сейчас они может и есть но при любом раскладе, нодовским инструментам придется «нагонять» классические решения на пхп(я молчу уже про сообщество, которое не менее пары лет будет это переваривать)
1) O — Принцип открытости (полимрфный) — на практике в вебе применяется часто, например реализовать возможность добавления функционала(поведения) классу или группе классов, без изменения его кода(любая модель+комментарии, лайки, загрузка файлов итп), в ООП языках интерфейс+трейт(микс и возможно + сервис) или интерфейс + наследование. В Js приходилось расширять протип уже самого объекта (например декоратором) или сам «класс» но это не очевидно и идет в ущерб читабельности и чистоте архитектуры проекта да и вообще это даже сложно представить в рамках масштабной архитектуры
2) LSP — в PHP наследования с 5-й версии (единичное). Так что может быть в некоторых случаях актуально
3) Интерфейсы кажется в джс появились в 2017 -м?
4) Начест DI не знаю, не видел и пока представить DI без основы на классическом ООП
, с абстрактными классами или интерфейсами, а так-же конечно с обычным человеческим конструктуром не могу, но даже в php DI «доделывается» на прикладном уровне, но используется уже лет 5 точно
Сейчас они может и есть но при любом раскладе, нодовским инструментам придется «нагонять» классические решения на пхп(я молчу уже про сообщество, которое не менее пары лет будет это переваривать)
1) O — Принцип открытости (полимрфный) — на практике в вебе применяется часто, например реализовать возможность добавления функционала(поведения) классу или группе классов, без изменения его кода(любая модель+комментарии, лайки, загрузка файлов итп), в ООП языках интерфейс+трейт(микс и возможно + сервис) или интерфейс + наследование. В Js приходилось расширять протип уже самого объекта (например декоратором) или сам «класс» но это не очевидно и идет в ущерб читабельности и чистоте архитектуры проекта да и вообще это даже сложно представить в рамках масштабной архитектуры
2) LSP — в PHP наследования с 5-й версии (единичное). Так что может быть в некоторых случаях актуально
3) Интерфейсы кажется в джс появились в 2017 -м?
4) Начест DI не знаю, не видел и пока представить DI без основы на классическом ООП
, с абстрактными классами или интерфейсами, а так-же конечно с обычным человеческим конструктуром не могу, но даже в php DI «доделывается» на прикладном уровне, но используется уже лет 5 точно
Если перестать мыслить и оперировать классами, то "O" можно прекрасно заимплеменить и в Javascript. С функциями это вполне выходит
function makeButton() {
return document.createElement('button');
}
function makeRedButton() {
const button = makeButton();
button.style.background = 'red';
return button;
}Это совсем не то, у тебя считай что происходит декорация объекта, но возможно ты прав, можешь привести пример как ввести функционал например лайков для любой модели, не изменяя старые методы и так чтобы это было универсально а не с помощью создания функциональности внутри модели? Я просто никогда не видел такое программирование в джс, встречал только сильное связывание
Express эквивалент Symfony? Это тупая прослойка с базовым функционалом для веба. Он не решает бизнес-задач, але.
До этого я уже был знаком с JS. Сначала работал с jQuery, потом освоил Angular, и, наконец, начал пользоваться React...… а потом перейду на Elm. ;)
В мире JavaScript выбор достойных редакторов кода гораздо богаче. Мы остановились на VS Code.Автодополнение JS кое где в нём не работает, перешёл на IntelliJ IDEA, где поддержка Node.js отличная.
nvm use v6.9.1
Стоит перейти на >7.6, в которой появилась нативная поддержка async/await и я на этом месте выбросил babel.
Промисы (теперь — встроенные в язык)
Да, но они реализованы на js и не самым оптимальным способом, мы используем bluebird, кроме того, что он быстрей, там есть Promise.promisifyAll который создает обертку вокруг всех методов с использованием колбеков.
Не понял, чем flow принципиально лучше, чем typescript, в последнем вы также можете писать нетипизированный javascript, если вам это нужно. Самое сложное при переходе на TS это настроить tsconfig.json и потом по тихонечку начинать с чистого js внедряя фичи ts, по мере изучения, первая фича это типы, потом остальное. Но это ваше дело конечно, чистый js это тоже хороший путь.
Так же рекомендую начать использовать линтеры, например eslint или tslint (для typescript).
И удачи :)
Понимаю, что перевод, но интересно, чем PhpStorm для разработки на JS не угодил.
Насколько помню, для JS есть Webstorm, все функции которого должны быть и в PhpStorm'е.
Сам на TypeScript в PhpStorm'е пишу — поэтому интересно, есть ли какие-то особые удобства в VC Code. Ни один раз про неё встречал упоминания, но, насколько понимаю, главное преимущество в её бесплатности?
Насколько помню, для JS есть Webstorm, все функции которого должны быть и в PhpStorm'е.
Сам на TypeScript в PhpStorm'е пишу — поэтому интересно, есть ли какие-то особые удобства в VC Code. Ни один раз про неё встречал упоминания, но, насколько понимаю, главное преимущество в её бесплатности?
Скорость работы самой оболочки, отзывчивость при наборе текста, расширения пишутся на том же ts (достаточно просто и быстро) — это все лучше, чем в жирном поделии от jetbrains. Ну и версии ts — можно использовать прямо самое свежее, а не ждать несколько месяцев, пока jetbrains-ы прокрутят жизненный цикл обновления версий в своих плагинах.
Про скорость работы аргумент понял. У себя тормозов в PhpStorm'е не замечаю, но. конечно, надо сравнить. Поставлю — попробую.
А что вы имеете в виду под самыми свежими версиями ts — отсутствие поддержки каких-то фич языка в IDE? Я пока с таким, видимо, не сталкивался.
А что вы имеете в виду под самыми свежими версиями ts — отсутствие поддержки каких-то фич языка в IDE? Я пока с таким, видимо, не сталкивался.
А что вы имеете в виду под самыми свежими версиями ts — отсутствие поддержки каких-то фич языка в IDE? Я пока с таким, видимо, не сталкивался.
Список изменений.
Ну и общий список релизов (в каждом есть линк на changelog): github.com/Microsoft/TypeScript/releases
Единственный минус — нестабильный встроенный watch в vscode для транспиляции в js. Если будет невалидный tsconfig или еще что-то вызовет краш фонового вотчера — об этом никаких сообщений не будет и сможешь догадаться об этом только если что-то вроде бы должно работать, а работать не будет. Поэтому всегда приходится запускать вотчер во встроенной консоли и периодически проверять его.
Еще обязательно ставить плагин поддержки tslint — он дает много всяких quickfix-действий типа автоимпорта классов и фикса стиля и постоянно развивается.
та у автора наверное главное мотивация это что бы что-то другое
НЛО прилетело и опубликовало эту надпись здесь
php меня кормит уже 4 года. Начинал с древнего php 5.3 сейчас активно использую 7.1 для реальных проектов. У нас команда из двух верстальщиков, двух студентов, двух мидлов и двух менеджеров что тоже пишут на php. Рядом еще отдел java с похожим составом.
Новый php в связки с laravel хорош, да есть еще легаси на 5.4 от которого стынет в жилах кровь. Только вот в плане фронта далеко на чистом php и старой доброй jquery далеко не уедешь. Angular/React/Vue быть и это полезные технологии которые позволяют очень многое. В данный момент разбираюсь с redux и делаю фановые штуки на React.
К сожалению сама по себе node.js не такая на мой взгляд платформа на которой стоит делать "серьезный" backend. Так что возможно работать в связке node+php где простые stateless компоненты взаимодействуют с более "серьезным" api на том же php. Проблема правда в том что для backend вместо php спокойно можно ставить java/go/python где серьезные вещи можно будет сделать проще на них.
Итог — если вы хотите чуть больше чем костыли на jq — node.js вам понадобиться, php — не сложный бэк и в этом он реально хорош, для кошмарных вещей лучше использовать java, для кучи мелких но быстрых go.
В поиске хорошей системы мониторинга мы перешли с Supervisord на его конкурента, написанного на JavaScript
Осталось только прикрутить надежную систему мониторинга для системы мониторинга, написанной на JavaScript :)
Понятно что ZF2/Symfony и Express.js совсем разные фреймворки, в мире node.js их роли больше занимает sail.js
Но вот по ORM, Sequelize даже рядом не стояла с Doctrine. От Sequelize создается впечатления не завершенного инструмента. Да в Doctrine много абстракций и многое делается довольно многословно, но это дает понимание, что происходит, дает нормальные интерфейсы.
Но вот по ORM, Sequelize даже рядом не стояла с Doctrine. От Sequelize создается впечатления не завершенного инструмента. Да в Doctrine много абстракций и многое делается довольно многословно, но это дает понимание, что происходит, дает нормальные интерфейсы.
В PHP можно было добавлять подсказки типов данных только тогда, когда это было нужно. Это — одна из моих любимых особенностей PHP
Ага, начиная с пхп 7-ой версии, насколько я знаю. «Старая добрая возможность в пхп..»
Падение серверов и мониторинг с помощью PM2
Настройте себе нормальный CI/CD бл%*$!!!
В мире JavaScript задачи конфигурирования можно решить с помощью отличной библиотеки DotEnv и файлов .env. Библиотека позволяет использовать переменные окружения для настройки приложения.
Оу правда?! Существуют переменные окружения? Вау! И из них можно делать конфиги?! И даже какая-то библиотека есть… Вот это класс…
Так как не было функции автоисправления..
Вы серьезно?
Disclaimer: сам пишу на джаваскрипте, пхп не пользуюсь. Но серьезно, это для вас и есть главные открытия 2017?? То о чем вам все и так постоянно говорят?? Блин, да у вас все хуже чем я думал…
Я так и не понял, в чем выгода перехода с PHP на Node. Количество коннектов к mySQL уменьшилось за счёт какого-то внутреннего менеджера пула запросов? Ну, можно было его на php написать, вероятно, быстрее, чем менять весь стек разработки?
И если сервер долго отдаёт результаты запроса, какая разница, что подвиснет в ожидании или вылетит с ошибкой — этот менеджер или что-то ещё?
Вместо знания PHP + frontend JS теперь надо знать backend JS + frontend JS? Ну, наверное, есть некоторый выигрыш от унификации подходов… если и бек, и фронт пишет один человек и ему сложно переключаться между языками.
Других выгод не увидел, картинка с инструментами красивая, но если я правильно понял — вместо выбора 1 из 3 инструментов для PHP, в Node обычно только один, без альтернатив?
Я, может, и хотел бы перейти на что-то другое с PHP, но так и не понял, в чем профит. А фраза про "в случае с node сервер подвисает целиком, поэтому его надо мониторить" меня категорически отпугивает.
Статья это типа такой странный троллинг что ли? Или так по приколу написали, чтобы написать?
Плюсы и и минусы странно сомнительные какие-то.
Так то у вас судя по всему есть некие проекты, ну так можно же написать, вот было Н серверов стало М на похожем функционале.
Раньше кодили нечто эдакое А дней, теперь Б.
Объемы переведенного опять же непонятны, а то вдруг некий не сильно большой сайт переписали, а потом придет вдруг осознание, что асинхронщина это вообщем-то больно, печально и не для всех в большом проекте. И намного дешевле было сервак добавить, чем адекватных джаваскриптеров найти, например.
Плюсы и и минусы странно сомнительные какие-то.
Так то у вас судя по всему есть некие проекты, ну так можно же написать, вот было Н серверов стало М на похожем функционале.
Раньше кодили нечто эдакое А дней, теперь Б.
Объемы переведенного опять же непонятны, а то вдруг некий не сильно большой сайт переписали, а потом придет вдруг осознание, что асинхронщина это вообщем-то больно, печально и не для всех в большом проекте. И намного дешевле было сервак добавить, чем адекватных джаваскриптеров найти, например.
Очередная ода хайповому языку. Особо позабавило что автор уверен, будто Node заменит нормальный вебсервер и его восторг по поводу классов в JS. Несмотря на всю мою любвь к этому языку вынужден признать, что как серверный его рассматривать не стоит. Если уж на то пошло, PHP тоже далеко не идеален, но годы использования сгладили его углы.
В данный момент чуть меньше года сижу на проекте с Node. И знаете что? Я его терпеть не могу. Промисы в промисах в промисах в промисах в промисах, нормального наследования нет, на каждый чих свой модуль… И тормозит это чудесное поделие так, как на PHP никогда не добиться.
В общем воля ваша, набирайте неофитов, но я серверным JS буду заниматься только по принуждению обстоятельств. Вся причина его популярности — низкий порог вхождения за счёт кучи JS разработчиков из фронта, где, собственно, JS хорош и востребован.
В данный момент чуть меньше года сижу на проекте с Node. И знаете что? Я его терпеть не могу. Промисы в промисах в промисах в промисах в промисах, нормального наследования нет, на каждый чих свой модуль… И тормозит это чудесное поделие так, как на PHP никогда не добиться.
В общем воля ваша, набирайте неофитов, но я серверным JS буду заниматься только по принуждению обстоятельств. Вся причина его популярности — низкий порог вхождения за счёт кучи JS разработчиков из фронта, где, собственно, JS хорош и востребован.
По-русски так не говорят: «в результате я никогда и не пытался как следует в нём разобраться», «эти стандарты по-настоящему полезны при подготовке правил оформления кода». Читая такие фразы мгновенно понимаешь, что это дословный перевод. Читать дословный перевод неудобно, потому что для русского языка подобные конструкции нестандартны и непривычны, — мозг спотыкается об них. Для маленькой статьи не критично, но когда читаешь книгу с таким переводом, хочется порвать её в клочья и сжечь.
Мне интересно, как люди борются с прожорливостью ноды по памяти? Есть какие-то статьи по теме?
Интересен был бы сравнительный обзор наиболее популярных бэкенд фреймворков (независимо от языка)…
сравнивать express ZF или Symfony это как минимум смешно да и вообще сравнивать node с php не серьёзно уж очень отстает node по возможностям
ммм… не то что бы очень хочется похоливарить, но тут как бы правила хорошего тона предполагают хоть какой ни будь списочек.
Express скорее справедливо сравнивать с http микро-фреймвормами — у них есть микрокаркас приложения / http kernel, прослойка middleware, роутер, возможно какой-нибудь di-контейнер. Так что думаю, что корректнее будет его сравнивать с фремворками Slim, Silex, возможно Lumen, но никак ни Laravel/Symfony/ZF.
Express наверное к Laravel будет ближе, если абстрагироваться от особенностей самих языков.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Node.js и переход с PHP на JavaScript