разработчик
0,0
рейтинг
22 апреля 2011 в 15:47

Разработка → Node.js и эра JavaScript перевод

Три месяца назад мы решили отказаться от использования Django на нашем сайте и переписать все с нуля на серверном JavaScript под Node.js (уж если бывает в жизни стартапа время, когда можно серьёзно менять инфраструктуру, так это в самом начале пути — когда есть наибольшая свобода маневра).

Что заставило нас принять такое решение? Одна простая мысль — стек LAMP мёртв. За два десятилетия, прошедшие со времени его рождения, произошли фундаментальные изменения в протоколах, контенте, серверах и клиентах, на которых построен Веб. Можно выделить три эры развития паутины:

1. 1991 — 1999: Эра HTML.

В основании эры HTML лежали документы, в полном соответствии с изначальным представлением Тима Бернерса-Ли о «виртуальной вселенной взаимосвязанных документов». Веб наполнялся статическими, созданными вручную файлами, топорный вид которых в тогдашних браузерах оскорблял вкус даже самого непритязательного дизайнера. Статичные документы отображались в статичных клиентах.

2. 2000 — 2009: Эра LAMP.

В основании эры LAMP лежали базы данных. Место документов занял стек веб-приложений. CGI, PHP, Ruby on Rails, Django заполняли HTML-шаблоны данными из БД. Теперь страницы динамически формировались на сервере, но в браузер приходили по-прежнему в статическом виде.

3. 2010 — ??: Эра JavaScript.

В основании эры JavaScript лежат потоки событий. Современные веб-страницы — это уже и не страницы вовсе, а управляемые событиями приложения для обмена информацией. Основа отображения контента в вебе — объектная модель документа — всё еще существует, но это уже не столько форма представления разметки HTML, сколько структура данных в памяти, генерируемая программой на JavaScript.

Архитектура LAMP мертва потому что мало кому сейчас хочется отправлять тонны HTML-разметки в ответ на каждое движение пользователя. Вместо этого лучше обновлять небольшие фрагменты DOM с помощью AJAX. Но когда объем кода JavaScript в наших серверных шаблонах переваливает за 90%, становится ясно — мы делаем всё неправильно.

Если мы признаем это, то увидим, что главная функция сервера теперь не хранение документов (эра HTML) или рендеринг шаблонов (эра LAMP), а доставка данных и функций для их обработки. Сервер должен отдать клиенту код приложения, а затем данные, которые приложение вставит в DOM.

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

Архитектура Node.js идеально подходит для этих функций. Так как JavaScript используется и клиентом и сервером, становится возможным перенести часть вычислений в браузер, без особых проблем с рассогласованием интерфейсов и без необходимости дважды писать код, делающий одно и то же, на разных языках (например, валидация форм).

Node.js отлично подходит и для работы с потоками событий. Благодаря асинхронной, неблокирующей архитектуре, он невероятно быстр. Он использует HTTP 1.1 и может держать тысячи открытых соединений одновременно.

Наконец, стоит упомянуть, что события — это не что иное, как пакеты данных, а JSON постепенно становится lingua franca для данных в сегодняшней паутине. Именно JSON наиболее удобен для приложений JavaScript на стороне клиента. И для Node.js это — родной формат.

Эра JavaScript превратит Веб из глобальной цифровой библиотеки в глобальную цифровую нервную систему, возможности которой мы только начинаем осознавать.

Об авторе:
профиль на LinkedIn,
персональный сайт.
Перевод: Michael E. Driscoll
Илья Сименко @ilya42
карма
526,7
рейтинг 0,0
разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (210)

  • +2
    А вы н
    • +20
      Случайно нажал:
      Правильно назвать не эрой JavaScript а эрой событийно-ориентированого программирования
      • –9
        Может быть. Но окно в эту эру сейчас пробивает прежде всего JavaScript, как самый распространенный язык, на котором принято программировать событийно, так что автор имел веские основания.
        • +1
          Это вы сильно загнули. Событийно программировали задолго до javascript.
          А если вы про веб, то SOA 2.0 изобретен уже достаточно давно и реализаций было достаточно.
        • –3
          Я тоже соглашусь с тем, что наступает эпоха Javascript.
          Кроме php/perl/ruby/wtf на веб-серверах, javascript-приложения вытеснят часть десктопного софта, отобрав хлеб у Java и .NET.
          На десктопах останутся только (клиенты ?) тяжелых штук типа 3D графики/игр и обработки видео, скорее всего написанные на С++, для которых стек http+html+javascript будет слишком медленным.
          • +4
            А что, много десктопного софта на Java и .NET? Сходу в голову приходят только IDE на Java для Java же (поддержка других языков — опции). Правда не знаю, может под виндой его действительно много…
            • +2
              Много корпоративного софта под заказ.
              • 0
                Очень много. И js там пока делать нечего.
                А вот на .net пишут обычные десктопные утилитки… только они действительно мало кому нужны — всё переходит в онлайн.
                • +1
                  По-моему, вы себе противоречите :) то у вас js делать нечего, а то вдруг всё уходит в онлайн. Где же место js, как не в онлайне?
                  Корпоративный софт уходит в онлайн, и вся клиентская часть пишется на js.
            • +3
              Ну, десктопного софта на С# и Java просто-таки до… я.
              Пользуясь случаем, передаю пламенный превед программистам на этих языках:)
              • 0
                Мне как-то всё встречается или на плюсах, или на питоне :)
      • 0
        Нет, client-driving services.
    • +32
      Вторая половина комментария прибудет асинхронно.
  • +74
    node.js, конечно, хорошая штука, но LAMP не мёртв
    • +4
      В данном случае, «мёртв» — понятие растяжимое :) Конечно, в ближайшие лет 5-10 веб-разработчики на PHP, Python или Ruby без работы не останутся. Но «передний край» веб-программирования сейчас определенно переместился в сторону таких вещей, как Node.js, CouchDB, Javascript, Erlang. Это всё еще очень незрелые вещи в области веб, но шансы на то, что это станет новым мэйнстримом, весьма высоки.
      • +38
        Проблема в том, что «передний край» — это эмоциональная оценка. В реальности все проще: есть задачи (поддержка длинных соединений, push-уведомлений, поддержка большого числа пользователей), которые проще решаются на асинхронных фреймворках.

        Раньше решения для этих задач были экзотикой, теперь для них появились более-менее удобные средства, отсюда все эти волнения и энтузиазм. Но ниоткуда не следует, что это все так уж важно. Ну можно будет в будущем (да и в настоящем уже) к сайту прикрутить realtime-поток сообщений из твиттера, счетчик посетителей и чатик, где тут сдвиг парадигмы? Для некоторых это, безусловно, актуально (как, например, для ребят, статью написавших — они панель с аналитикой делают, штука очень ведь специфичная).

        Загвоздка в том, что остальные-то задачи проще решаются на синхронных фреймворках. Т.к. синхронный код — проще и понятнее (= дешевле в написании и поддержке). Все эти realtime-штуки имеют свою нишу, это новая ниша и она расширяется, но ниша обычной веб-разработки от этого меньше-то не становится. Противопоставление тут, как мне кажется, неоправданное.
        • –3
          Я не вижу тут противопоставления. Передний край — то, что сейчас бурно растет и развивается. LAMP устоялся. Это зрелая вещь, и в том, что он не на переднем крае — ничего плохого. То есть это не значит, что устоявшиеся технологии вдруг станут никому не нужны, но вполне может быть, что рядом с ними (а не вместо них) вырастет нечто новое и не менее значительное.
          • +11
            Противопоставление и эмоциональность — скорее в статье, про все эти эпохи и мертвичину) Это же глупость — объяснять технические решения какими-то невнятными провидческими опусами.
          • +16
            Ну и скажите мне, какая принципиальная разница между этими клиент-серверами:

            — клиент: HTML+Js. Сервер: LAMP
            — клиент: HTML+Js. Сервер: Erlang
            — клиент: HTML+Js. Сервер: Node.js

            :-\
            • +3
              Чисто формально последний вариант позволяет обходиться одним ЯП. Хотя я бы предпочёл поддержку P (и R) в браузерах :)
              • 0
                Мне кажется, тогда сложнее было бы отделить логику от представления.
                • 0
                  Чем сложнее?
                  • 0
                    Тем, что начали бы смешивать серверную и клиентскую логику, использовать сложные языковые конструкции в представлении. Не даром в RoR и Django используются шаблонны не совпадающие полностью с основным языком.
                    Безусловно, это проблемы не языка\системы\технологии, а программиста.
                    • +1
                      Хотите сказать, что сейчас не используют сложные языковые конструкции JS? Тем более, что HTML+JS представление в терминах сервер-сайда является целым приложением в терминах клиентсайда, в котором по хорошему тоже надо отделять логику от представления. А в особо изощренных случаях чуть ли не полностью дублировать код PHP, Python или Ruby на JS.
                      • 0
                        Как относиться в данном случае к JS, если честно, я не знаю. Но смешивание северного и клиентского кода приводит к хаосу. Писать просто, но разобраться в этом через месяц очень трудно. Дублирование кода — отдельная головная боль. Но всего скорее есть какое-то простое и красивое решение.

                        Про поддержку языков в браузерах — можно написать самому (по-моему только для IE ничего не получится) и разослать разработчикам. Только, боюсь, оно не будет пользоваться популярностью. Знаю, были случаи когда люди писали браузерные интерпретаторы lisp.
                        • +2
                          Ну в обычных (не веб) сетевых приложениях часто десктопный клиент и серверная часть написаны на одном языке в рамках одного проекта и даже используют общий код. Хаоса как-то не возникает. Чисто субъективно кажется, что больше хаоса когда приложение написано на 6 языках (PHP/Python/Ruby/Perl/..., SQL, HTML, CSS, JS, язык шаблонизатора) :)

                          Даже видел и чуть-чуть ковырял такие попытки в интранет сети, но потом от них отказались — самостоятельно поддерживать сложно.
                          • 0
                            > даже используют общий код.
                            Из того что я видел (и к сожалению, в этом участвовал) — было плохо. С одной стороны, это, конечно, удобно, с другой плодит ненужные зависимости. На самом деле, если архитектура спроектирована нормально, то все равно какие средства используются.

                            > когда приложение написано на 6 языках
                            За это надо руки отрывать. Но, как вы отмечали выше, сторона клиента и сторона сервера — суть разные приложения.
              • 0
                Ну вот, в принципе, и все :-)

                Берем в руки GWT и получаем тот же профит. Вернее, намного бОльший, по понятным причинам.

                То есть, автор перевода и сам автор изначального сообщения маленько не понимает, что разницы, в принципе, вообще никакой :)
      • +26
        Да чепуха всё это про «передний край». Так обычно называют модные и прикольные по мнению разработчиков технологии. И пиарят их больше всех люди, которые на практике не использовали их никогда на реальных проектах, но хотели бы. Node.js и Javascript в этом отношении очень показательны, тут нет ничего нового, джаваскрипт как серверный язык не имеет никаких преимуществ над руби и питоном, фреймворки для асинхронных серверов существовали и до него. Просто новая модная штука. То же самое с эрлангом. В своей нише он очень хорош, для производительного инфраструктурного сервера отличный выбор, но хорошо ли подходит чисто функциональный язык для типичного сайта или веб сервиса со сложной бизнес логикой…
      • +2
        никто на Erlang делать веб проекты не будет, ну кроме restful, и то проще написать на eventmachine
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            пардон, оказывается я не разрабатывал сайты на webmachine и mochiweb и не могу судить, где erlang взлетает, а где он недостаточно удобен.
          • +1
            да, я считаю, что лучше писать на erlang'е, чем на javascript + nodejs. просто front end надо писать используя ту платформу, где создания front end'ов является одним из главных фич — это sinatra или ror.

            я это заявляю на личном опыте — спагетти из бумеранга кода (даже используя step) на nodejs против просто чудовищно лаконичного кода на erlang'е использую webmachine для restful сервиса — это стоило того.
        • 0
          Миллион COMET подключений на один сервер. Last.fm. Nuff said.

          www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1
    • +4
      — По мне хоть всю жизнь живи, раз хороший человек.
      © Дворник Тихон
    • 0
      Я тоже думаю что вокруг Node много шума а для большинства web приложений от асинхронности столько же пользы сколько от реактивного двигателя для трактора. Но использовать один и тот же язык внутри браузера и на сервере разумно. Поэтому я продвигаю Akshell — попробуйте и убедитесь сами что server side JavaScript это круто.
  • +9
    Вот только не надо путать разработку веб сайтов с разработкой веб-приложений. В первом случае доминанта на потреблении информации пользователем. Во втором на производстве. LAMP очень даже хорош для своих задач и будет оставаться таким ещё долго.
  • +8
    Вот еще бы в начале статьи пояснили, почему платформа Джанго не отвечала возросшим требованиям — что это был за сайт? Кто на него ходил и что там делал?
    Это мое личное мнение, но отдавать клиенту DOM кусочками можно независимо от выбранной серверной платформы. Тут вопрос в общей архитектуре веб-приложения, а написать неподъемный многослойный тормозной пирог на Node.js можно даже проще, чем на Django…
    • 0
      У них сайт предоставляет сервис рыночной аналитики в реальном времени, насколько я понял, так что поток событий там должен быть неслабый.
  • +2
    Ещё нужно добавить, что GWT и им подобные системы, в которых JS генерируется с сервера, который вызывает другие части страниц, генерирующие дополнительный JS — апофеоз ламповой эры, рухнувший под своей тяжестью. Писать такое ещё с трудом можно, а изменять — ….
    • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • +10
      А в чем сложность изменять?

      Разрабатывая с использованием GWT вы пишете в основном на Java (JS-вставки можно рассматривать как ASM-вставки в С/С++ код, на практике очень редко встречается необходимость).

      Дебаг тоже идет только по java-исходникам. Компиляция в реальный JS происходит во время деплоя на продакшен, и при разработке очень редко имеет смысл о нем задумываться.

      За это вы получаете строгую типизацию, оптимизацию под конкретные броузера/языки (например если я захожу Firefox4 и хочу на русском языке, зачем мне какие либо куски кода для других броузеров и языков), спрайтинг для иконок, UI-Binding, единый язык для сервера и клиента (общий код валидации данных и т.д.).

      И самая «вкусная» штука — это code splitting когда на клиент загружается только че части приложения, которые нужны ему сейчас. И за зависимостями следит сам GWT.

      Конечно хоум-пейджи клипать не стоит, но плюсы для rich web applications просто огромные. И сравнимы с плюсами от использования Silverlight/Flex.

      Я не говорю что GWT — супер-мега вещь, которую стоит везде юзать, но не вижу причин не считать довольно интересной и сильной платформой.
  • +5
    Вы вот это все поисковикам расскажите для начала
    • +3
      Да, но с другой стороны, «не человек для поисковика, но поисковик для человека». Может им тоже пора парадигму менять?
    • +1
      А это, по идее, nodeJS должен рассказывать тем же языком, на котором идёт основная работа клиента. Как только начинаем задумываться о поисковиках и примитивных бр-рах (которых много в мобильных) — требуется дублирование логики клиентского приложения на сервере.
    • НЛО прилетело и опубликовало эту надпись здесь
      • –1
        Ну так совсем по другой причине :)
        • 0
          По какой?
          • +1
            anatolix.livejournal.com/52547.html

            Хотят сделать живую выдачу как у гугла и таскать части приложения между клиентом и сервером туда-сюда.

            Но первый комментарий пожалуй был о том, что Full-AJAX приложения не индексируются.
    • +1
      А в чем проблема? Тот же Твиттер отлично индексируется поисковиками.
  • +10
    Интересно, что думают те, кто работал с Node.js об этом?
    • –2
      Там эмоций больше, чем мыслей. Если спокойно резюмировать — весь смысл вопля сводится к одному предложению — «Node.js ещё очень сырой». Ну да, никто ведь и не спорит. Абсолютно все технологии когда-то были сырыми, глючными и медленными. Вопрос лишь в том, есть ли в принципе перспектива? Автор статьи считает, что есть. Я тоже, потому и перевёл.
    • 0
      Это тонкий стёб, кмк ;)
    • +8
      Написано эмоционально, но справедливо. Node.js ещё очень сырой, версии не всегда обратно совместимы, да и асинхронный код писать на JS хоть немного удобнее, чем на других мейнстрим языках, но, например, в Erlang писать такой код на порядок удобнее, безопаснее, а результат эффективнее. Лично я рассматриваю Node.js как неплохую альтернативу прочим языкам. Не думаю, что это «новая» эра, или убийца PHP/Python/Ruby/<ваш любимый язык>. Движок V8 действительно быстр, язык прост, сборщик мусора хорош, а прототипо-ориентированное программирование имеет свою определенную прелесть.
      • +6
        Как вы ловко Perl замаскировали ;-)
  • +6
    складывается впечатление, что автор просто перешёл с менее подходящего лично для него языка программирования/технологии на что-то, что ему больше нравится, и под впечатлением фанатично расписывает все прелести данной технологии.
    на самом деле не буду говорить конкретно про Django, но:
    1) в PHP и даже Ruby on Rails хватает средств чтобы писать асинхронные событийные приложения.
    2) для нагруженных сервисов действительно асинхронно-событийная архитектура является на данный момент преобладающей, однако не стоит забывать, что в интернетах до сих пор значительная часть корпоративных, рекламных, справочных и т.п. сайтов, которым она просто-напросто не нужна.
    3) не забывайте, что LAMP = Linux + Apache + Mysql + PHP. если не говорить конкретно о наборе программного обеспечения, то LAMP наоборот сейчас является преобладающим. даже облака для хостинга сервисов сейчас используются либо как один из элементов инфраструктуры, либо только среди сервисов средней весовой категории, ибо аренда сервера пока ещё дешевле и гибче для мелких сервисов, а крупные могут себе позволить датацентры, всё с теми же LAMP.
  • +35
    Господи, успокойтесь. node.js лишь модный фреймворк. Не технология, не язык, а просто фреймворк. Кроме того не единственный. Он на очень ранней стадии, есть проблемы у самого V8 и node.js соответственно их перенимает. Он безбожно течет, стоит только написать что-то большее чем обычный чат. Есть технологии более совершеннее и мощнее того же node.js vs V8. Есть Erlang, есть Java NIO & Deft, который быстрее node.js и V8. Да технологии меняются, да была проблема C10k, сейчас можно сказать C100k. Но node.js тут вообще не выход. Я не хочу никого обидеть, но весь этот стек недостаточно стабилен. Мы тестируем его, нам интересно его использовать, так как FrontEnd разработчики его знают, но писать стабильный продукт на нем сейчас просто невозможно.
    • +1
      Да, всё пока очень сыро. Но если стоит вопрос не о том, чтобы сделать стабильный сайт быстро и без проблем, а о том, на какую технологию стоит ставить в перспективе, то тут уже можно крепко задуматься. Когда-то и LAMP был сырым и глючным, по сравнению со старым добрым статическим HTML.
      • +11
        Я согласен, поэтому мы ставим на Erlang и Java NIO.
    • +2
      Висит несколько сайтов, в основном магазины, на нодовском expressjs. Аптайм — полгода, не протекло ни капли, летает все отлично. Технология молодая, но уже не сырая. Модули добавляются и правятся постоянно, на гитхабе многие топовые пользователи — именно нодовские контрибьюторы.
      • +2
        Мне сложно с Вами спорить. Мы создаем системы, которые обязаны быть стабильными. Когда технология уже проверенна. При использовании MongoDB, MySQL, Memcached при количестве активных подключений в десятки тысяч, все не то что течет, а тупо падает. Я вообще не понимаю смысла писать магазин на асихронно-событийном фреймворке. У Вас там посещаемость в 100к пользователей в единицу времени? И ничего не течет? Не верю :)
        • –2
          Использовать node.js имеет смысл для укрощения кода. Например, модель может хранить своё состояние в себе, а не быть очередной прослойкой для базы данных, перезагружая себя с каждым клиентом.
        • +2
          Что тут понимать, вы сами ответили на свой вопрос в первом комменте — я как раз frontend разработчик, так что nodejs + mongodb это мое все :) По поводу стабильности — plurk давно уже запустил свои realtime чаты на ноде, потом трезвонили на весь свет как все быстро летает, по тыщам блогов разошлось. В итоге вроде бы через год поменяли технологию, не подошла она чем-то. Хоть это и дела давно минувших, но даже сейчас не посоветовал бы запускать что-то нагруженное в продакшн на ноде. Но для быстрых проектов для разработчиков с фронтенд бекграундом — nodejs + expressjs + mongodb очень советую.
        • +2
          ну мы вот пишем специализированные финансовые сервисы — там ситуация простоя в секунду или задержка в 500 мс уже трагедия — и работает месяцами, не течет и не требует особо специфичных навыков разработчика
        • 0
          А мочему бы и нет? Ну не на ноде, на Ruby/jRuby + EventMachine, ну или Erlang OTP, Java NIO, почему вы считаете, что использовать эти инструменты можно только при хайлоаде?
          • 0
            Я считаю, что каждый инструмент нужно использовать отталкиваясь от задачи. Таким образом для создания корпоративного портала мы не будем использовать стек Java или Erlang, а воспользуемся RoR или PHP.
            • 0
              А почему бы и нет? Я вот делаю себя RESTful API на sinatra (хочу переписать на Erlang), фронтэнд на Cappuccino.
              • +2
                Потому что себестоимость разработки на PHP ниже чем на Erlang.
                • +2
                  А чистая трудоёмкость?
    • 0
      для небольших быстрых сервисов очень удобен. а на нестабильность — есть bluepill/monit/god.

      Хотя последний ужасный случай падения продакшена при пиковых нагрузках у нас произошел на Erlang (кролег). beam.smp сожрал всю память в самый неудобный момент.

      До этого такого не приключалось, не сразу разобрались. Ну кто могу подумать, когда в обычном режиме кролик кушает 0.3% CPU и 3% памяти в пике.
      • +2
        Акжан. Я уже 20 раз объяснял Алексею, откуда берется конкретно эта проблема с RabbitMQ. Алексей мои слова игнорировал и не хотел вносить те патчи, о которых я говорил.

        В итоге, что ты, что бустед ходите по интернету и трезвоните про «erlang падает», вместо того, что бы пофиксить простую ошибку.
        • 0
          скинь ссылочку на патчи, поправлю пакет.
    • +2
      Господи, успокойтесь. node.js лишь модный фреймворк. Не технология, не язык, а просто фреймворк.
      Это именно технология, использующая JavaScript v8 + libioe + libev.

      Он на очень ранней стадии, есть проблемы у самого V8 и node.js соответственно их перенимает.
      Предельно голословно. Не сомневаюсь, что в v8 есть определенные проблемы, но разве их нет в других интерпретаторах скриптовых языков? Даже в gcc вон нашли «баг года».
      Ранняя стадия определяет только распространенность технологии, а менее распостраненные языки пугают разработчиков. Node.js базируется на JavaScript, который знает в той или иной степени каждый web-разработчик. Чего тут бояться?
      Да и не V8 одним едины. Сейчас есть 2 приемлемых для Node.js движка: V8 и SpiderMonkey на последний скоро портируют.

      Он безбожно течет, стоит только написать что-то большее чем обычный чат.
      Опять слова, я думаю вы прочитали отзыв Вконтакта о Node.js и фраза «а также течет память» перевернула ваше представление о Node.js. Там нет конкретных причин течи, кто знает мб все дело в руках. Например SAX XML парсер + модуль xml2json безбожно «течет» на 250 rps, как следствие частый gc (50-60 Мб каждые 5-10 секунд, фриз 1 сек), который приводит к лагам(1кб каждая XMLка). Тут проблема не в Node.js и даже не в SAX XML, а в xml2json. Исправив проблему с xml2json убрали течь итог: 1000 rps, gc раз в несколько минут (1мб), фриз пару тысячных.
      Я вас уверяю, что все, что вы пишете может течь, даже С++ при «умелом» обращении.

      Есть технологии более совершеннее и мощнее того же node.js vs V8. Есть Erlang, есть Java NIO & Deft, который быстрее node.js и V8.
      На вкус и цвет. Не стоит бросаться словами насчет скорости работы и разработки.

      Если вам не нравится JavaScript, то вам придется его полюбить потому, что он единственный скриптовый язык на клиенте (VB не в счет), он уже проник на сервер, он проник в БД — MapReduce в MongoDB и CouchDB, хотя последний имеет несколько языков запросов, но один из популярных все-таки JavaScript.

      Пожалуйста, разбавьте свои слова хоть какими-то фактами.
      • +6
        Мы не читаем, мы тестируем. При наших задачах node.js падал и тек. Проблемы были с модулем Mongo и Memcached. Перед тем как сказать что нам не нравится технология, или мы от нее отказываемся, мы проводим множество тестов которые решают поставленную задачу. В результате чего мы определяем наиболее оптимальную технологию.

        Кроме того нам не нравится как работает GC в V8. Мы не можем себе позволить что бы приложение не отвечало во время обработки GC.

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

        Резюмируя — мы не ориентируемся на отзывы кого-то о чем-то, мы проводим тесты, неделям, с миллиардами итераций, при таких нагрузках мы выбираем наиболее оптимальные решения.
  • +2
    You can use AJAX without JS on server.

    The possibility not to write code twice for the validation of form data is that what would make me wish to switch from PHP/Perl or Python to Js? They should take a look at PHP and Python codebases and then do the same with Js.

    Js is a good language but it's not time yet to use it as server-side one.
  • +4
    Автор переписал приложение с Django на Node.js потому что LAMP мертв? В огороде бузина а в Киеве дядька. Типа на LAMP не работает ajax. Данные прекрасно доставляются на клиент в любом современном фреймворке, REST архитектура раздаст все красиво в любом формате хоть в Django, хоть в ROR, хоть в нодовском Expressjs. В Node.js такие же возможности доставки данных как в PHP.
  • +3
    Не согласен. Нет, хорошо, что node,js построен на событиях, но писать в таком стиле:

    getSomeData(function() {
        getMoreData(function() {
            getEvenMoreData(function() {
                // ...
            });
        });
    })
    


    жутко неудобно. Идеальным мне кажется решением Python + gevent. Вы продолжаете писать в синхронном стиле, а все возможные сокеты и подобное делается в асинхронном стиле за вас.
    • –2
      Пачка статей на хабре пролетала как работать красиво с вложенными коллбеками. Есть туча модулей с разными подходами на любой вкус. Это уже теперь не проблема, у nodejs есть другие проблемы, похуже. Например падение всего nodejs сервера при неотловленном исключении в любом коллбеке.
      • +7
        Дайте угадаю, чиниться одной строчкой кода?
        • –1
          Я рад был бы узнать такую волшебную строчку.
          • +8
            process.on('uncaughtException', function (err) {
                    // Add here storage for saving and resuming
                    sys.puts("FATAL - " + err.message);
                    sys.puts(err.stack);
            });
            
        • +3
          Очнитесь, кто читает доки? :)
      • +1
        Для не отловленных исключений есть uncaughtException. Или вы о чем-то другом?

        Мне поблема видится в другом. Вот произошло исключение неизвестно где. Мы даже его отловили в этом uncaughtException. А дальше что? Генерация страницы прервется, а ответ об ошибке отдать будет некому. Пользователь отвалится только по таймауту.
        • 0
          ловите тогда эксешпен в цикле обработки, а вообще в асинхронной системе ноды в 99% случаях вам надо будет самому (про)кинуть эксешен пришедший вам в колбек чтобы он стал эксешеном.
        • 0
          Исключения в Node.JS — плохой тон. Всегда смотрите err у коллбэка.
  • +26
    Что там у нас еще мертво? Радио, газеты, журналы, театр, игры под PC, бумажные книги, обычные сигареты, оффлайн магазины. Вроде всё упомянул?
    • 0
      >с тем, что игры на PS3 мертвы, соглашусь
      fix
      • 0
        PS и PC — разные вещи.
        • 0
          Это человек никогда не играл в Uncharted или Little Big Planet или Rain…
          • 0
            А что там такого в замыленных из-за недостатка производительности картинках? Геймплей на уровне «Press X to Jason»?
            • 0
              Вы не сможете понять, пока не попробуете эти три игры. да, третья игра называется на самом деле Heavy Rain.
              • 0
                «Press X to Jason» — это как раз из Heavy Rain, если набрать эту фразу в гугле можно понять почему некоторым не нравятся игры PS3
  • +2
    Я не фанат стека LAMP но если честно из статьи не понял почему он мертв. Кто мешает организовать поток событий на таком стеке? Чем это противоречит Node.js? LAMP это же просто стек технологий для трехзвенки. Кто из них мертв? Линкс — не думаю. Аапч — нет. MySQL — есть альтернатива postgre но они примерно равнозначны. PHP — ну да это довольно старая технология но вроде как вполне живая.
    • +4
      >Кто мешает организовать поток событий на таком стеке?
      6000 висячих соединений
      • 0
        Я думаю что HTML 5 и web sockets должны снизить остроту проблемы. Ну если еще нет, то думаю скоро и для PHP должны появится движки по типу Явской атмосферы.
        • 0
          Apache вроде о поддержке WebSocket или ещё какой push технологии не заявлял.
          • 0
            А куда он нафиг денется если в браузерах начнут поддерживать?
            вот что говорит гугл

            • 0
              code.google.com/p/pywebsocket/

              e pywebsocket project aims to provide a WebSocket extension for Apache HTTP Server, mod_pywebsocket. You can also run it as a standalone server.

              mod_pywebsocket is intended for testing or experimental purposes. mod_python is required. For wss, mod_ssl is also required.

              issues.apache.org/bugzilla/show_bug.cgi?id=47485

              Senthilkumar 2009-07-06 17:54:24 EDT

              I am creating this BUG to track HTML5 web socket (now it is IETF websocket
              protocol. I am able to see browsers such as
              1. Mozilla Firefox (Websocket code is checked into the latest Trunk)
              2. Google Chrome docs.google.com/View?id=dfm7gfvg_1dm97qxgm
              3. Webkit (Safari) docs.google.com/View?id=dfm7gfvg_0fpjg22gh
              are going to support officially in few months.
              This entry is to make sure apache is not missing the web socket part.
              • 0
                Few month прошло с 2009, только Хром и Сафари поддерживают «из коробки» насколько я знаю. Бог с ним с ИЕ, но Файерфокс и Опера не поддерживают.
  • +2
    Это все отлично, но скажите мне кто развивает этот Javascript? Сам язык застрял где-то в 90-х, есть конечно фреймворки и хорошие, но как-то не вериться в благое будущее языка без динамичного развития его базы. Писать на нем действительно большие приложения в разы сложнее, чем на той же JAVA или C#, которые активно развиваются, и не только сообществом.
    Ну LAMP мертв это круто, по хабровский, сколько сейчас про себя подумали — «да, да это отстой. Node.js это реально круто, давайте все перепишем и наконец-то все заработает как надо!
    • +2
      5 версий за 14 лет я считаю неплохой результат
      например для Си всего 3 версии стандарта (C89, C90. C99), а ему 33 года. А для плюсов вообще только парочка.
      Так что нединамичнось развития языка трудно приписать ECMAScript'у.
      • +4
        При этом, даже примерно прикинув, у плюсов БАЗОВЫЙ функционал, в сотни раз богаче. Кол-во версии стандарта не говорит ровным счетом ни о чем.
        • 0
          то вы говорите про развитие языка, а теперь уже про базовый функционал.
          динамичность языка измеряется частотой выхода стандартов, базовый функционал — архитектурой языка.
          • 0
            вот внимательно прочитайте, что вы написали, еще разок) возможно просто не то имели ввиду или пятница, я уж не знаю
        • +3
          ФВП, замыкания и prototype-based OO в С++ уже появились?
          • 0
            В С++ на все вопросы о языке есть один ответ. Boost.
            Лямды? Boost. Замыкания? Boost. Обобщенное программирование? Boost. И так любые вопросы.
            • +2
              А как начиналось-то! Базовый функционал, то сё. Как только задаешь вопрос — сразу Boost :-\

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

              Ну и да.

              Boost — Это адовый ад
              list<int> v(10);
              for_each(v.begin(), v.end(), _1 = 1);
              
              vector<int*> vp(10); 
              transform(v.begin(), v.end(), vp.begin(), &_1);
              
              int foo(int);
              for_each(v.begin(), v.end(), _1 = bind(foo, _1));
              sort(vp.begin(), vp.end(), *_1 > *_2);
              


              Ну и т.п.
              • 0
                После вашего поста так захотелось снова сесть за C и Boost и написать что-нибудь этакое.
                • 0
                  Зачем? Лучше сесть за человеческий язык и написать что-нибудь этакое ;)
      • –6
        В том-то и дело, что сначала для Си 3 версии, потом С++ парочка, потом C#. Там принято не версии менять, а названия с каждой новой версией другое придумывать:)
        • +1
          C# — незаконнорожденный сын C, причём даже непонятно, то ли от Java, то ли от Delphi… шведская семья, короче.
          • –1
            Скорее выкидыш, который чудом ожил.
          • 0
            Я свое сообщение написал, не подумав, как шутку. Пойду дальше шутить про руби, его я по крайней мере знаю, в отличии от c# ;)
    • +1
      Сам язык застрял где-то в 90-х
      А тем временем лучшие умы Yahoo, Mozilla, Microsoft, Google, Apple (а также Opera и Microsoft) вводят Proxy и продолжают развивать язык. К чему бы это?!
      • +4
        Microsoft забыли ;)
  • +3
    > и переписать все с нуля

    Такое должно зарезаться сверху на корню.
    • +5
      по тексту не раз проскакивает юный максимализм, деление на черное и белое
  • 0
    Использую EventMachine в связке с thin, можно, спокойно реализовать асинхронное, событийно ореинтированное web приложение и в RoR. Дело тут не в node.js, это все го лишь фреймворк, одно из сотен решений одной задачи
    • 0
      Поинтересуйтесь как-нибудь, какие баги ловил в свое время с EM Макс Лапшин (erlyvideo). Лучше уж Erlang.
      • 0
        Я же говорю, всего одно из решений, есть еще goliath
  • +8
    Меня умиляет, как Django и RoR сравнили с LAMP-стеком во главе с пхп, который, к тому же, еще и умирает. А мне-то казалось, что это довольно развивающиеся и современные фреймворки (которые прекрасно используют LAM, без P).

    В RoR есть eventmachine, в Django — Twisted (это если говорить языком автора, который определенно путает между собой языки, технологии и фреймворки).

    Про валидации меня порадовало очень: мол, чтобы не валидировать формы на разных языках. Не знаю как в Django, в RoR формы валидируются вызовом методов вроде validates_presence_of :title, :content, :created_at в моделях. То же с другими валидациями. Очень сложно и долго, да.

    А с такими вещами, как github.com/nesquena/rabl, разработка современных и сложных RIA приложений стала еще быстрее и удобнее (и это при том, что рельсы из коробки поддерживают REST и создание REST API), а вот НОРМАЛЬНОЙ библиотеки на JS для работы с этим самым REST API еще нет. Ни одной нормальной, удобной. Не монстров типа «позвоночника», а просто банальную библиотеку для REST'ового доступа к данным (в родном, как сказано в статье, json'e).

    Поэтому js хорош, node — прикольная штука, но… автор статьи просто не очень в курсе, что есть что-то другое. Мне его жаль. И переводчика тоже жаль, куча потраченного времени на бессмысленный перевод.
    • +1
      В PHP есть phpdaemon ;) И фреймворки, поддерживающие REST из коробки тоже.
      • +1
        Хоть я пхп ненавижу, не понимаю и не знаю, коммент писался в ключе «задрали со своей нодой, нам и без нее хорошо». Про фреймворки в пхп я, конечно же, в курсе.

        Короче, «прочие серверные разработчики» должны срочно навалять нодовцам, забыв о своей внутренней вражде:)
    • 0
      Вот вам хорошая клиентская библиотека для REST: github.com/benpickles/js-model
      • 0
        Спасибо, я видел ее и даже переписывался с автором. Она мне больше всех понравилась, кстати.

        Но… есть в ней маленькая проблемка. Нельзя выбрать запись по id. То есть если я хочу выбрать все записи (посты, например), то идет запрос на /posts.json (что верно). А если мне нужен первый, логично было бы посылать запрос на /posts/1.json (исходя из того, что это REST), а запрос все равно идет на /posts.json, выбираются все записи и потом мне отдается только одна запись.
        Мне кажется, это немного неправильно
        • 0
          Это же гитхаб, форк и фикс )
          • 0
            Из меня такой джаваскриптер, как… как из меня балерина:)
            Да и автор сам сказал «я хрен знает как это лучше сделать», я ему пару идей подкинул:)
  • +2
    >Но когда объем кода JavaScript в наших серверных шаблонах переваливает за 90%, становится ясно — мы делаем всё неправильно.

    Весьма сомнительная мысль, по-моему. Как код в шаблонах может означать, что всё неправильно? Эти 90% в любом (почти) случае запрашивают данные через HTTP, а кто им их выдаст — LAMP, Node.js или это будут статические страницы клиентскому коду без разницы. Да, какой-то профит можно поиметь за счёт отсутствия необходимости дублировать одну и ту же логику на разных языках, ещё меньший за счёт того, что JSON будет родным и для сервера, и для клиента, а остальное…

    HTTP в принципе синхронный, асинхронные его расширения типа WebSocket не поддерживаются большинством популярных браузеров «из коробки», да ещё ограничения на количество одновременных соединений. В чём практическая польза асинхронности на стороне и сервера, и клиента, когда между ними лежит синхронный протокол, по-моему, далеко не очевидно с точки зрения архитектуры распределенного между сервером и клиентом приложения.
    • +1
      Всякие Sammy.js и прочие модные фреймворки позволяют хранить шаблоны на клиенте (отрисовывать, точнее, на клиенте). То есть с сервера изначально приходит пачка скриптов, стилей и что-нибудь еще, а потом уже идет общение с сервером только json'ом.
      Я сейчас с подобным играюсь, но… Вот Ноду хвалят за то, что типа везде один язык. Ну вот знаю я руби/рельсы, знаю js на уровне работы с DOM в jQuery, попытался сделать КРАСИВО и БЕЗ КОСТЫЛЕЙ такую работу, и хрен! Все недоразвитое, везде нужно писать кучу кода, чтобы что-то начало работать (после рельсов, знаете ли, непривычно!).

      Я не считаю это какой-то революцией. Но я не против ноды в принципе, я просто ТАКОГО СИЛЬНОГО продвижения, типа прямо спасет мир и все такое. Мир не катится в пропасть, как многим бы хотелось.
      • +1
        Дык с новыми технологиями и парадигмами всегда так. Вспомните, сколько шума было вокруг RoR, когда он только появился. Он не стал «убийцей» чего-либо, но занял своё место среди других языков и фреймворков и, между прочим, сильно обогатил другие платформы своими идеями. Например, PHP-шный Yii создан под сильным впечатлением от рельс, HAML, SASS тоже родом из сообщества RoR.

        Node.js и серверный JavaScript вообще сейчас резко стали «модными». Может быть, вокруг них слишком много шума, но это не значит, что нет ничего, кроме шума. Схлынет эта волна, и тогда станет видно, что к чему.
        • 0
          Я не говорю, что node-js — это плохо. Это очень хорошо! Но вот да, слишком много шума. И вот бесит это «все знают javascript». Далеко не каждый знаток руби станет сходу «въедет» в рельсы. Я неплохо знал php, но так и не разобрался с Zend'ом, сбежал в рельсы. Так же и тут: это совсем разные джаваскрипты, блин)
          • 0
            Это точно. Я сам сейчас с этим столкнулся — вроде бы туча книг, сайтов и учебников с примерами есть по JavaScript, но 99% — вещи типа «как сделать выпадающее меню». Все знают синтаксис JavaScript, а вот семантику — с этим очень и очень туго. А там ведь целые горы принципиально новых вещей для привыкших к императивному стилю людей.
            • 0
              Кстати да, затрудняюсь что писать в резюме о JavaScript: с одной стороны сделать «выпадающее меню» или валидацию какую могу, пару фреймворков могу использовать для «красивостей» или автодополнений, то есть синтаксис более-менее знаю, но вот писать JS приложение не возьмусь, по крайне мере без большого запаса по времени, лучше предложу Java-апплет — синтаксис знаю чуть похуже, зато привычная императивщина.
            • 0
              ИМХО JSG основы семантики описывает достаточно неплохо.
  • +33
    Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем server-side JS и node.js, ведь мы уже знаем JS.
    • +3
      Да, все верно!
    • 0
      У меня складывается сильнейшее впечатление, что минимум 70% прочитавших пост не поняло, что это ирония.
      • +2
        Ура, телепаты вернулись из отпуска. Схожу, ЛОР обрадую.
      • +2
        72.8%
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Для тех, для которых <, есть github.com/basho/erlang_js. Просто в целом Erlang >> JS. По причинам, изложеным выше.
  • +3
    а чем этот node.js крут, чтобы списывать php в утиль?
    • –8
      Просто модная штука от google. Из статьи для себя совершенно ничего не вынес. Просто какое то мнение, с которым я не согласен. 0 Обоснований, просто мнение. Почему мертв? Чем так хорош node.js? Почему это же нельзя было сделать в Django, RoR и ...? В общем, такие статьи в топку…
      • +2
        node.js не от Google ;)
        • 0
          Это так важно? Основана все равно на технологиях от google.
          • +3
            А это так важно, что основано на технологиях от google? Зачем делать на этом такой акцент?
          • +3
            Какие там, простите, ТЕХНОЛОГИИ ОТ GOOGLE? Чукча не читатель, чукча писатель?

            Я могу только сказать что есть v8, к которому только гугл прикладывается, и всего. Но это только фундамент, и легко в теории заменяемый. Весь стек технологий к гуглу не имеет отношения вообще никак.
    • +1
      может тем что совершенно разные ниши занимают эти 2 продукта?
    • 0
      он быстрее по своей «не блокируемой» природе. Ровно такая же природа частично реализована в phpDaemon, за исключением того что в пхп нет асинхронных операций «нижнего» уровня.
      • 0
        Кстати, почему он быстрее для обычных «статических» страниц я так и не понял. Если, грубо говоря, формирование страницы состоит из трёх фаз (подготовка запроса к БД, запрос к БД, шаблонизация результатов запроса) по 100мс, то никак быстрее 300мс клиент ответ же не получит, пока каждая из фаз не отработает? Если узкое место БД (допустим запрос 300 мс выполняется), то будем иметь 100500 запросов ожидающих ответа от БД вместо 100500 запросов ожидающих подготовки запроса к БД.
        • 0
          Он имеет асинхронный/событийный ввод-вывод. Пока ваш скрипт, например, на PHP ждет когда же ему ответит MySQL Node.js в этой ситуации обрабатывает другой запрос — не ждет как PHP. I/O самая медленная операция поэтому прирост огромный.
          • 0
            Ну вообще-то I/O в память быстрей, чем в сеть.
            А если у нас висит база и нет кеширования, хоть дважды ноджс приделай — не поможет.

            В смысле, на большинстве сайтов узкое место — вовсе не тормозной LAMP. И зачем переписывать весь код чтобы получить пару процентов выигрыша?
          • 0
            Node.js в этой ситуации начнёт обрабатывать другой запрос (если вообще другой запрос в это время есть) — завершить он его сможет только когда отработается первый. Скорость N-го обработки запроса не может быть больше, чем скорость N-го запроса к БД. Некоторый выигрыш можно получить за счёт выноса БД на отдельный сервер, но сомневаюсь, что он будет огромным, по крайней мере для задач, где обращение к БД занимают бОльшую долю времени обработки запроса в целом.
  • +3
    если уж утрировать и делить по этой схеме:

    1. в эту эпоху инет можно было делать «из говна и палок», сайты были простые, их было мало, интерактивности никакой.

    2. в эту эпоху появились сотни, тысячи фреймворков, стандартов шаблонов, серверных примочек и IDE, чтоб всё это красиво оформлять. потому

    3. эра javascript в ближайшее время не наступит, просто потому что:

    — это не стандарт и трудно найти разработчиков
    — разработчикам трудно переучиваться т.к. нет фреймворков
    — зачем писать фреймворки, если это не стандарт и завтра твое творение могут выкинуть в помойку?
    — зачем выбирать javascript, если на нём никто не пишет? вот есть многофункциональная, удобная и красивая scala. но она никогда не вытеснит java, потому что за java — инфраструктура и имя ей легион а за scala — пара этнузиастов.

    автор путает развитие компьютеров до ~2000 и после. до 2000 года не было никаких стандартов, можно было менять API, целые языки, операционные системы и даже платформы раз в квартал и особо не страдать при этом. господам учёным и паре энтузиастов даже было в прикол разнообразить суровые будни веселыми сетапами-ресетапами.

    с повсеместной компьютеризацией всё устаканилось и 80% времени отнимает соблюдение стандартов и поддержка обратной совместимости. и совместимости не только с кодом, а и с огромной арминей специалистов, которые будут эти продукты обслуживать.
  • +2
    Прочитал топик и заинтересовался Node.js. Посмотрел видео с гугла с разработчиком — интерес усилился.
    Нашел сравнение Node.js с Erlang. Рассказывается и о технологиях, и о истории, и даже есть результаты авторского тестирования с выводами. Вроде небыло на хабре. На топик-ссылку не хватает кармы.
    • +1
      Одна из интересных ссылок, который косвенно показывает интересность ноды — это список модулей, которые работают с ним:

      Просто прокрутите до конца github.com/joyent/node/wiki/modules
    • +1
      Статья та в фпрог отстой, потому как сравнивает письку с пальцем. Краткое резюме — habrahabr.ru/blogs/nodejs/117887/#comment_3842098. Ещё короче, в трёх словах — уделите время Erlang.
  • +1
    >>> Архитектура LAMP мертва потому что мало кому сейчас хочется отправлять тонны HTML-разметки в ответ на каждое движение пользователя.

    Теплое более теплое, чем мягкое. Поэтому мягкое твердое.

    Автор явно не дружит с технологиями. Гонять HTML можно кусочками. А вот генерировать HTML на стороне клиента — еще та проблема. Работать со строками на уровне сервера гораздо удобнее и менее трудозатратно чем генерировать разметку на стороне клиента.

  • 0
    Чего-то в этом не так ))) На данный момент HTML мертв => индексировать никак => Google мертв… Протрите мне глаза, но я этого не вижу
    • +3
      «Мама, он меня сукой обозвал»
  • +1
    Все в жизни меняется бешенными темпами. Возможно в будущем php будет работать по принципу node.js и будет иметь не меньшую производительность. Как сейчас mysql уже можно использовать в качестве NoSQL. Раньше все писали, что XSLT — это разметка, которой будут пользоваться все. Где она сейчас?
    • +1
      Там, где она удобнее всего.
    • 0
      Я Яндексе и в ЮМИ.ЦМС. Но хотя да, для большинства Web-приложений JSON и HAML намного удобнее, чем XML-основанные протоколы. Ибо легковеснее и эффективнее, и проще в понимании и использовании.
      • 0
        Удобнее в каком плане? В использовании? В разработке? В масштабируемости? Без иронии, реально интересует мнение.
        • 0
          Читабельнее, удобнее получить элемент. Грубо говоря в php из json создается объект и погнал по ключам, а в xml нужно какой-то либой его разбирать) Я юзал и то и то и json — удобнее.
          • 0
            Уж добыть либу не проблема — больше проблема в том, что сам xslt тяжёловат для чтения (не первичного понимания!) его в большом кол-ве, а на клиенте еще и довольно ограничен.
            • 0
              Либу то добыть не проблема, а вот удобную либу. Например, на php я еще не нашёл ни одной достаточно удобной.
              • 0
                А чем стандартная неудобна?
                • 0
                  Долго рассказывать. Впечатление субъективное, кому-то оно ведь удобно)
              • 0
                Достаточно удобной для чего? Задачи какие надо решать?
                • 0
                  из последнего — распарпсить ррс-фид во внутреннее представление программы. ррс-фид может быть на xml или json. что-то типа яндекс.маркета. Короче, часть с json получилась намного приятнее.
                  • 0
                    Не вижу разницы между $arr['items']['item'][0] и $xml->items->item.
                    • 0
                      Какие-то у вас странные примеры. Начнём с того, что в json нету идиотского дублирования названий в массивах, когда надо делать тег , а в нём — .

                      В json получение первого элемента массива items будет выглядеть красиво и понятно(не так, как вы написали):
                      $arr->items[0]
                      


                      Вы предложили simpleXML, на его примере рассмотрим:
                      В php есть simpleXML


                      То, что вы предложили на счёт $xml вообще имеет мало смысла. В SimpleXMLElement я вообще не вижу возможности получить тег через гетер (хотя через foreach его можно итерировать). Также, я не вижу вменяемой возможности определить, что это массив значений (на примере магазина — перечисление цветов, или на примере туристической фирмы — перечисление опорных точек путешествия), мне надо явно указывать это. Если $xml->items->item возвращает нам массив элементов item, то это достаточно костыльно — зачем тогда нужен items? и тогда, чтобы пройти через все элементы необходим такой код:
                      // json
                      foreach ($arr->items as $item):
                      
                      // xml:
                      foreach($arr->items->item as $item):
                      


                      Вторая запись показывает одну из родовых проблем xml.

                      • 0
                        Во-вторых, json более близок к внутреннему представлению программы.
                        В xml есть атрибуты тега и дети, в то же время в моих объектах это разделение нафиг не нужно. JSON проще и излишние усложнения xml просто не нужны.
                        • +1
                          Не вижу никакой принципиальной разницы между ассоциативным массивом и объектом SimpleXML, и то и другое близко к внутреннему представлению программы.

                          JSON лучше при передаче данных, потому что гоняется меньше этих самых данных. Но на стороне сервера я бы три раза еще подумал, прежде чем использовал json

                          Смертельный аргумен: $xml->xpath("/a/b/c") :)
                      • 0
                        Без дублирования так без дублирования.
                        Никто не мешает вам убрать дополнительный контейнер, и итерировать вот так

                        foreach ( $xml->item as $item )

                        >> В SimpleXMLElement я вообще не вижу возможности получить тег через гетер

                        Ничего не понял. Пример приведите, и задачу, которую он решает

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

                        А зачем вам это? Вы применяете json-логику к xml.
                        Да и вариантов масса:

                        if ( isset($xml->item[1]) ) {}

                        или

                        if ( count( $xml->children() ) ) {}

                        >> Если $xml->items->item возвращает нам массив элементов item

                        Он возвращает вам первый элемент item в контейнере items

                        >> Вторая запись показывает одну из родовых проблем xml.

                        Без обид, но она показывает ваше незнание SimpleXML. К xml это не имеет никакого отношения.
          • 0
            В php есть simpleXML. Загнал контент, и погнал по полям. Плюс есть xpath, плюс легко (относительно конечно) можно использовать xslt.

            К слову, в банках XML и SOAP — знакомые слова. JSON — к таким не относится.

            Я не хочу выпячивать одну технологию или уменьшать плюсы второй, но пока что мне видится один плюс XML — его легче изучать людям, даже далеким от программирования.

            Каждой технологии — свое место. Удивительно, но в нашем проекте используется и json, и xml, и xslt, и soap, и большой еще зоопарк решений.
            • +3
              simpleXML и использовал. Неудобно.
              В банках много чего знакомо. Им еще фортран знаком и кобол, а питон — врядли.

              но пока что мне видится один плюс XML — его легче изучать людям, даже далеким от программирования.

              Ох и заблуждение)
              items: [
                'first',
                'second',
                'third'
              ]
              // vs
              <items>
                <item>first</item>
                <item>second</item>
                <item>third</item>
              </items>
              

              Просто вы больше любите xml, потому вам кажется, что люди его лучше понимают ;) у меня вот другая практика. xml для людей — ад.

              • 0
                Приведенный пример не репрезентативен.

                И дело не в моей любви к xml, дело в совершенно разном восприятии программистов и непрограммистов. Программист при желании может и бинарные файлы без проблем «читать» :). Обычные люди на такое смотрят как проявление инопланетных способностей и носитель подлежит немедленному уничтожению.

                По моему опыту общения с разными людьми разных профессий и уровня познаний, быстрее у них получалось разобраться именно с XML, может еще и потому, что у людей уже были изначальные знания.
                • +2
                  По моему опыту общения с разными людьми разных профессий и уровня познаний, быстрее у них получалось разобраться именно с XML, может еще и потому, что у людей уже были изначальные знания.

                  Ну с изначальными знаниями — конечно. Люди лучше знают то, что знают, чем то, что не знают)
                  Придите к совершенно нулевому человеку и спросите, что ему понятнее, попросите его добавить в этот список отчество Иванова. Особо люди путаются в закрывающих тегах. Вон сколько верстальщиков не могут сделать валидный и well-formed html, а вы говорите xml.
                  {
                     "firstName": "Иван",
                     "lastName": "Иванов",
                     "address": {
                         "streetAddress": "Московское ш., 101, кв.101",
                         "city": "Ленинград",
                         "postalCode": 101101
                     },
                     "phoneNumbers": [
                         "812 123-1234",
                         "916 123-4567"
                     ]
                  }
                  

                  <person>
                    <firstName>Иван</firstName>
                    <lastName>Иванов</lastName>
                    <address>
                      <streetAddress>Московское ш., 101, кв.101</streetAddress>
                      <city>Ленинград</city>
                      <postalCode>101101</postalCode>
                    </address>
                    <phoneNumbers>
                      <phoneNumber>812 123-1234</phoneNumber>
                      <phoneNumber>916 123-4567</phoneNumber>
                    </phoneNumbers>
                  </person>
                  
                  • +3
                    А запятую поставить, думаете додумаются?

                    А почему тут в одном месте {}, а в другом []? А зачем firstName в кавычках написано? А чего вы в одном месте в кавычках пишете, а в другом — без?
                  • +4
                    Хех, если говорить о человекочитаемости, то лучше, имхо, выглядит YAML:
                    person:
                      firstName: Иван
                      lastName: Иванов
                      address:
                          streetAddress: Московское ш., 101, кв.101
                          city: Ленинград
                          postalCode: 101101
                      phoneNumbers:
                           - 812 123-1234
                           - 916 123-4567
                    
                    • +2
                      Ага. а JSON является подмножеством языка yaml.
            • +2
              В банках и прочем entrpise xml вовсе не за то ценится. а за то что вокруг xml сидит. Схемы, валидаторы, генераторы. Т.е. все то что в первую очередь требуется для автоматизации и надежности. Читабельность тут самый последний аргумент.

              Читать простыни данных с кучей мусора в виде тегов. увольте. Читабельными остаются только самые травильные документы.
              • 0
                *тривиальные
              • 0
                Оппонент выражал мнение про читабельность. До валидации, трансформации и прочих плюшек мы еще не дошли :)

                • 0
                  Ну про читабельность Вы начали)
                  пока что мне видится один плюс XML — его легче изучать людям, даже далеким от программирования.
  • +6
    Авторы — отвратительные тролли, а если и не тролли, то неучи.

    Освоили одну технологию и теперь «за ней будущее».
  • 0
    А насколько быстр Node.js по сравнению с apache2 + php или серверным приложением на c++?
    • +1
      На искуственных тестах они оба в сотню раз медленнее, чем C++, то вы задолбетесь, прежде чем напишите веб-приложение на c++ и оно врядли у вас получится таким же быстрым, как на на node.js, без годов оптимизаций и тестов.
      • –1
        На qt4 у меня вроде неплохо получается. А как насчет php vs node.js?
        • +1
          Простите, может я не понял, мы говорим о веб-программировании на С++?

          У node.js круче сборка мусора + то, что выше назвали, но я не думаю, что различие в скорости будет даже на порядок. Значительно меньше.
          • –2
            Апач без nginx-а? Тогда может даже на 2 порядка )
            • –1
              Апач и nginx — это серверы, php и node.js — интерпретаторы языков. Какая связь-то?
              • –3
                node.js — это фрефворк.
                • 0
                  Вообще-то это не фреймворк и не интерпретатор. Фреймворк — это, например, Express, а интерпретатор там — V8.
                  • 0
                    Наверное можно назвать низкоуровневым фреймворком для сетевых приложений, на базе которого можно построить и веб-приложения начиная собственно с веб-сервера., а в более высокоуровневых фреммйворках часть работы уже сделана.
                  • 0
                    Начнем с того, что V8 не интерпретатор, а компилятор. А node.js это что-то наподобие базовой библиотеки.
                    • 0
                      Благодаря JIT-компиляции уже вообще трудно провести границу между компилятором и интерпретатором. Но, если в «настоящих» компиляторах результат компиляции может жить своей, независимой от исходника жизнью, в виде .exe, например, то V8 всё же ближе к интерпретаторам.
                      • –1
                        >Благодаря JIT-компиляции
                        > трудно провести границу между компилятором и интерпретатором
                        > JIT-компиляции
                        > компиляции

                        Сами же ответили. V8 не может быть интерпретатором, потому, что он компилирует js в машинный код, в то время как интерпретатор интерпретирует фаил построчно. JIT-компиляция это конечно не AOT, но все же компиляция.
                        • +3
                          Я имел в виду, что если применить к V8 «утиную типизацию», то, раз он снаружи выглядит, как интерпретатор, и ведет себя, как интерпретатор, то мы можем считать его интерпретатором: ) Ну а внутри это, конечно, компилятор.
              • +1
                Я, может, зря написал про nginx, хотя без него апач будет дольше работать в реальном примере, а не какой-дь совсем синтетике, но вы вообще какой-то бред пишете.

                Заходим на nodejs.org/ и во первых строках сайта видим:
                An example of a web server written in Node which responds with «Hello World» for every request.
                Т.е. для node.js не используется веб-сервер! А php без вёб-сервера — почти ничто. Можно, наверное, на голом пхп его написать, но это будет ад, угар, трэш и содомия.

                И для закрепления материала упрощённая табличка:
                language       php     js
                interprer      zend*   V8
                host env       apache  node

                * сепциально для хомячков, которые минусуют, не думая: сам «интерпретатор» пхп тоже называется zend.

                Да, V8 фактически является частью ноды. Поэтому и упрощённая.

                И да, я бы тоже называл node.js фреймворком. microsoft же называется свой .net run-time enivroment фреймворком.
                • +1
                  Вот «run-time environment», по-моему, более удачное наименование, чем фреймворк, как для .net, так и для node.js+v8. А фреймворк это всё же нечто большее. Работая без фреймворка, пишешь программу в целом для решения частной проблемы, а для маленьких общих задач используешь библиотеки или плагины. С фреймворком — всё наоборот. Программа в самом общем виде уже написана, а ты добавляешь немножко кода там и сям, чтобы приспособить программу к своему частному случаю.
                • +1
                  >А php без вёб-сервера — почти ничто. Можно, наверное, на голом пхп его написать, но это будет ад, угар, трэш и содомия.

                  Всё уже написано до нас
                  phpDaemon — asynchronous server-side framework of network applications implemented in PHP using famous libevent which makes possible to handle hundreds and thousands of simultaneous connections.
                  Its master process spawns a bunch of worker-processes (workers) that run your applications. Each worker doesn't block (sleep) at all, and has event-driven architecture.
                  Designed for highload.

                  Out-of-Box
                  Network servers:
                  HTTP server (supports multipart, uploads, etc)
                  WebSocket server (supports latest protocol specification)
                  FastCGI server
                  FlashPolicy server — cross-domain policy at port 843
                  Socks server.
                  LockServer.


                  Идеологических отличий от Node возможно не так уж много.
                • 0
                  Заходим на nodejs.org и во первых строках сайта видим:
                  An example of a web server written in Node
                  Т.е. вы отождествляете пример сервера, написанный на Node и саму Node?
                  Т.е. для node.js не используется веб-сервер!
                  Клево! А кто картинки отдавать будет? Ну, к примеру вы напишете сервер с помошью той же Node, который картинки отдает. Тоже будете говорить, что он равен Node?

                  И php давно уже можно без apache пускать, тоже в виде сервера приложений, в fastcgi. А проекты на Django можно запустить по полдюжине протоколов.

                  Мне кажется логичным отделять сервера приложений на Node, PHP и Django от веб-серверов apache и nginx, смотрящих наружу.
                  • +1
                    Учитывая, что он пишется проще, чем конфигурируется апач — да.
                    Про картинки — да, я именно это и имел ввиду. Что даже если мы картинки будем «вручную» отдавать через node.js — это может оказаться быстрей, чем связка apache+php без nginx.

                    А мне кажется логичным не ставить в один ряд Node.js, Django и PHP, если уж хочется быть последовательным и формальным.

                    Ладно, это бессмысленный спор о формализме.
                    • 0
                      По-моему, Node лежит где-то между PHP и Apache/nginx+PHP, Django лежит ещё выше.
  • 0
    Думается мне, что просто уже много лет веб уходит от ультра-тонкого клиента в сторону клиента более толстого, без всяких там «эр». И флэш был первой весточкой ещё в начале 2000х. То же мне, «эра LAMP», блин :)
  • +1
    Архитектура LAMP мертва потому что мало кому сейчас хочется отправлять тонны HTML-разметки в ответ на каждое движение пользователя. Вместо этого лучше обновлять небольшие фрагменты DOM с помощью AJAX.

    Серьезно? По-моему в данной статье речь идёт о RIA, а не о веб-сайтах. Вот если бы Интернет был совокупностью RIA, тогда да.

    Надо отталкиваться от задачи. Будем честны, для большинства задач веба (веб-сайты а не RIA) асинхронные фреймворки не подходят, хотя для специфичных задач (см. комменты выше) они идеальны.

    Также открытым остается вопрос с SEO. Пользуясь терминологией автора, поисковые системы сейчас всё ещё живут в эре «LAMP». Так что для самого раскрутецкого сайта на Node.JS придётся делать вариант для поисковиков?!

    /* погружаясь в мечты */ Вот если бы был стандартный интерфейс (наподобие sitemaps) взаимодействия всех поисковых систем с веб-сайтами, и вместо поисковых ботов-парсеров происходил бы обмен данными веб-приложение <-> поисковик по опять таки стандартному протоколу, тогда да. Можно было бы и пренебречь второй версией сайта. Но как говорится, если бы у бабушки был бы ..., это был бы дедушка.

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.