DjangoBB LoFi version

Полная версия: node.js

1 2

o7412369815963

Июль 30, 2012 07:51:33

Кто что думает о данном звере?
В плане веба и бизнес приложения.

Чем “затягивает” node.js
+ изначально асинхронный
+ полноценные анонимные ф-ии
+ на порядок быстрее (считается что обычно язык не является узким местом в приложении, но все же скорость лишней не бывает)
+ для веба, один язык для сервера и клиента (но пока не считаю это большим преимуществом)
+ по ощущениям гибче (не считая отсутствие yield), например у объекта можно подменить родительский “класс” (прототип), меньше “выкрутасов” для получения “магии” - метаклассы, декораторы и пр. а в JS это все делается в лоб - функциями, как по философии питона - “явное лучше не явного”.

в противовес, у питона:
+ стабильность (хотя node.js вроде уже не такой падающий как в первых версиях)
+ есть “yield” (в node.js пока этого нет)

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

Lexander

Июль 30, 2012 17:53:28

o7412369815963
+ изначально асинхронный

Как на счет gevent, Twisted например? Когда это действительно нужно, а не всегда.
Лапша из inplace обработчиков асинхронных событий в JavaScript - одна их худших вещей, что могли “придумать” для читаемости кода.
Например:

app.get('/', function(req, res) {
    var a = null;
    some_object.some_method('my_param', function(err, result) {
        if (err) {
            sys.puts('Error');
            return;
        }
        other_object.other_method(result, function(err, result2)){
            if (err) {
                sys.puts('Naive error');
                return;
            }
        a = result2;
        });
    });
});

Нравится?

o7412369815963
+ на порядок быстрее

Быстрее Питона? Зависит от задачи. Распараллеливание (и асинхронность) эффективно вне зависимости от языка.
Я думаю, что сейчас использовать синтетические тесты и по ним оценивать язык уже нет смысла, т.к. на “поле брани” - в системах с огромным объемом данных узкими местами все равно остаются операции IO.

o7412369815963
+ полноценные анонимные ф-ии

И все та же лапша из многовложенного кода.
Возможностей лямбд не хватает?

o7412369815963
+ для веба, один язык для сервера и клиента (но пока не считаю это большим преимуществом)

Это чуть ли не единственный конек node.js.
Но только на первый взгляд.
Он призван уменьшить затраты на средних и больших проектах. Типа один язык разработки подразумевает более однородную среду разработки, однородную команду и тем самым снижает затраты на проект.

Но, тут не все так гладко.
Во-первых, те кто пишет для клиента и те, кто пишет для сервера - это разные люди. Как по знаниям и опыту, так и используемым технологиям.

Во-вторых, для оговоренных средних и больших проектов команды разработчиков сервера и клиента - разные команды. Таким образом их однородность существует только на бумаге.

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

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

О гибкости ничего сказать не могу, у меня опыта разработки на node.js, поэтому могу оценивать ее только как технологию в целом или отдельные архитектурные особенности.

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

О построении страницы на стороне клиента.
Эта естественная возможность - еще одна фишка node.js, которую объявляют как преимущество.
Твиттер в прошлом году перешел как раз на использование такого подхода: страница генерируется блоками, которые вставляются и обрабатываются уже на клиенте. Цель перехода - оптимизация.
В этом году Твиттер отказался от такого подхода и вернулся к старой схеме - генерация страницы на сервере полностью. Причина возврата - просела производительность системы и старый подход позволяет добиться большей оптимизации.
На примере Твиттера заявленный подход генерации страницы на стороне клиента в качестве способа оптимизации и снижения нагрузки на сервера оказался неработоспособным!

В общем, любой инструмент хорошо использовать по назначению,- исходя из требований проекта.

Lexander

Июль 30, 2012 17:58:36

В догонку.
Молодой node.js уже показал себя не самой лучшей стороны фундаментальными изменениями в API.
Ну и, конечно, как на счет малого количества готовых библиотек - тоже следствие молодости.

o7412369815963

Июль 30, 2012 21:51:03

С лапшой согласен, хотя можно и без лапши.

О построении страницы на стороне клиента.
Эта естественная возможность - еще одна фишка node.js, которую объявляют как преимущество.

тут сервер не причем, с любым сервером можно строить на клиенте.

Молодой node.js уже показал себя не самой лучшей стороны фундаментальными изменениями в API.

Где про это можно почитать?

Быстрее Питона? Зависит от задачи.

Задача - само собой, я имею ввиду скорость отработки самого языка. но это не решающий фактор.

Ну и, конечно, как на счет малого количества готовых библиотек - тоже следствие молодости.

Смотря как посчитать, вообще там уже навалом библиотек, конечно меньше чем у питона, но мне достаточно.
Например там есть конекторы для mongodb и sphinx-search, а у python+web tornado с этим не айс: для sphinx-search нет либы под торнадо, а для mongodb есть 4 либы (для торнадо) - 2 костыльные (не через tornado loop) и 2 не доделаных. Хотя для nodejs они тоже возможно не доделаны.

На примере Твиттера заявленный подход генерации страницы на стороне клиента в качестве способа оптимизации и снижения нагрузки на сервера оказался неработоспособным!

это клиентская часть, сервер может быть любым, как бы node.js ни причем.
тут вопрос клиентская генерация VS серверная, твитер конечно авторитет, но эта новость на хабре (там я её прочел) какая-то полужелтая да и думаю твитер что-то темнят.
У меня есть куча примеров где клиентская генерация по многим показателям опережает серверную.
Да и Google и Facebook юзает клиентскую и все ок.

o7412369815963

Июль 30, 2012 21:56:28

Я думаю надо попробовать что-то небольшое написать на node.js, что-б прочувствовать плюсы-минусы.
а там виднее будет, но подискутировать ещё готов.

Lexander

Июль 30, 2012 22:54:10

o7412369815963
Где про это можно почитать?

Вот, например.
А вообще в Гугле “node.js api changes”.

o7412369815963
тут сервер не причем, с любым сервером можно строить на клиенте.

Эта фишка была заявлена авторами на одной из презентаций как килер-фича.

o7412369815963
это клиентская часть, сервер может быть любым, как бы node.js ни причем.

Речь как раз о том, как быстро отдает серверная часть данные и как эта серверная часть масштабируется.

o7412369815963
тут вопрос клиентская генерация VS серверная, твитер конечно авторитет, но эта новость на хабре (там я её прочел) какая-то полужелтая да и думаю твитер что-то темнят.
У меня есть куча примеров где клиентская генерация по многим показателям опережает серверную.
Да и Google и Facebook юзает клиентскую и все ок.

Я читал это в блоге Твиттера - т.е. в первоисточнике, думаю, верить можно, иначе их бы давно заклевали.
Одно дело, когда на клиента передаются часть данных, совсем другое, когда генерится вся страница.
Первое позволяет сделать интерфейс более отзывчивым, второе конкретно затрудняет создание страниц и их отладку.

odnochlen

Авг. 1, 2012 06:18:54

Lexander
Лапша из inplace обработчиков асинхронных событий в JavaScript - одна их худших вещей, что могли “придумать” для читаемости кода.
Например:

Это люди так страдают от отсутствия async?

Линукскапец++

Lexander
Распараллеливание (и асинхронность) эффективно вне зависимости от языка.

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

Так что это не фича, а баг, пока дело не касается проблемы 10к соединений.

Lexander

Авг. 1, 2012 12:42:09

odnochlen
Эффективность асинхронности зависит от языка. Питон в многопоточность под нагрузкой не может - из-за гила он в несколько потоков и особенно на нескольких ядрах работает не быстрее, а медленнее Так что это не фича, а баг, пока дело не касается проблемы 10к соединений.

Речь об асинхронности в контексте node.js. В основном, это - IO.
А что касается многопоточности, то Нода однопоточна, как и Питон.
Для реализации многопоточности используются те же средства.

odnochlen

Авг. 3, 2012 05:42:39

Lexander
то Нода однопоточна, как и Питон.

Это как - там тоже GIL, и многопоточность через процессы?

Lexander

Авг. 3, 2012 11:40:08

Что-то типа того.
Там есть пул потоков, которые обслуживаются в цикле (event loop).
Многопоточность - через процессы.

Их вкусностей - есть модуль кластеризации, который очень просто позволяет загрузить все ядра на текущей машине или передать работу на другие сервера кластера. Фактически - это синтакс-шугар для создания новых процессов (воркеров) и передачу им данных для обработки.

В Питоне, кстати, полно своих похожих инструментов. Parallel Python, execnet, например.
Да что там говорить, у нас есть целый раздел http://wiki.python.org/moin/ParallelProcessing