Comments 20
Примите поправку: блог называется «Nodebits» и расположен эвона где.
Интересно, что эти новые взаимосвязанные проекты Cloud9 при поддержке людей из Фонда Мозиллы получили свою долю внимания и во блоге «Mozilla Hacks» (во блогозаписи «JavaScript on the server: Growing the Node.js Community»), хотя бóльшая часть этого блога, насколько я его помню, последние годы была посвящена новинкам Файерфокса.
Пользователям блогохостинга LiveJournal (если такие есть среди поклонников Node) будет полезно добавить во friends трансляционную учётную запись rss_nodebitsorg, только что мною созданную.
Те, кто считает JS хорошим языком, в первую очередь ориентируются на C-подобный синтаксис. Мол, почти старый привычный C. Но учитывая, что семантика JS очень сильно отличается от C, то такой синтаксис только мешает. Erlang наоборот, имеет странный непонятный Prolog-like синтаксис, а так как на прологе никто сейчас не пишет, то и ерланг воспринимается как эзотерика. Принцип встречи по одёжке никто ещё не отменил, да. Вот и получается, что те, кто не захотел глубоко копнуть, пишут на Node даже не подозревая, что они страдают, а другие пишут на ерланге и не страдают. Примерно как с пользователями Windows и PHP — люди с малолетства привыкают к развесистым костылям и подпоркам и считают, что это вполне нормально, от этого никто не умирает, и потом сами считают в порядке вещей писать разный ментальный ужас и инфернальные вызовы. Jedem das Seine, чо.
Проблемы с памятью, указанные по приведённой Вами гиперссылке, действительно существуют.
К сожалению, ограничения объёма используемой памяти свойственны не языку JavaScript и даже не движку Node, а виртуальной машине (интерпретатору джаваскриптов) V8, на которой Node построен, поэтому их устранение займёт некоторое время.
(Одно из таких ограничений ужé было убрано в сентябре 2011 года, а другие, быть может, убраны или будут убраны позднее. Но сегодня проблема всё ещё не решена.)
Это делает движок Node непригодным для обработки данных гигабайтового размера за один присест — их придётся пережёвывать меньшими кусками. Неприятно, конечно; но обходной путь всегда можно найти, перестроив алгоритм, больше полагаясь на работу с файлами, чем с памятью.
Что же касается невозможности нормальной кластеризации, то по приведённой Вами гиперссылке я об этом не увидел ни слóва.
К сожалению, ограничения объёма используемой памяти свойственны не языку JavaScript и даже не движку Node, а виртуальной машине (интерпретатору джаваскриптов) V8, на которой Node построен, поэтому их устранение займёт некоторое время.
(Одно из таких ограничений ужé было убрано в сентябре 2011 года, а другие, быть может, убраны или будут убраны позднее. Но сегодня проблема всё ещё не решена.)
Это делает движок Node непригодным для обработки данных гигабайтового размера за один присест — их придётся пережёвывать меньшими кусками. Неприятно, конечно; но обходной путь всегда можно найти, перестроив алгоритм, больше полагаясь на работу с файлами, чем с памятью.
Что же касается невозможности нормальной кластеризации, то по приведённой Вами гиперссылке я об этом не увидел ни слóва.
Если бы в этой ссылке было написано что кластеризация в ноде страдает, вы бы тогда ответили как там на самом деле с этим обстоят дела? Может быть просто скажете пару слов об этом, что бы я не пытался найти того, чего возможно и нет. И кстати это я перечислил детские проблемы, которые видимо вылечатся каким-нибудь фреймворками аля jquery или патчем v8. Мне было интересно не то, как правильно это чинится, а преимущества ноды.
Кластеризация в Node — сравнительно новая фича, выросшая не так давно из метода child_process.fork(), как былинка вырастает из семечка. Умеет пока что не так много (см. описание API). В настоящее время Andreas Madsen ведёт обширную и плодотворную работу, направленную на улучшение кластеризации Node, но эта работа ещё не завершена. (По моему мнению, раньше выхода Node версии 0.8 он и не успеет завершить её в любом случае.)
Преимущества ноды были прекрасно изложены на днях во блоге «Mozilla Hacks» (во блогозаписи «JavaScript on the server: Growingthe Node.js Community», на которую я сослался чуть выше).
Прежде всего это те преимущества, которые сулит использование языка JavaScript.
Во-первых, повторное использование готовых навыков и знаний. Любой такой веборазработчик, который знает JavaScript и программировал на нём для браузера, теперь может использовать свои навыки и знания для создания серверных скриптови (или) даже десктопных приложений (пока только консольных приложений, но это может измениться в связи с получением доступа к системным API).
Во-вторых, повторное использование готового кода. Если готовая библиотека джаваскриптовых функций не имеет никакого дела с браузерною DOM, а занимается обработкою данных (например, такая библиотека,как underscore), то она ничуть не хуже работает на ноде, чем во браузере. Если правильность заполнения некоторого бланка (<form>) надо проверить сперва во браузере, а затем на сервере, то это можно сделать одним и тем же кодом на одном и том же языке — на джаваскрипте.
Ну а по сравнению с другими джаваскриптовыми движками (Jaxer, Helma, JSDB) нода выигрывает за счёт использования интерпретатора V8, превосходящего SpiderMonkey и Rhino по скорости.
Преимущества ноды были прекрасно изложены на днях во блоге «Mozilla Hacks» (во блогозаписи «JavaScript on the server: Growing
Прежде всего это те преимущества, которые сулит использование языка JavaScript.
Во-первых, повторное использование готовых навыков и знаний. Любой такой веборазработчик, который знает JavaScript и программировал на нём для браузера, теперь может использовать свои навыки и знания для создания серверных скриптов
Во-вторых, повторное использование готового кода. Если готовая библиотека джаваскриптовых функций не имеет никакого дела с браузерною DOM, а занимается обработкою данных (например, такая библиотека,
Ну а по сравнению с другими джаваскриптовыми движками (Jaxer, Helma, JSDB) нода выигрывает за счёт использования интерпретатора V8, превосходящего SpiderMonkey и Rhino по скорости.
Мицгол, ваши «преимущества ноды» заставляют меня озадаченно удивляться.
Начнём с языка. Из ваших слов, выходит, что единственное, что сдерживало тысячи веб-девелоперов от того, чтобы заполонить мир своими высококачестенными быстрыми серверными приложениями — незнание языка на котором можно написать какой-нить сервер.
Не, действительно, что ещё нужно? Ведь серверное ПО это просто такая особенная вебстраничка или вебаппликуха, да? Надо просто было как-то запустить вебаппликуху без браузера…
Я думаю, если научить вдруг видеокарты понимать javascript, то существующих игроделов ждет несколько неприятных лет в страхе от новых конкурентов. А если встроить V8 в ардуино, то роботы просто захватят мир.
Вебдевелоперы, это такие особенные программисты, которые сходу смогут всё, только узкоспециализированность javascript сдерживает их от захвата всех остальных сфер разработки.
Повторное использование кода. То-то все вдруг стали вынуждены писать просто тонны новых библиотек для ноды. А аналоги большинства из них есть почти в любом языке, не настолько заточенном на вебдеве, как javascript.
Начнём с языка. Из ваших слов, выходит, что единственное, что сдерживало тысячи веб-девелоперов от того, чтобы заполонить мир своими высококачестенными быстрыми серверными приложениями — незнание языка на котором можно написать какой-нить сервер.
Не, действительно, что ещё нужно? Ведь серверное ПО это просто такая особенная вебстраничка или вебаппликуха, да? Надо просто было как-то запустить вебаппликуху без браузера…
Я думаю, если научить вдруг видеокарты понимать javascript, то существующих игроделов ждет несколько неприятных лет в страхе от новых конкурентов. А если встроить V8 в ардуино, то роботы просто захватят мир.
Вебдевелоперы, это такие особенные программисты, которые сходу смогут всё, только узкоспециализированность javascript сдерживает их от захвата всех остальных сфер разработки.
Повторное использование кода. То-то все вдруг стали вынуждены писать просто тонны новых библиотек для ноды. А аналоги большинства из них есть почти в любом языке, не настолько заточенном на вебдеве, как javascript.
Если критикую, значит надо предложить. А чего же он так популярен?
Все дело в V8 — в движке который годами затачивался на скорость. Этот показатель критичен в войне браузеров.
И второе, там смогли более-менее удобно сделать скелет для reactor-based серверных приложений.
Есть много способов написать многозадачное приложение, и reactor — это самый низкоуровневый из них. Выключается целая прослойка, которая тянет ресурсы — scheduler, что ещё больше увеличивает скорость приложения. (это как выбрать компилируемый язык, чтобы избавиться от интерпретатора)
В замен надо самому указывать места, где можно затормозить задачу и отдать ресурсы другой. Больше усилий, меньше читабельность кода за счёт колбеков.
Итого: выбирая node вы получаете высокоуровневый интерпретируемый язык, который имеет бонус в скорости за счёт V8, бонус скорости за счёт отсутствия шедулера. Но чем больше приложение тем сложнее его написать. Идеальное решения для маленьких но жутко шустрых серверных штук.
И большинство этих сакцес стори для ноды, которые гуляют везде, писали не вебдевелоперы, что вы. Писать на калбеках код 24x7x365 это не просто страничку со временем жизни 5-20 минут. Писали люди знающие с какой стороны подойти к concurrency и реактору.
Все дело в V8 — в движке который годами затачивался на скорость. Этот показатель критичен в войне браузеров.
И второе, там смогли более-менее удобно сделать скелет для reactor-based серверных приложений.
Есть много способов написать многозадачное приложение, и reactor — это самый низкоуровневый из них. Выключается целая прослойка, которая тянет ресурсы — scheduler, что ещё больше увеличивает скорость приложения. (это как выбрать компилируемый язык, чтобы избавиться от интерпретатора)
В замен надо самому указывать места, где можно затормозить задачу и отдать ресурсы другой. Больше усилий, меньше читабельность кода за счёт колбеков.
Итого: выбирая node вы получаете высокоуровневый интерпретируемый язык, который имеет бонус в скорости за счёт V8, бонус скорости за счёт отсутствия шедулера. Но чем больше приложение тем сложнее его написать. Идеальное решения для маленьких но жутко шустрых серверных штук.
И большинство этих сакцес стори для ноды, которые гуляют везде, писали не вебдевелоперы, что вы. Писать на калбеках код 24x7x365 это не просто страничку со временем жизни 5-20 минут. Писали люди знающие с какой стороны подойти к concurrency и реактору.
Буду отвечать на Ваши вопросы последовательно, начиная с последнего — как если бы они располагались в своего рода стэке.
Критика JavaScript, на которую Вы сослались, критикует единственный элемент его: возможность прозевать «var» приводит не к ошибке интерпретатора, а к тому, что глобальная переменная окажется определена вместо локальной и нарушит логику работы всего алгоритма.
Да, эта критика справедлива.
Однако не могу не заметить, что и в чрезвычайно многихCи-подобных языках программирование вообще требует кропотливой внимательности: в операторах наподобие «==», «+=», «-=», «*=», «/=», «%=», «>>=», «&=», «^=», «|=» достаточно пропустить единственный символ равенства — и оператор станет другим, но всё равно сработает, и даже даст результат, автоматически приводимый к логическому «true» или «false» (если он стоит внутри «if»), так что приведёт не к ошибке интерпретатора, а к тому, что нарушится логика работы всего алгоритма.
Критика JavaScript, на которую Вы сослались, критикует единственный элемент его: возможность прозевать «var» приводит не к ошибке интерпретатора, а к тому, что глобальная переменная окажется определена вместо локальной и нарушит логику работы всего алгоритма.
Да, эта критика справедлива.
Однако не могу не заметить, что и в чрезвычайно многих
То есть не просто ключевое слово из трёх символов с последующим пробелом, но и буквально один символ пропустить нельзя без того, чтобы алгоритм не облажался.
Тем не менее, ничего, программируюткак-то, долгие годы программируют — целые операционные системы пишут на Си, например. Не переходя на Паскаль да Дельфи, в котором «:=».
Тем не менее, ничего, программируют
Присоединяясь к вышесказанному так же отмечу, что проблема var может лечиться линтом кода, а то и вовсе исчезнуть при использовании разного рода препроцессоров javascript
Некоторые люди считают, что код, написанный под ноду, очень избыточный и запутанный.Вы приводите гиперссылку на мнение человека, который не только не считает код, написанный под ноду, избыточным и запутанным, но и полагает его куда более понятным и пригодным для написания работоспособных относительно сложных проектов, нежели, например, язык Erlang:
I see a lot of crap online about how Erlang kicks node.js' ass in just about every conceivable category. So I'd like to learn Erlang, and give it a shot, but here's the problem. I'm finding that I have a much harder time picking up Erlang than I did picking up node.js. With node.js, I could pick a relatively complex project, and in a day I had something working. With Erlang, I'm running into barriers, and not going nearly as quickly.Иными словами, Вы сами же и привели гиперссылку на контраргумент к своему тезису, так что мне нечего и делать тут.
So… for those with more experience, is Erlang complicated to learn, or am I just missing something? Node.js might not be perfect, but I seem to be able to get things done with it.
Вы не верно поняли, это было не мнение а вопрос. Вопрос того человека, который в чём-то сомневается, а в низу в качестве ответов на этот вопрос идут развернутые комментарии, почему код на ноде превращается в лапшу. И если уж на то пошло, обратите внимание на зеленую галочку на против одного из ответов, это означает что автор вопроса счел этот комментарий верным и исчерпывающим. Так что ни каким контраргументом к моему исходному вопросу данная ссылка не является.
Пожалуйста, перескажите своими словами тот комментарий о том, почему код на Node превращается в лапшу, отклик на который Вы желали бы от меня увидеть.
Тот ответ, который помечен зелёной галочкою, куда обширнее говорит о достоинствах Эрланга при обращении с мьютексами, нежели о чём бы то ни было нодовом. Особенной критики Node в том ответе я не усмотрел, честно говоря — автор ответа скорее просто говорит о том, что у каждого языка, как у инструмента, есть своя собственная ниша, в которой он наиболее пригоден.
Тот ответ, который помечен зелёной галочкою, куда обширнее говорит о достоинствах Эрланга при обращении с мьютексами, нежели о чём бы то ни было нодовом. Особенной критики Node в том ответе я не усмотрел, честно говоря — автор ответа скорее просто говорит о том, что у каждого языка, как у инструмента, есть своя собственная ниша, в которой он наиболее пригоден.
Касательно запутанности js-кода из-за обилия callback-ов. Я использую node-sync, и проблем с callback-ами не имею в виду практически полного их отсутствия. Использую такой расклад:
1. в функции обрабатывающей пользовательский запрос использую sync( function(){… } ).
2. все «не свои» функции с callback-ми использую как func.sync( func,… )
3. в виду пунка 2 — свои функции не нуждаются в callback-ах
Итого имею привычный всем php-программистам код без большой вложенности. sync-ми код тоже не захламляется, т.к. используется в сравнительно небольшом количестве мест. Пример запроса к mongodb:
Я не знаю сильно ли я расплачиваюсь производительностью за такие «фокусы», но в виду того, что пишу простой «уютный бложик», развёрнутый на VPS, для меня это совсем не критично. Впрочем если судить по времени генерации обычной блог-страницы (5-80мс) — шустро бегает.
Чем хорош такой подход? Тем что позволяет сильно упростить код и повысить его читаемость (~до уровня обычного php-кода). Проблемы с блокированием одного волокна во время простоя другого не стоит, в виду их реализации в node-fibers. Т.е. пока 1 волокно, скажем запрос 1го пользователя, ждёт ответа от mongodb, запрос другого пользователя выполняется. При первой же возможности (и разумеется получении ответа от mongo) первое волокно «размораживается» и продолжает свой жизненный путь, как ни в чём не бывало. Т.е. концепция асинхронной работы (и все её преимущества, разумеется) сохраняется.
Из проблем, на которые я уже наткнулся — сложно дебажить код. + как то не очень стабильно работает. Запускать его без forever на живом проекте — самоубийство. Надеюсь эти проблемы — дело времени.
1. в функции обрабатывающей пользовательский запрос использую sync( function(){… } ).
2. все «не свои» функции с callback-ми использую как func.sync( func,… )
3. в виду пунка 2 — свои функции не нуждаются в callback-ах
Итого имею привычный всем php-программистам код без большой вложенности. sync-ми код тоже не захламляется, т.к. используется в сравнительно небольшом количестве мест. Пример запроса к mongodb:
user.find( { parent: parent_id }, { skip: 10, limit: 10, sort: { create: -1 } );Я не знаю сильно ли я расплачиваюсь производительностью за такие «фокусы», но в виду того, что пишу простой «уютный бложик», развёрнутый на VPS, для меня это совсем не критично. Впрочем если судить по времени генерации обычной блог-страницы (5-80мс) — шустро бегает.
Чем хорош такой подход? Тем что позволяет сильно упростить код и повысить его читаемость (~до уровня обычного php-кода). Проблемы с блокированием одного волокна во время простоя другого не стоит, в виду их реализации в node-fibers. Т.е. пока 1 волокно, скажем запрос 1го пользователя, ждёт ответа от mongodb, запрос другого пользователя выполняется. При первой же возможности (и разумеется получении ответа от mongo) первое волокно «размораживается» и продолжает свой жизненный путь, как ни в чём не бывало. Т.е. концепция асинхронной работы (и все её преимущества, разумеется) сохраняется.
Из проблем, на которые я уже наткнулся — сложно дебажить код. + как то не очень стабильно работает. Запускать его без forever на живом проекте — самоубийство. Надеюсь эти проблемы — дело времени.
Оформление мануала на nodejs.org гораздо круче и читабельнее в 1000 раз. Как можно так лажать с доками? Конечно, может быть, приведенная там информация будет на столько актуальна, что про этот косяк можно будет забыть, но когда люди забывают о информации и занимаются украшательством… Не знаю…
Sign up to leave a comment.
Авторы Cloud9 IDE представили сборник документации по Node.js