Актуально ли? Backend на Node.JS или на php? Стоит ли изучать NodeJS?

[Feeddie]

Сообщение от Alex11223

Так вы ж говорите
Одно из определений слова "сложный" — состоящий из нескольких частей/компонентов.

Вот я и говорю, что можно не мешать все в кучу потому что далеко не все связанное с Node.JS относится к бекенду и никто не мешает все эти вещи использовать с РНР (что многие и делают).

Вообще про "только скуку и грусть" не очень понятно. РНР используется для разных вещей, а не только для вордпресса и битрикса
В нем как и в других языках есть современные фреймворки типа Laravel, Symfony если вы это хотели.

Как раньше и сказал, люблю JS) за работу с dom

[Naive]

Сообщение от Feeddie

Как раньше и сказал, люблю JS) за работу с dom

Любишь JS за наверное самую не продуманную его часть? Интересно...
jQuery и выстрелил, и продолжает держать марку за счет того, что это отличная обёртка над dom и... над AJAX. Что как бы уже само по себе кричит о несовершенстве API по работе с dom и собсна AJAX.
К чему я все про AJAX? — к тому, что если ты делал многоступенчатые запросы хотябы в jQ, то знаком с понятием "асинхронный ад". В jQ есть механизм собственных промисов, который предназначен для решения этой проблемы. Я об этом говорю, потому что знал бы ты что такое промисы, ты бы не задавал вопрос об актуальности node.js. Нода — это асинхронный ад в десятой степени. Он, конечно имеет возможность писать в классическом php-стиле, но тогда нода сильно теряет в производительности по сравнению с нормальными синхронными языками (пых, перл, си). Нода работает хуже с текстом, чем перл; хуже с данными, чем все... Но когда ты умело можешь все тяжкие операции сбросить на других, а нода у тебя выполняет функции регулировщика и не нагружает себя тяжелыми задачами, то превращается в конфетку. Потому что пока он ожидает выдачи из БД, к примеру, или конвертации картинки, или парсера текста, этот же самый скрипт обработает пару тысяч других пользователей и направит от них запросы и на обработку изображений, и проверку текста, и запрос к БД зашлет. А потом обработает результат первого и остальных 2к юзеров. Тут ему равных нет (кроме наверна моджолиус, но чтобы впарываться в перл, наверное надо отказаться от личной жизни).

Так что node.js актуален и многие на него с удовольствием дрочат, у нас на проекте тоже вполне успешно юзается. Но кодинг под ним сильно отличается от jQuery-style, ибо у jQ это в основном функциональное программирование с кайфовыми цепочками, а нода — это асинхронный ад, промисы и ES2016.

[8Observer8]

Я тоже изучаю Node.js Среду выбрал - VS Code. Если честно, мне JS не очень понравился, потому что я привык к C#, C++ и Python, поэтому вместо JS я использую TypeScript. TS - это надстройка на JS, то есть TS полностью включает в себя JS. Компилятор TS на выходе даёт JS-код. Всё это через gulp настраивается: можно автоматизировать unit-тестирование - на выходе получается минимизированный .min.js Я выбрал Node.js + TS чтобы учиться делать браузерные WebGL игры с мультиплеером и 3D приложения для сайтов.

[Naive]

Сообщение от 8Observer8

Я выбрал Node.js + TS чтобы учиться делать браузерные WebGL игры с мультиплеером и 3D приложения для сайтов.

Дык WebGL в браузере рисуется, какая разница на чем у тебя сервер?

[8Observer8]

Конечно, без разница. Сервер можно сделать на Python, C#, C++ и т.д., но мне понравилось на Node.js тем, что некоторый код игр можно делать общим. А ещё инструменты типа: Jade/Pug, Express, MongoDB, Socket.io и т.д. Node.js/npm делает удобным разработку и клиента и сервера.

[Alex11223]

npm да (а лучше yarn), но никто не мешает его и без Node.JS бекенда использовать.

[8Observer8]

Сообщение от Alex11223

npm да (а лучше yarn),

Чем лучше? Я пока ещё мало работал с npm и вроде меня пока устраивает. В npm есть какие-то подводные камни, которых в yarn нет?

Сообщение от Alex11223

но никто не мешает его и без Node.JS бекенда использовать.

Серверную часть на Node.js (базы данных, socket.io) я ещё очень мало использовал. Но если даже брать клиентскую браузерную часть, то и здесь Node.js очень удобный. Мне достачно ввести одну команду "gulp" и автоматически все мои .ts скрипты будут преобразованы в .js, склеются вместе в один bundle.js-файл. Далее, этот файл будет обработан uglify, чтобы сжать. При этом будет сгенерирован ещё один файл - bundle.map.js, который позволит ставить точки останова и отлаживать по шагам .ts файлы в среде Visual Studio Code. Осталось ещё научиться подключить unit-тестирование к gulp, что-то из этого: jasmine, mocha, karma, sinon и т.д.

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

[Alex11223]

Сообщение от 8Observer8

Чем лучше? Я пока ещё мало работал с npm и вроде меня пока устраивает. В npm есть какие-то подводные камни, которых в yarn нет?

Быстрее и некоторые команды более удобные/логичные, нормальный lockfile.
Это что-то типа альтернативного клиента для того же репозитория пакетов npm.

[Человек_Борща]

Здравствуите. В общем, задался я тут вопросом. Я хочу разрабатывать саиты как на стороне клиента, так и на стороне сервера. Долгое время программировал на php, но понял в итоге, что php вызывает у меня только скуку и грусть, но зато я просто обожаю javascript, а библиотека джиКуэри - это вообще любовь пожизненно.

Так вот, узнал я о такои вещи как Node.JS и сразу же приглянулась мне она, особенно мне приглянулись компоненты gulp, sass и Express для серверных запросов. Выглядит все довольно сложно и хотелось бы услышать советы гуру.

Стоит ли? И где искать уроки по даннои среде?

Конечно хорошо знать всего 1 язык программирования и делать им всё - просто мечта, но это так не бывает, увы.

Минусы самого JS, которые не сильно резали глаза в браузере, но вылезли на сервере, в следующем:
1. Нельзя управлять кучей (память), вообще, т.е. ты просто обязан думать сколько твой код жрет ресурсов, иначе начнутся проблемы и придется периодически просто срубать процесс.

2. Он асинхронный. Нельзя просто так взять и написать f1(); f2(); f3(); и думать, что они выполняться один за другим. Хрен там. До появления встроенных Promise, это просто пи..... как страшно, когда у тебя в ряд стоит не 3-5 функций, а 7-10, и они ещё ветвятся по условиям. И везде надо писать callback-и, и ветвить далее. Короче АДище!

Вот для примера:

fs.readdir(source, function (err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function (filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function (err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function (width, widthIndex) {
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})

Сейчас это заменили всякие Promise, но и от них как-то не легче.

3. Он однопоточный. Нельзя делать тяжелые задачи все в одном скрипте, их надо куда-то выносить, реализовывать форки node и давать им под-задачи.

4. Node.js не выгружается, он работает постоянно.



В node.js все эти проблемы разом всплывают на стороне сервера, сервер делает много задач, часто задача из себя представляет цепочку мелких функций, которые должны отработать по очереди,очень часто любые задачи на ввод/вывод данных - синхронные, а JS-то асинхронный! Задачи могут быть разные по весу и соответственно отъедать нормально памяти и времени.

Получается вот какой ад:
Если тебе надо выполнить цепочку связанных друг-с-другом задач (функций), тебе придется использовать Promise, или по-старинке ад из Call-back'ов. Если задача ещё и тяжелая по времени, то её придется отправить в отдельный процесс, потому что на время её выполнения, повиснет вообще весть процесс текущего скрипта. Далее, сервер всегда работает с БД, а БД это часто синхронный ввод/вывод данных дабы ничего не запороть и не сломать в этой самой БД, а значит для node.js нужен ещё и механизм очередей запросов к БД, который будет хранить в себе некую инфу на запись, и когда рак на горе свиснет, эта очередь вызовет callback где-то, дабы кто-то узнал, что инфа таки легла в базу.
А учитывая тот факт, что node не выгружает скрипт, и отпускает занятые им ресурсы либо при вызове GC либо при убивании процесса, то получаем ещё и головную боль с поиском утечек памяти, а будут они аж двух видов:
1. Память просто утекает ппц как быстро, надо часто убивать процесс, чтобы система работала.
2. Память утекает не так быстро, но её чистка, при запуске GC, просто "фризит" процесс на время чистки, потому как занято и не высвобождено много уже использованных ресурсов, но не достаточно много, чтобы например забить весь доступный RAM.

И вот node.js упирается в кучу этих вроде как мелких проблем, кстати говоря, не существующих вообще в том же C++ или PHP. И вот, node.js моментально обрастает кучей дополнительных ресурсоёмких механизмов которые надо юзать, дабы правильно использовать БД и не думать как оно там и когда запишется, как правильно реализовывать тяжелые задачи, и как делать очереди чего-либо и т.д.



Этим всем мне и не понравился Node, средней сложности вещи - требуют диких затрат по ресурсам, сложные - сложно контролировать (нет, есть куча пакетов на npm чтобы решать ещё и это).
Короче для поиграться - это наше все, мелкие игрульки - туда же, сайты-визитки, простые блоги и форумы, микро-сервисы и какой-то простенький backend - туда же. А серьёзные проекты надо решать языком программирования, который на стороне сервера позволит управлять кучей, и создавать потоки для асинхронной работы чего-либо тогда, когда это реально надо.

P.S. npm с gulp и приблудами, нормально заходит вместо cmd и powershell))

[8Observer8]

Плюсом Node.js является то, что с него проще начать знакомиться с программированием сетевых приложений. Я когда начал, то первая элементарная задача, которую я себе поставил было: сделать простейший сервер в несколько строк задача которого была бы принять текстовое сообщение от одного клиента и разослать остальным. Результатом такого простого приложение была бы возможность отправить ссылку кому-то из знакомых и чтобы мы могли находиться на одном сервере и обмениться сообщениями. Такой вот "Hello, World". На Node.js оказалось проще всего сделать этот первый шаг. Есть бесплатные хостинги типа: heroku.com, openshift.com и т.д., где есть короткие пошаговые инструкции, как легко можно развернуть приложение. Сочетание таких хостингов + Node.js + socket.io позволяет приступить к изучению сетевого программирования. Можно создавать приложения на двоих: карточные игры (дурак, покер), морской бой и т.д., изучая программирование на практике. Если начинать делать с чего-то другого, то может дело даже не дойти до начала создания реального маленького приложения по глобальной сети, а погрязнуть в преждевременных сложностях.