Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 210
А вы н
Случайно нажал:
Правильно назвать не эрой JavaScript а эрой событийно-ориентированого программирования
Правильно назвать не эрой JavaScript а эрой событийно-ориентированого программирования
Это вы сильно загнули. Событийно программировали задолго до javascript.
А если вы про веб, то SOA 2.0 изобретен уже достаточно давно и реализаций было достаточно.
А если вы про веб, то SOA 2.0 изобретен уже достаточно давно и реализаций было достаточно.
Я тоже соглашусь с тем, что наступает эпоха Javascript.
Кроме php/perl/ruby/wtf на веб-серверах, javascript-приложения вытеснят часть десктопного софта, отобрав хлеб у Java и .NET.
На десктопах останутся только (клиенты ?) тяжелых штук типа 3D графики/игр и обработки видео, скорее всего написанные на С++, для которых стек http+html+javascript будет слишком медленным.
Кроме php/perl/ruby/wtf на веб-серверах, javascript-приложения вытеснят часть десктопного софта, отобрав хлеб у Java и .NET.
На десктопах останутся только (клиенты ?) тяжелых штук типа 3D графики/игр и обработки видео, скорее всего написанные на С++, для которых стек http+html+javascript будет слишком медленным.
А что, много десктопного софта на Java и .NET? Сходу в голову приходят только IDE на Java для Java же (поддержка других языков — опции). Правда не знаю, может под виндой его действительно много…
Много корпоративного софта под заказ.
Ну, десктопного софта на С# и Java просто-таки до… я.
Пользуясь случаем, передаю пламенный превед программистам на этих языках:)
Пользуясь случаем, передаю пламенный превед программистам на этих языках:)
Нет, client-driving services.
Вторая половина комментария прибудет асинхронно.
node.js, конечно, хорошая штука, но LAMP не мёртв
Проблема в том, что «передний край» — это эмоциональная оценка. В реальности все проще: есть задачи (поддержка длинных соединений, push-уведомлений, поддержка большого числа пользователей), которые проще решаются на асинхронных фреймворках.
Раньше решения для этих задач были экзотикой, теперь для них появились более-менее удобные средства, отсюда все эти волнения и энтузиазм. Но ниоткуда не следует, что это все так уж важно. Ну можно будет в будущем (да и в настоящем уже) к сайту прикрутить realtime-поток сообщений из твиттера, счетчик посетителей и чатик, где тут сдвиг парадигмы? Для некоторых это, безусловно, актуально (как, например, для ребят, статью написавших — они панель с аналитикой делают, штука очень ведь специфичная).
Загвоздка в том, что остальные-то задачи проще решаются на синхронных фреймворках. Т.к. синхронный код — проще и понятнее (= дешевле в написании и поддержке). Все эти realtime-штуки имеют свою нишу, это новая ниша и она расширяется, но ниша обычной веб-разработки от этого меньше-то не становится. Противопоставление тут, как мне кажется, неоправданное.
Раньше решения для этих задач были экзотикой, теперь для них появились более-менее удобные средства, отсюда все эти волнения и энтузиазм. Но ниоткуда не следует, что это все так уж важно. Ну можно будет в будущем (да и в настоящем уже) к сайту прикрутить realtime-поток сообщений из твиттера, счетчик посетителей и чатик, где тут сдвиг парадигмы? Для некоторых это, безусловно, актуально (как, например, для ребят, статью написавших — они панель с аналитикой делают, штука очень ведь специфичная).
Загвоздка в том, что остальные-то задачи проще решаются на синхронных фреймворках. Т.к. синхронный код — проще и понятнее (= дешевле в написании и поддержке). Все эти realtime-штуки имеют свою нишу, это новая ниша и она расширяется, но ниша обычной веб-разработки от этого меньше-то не становится. Противопоставление тут, как мне кажется, неоправданное.
Противопоставление и эмоциональность — скорее в статье, про все эти эпохи и мертвичину) Это же глупость — объяснять технические решения какими-то невнятными провидческими опусами.
Ну и скажите мне, какая принципиальная разница между этими клиент-серверами:
— клиент: HTML+Js. Сервер: LAMP
— клиент: HTML+Js. Сервер: Erlang
— клиент: HTML+Js. Сервер: Node.js
:-\
— клиент: HTML+Js. Сервер: LAMP
— клиент: HTML+Js. Сервер: Erlang
— клиент: HTML+Js. Сервер: Node.js
:-\
Чисто формально последний вариант позволяет обходиться одним ЯП. Хотя я бы предпочёл поддержку P (и R) в браузерах :)
Мне кажется, тогда сложнее было бы отделить логику от представления.
Чем сложнее?
Тем, что начали бы смешивать серверную и клиентскую логику, использовать сложные языковые конструкции в представлении. Не даром в RoR и Django используются шаблонны не совпадающие полностью с основным языком.
Безусловно, это проблемы не языка\системы\технологии, а программиста.
Безусловно, это проблемы не языка\системы\технологии, а программиста.
Хотите сказать, что сейчас не используют сложные языковые конструкции JS? Тем более, что HTML+JS представление в терминах сервер-сайда является целым приложением в терминах клиентсайда, в котором по хорошему тоже надо отделять логику от представления. А в особо изощренных случаях чуть ли не полностью дублировать код PHP, Python или Ruby на JS.
Как относиться в данном случае к JS, если честно, я не знаю. Но смешивание северного и клиентского кода приводит к хаосу. Писать просто, но разобраться в этом через месяц очень трудно. Дублирование кода — отдельная головная боль. Но всего скорее есть какое-то простое и красивое решение.
Про поддержку языков в браузерах — можно написать самому (по-моему только для IE ничего не получится) и разослать разработчикам. Только, боюсь, оно не будет пользоваться популярностью. Знаю, были случаи когда люди писали браузерные интерпретаторы lisp.
Про поддержку языков в браузерах — можно написать самому (по-моему только для IE ничего не получится) и разослать разработчикам. Только, боюсь, оно не будет пользоваться популярностью. Знаю, были случаи когда люди писали браузерные интерпретаторы lisp.
Ну в обычных (не веб) сетевых приложениях часто десктопный клиент и серверная часть написаны на одном языке в рамках одного проекта и даже используют общий код. Хаоса как-то не возникает. Чисто субъективно кажется, что больше хаоса когда приложение написано на 6 языках (PHP/Python/Ruby/Perl/..., SQL, HTML, CSS, JS, язык шаблонизатора) :)
Даже видел и чуть-чуть ковырял такие попытки в интранет сети, но потом от них отказались — самостоятельно поддерживать сложно.
Даже видел и чуть-чуть ковырял такие попытки в интранет сети, но потом от них отказались — самостоятельно поддерживать сложно.
> даже используют общий код.
Из того что я видел (и к сожалению, в этом участвовал) — было плохо. С одной стороны, это, конечно, удобно, с другой плодит ненужные зависимости. На самом деле, если архитектура спроектирована нормально, то все равно какие средства используются.
> когда приложение написано на 6 языках
За это надо руки отрывать. Но, как вы отмечали выше, сторона клиента и сторона сервера — суть разные приложения.
Из того что я видел (и к сожалению, в этом участвовал) — было плохо. С одной стороны, это, конечно, удобно, с другой плодит ненужные зависимости. На самом деле, если архитектура спроектирована нормально, то все равно какие средства используются.
> когда приложение написано на 6 языках
За это надо руки отрывать. Но, как вы отмечали выше, сторона клиента и сторона сервера — суть разные приложения.
Ну вот, в принципе, и все :-)
Берем в руки GWT и получаем тот же профит. Вернее, намного бОльший, по понятным причинам.
То есть, автор перевода и сам автор изначального сообщения маленько не понимает, что разницы, в принципе, вообще никакой :)
Берем в руки GWT и получаем тот же профит. Вернее, намного бОльший, по понятным причинам.
То есть, автор перевода и сам автор изначального сообщения маленько не понимает, что разницы, в принципе, вообще никакой :)
Да чепуха всё это про «передний край». Так обычно называют модные и прикольные по мнению разработчиков технологии. И пиарят их больше всех люди, которые на практике не использовали их никогда на реальных проектах, но хотели бы. Node.js и Javascript в этом отношении очень показательны, тут нет ничего нового, джаваскрипт как серверный язык не имеет никаких преимуществ над руби и питоном, фреймворки для асинхронных серверов существовали и до него. Просто новая модная штука. То же самое с эрлангом. В своей нише он очень хорош, для производительного инфраструктурного сервера отличный выбор, но хорошо ли подходит чисто функциональный язык для типичного сайта или веб сервиса со сложной бизнес логикой…
никто на Erlang делать веб проекты не будет, ну кроме restful, и то проще написать на eventmachine
пардон, оказывается я не разрабатывал сайты на webmachine и mochiweb и не могу судить, где erlang взлетает, а где он недостаточно удобен.
да, я считаю, что лучше писать на erlang'е, чем на javascript + nodejs. просто front end надо писать используя ту платформу, где создания front end'ов является одним из главных фич — это sinatra или ror.
я это заявляю на личном опыте — спагетти из бумеранга кода (даже используя step) на nodejs против просто чудовищно лаконичного кода на erlang'е использую webmachine для restful сервиса — это стоило того.
я это заявляю на личном опыте — спагетти из бумеранга кода (даже используя step) на nodejs против просто чудовищно лаконичного кода на erlang'е использую webmachine для restful сервиса — это стоило того.
Миллион COMET подключений на один сервер. Last.fm. Nuff said.
www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1
www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1
— По мне хоть всю жизнь живи, раз хороший человек.
© Дворник Тихон
© Дворник Тихон
Я тоже думаю что вокруг Node много шума а для большинства web приложений от асинхронности столько же пользы сколько от реактивного двигателя для трактора. Но использовать один и тот же язык внутри браузера и на сервере разумно. Поэтому я продвигаю Akshell — попробуйте и убедитесь сами что server side JavaScript это круто.
Вот только не надо путать разработку веб сайтов с разработкой веб-приложений. В первом случае доминанта на потреблении информации пользователем. Во втором на производстве. LAMP очень даже хорош для своих задач и будет оставаться таким ещё долго.
Вот еще бы в начале статьи пояснили, почему платформа Джанго не отвечала возросшим требованиям — что это был за сайт? Кто на него ходил и что там делал?
Это мое личное мнение, но отдавать клиенту DOM кусочками можно независимо от выбранной серверной платформы. Тут вопрос в общей архитектуре веб-приложения, а написать неподъемный многослойный тормозной пирог на Node.js можно даже проще, чем на Django…
Это мое личное мнение, но отдавать клиенту DOM кусочками можно независимо от выбранной серверной платформы. Тут вопрос в общей архитектуре веб-приложения, а написать неподъемный многослойный тормозной пирог на Node.js можно даже проще, чем на Django…
Ещё нужно добавить, что GWT и им подобные системы, в которых JS генерируется с сервера, который вызывает другие части страниц, генерирующие дополнительный JS — апофеоз ламповой эры, рухнувший под своей тяжестью. Писать такое ещё с трудом можно, а изменять — ….
А в чем сложность изменять?
Разрабатывая с использованием GWT вы пишете в основном на Java (JS-вставки можно рассматривать как ASM-вставки в С/С++ код, на практике очень редко встречается необходимость).
Дебаг тоже идет только по java-исходникам. Компиляция в реальный JS происходит во время деплоя на продакшен, и при разработке очень редко имеет смысл о нем задумываться.
За это вы получаете строгую типизацию, оптимизацию под конкретные броузера/языки (например если я захожу Firefox4 и хочу на русском языке, зачем мне какие либо куски кода для других броузеров и языков), спрайтинг для иконок, UI-Binding, единый язык для сервера и клиента (общий код валидации данных и т.д.).
И самая «вкусная» штука — это code splitting когда на клиент загружается только че части приложения, которые нужны ему сейчас. И за зависимостями следит сам GWT.
Конечно хоум-пейджи клипать не стоит, но плюсы для rich web applications просто огромные. И сравнимы с плюсами от использования Silverlight/Flex.
Я не говорю что GWT — супер-мега вещь, которую стоит везде юзать, но не вижу причин не считать довольно интересной и сильной платформой.
Разрабатывая с использованием GWT вы пишете в основном на Java (JS-вставки можно рассматривать как ASM-вставки в С/С++ код, на практике очень редко встречается необходимость).
Дебаг тоже идет только по java-исходникам. Компиляция в реальный JS происходит во время деплоя на продакшен, и при разработке очень редко имеет смысл о нем задумываться.
За это вы получаете строгую типизацию, оптимизацию под конкретные броузера/языки (например если я захожу Firefox4 и хочу на русском языке, зачем мне какие либо куски кода для других броузеров и языков), спрайтинг для иконок, UI-Binding, единый язык для сервера и клиента (общий код валидации данных и т.д.).
И самая «вкусная» штука — это code splitting когда на клиент загружается только че части приложения, которые нужны ему сейчас. И за зависимостями следит сам GWT.
Конечно хоум-пейджи клипать не стоит, но плюсы для rich web applications просто огромные. И сравнимы с плюсами от использования Silverlight/Flex.
Я не говорю что GWT — супер-мега вещь, которую стоит везде юзать, но не вижу причин не считать довольно интересной и сильной платформой.
Вы вот это все поисковикам расскажите для начала
А это, по идее, nodeJS должен рассказывать тем же языком, на котором идёт основная работа клиента. Как только начинаем задумываться о поисковиках и примитивных бр-рах (которых много в мобильных) — требуется дублирование логики клиентского приложения на сервере.
Ну так совсем по другой причине :)
По какой?
anatolix.livejournal.com/52547.html
Хотят сделать живую выдачу как у гугла и таскать части приложения между клиентом и сервером туда-сюда.
Но первый комментарий пожалуй был о том, что Full-AJAX приложения не индексируются.
Хотят сделать живую выдачу как у гугла и таскать части приложения между клиентом и сервером туда-сюда.
Но первый комментарий пожалуй был о том, что Full-AJAX приложения не индексируются.
А в чем проблема? Тот же Твиттер отлично индексируется поисковиками.
Интересно, что думают те, кто работал с Node.js об этом?
Это тонкий стёб, кмк ;)
Написано эмоционально, но справедливо. Node.js ещё очень сырой, версии не всегда обратно совместимы, да и асинхронный код писать на JS хоть немного удобнее, чем на других мейнстрим языках, но, например, в Erlang писать такой код на порядок удобнее, безопаснее, а результат эффективнее. Лично я рассматриваю Node.js как неплохую альтернативу прочим языкам. Не думаю, что это «новая» эра, или убийца PHP/Python/Ruby/<ваш любимый язык>. Движок V8 действительно быстр, язык прост, сборщик мусора хорош, а прототипо-ориентированное программирование имеет свою определенную прелесть.
складывается впечатление, что автор просто перешёл с менее подходящего лично для него языка программирования/технологии на что-то, что ему больше нравится, и под впечатлением фанатично расписывает все прелести данной технологии.
на самом деле не буду говорить конкретно про Django, но:
1) в PHP и даже Ruby on Rails хватает средств чтобы писать асинхронные событийные приложения.
2) для нагруженных сервисов действительно асинхронно-событийная архитектура является на данный момент преобладающей, однако не стоит забывать, что в интернетах до сих пор значительная часть корпоративных, рекламных, справочных и т.п. сайтов, которым она просто-напросто не нужна.
3) не забывайте, что LAMP = Linux + Apache + Mysql + PHP. если не говорить конкретно о наборе программного обеспечения, то LAMP наоборот сейчас является преобладающим. даже облака для хостинга сервисов сейчас используются либо как один из элементов инфраструктуры, либо только среди сервисов средней весовой категории, ибо аренда сервера пока ещё дешевле и гибче для мелких сервисов, а крупные могут себе позволить датацентры, всё с теми же LAMP.
на самом деле не буду говорить конкретно про Django, но:
1) в PHP и даже Ruby on Rails хватает средств чтобы писать асинхронные событийные приложения.
2) для нагруженных сервисов действительно асинхронно-событийная архитектура является на данный момент преобладающей, однако не стоит забывать, что в интернетах до сих пор значительная часть корпоративных, рекламных, справочных и т.п. сайтов, которым она просто-напросто не нужна.
3) не забывайте, что LAMP = Linux + Apache + Mysql + PHP. если не говорить конкретно о наборе программного обеспечения, то LAMP наоборот сейчас является преобладающим. даже облака для хостинга сервисов сейчас используются либо как один из элементов инфраструктуры, либо только среди сервисов средней весовой категории, ибо аренда сервера пока ещё дешевле и гибче для мелких сервисов, а крупные могут себе позволить датацентры, всё с теми же LAMP.
Висит несколько сайтов, в основном магазины, на нодовском expressjs. Аптайм — полгода, не протекло ни капли, летает все отлично. Технология молодая, но уже не сырая. Модули добавляются и правятся постоянно, на гитхабе многие топовые пользователи — именно нодовские контрибьюторы.
Использовать node.js имеет смысл для укрощения кода. Например, модель может хранить своё состояние в себе, а не быть очередной прослойкой для базы данных, перезагружая себя с каждым клиентом.
Что тут понимать, вы сами ответили на свой вопрос в первом комменте — я как раз frontend разработчик, так что nodejs + mongodb это мое все :) По поводу стабильности — plurk давно уже запустил свои realtime чаты на ноде, потом трезвонили на весь свет как все быстро летает, по тыщам блогов разошлось. В итоге вроде бы через год поменяли технологию, не подошла она чем-то. Хоть это и дела давно минувших, но даже сейчас не посоветовал бы запускать что-то нагруженное в продакшн на ноде. Но для быстрых проектов для разработчиков с фронтенд бекграундом — nodejs + expressjs + mongodb очень советую.
ну мы вот пишем специализированные финансовые сервисы — там ситуация простоя в секунду или задержка в 500 мс уже трагедия — и работает месяцами, не течет и не требует особо специфичных навыков разработчика
А мочему бы и нет? Ну не на ноде, на Ruby/jRuby + EventMachine, ну или Erlang OTP, Java NIO, почему вы считаете, что использовать эти инструменты можно только при хайлоаде?
для небольших быстрых сервисов очень удобен. а на нестабильность — есть bluepill/monit/god.
Хотя последний ужасный случай падения продакшена при пиковых нагрузках у нас произошел на Erlang (кролег). beam.smp сожрал всю память в самый неудобный момент.
До этого такого не приключалось, не сразу разобрались. Ну кто могу подумать, когда в обычном режиме кролик кушает 0.3% CPU и 3% памяти в пике.
Хотя последний ужасный случай падения продакшена при пиковых нагрузках у нас произошел на Erlang (кролег). beam.smp сожрал всю память в самый неудобный момент.
До этого такого не приключалось, не сразу разобрались. Ну кто могу подумать, когда в обычном режиме кролик кушает 0.3% CPU и 3% памяти в пике.
Господи, успокойтесь. 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.
Пожалуйста, разбавьте свои слова хоть какими-то фактами.
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.
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.
Автор переписал приложение с Django на Node.js потому что LAMP мертв? В огороде бузина а в Киеве дядька. Типа на LAMP не работает ajax. Данные прекрасно доставляются на клиент в любом современном фреймворке, REST архитектура раздаст все красиво в любом формате хоть в Django, хоть в ROR, хоть в нодовском Expressjs. В Node.js такие же возможности доставки данных как в PHP.
Не согласен. Нет, хорошо, что node,js построен на событиях, но писать в таком стиле:
жутко неудобно. Идеальным мне кажется решением Python + gevent. Вы продолжаете писать в синхронном стиле, а все возможные сокеты и подобное делается в асинхронном стиле за вас.
getSomeData(function() {
getMoreData(function() {
getEvenMoreData(function() {
// ...
});
});
})
жутко неудобно. Идеальным мне кажется решением Python + gevent. Вы продолжаете писать в синхронном стиле, а все возможные сокеты и подобное делается в асинхронном стиле за вас.
Пачка статей на хабре пролетала как работать красиво с вложенными коллбеками. Есть туча модулей с разными подходами на любой вкус. Это уже теперь не проблема, у nodejs есть другие проблемы, похуже. Например падение всего nodejs сервера при неотловленном исключении в любом коллбеке.
Дайте угадаю, чиниться одной строчкой кода?
Для не отловленных исключений есть uncaughtException. Или вы о чем-то другом?
Мне поблема видится в другом. Вот произошло исключение неизвестно где. Мы даже его отловили в этом uncaughtException. А дальше что? Генерация страницы прервется, а ответ об ошибке отдать будет некому. Пользователь отвалится только по таймауту.
Мне поблема видится в другом. Вот произошло исключение неизвестно где. Мы даже его отловили в этом uncaughtException. А дальше что? Генерация страницы прервется, а ответ об ошибке отдать будет некому. Пользователь отвалится только по таймауту.
Что там у нас еще мертво? Радио, газеты, журналы, театр, игры под PC, бумажные книги, обычные сигареты, оффлайн магазины. Вроде всё упомянул?
Я не фанат стека LAMP но если честно из статьи не понял почему он мертв. Кто мешает организовать поток событий на таком стеке? Чем это противоречит Node.js? LAMP это же просто стек технологий для трехзвенки. Кто из них мертв? Линкс — не думаю. Аапч — нет. MySQL — есть альтернатива postgre но они примерно равнозначны. PHP — ну да это довольно старая технология но вроде как вполне живая.
>Кто мешает организовать поток событий на таком стеке?
6000 висячих соединений
6000 висячих соединений
Я думаю что HTML 5 и web sockets должны снизить остроту проблемы. Ну если еще нет, то думаю скоро и для PHP должны появится движки по типу Явской атмосферы.
Apache вроде о поддержке WebSocket или ещё какой push технологии не заявлял.
А куда он нафиг денется если в браузерах начнут поддерживать?
вот что говорит гугл
вот что говорит гугл
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.
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.
Это все отлично, но скажите мне кто развивает этот Javascript? Сам язык застрял где-то в 90-х, есть конечно фреймворки и хорошие, но как-то не вериться в благое будущее языка без динамичного развития его базы. Писать на нем действительно большие приложения в разы сложнее, чем на той же JAVA или C#, которые активно развиваются, и не только сообществом.
Ну LAMP мертв это круто, по хабровский, сколько сейчас про себя подумали — «да, да это отстой. Node.js это реально круто, давайте все перепишем и наконец-то все заработает как надо!
Ну LAMP мертв это круто, по хабровский, сколько сейчас про себя подумали — «да, да это отстой. Node.js это реально круто, давайте все перепишем и наконец-то все заработает как надо!
5 версий за 14 лет я считаю неплохой результат
например для Си всего 3 версии стандарта (C89, C90. C99), а ему 33 года. А для плюсов вообще только парочка.
Так что нединамичнось развития языка трудно приписать ECMAScript'у.
например для Си всего 3 версии стандарта (C89, C90. C99), а ему 33 года. А для плюсов вообще только парочка.
Так что нединамичнось развития языка трудно приписать ECMAScript'у.
При этом, даже примерно прикинув, у плюсов БАЗОВЫЙ функционал, в сотни раз богаче. Кол-во версии стандарта не говорит ровным счетом ни о чем.
то вы говорите про развитие языка, а теперь уже про базовый функционал.
динамичность языка измеряется частотой выхода стандартов, базовый функционал — архитектурой языка.
динамичность языка измеряется частотой выхода стандартов, базовый функционал — архитектурой языка.
ФВП, замыкания и prototype-based OO в С++ уже появились?
В С++ на все вопросы о языке есть один ответ. Boost.
Лямды? Boost. Замыкания? Boost. Обобщенное программирование? Boost. И так любые вопросы.
Лямды? Boost. Замыкания? Boost. Обобщенное программирование? Boost. И так любые вопросы.
А как начиналось-то! Базовый функционал, то сё. Как только задаешь вопрос — сразу Boost :-\
Boost как бы теоретически хорош. Но — не нужен :) Это — яркий пример того, как можно изнасиловать себя и язык до любых форм, но так, что никто никогда в жизни не поймет, как оно работает, что с этим делать, и как дождаться, пока оно скомпилится ;)
Ну и да.
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);
Ну и т.п.
В том-то и дело, что сначала для Си 3 версии, потом С++ парочка, потом C#. Там принято не версии менять, а названия с каждой новой версией другое придумывать:)
> и переписать все с нуля
Такое должно зарезаться сверху на корню.
Такое должно зарезаться сверху на корню.
Использую EventMachine в связке с thin, можно, спокойно реализовать асинхронное, событийно ореинтированное web приложение и в RoR. Дело тут не в node.js, это все го лишь фреймворк, одно из сотен решений одной задачи
Меня умиляет, как 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 — прикольная штука, но… автор статьи просто не очень в курсе, что есть что-то другое. Мне его жаль. И переводчика тоже жаль, куча потраченного времени на бессмысленный перевод.
В 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 — прикольная штука, но… автор статьи просто не очень в курсе, что есть что-то другое. Мне его жаль. И переводчика тоже жаль, куча потраченного времени на бессмысленный перевод.
В PHP есть phpdaemon ;) И фреймворки, поддерживающие REST из коробки тоже.
Вот вам хорошая клиентская библиотека для REST: github.com/benpickles/js-model
Спасибо, я видел ее и даже переписывался с автором. Она мне больше всех понравилась, кстати.
Но… есть в ней маленькая проблемка. Нельзя выбрать запись по id. То есть если я хочу выбрать все записи (посты, например), то идет запрос на /posts.json (что верно). А если мне нужен первый, логично было бы посылать запрос на /posts/1.json (исходя из того, что это REST), а запрос все равно идет на /posts.json, выбираются все записи и потом мне отдается только одна запись.
Мне кажется, это немного неправильно
Но… есть в ней маленькая проблемка. Нельзя выбрать запись по id. То есть если я хочу выбрать все записи (посты, например), то идет запрос на /posts.json (что верно). А если мне нужен первый, логично было бы посылать запрос на /posts/1.json (исходя из того, что это REST), а запрос все равно идет на /posts.json, выбираются все записи и потом мне отдается только одна запись.
Мне кажется, это немного неправильно
>Но когда объем кода JavaScript в наших серверных шаблонах переваливает за 90%, становится ясно — мы делаем всё неправильно.
Весьма сомнительная мысль, по-моему. Как код в шаблонах может означать, что всё неправильно? Эти 90% в любом (почти) случае запрашивают данные через HTTP, а кто им их выдаст — LAMP, Node.js или это будут статические страницы клиентскому коду без разницы. Да, какой-то профит можно поиметь за счёт отсутствия необходимости дублировать одну и ту же логику на разных языках, ещё меньший за счёт того, что JSON будет родным и для сервера, и для клиента, а остальное…
HTTP в принципе синхронный, асинхронные его расширения типа WebSocket не поддерживаются большинством популярных браузеров «из коробки», да ещё ограничения на количество одновременных соединений. В чём практическая польза асинхронности на стороне и сервера, и клиента, когда между ними лежит синхронный протокол, по-моему, далеко не очевидно с точки зрения архитектуры распределенного между сервером и клиентом приложения.
Весьма сомнительная мысль, по-моему. Как код в шаблонах может означать, что всё неправильно? Эти 90% в любом (почти) случае запрашивают данные через HTTP, а кто им их выдаст — LAMP, Node.js или это будут статические страницы клиентскому коду без разницы. Да, какой-то профит можно поиметь за счёт отсутствия необходимости дублировать одну и ту же логику на разных языках, ещё меньший за счёт того, что JSON будет родным и для сервера, и для клиента, а остальное…
HTTP в принципе синхронный, асинхронные его расширения типа WebSocket не поддерживаются большинством популярных браузеров «из коробки», да ещё ограничения на количество одновременных соединений. В чём практическая польза асинхронности на стороне и сервера, и клиента, когда между ними лежит синхронный протокол, по-моему, далеко не очевидно с точки зрения архитектуры распределенного между сервером и клиентом приложения.
Всякие Sammy.js и прочие модные фреймворки позволяют хранить шаблоны на клиенте (отрисовывать, точнее, на клиенте). То есть с сервера изначально приходит пачка скриптов, стилей и что-нибудь еще, а потом уже идет общение с сервером только json'ом.
Я сейчас с подобным играюсь, но… Вот Ноду хвалят за то, что типа везде один язык. Ну вот знаю я руби/рельсы, знаю js на уровне работы с DOM в jQuery, попытался сделать КРАСИВО и БЕЗ КОСТЫЛЕЙ такую работу, и хрен! Все недоразвитое, везде нужно писать кучу кода, чтобы что-то начало работать (после рельсов, знаете ли, непривычно!).
Я не считаю это какой-то революцией. Но я не против ноды в принципе, я просто ТАКОГО СИЛЬНОГО продвижения, типа прямо спасет мир и все такое. Мир не катится в пропасть, как многим бы хотелось.
Я сейчас с подобным играюсь, но… Вот Ноду хвалят за то, что типа везде один язык. Ну вот знаю я руби/рельсы, знаю js на уровне работы с DOM в jQuery, попытался сделать КРАСИВО и БЕЗ КОСТЫЛЕЙ такую работу, и хрен! Все недоразвитое, везде нужно писать кучу кода, чтобы что-то начало работать (после рельсов, знаете ли, непривычно!).
Я не считаю это какой-то революцией. Но я не против ноды в принципе, я просто ТАКОГО СИЛЬНОГО продвижения, типа прямо спасет мир и все такое. Мир не катится в пропасть, как многим бы хотелось.
Я не говорю, что node-js — это плохо. Это очень хорошо! Но вот да, слишком много шума. И вот бесит это «все знают javascript». Далеко не каждый знаток руби станет сходу «въедет» в рельсы. Я неплохо знал php, но так и не разобрался с Zend'ом, сбежал в рельсы. Так же и тут: это совсем разные джаваскрипты, блин)
Кстати да, затрудняюсь что писать в резюме о JavaScript: с одной стороны сделать «выпадающее меню» или валидацию какую могу, пару фреймворков могу использовать для «красивостей» или автодополнений, то есть синтаксис более-менее знаю, но вот писать JS приложение не возьмусь, по крайне мере без большого запаса по времени, лучше предложу Java-апплет — синтаксис знаю чуть похуже, зато привычная императивщина.
ИМХО JSG основы семантики описывает достаточно неплохо.
Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем server-side JS и node.js, ведь мы уже знаем JS.
Да, все верно!
У меня складывается сильнейшее впечатление, что минимум 70% прочитавших пост не поняло, что это ирония.
Для тех, для которых <, есть github.com/basho/erlang_js. Просто в целом Erlang >> JS. По причинам, изложеным выше.
а чем этот node.js крут, чтобы списывать php в утиль?
Просто модная штука от google. Из статьи для себя совершенно ничего не вынес. Просто какое то мнение, с которым я не согласен. 0 Обоснований, просто мнение. Почему мертв? Чем так хорош node.js? Почему это же нельзя было сделать в Django, RoR и ...? В общем, такие статьи в топку…
Это так важно? Основана все равно на технологиях от google.
Какие там, простите, ТЕХНОЛОГИИ ОТ GOOGLE? Чукча не читатель, чукча писатель?
Я могу только сказать что есть v8, к которому только гугл прикладывается, и всего. Но это только фундамент, и легко в теории заменяемый. Весь стек технологий к гуглу не имеет отношения вообще никак.
Я могу только сказать что есть v8, к которому только гугл прикладывается, и всего. Но это только фундамент, и легко в теории заменяемый. Весь стек технологий к гуглу не имеет отношения вообще никак.
может тем что совершенно разные ниши занимают эти 2 продукта?
он быстрее по своей «не блокируемой» природе. Ровно такая же природа частично реализована в phpDaemon, за исключением того что в пхп нет асинхронных операций «нижнего» уровня.
Кстати, почему он быстрее для обычных «статических» страниц я так и не понял. Если, грубо говоря, формирование страницы состоит из трёх фаз (подготовка запроса к БД, запрос к БД, шаблонизация результатов запроса) по 100мс, то никак быстрее 300мс клиент ответ же не получит, пока каждая из фаз не отработает? Если узкое место БД (допустим запрос 300 мс выполняется), то будем иметь 100500 запросов ожидающих ответа от БД вместо 100500 запросов ожидающих подготовки запроса к БД.
Он имеет асинхронный/событийный ввод-вывод. Пока ваш скрипт, например, на PHP ждет когда же ему ответит MySQL Node.js в этой ситуации обрабатывает другой запрос — не ждет как PHP. I/O самая медленная операция поэтому прирост огромный.
Ну вообще-то I/O в память быстрей, чем в сеть.
А если у нас висит база и нет кеширования, хоть дважды ноджс приделай — не поможет.
В смысле, на большинстве сайтов узкое место — вовсе не тормозной LAMP. И зачем переписывать весь код чтобы получить пару процентов выигрыша?
А если у нас висит база и нет кеширования, хоть дважды ноджс приделай — не поможет.
В смысле, на большинстве сайтов узкое место — вовсе не тормозной LAMP. И зачем переписывать весь код чтобы получить пару процентов выигрыша?
Node.js в этой ситуации начнёт обрабатывать другой запрос (если вообще другой запрос в это время есть) — завершить он его сможет только когда отработается первый. Скорость N-го обработки запроса не может быть больше, чем скорость N-го запроса к БД. Некоторый выигрыш можно получить за счёт выноса БД на отдельный сервер, но сомневаюсь, что он будет огромным, по крайней мере для задач, где обращение к БД занимают бОльшую долю времени обработки запроса в целом.
если уж утрировать и делить по этой схеме:
1. в эту эпоху инет можно было делать «из говна и палок», сайты были простые, их было мало, интерактивности никакой.
2. в эту эпоху появились сотни, тысячи фреймворков, стандартов шаблонов, серверных примочек и IDE, чтоб всё это красиво оформлять. потому
3. эра javascript в ближайшее время не наступит, просто потому что:
— это не стандарт и трудно найти разработчиков
— разработчикам трудно переучиваться т.к. нет фреймворков
— зачем писать фреймворки, если это не стандарт и завтра твое творение могут выкинуть в помойку?
— зачем выбирать javascript, если на нём никто не пишет? вот есть многофункциональная, удобная и красивая scala. но она никогда не вытеснит java, потому что за java — инфраструктура и имя ей легион а за scala — пара этнузиастов.
автор путает развитие компьютеров до ~2000 и после. до 2000 года не было никаких стандартов, можно было менять API, целые языки, операционные системы и даже платформы раз в квартал и особо не страдать при этом. господам учёным и паре энтузиастов даже было в прикол разнообразить суровые будни веселыми сетапами-ресетапами.
с повсеместной компьютеризацией всё устаканилось и 80% времени отнимает соблюдение стандартов и поддержка обратной совместимости. и совместимости не только с кодом, а и с огромной арминей специалистов, которые будут эти продукты обслуживать.
1. в эту эпоху инет можно было делать «из говна и палок», сайты были простые, их было мало, интерактивности никакой.
2. в эту эпоху появились сотни, тысячи фреймворков, стандартов шаблонов, серверных примочек и IDE, чтоб всё это красиво оформлять. потому
3. эра javascript в ближайшее время не наступит, просто потому что:
— это не стандарт и трудно найти разработчиков
— разработчикам трудно переучиваться т.к. нет фреймворков
— зачем писать фреймворки, если это не стандарт и завтра твое творение могут выкинуть в помойку?
— зачем выбирать javascript, если на нём никто не пишет? вот есть многофункциональная, удобная и красивая scala. но она никогда не вытеснит java, потому что за java — инфраструктура и имя ей легион а за scala — пара этнузиастов.
автор путает развитие компьютеров до ~2000 и после. до 2000 года не было никаких стандартов, можно было менять API, целые языки, операционные системы и даже платформы раз в квартал и особо не страдать при этом. господам учёным и паре энтузиастов даже было в прикол разнообразить суровые будни веселыми сетапами-ресетапами.
с повсеместной компьютеризацией всё устаканилось и 80% времени отнимает соблюдение стандартов и поддержка обратной совместимости. и совместимости не только с кодом, а и с огромной арминей специалистов, которые будут эти продукты обслуживать.
Прочитал топик и заинтересовался Node.js. Посмотрел видео с гугла с разработчиком — интерес усилился.
Нашел сравнение Node.js с Erlang. Рассказывается и о технологиях, и о истории, и даже есть результаты авторского тестирования с выводами. Вроде небыло на хабре. На топик-ссылку не хватает кармы.
Нашел сравнение Node.js с Erlang. Рассказывается и о технологиях, и о истории, и даже есть результаты авторского тестирования с выводами. Вроде небыло на хабре. На топик-ссылку не хватает кармы.
Одна из интересных ссылок, который косвенно показывает интересность ноды — это список модулей, которые работают с ним:
Просто прокрутите до конца github.com/joyent/node/wiki/modules
Просто прокрутите до конца github.com/joyent/node/wiki/modules
Статья та в фпрог отстой, потому как сравнивает письку с пальцем. Краткое резюме — habrahabr.ru/blogs/nodejs/117887/#comment_3842098. Ещё короче, в трёх словах — уделите время Erlang.
>>> Архитектура LAMP мертва потому что мало кому сейчас хочется отправлять тонны HTML-разметки в ответ на каждое движение пользователя.
Теплое более теплое, чем мягкое. Поэтому мягкое твердое.
Автор явно не дружит с технологиями. Гонять HTML можно кусочками. А вот генерировать HTML на стороне клиента — еще та проблема. Работать со строками на уровне сервера гораздо удобнее и менее трудозатратно чем генерировать разметку на стороне клиента.
Теплое более теплое, чем мягкое. Поэтому мягкое твердое.
Автор явно не дружит с технологиями. Гонять HTML можно кусочками. А вот генерировать HTML на стороне клиента — еще та проблема. Работать со строками на уровне сервера гораздо удобнее и менее трудозатратно чем генерировать разметку на стороне клиента.
Чего-то в этом не так ))) На данный момент HTML мертв => индексировать никак => Google мертв… Протрите мне глаза, но я этого не вижу
Все в жизни меняется бешенными темпами. Возможно в будущем php будет работать по принципу node.js и будет иметь не меньшую производительность. Как сейчас mysql уже можно использовать в качестве NoSQL. Раньше все писали, что XSLT — это разметка, которой будут пользоваться все. Где она сейчас?
Там, где она удобнее всего.
Я Яндексе и в ЮМИ.ЦМС. Но хотя да, для большинства Web-приложений JSON и HAML намного удобнее, чем XML-основанные протоколы. Ибо легковеснее и эффективнее, и проще в понимании и использовании.
Удобнее в каком плане? В использовании? В разработке? В масштабируемости? Без иронии, реально интересует мнение.
Читабельнее, удобнее получить элемент. Грубо говоря в php из json создается объект и погнал по ключам, а в xml нужно какой-то либой его разбирать) Я юзал и то и то и json — удобнее.
Уж добыть либу не проблема — больше проблема в том, что сам xslt тяжёловат для чтения (не первичного понимания!) его в большом кол-ве, а на клиенте еще и довольно ограничен.
Либу то добыть не проблема, а вот удобную либу. Например, на php я еще не нашёл ни одной достаточно удобной.
А чем стандартная неудобна?
Достаточно удобной для чего? Задачи какие надо решать?
из последнего — распарпсить ррс-фид во внутреннее представление программы. ррс-фид может быть на xml или json. что-то типа яндекс.маркета. Короче, часть с json получилась намного приятнее.
Не вижу разницы между $arr['items']['item'][0] и $xml->items->item.
Какие-то у вас странные примеры. Начнём с того, что в json нету идиотского дублирования названий в массивах, когда надо делать тег , а в нём — .
В json получение первого элемента массива items будет выглядеть красиво и понятно(не так, как вы написали):
Вы предложили simpleXML, на его примере рассмотрим:
То, что вы предложили на счёт $xml вообще имеет мало смысла. В SimpleXMLElement я вообще не вижу возможности получить тег через гетер (хотя через foreach его можно итерировать). Также, я не вижу вменяемой возможности определить, что это массив значений (на примере магазина — перечисление цветов, или на примере туристической фирмы — перечисление опорных точек путешествия), мне надо явно указывать это. Если
Вторая запись показывает одну из родовых проблем xml.
В 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.
Во-вторых, json более близок к внутреннему представлению программы.
В xml есть атрибуты тега и дети, в то же время в моих объектах это разделение нафиг не нужно. JSON проще и излишние усложнения xml просто не нужны.
В xml есть атрибуты тега и дети, в то же время в моих объектах это разделение нафиг не нужно. JSON проще и излишние усложнения xml просто не нужны.
Не вижу никакой принципиальной разницы между ассоциативным массивом и объектом SimpleXML, и то и другое близко к внутреннему представлению программы.
JSON лучше при передаче данных, потому что гоняется меньше этих самых данных. Но на стороне сервера я бы три раза еще подумал, прежде чем использовал json
Смертельный аргумен: $xml->xpath("/a/b/c") :)
JSON лучше при передаче данных, потому что гоняется меньше этих самых данных. Но на стороне сервера я бы три раза еще подумал, прежде чем использовал json
Смертельный аргумен: $xml->xpath("/a/b/c") :)
Без дублирования так без дублирования.
Никто не мешает вам убрать дополнительный контейнер, и итерировать вот так
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 это не имеет никакого отношения.
Никто не мешает вам убрать дополнительный контейнер, и итерировать вот так
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 это не имеет никакого отношения.
В php есть simpleXML. Загнал контент, и погнал по полям. Плюс есть xpath, плюс легко (относительно конечно) можно использовать xslt.
К слову, в банках XML и SOAP — знакомые слова. JSON — к таким не относится.
Я не хочу выпячивать одну технологию или уменьшать плюсы второй, но пока что мне видится один плюс XML — его легче изучать людям, даже далеким от программирования.
Каждой технологии — свое место. Удивительно, но в нашем проекте используется и json, и xml, и xslt, и soap, и большой еще зоопарк решений.
К слову, в банках XML и SOAP — знакомые слова. JSON — к таким не относится.
Я не хочу выпячивать одну технологию или уменьшать плюсы второй, но пока что мне видится один плюс XML — его легче изучать людям, даже далеким от программирования.
Каждой технологии — свое место. Удивительно, но в нашем проекте используется и json, и xml, и xslt, и soap, и большой еще зоопарк решений.
simpleXML и использовал. Неудобно.
В банках много чего знакомо. Им еще фортран знаком и кобол, а питон — врядли.
Ох и заблуждение)
Просто вы больше любите xml, потому вам кажется, что люди его лучше понимают ;) у меня вот другая практика. xml для людей — ад.
В банках много чего знакомо. Им еще фортран знаком и кобол, а питон — врядли.
но пока что мне видится один плюс XML — его легче изучать людям, даже далеким от программирования.
Ох и заблуждение)
items: [
'first',
'second',
'third'
]
// vs
<items>
<item>first</item>
<item>second</item>
<item>third</item>
</items>
Просто вы больше любите xml, потому вам кажется, что люди его лучше понимают ;) у меня вот другая практика. xml для людей — ад.
Приведенный пример не репрезентативен.
И дело не в моей любви к xml, дело в совершенно разном восприятии программистов и непрограммистов. Программист при желании может и бинарные файлы без проблем «читать» :). Обычные люди на такое смотрят как проявление инопланетных способностей и носитель подлежит немедленному уничтожению.
По моему опыту общения с разными людьми разных профессий и уровня познаний, быстрее у них получалось разобраться именно с XML, может еще и потому, что у людей уже были изначальные знания.
И дело не в моей любви к xml, дело в совершенно разном восприятии программистов и непрограммистов. Программист при желании может и бинарные файлы без проблем «читать» :). Обычные люди на такое смотрят как проявление инопланетных способностей и носитель подлежит немедленному уничтожению.
По моему опыту общения с разными людьми разных профессий и уровня познаний, быстрее у них получалось разобраться именно с XML, может еще и потому, что у людей уже были изначальные знания.
По моему опыту общения с разными людьми разных профессий и уровня познаний, быстрее у них получалось разобраться именно с 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>
А запятую поставить, думаете додумаются?
А почему тут в одном месте {}, а в другом []? А зачем firstName в кавычках написано? А чего вы в одном месте в кавычках пишете, а в другом — без?
А почему тут в одном месте {}, а в другом []? А зачем firstName в кавычках написано? А чего вы в одном месте в кавычках пишете, а в другом — без?
Хех, если говорить о человекочитаемости, то лучше, имхо, выглядит YAML:
person:
firstName: Иван
lastName: Иванов
address:
streetAddress: Московское ш., 101, кв.101
city: Ленинград
postalCode: 101101
phoneNumbers:
- 812 123-1234
- 916 123-4567
В банках и прочем entrpise xml вовсе не за то ценится. а за то что вокруг xml сидит. Схемы, валидаторы, генераторы. Т.е. все то что в первую очередь требуется для автоматизации и надежности. Читабельность тут самый последний аргумент.
Читать простыни данных с кучей мусора в виде тегов. увольте. Читабельными остаются только самые травильные документы.
Читать простыни данных с кучей мусора в виде тегов. увольте. Читабельными остаются только самые травильные документы.
Авторы — отвратительные тролли, а если и не тролли, то неучи.
Освоили одну технологию и теперь «за ней будущее».
Освоили одну технологию и теперь «за ней будущее».
На искуственных тестах они оба в сотню раз медленнее, чем C++, то вы задолбетесь, прежде чем напишите веб-приложение на c++ и оно врядли у вас получится таким же быстрым, как на на node.js, без годов оптимизаций и тестов.
Простите, может я не понял, мы говорим о веб-программировании на С++?
У node.js круче сборка мусора + то, что выше назвали, но я не думаю, что различие в скорости будет даже на порядок. Значительно меньше.
У node.js круче сборка мусора + то, что выше назвали, но я не думаю, что различие в скорости будет даже на порядок. Значительно меньше.
Апач без nginx-а? Тогда может даже на 2 порядка )
Апач и nginx — это серверы, php и node.js — интерпретаторы языков. Какая связь-то?
Наверное можно назвать низкоуровневым фреймворком для сетевых приложений, на базе которого можно построить и веб-приложения начиная собственно с веб-сервера., а в более высокоуровневых фреммйворках часть работы уже сделана.
Начнем с того, что V8 не интерпретатор, а компилятор. А node.js это что-то наподобие базовой библиотеки.
>Благодаря JIT-компиляции
> трудно провести границу между компилятором и интерпретатором
> JIT-компиляции
> компиляции
Сами же ответили. V8 не может быть интерпретатором, потому, что он компилирует js в машинный код, в то время как интерпретатор интерпретирует фаил построчно. JIT-компиляция это конечно не AOT, но все же компиляция.
> трудно провести границу между компилятором и интерпретатором
> JIT-компиляции
> компиляции
Сами же ответили. V8 не может быть интерпретатором, потому, что он компилирует js в машинный код, в то время как интерпретатор интерпретирует фаил построчно. JIT-компиляция это конечно не AOT, но все же компиляция.
Я, может, зря написал про nginx, хотя без него апач будет дольше работать в реальном примере, а не какой-дь совсем синтетике, но вы вообще какой-то бред пишете.
Заходим на nodejs.org/ и во первых строках сайта видим:
An example of a web server written in Node which responds with «Hello World» for every request.
Т.е. для node.js не используется веб-сервер! А php без вёб-сервера — почти ничто. Можно, наверное, на голом пхп его написать, но это будет ад, угар, трэш и содомия.
И для закрепления материала упрощённая табличка:
* сепциально для хомячков, которые минусуют, не думая: сам «интерпретатор» пхп тоже называется zend.
Да, V8 фактически является частью ноды. Поэтому и упрощённая.
И да, я бы тоже называл node.js фреймворком. microsoft же называется свой .net run-time enivroment фреймворком.
Заходим на 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 фреймворком.
>А php без вёб-сервера — почти ничто. Можно, наверное, на голом пхп его написать, но это будет ад, угар, трэш и содомия.
Всё уже написано до нас
Идеологических отличий от Node возможно не так уж много.
Всё уже написано до нас
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 возможно не так уж много.
Заходим на nodejs.org и во первых строках сайта видим:Т.е. вы отождествляете пример сервера, написанный на Node и саму Node?
An example of a web server written in Node
Т.е. для node.js не используется веб-сервер!Клево! А кто картинки отдавать будет? Ну, к примеру вы напишете сервер с помошью той же Node, который картинки отдает. Тоже будете говорить, что он равен Node?
И php давно уже можно без apache пускать, тоже в виде сервера приложений, в fastcgi. А проекты на Django можно запустить по полдюжине протоколов.
Мне кажется логичным отделять сервера приложений на Node, PHP и Django от веб-серверов apache и nginx, смотрящих наружу.
Учитывая, что он пишется проще, чем конфигурируется апач — да.
Про картинки — да, я именно это и имел ввиду. Что даже если мы картинки будем «вручную» отдавать через node.js — это может оказаться быстрей, чем связка apache+php без nginx.
А мне кажется логичным не ставить в один ряд Node.js, Django и PHP, если уж хочется быть последовательным и формальным.
Ладно, это бессмысленный спор о формализме.
Про картинки — да, я именно это и имел ввиду. Что даже если мы картинки будем «вручную» отдавать через node.js — это может оказаться быстрей, чем связка apache+php без nginx.
А мне кажется логичным не ставить в один ряд Node.js, Django и PHP, если уж хочется быть последовательным и формальным.
Ладно, это бессмысленный спор о формализме.
Думается мне, что просто уже много лет веб уходит от ультра-тонкого клиента в сторону клиента более толстого, без всяких там «эр». И флэш был первой весточкой ещё в начале 2000х. То же мне, «эра LAMP», блин :)
Архитектура LAMP мертва потому что мало кому сейчас хочется отправлять тонны HTML-разметки в ответ на каждое движение пользователя. Вместо этого лучше обновлять небольшие фрагменты DOM с помощью AJAX.
Серьезно? По-моему в данной статье речь идёт о RIA, а не о веб-сайтах. Вот если бы Интернет был совокупностью RIA, тогда да.
Надо отталкиваться от задачи. Будем честны, для большинства задач веба (веб-сайты а не RIA) асинхронные фреймворки не подходят, хотя для специфичных задач (см. комменты выше) они идеальны.
Также открытым остается вопрос с SEO. Пользуясь терминологией автора, поисковые системы сейчас всё ещё живут в эре «LAMP». Так что для самого раскрутецкого сайта на Node.JS придётся делать вариант для поисковиков?!
/* погружаясь в мечты */ Вот если бы был стандартный интерфейс (наподобие sitemaps) взаимодействия всех поисковых систем с веб-сайтами, и вместо поисковых ботов-парсеров происходил бы обмен данными веб-приложение <-> поисковик по опять таки стандартному протоколу, тогда да. Можно было бы и пренебречь второй версией сайта. Но как говорится, если бы у бабушки был бы ..., это был бы дедушка.
Так что исходим из задач, и подбираем оптимальный инструмент. Не надо пытаться решить одним инструментом все проблемы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Node.js и эра JavaScript