Pull to refresh

Comments 145

на хабре тенденция минусовать первый коммент??
на хабре традиция первый коммент ("полезно, спасибо!") плюсовать до 24-36, потом через 20 комментариев кто-то говорит "гавно" и еще десяток комментов ниже о том же плюсуют до 5-10. Синусойдо опасносте.
UFO just landed and posted this here
лоджико опасносте
ажякс опасносте
и теперь моя карма тоже... пыщьпыщь кал'айдер в действии!!!""22двадва
вот это суровая правда жизни.
имеется у нас как-то проект один который полностью построен на аяксе, т.е. минимум переходов по страницам (так захотел заказчик). в итоге этот портал просто монстрообразен, код ужасен, куча скриптов совершенно не нужных (если мыслить логически про переходы), и попытка отрыть оный в ИЕ6 его просто вешает.
>делает работу сайта непредсксказуемой и ощутимо затормаживает работу даже на новейших компьютерах
руки. прямые руки, которые не тянутся к фреймворкам и действуют не сами по себе, а центролизовано (от головы)
> Referer is a common misspelling of the word referrer.
Тем не менее, HTTP_REFERER :) Дело не в том как правильно пишется, а в том как в реале пишется.
ну да, в CSS тоже никто colour не пишет
UFO just landed and posted this here
> therefore become the standard industry spelling when discussing HTTP referers.
Вы перепутали с выражением Referral Url
Объект Referer, а свойство document.referrer
Каюсь, перепутал, но зачем минусы-то ставить?(
"К примеру для несложных манипуляций замечательно подойдёт YAML или CSV, а XML будет излишне толстым"
А как же JSON?
JSON, не смотря на все свои прелести - пока мало используем...
Да и чаще всего грузится все таки обычный HTML ... Вот поэтому наверное и забыли указать ....
Статистику покажите. Почему вы думаете, что его используют мало?
JSON мало используем? Ой, кажется, я не в том мире живу.
Я не говорю за всех .. и минусовать - это плохой тон для диалога...
Больше говорить ничего не хочется.. спсб
я тебя не минусовал — в карме твоей вообще плюс стоит

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

Вообщем я про что ... У нас контора разработывает системы Telebank и прочие для проведения финансовых операций через internet... так вот JSON Используется только в одном приложении из многих... Потому что в остальных AJAX отвечает только за доставку контента (функционального в том числе)...
И, я предположу, что в системах где главной задачей AJAX является всего лишь доставка контента чаще всего работают с бональным HTML c примесью скриптов внутри...
Но это всего лишь предположение....
достаточно странно перекидывать большие хтмл-штуки через аякс. я бы (может, я и не прав), придумал бы как формировать из полученных данных хтмл уже на клиенте, загрузив один раз скрипт для формирования
Отработка скрипта по обработке контента на клиенте - особенно на медленной машине может стать проблемой...
Решено было делать просто и быстро...
далеко не всегда. я же не предлагаю на клиенте bbcode перелопачивать, я про то, что если нужно список вывести — дешевле, в т.ч. для обработки, послать массивом. тем более, innerHTML и прочее не рекомендуется

ps: а зачем... эти... троеточия...? :)
Это я думаю так - троеточиями )
Странно, я думаю головой, а не троеточиями.
Многоточие, блин... мно-го-то-чи-е!
Да я-то знаю, что многоточие, но посмотреть профиль randoom ведь говорил о троеточиях.
и кроме того, на стороне клиента можно скины организовать или прочие прелести обработки чистых данных :) Потому JSON, XML, etc предпочтительнее. Хотя, опять же, бывает проще обухом...
а я вот не соглашусь, пожалуй. На сколько помню, innerHTML таки в W3C имеется, более того, он более чем в 3 раза быстрее, чем тот же DOM (смотрим тесты JS DOM vs innerHTML на хабре), этого достаточно, чтобы хотя б рассмотреть возможность его применения для статики.
От задач зависит. Если строим здоровенный SELECT в форме, то тут innerHTML предпочтительней, конечно же. DOM у клиента из такого списка может минуту строиться. :)
списочек - возможно и проще. но чаще вывод более сложный. плюс ко всему - я предпочту поменять шаблон вывода на сервере (особенно если не просто внешний вид сменился, а, например, колонка новая добавилась с данными).
А есть какие-нибудь данные на эту тему?
Я выбрал именно ваш путь решения этой проблемы. В этом случае JSON просто незаменим. Если грамотно составить документ, то, в отличии от XML, его даже не надо разбирать, что бы на основе полученных данных строить HTML. В общем все круто, но меня несколько пугает мысль о том, что прийдется строить достаточно большие документы (сейчас строятся таблицы 10-20 строк).
а что такого страшного-то? :)
жсон по сети передастся быстрее, и распарсится и обработается вряд ли медленнее, чем хмл
Я имел ввиду насколько затратно собирать HTML на клиенте.
Думаю попозже напишу скриптик и посмотрю как сильно построение страничек грузит браузер.
давайте, а результаты бенчмарка покажете :)
и сравните с хмл и прочим ;)
Нене... Я всеми руками за JSON. Я уже писал, что меня в нем привлекает сравнительно малый объем передаваемых данных и возможность исключения предварительно обработки перед использованием.

Мне интересно не убъет ли построение больших страниц браузер. Может в некоторых случаях лучше строить шаблонизатором HTML и просто вставлять его на страницу?
вы gmail видели? :) не убивает же
Gmail очень тяжко грузит офисные целероны ;(
фаерфокс 2, да? ни в третьем, ни в опере не грузит так уж мой старенький комп
Если делать приложения для широкой аудитории, то нужно рассчитывать также на IE, а у него производительность JS, по-моему, самая низкая.
Вы попробуйте на примере больших данных :) Будет интересно
а наша контора перекидывает через аякс готовые штмльные куски только в уникальных случаях.

Json уже года два как нашел прибежище во всех наших либах для аяксовой передачи данных.
json'a меньше чем ямла или цвс?
JSON используется для решения cross domain browser security. Это когда надо послать запрос на скрипт, находящийся на другом домене. Например, при колбеках.
Вообще-то, для этого используется JSONP.
не часть, а реализация, наверное. тем более, в ямле нет комментов /* */ ;) (вроде бы)
http://yaml.org/spec/1.2/#id2560236 третий абзац
все таки часть, потому что там кое чего не хватает, а в ямле не хватает комментов - это факт
ага, спасибо
но все-таки стоило бы как-нибудь жсон в статье отметить :)
Не реализация, а похожий по синтаксису формат.
JSON проще всего, использую только его: на php json_encode(), json_decode(), вот только на JS json_encode пришлось реализовать ручками.
Если кинуть IE в топку, то {foo: "bar"}.toSource() можно использовать вместо самиздата.
Спасибо, правда спасибо... Все знал - но читать было приятно....
Отплюсовал, как говорится )
Мда... и про картинки - если честно не совсем понятен их сокральный смысл )
Интересно было бы почитать про то, есть ли какие-то доступные способы оптимизации страниц с большим количеством аякса для поисковых ботов.
я делал пару сайтов фактически как AJAX приложения и там была задача обеспечения индексации. Надо сказать, что по JS ссылкам не все боты ходить умеют, поэтому делать пришлось немного через заднее место. Был добавлен скрытый фрейм, в котором все ссылки сайта меняли информацию, он ребутился каждый раз и выводил тексты сам в себя, на нем же были скрипты, которые меняли нужные parent.* блоки, чтобы не загружать контент по второму разу, таким образом компромис получился неплохим. Боты в основном индексировали содержимое фрейма, а люди видели копирование контента из этого фрейма в основной шаблон, так как фрейм скрытый, на его рендеринг время на клиенте не тратилось.
так же была побеждена кнопка "Назад", она просто открывала предыдущий фрейм и он автматом обновлял все блоки на предыдущее состояние.
Весьма оригинально организовано. Скину линк на ваш пост своим программерам - пусть курят его) а то они мне предлагали совсем какие-то замороченные методы.
Спасибо.
оригинально? вроде стандартный метод. Его минусы в повышенном потреблении памяти и общей некошерности.

ЗЫ быстрей бы боты научились жс нормально воспринимать :)
я делал так - страница загружается с обычными ссылками, но те ссылки, которые, в случае наличии у клиента работающего яваскрипта, должны грузится c использованием AJAX, имеют rel="ajax" и onload="функция загрузки аяксом". При наступлении события Domready запускается javascript (если он есть) и заменяет ссылки на "javascript:void(0)". По-этому сайт работает как без яваскрипта (читай AJAXа), так и с ним. Проблем с индексацией нет. Правда такой подход не решает проблему кнопки "Назад".
>Так же проверяйте HTTP Referer - ибо это важно
сталкнулся один раз, что у клиента в офисе был как то настроен фаервол, что их браузеры не отправляли HTTP Referer, пришлось Referer руками прописывать у каждой формы в хидден
плохо, потому что то, что написано в форме можно прописать ручками => никакой защитой тут и не пахнет. ну раз других вариантов не было, что ж... Когда без вариантов это - вариант :) Так же, как и куки, впрочем. Ну не суть, передавать рефера через GPC - плохо.

Кстати, можно было заюзать сессии :)
это делалось для админки, так что и через форму было нормально.
AJAX появился благодаря Microsoft, не стоит принижать их роль. Именно они придумали XMLHTTP с которого всё началось.

Так же, рассказывая про AJAX, нельзя не упомянуть JSON, это более к месту, чем YAML.
AJAX появился благодаря толстым каналам. То, что XMLHttpRequest удобен - это правда, но что незаменим - нет. Можно делать динамические сайты с помощью фреймов. Мы такие вещи делали во времена когда поддержка Netscape 4.x была актуальна, а термина AJAX ещё не было. С полноценной модификацией сайтов "на лету" при получении новой информации от сервера и прочим. Не так удобно, да, но и не смертельно сложно.
можно засунуть обе реазилации, через фреймы и XMLHttpRequest в один объект, сделать общий интерфейс и не париться :)
Я тоже делал это фреймами, мой знаменитый чат (стоял, например, у Экслера на сайте) был сделан именно так.

Объясните связь AJAX и толстых каналов. AJAX как раз помогает экономить трафик.
Очень интересно было почитать. Спасибо!
Понравилось то что "браузеры от Microsoft" как-то не так работают с Ajax, учитывая то что в Microsoft его и придумали.
Вообще для начинающего веб-разработчика оч хорошая статья. + вам ;)
Microsoft не придумал AJAX. Microsoft придумал XMLHttpRequest - это сильно не одно и то же.
Тоже верно. Но 1) в статье наверняка и имелся ввиду сам объект (хотя написано Ajax) 2) не будь XMLHttpRequest не было бы и Ajax'а (хотя кто его знает) 3) Microsoft придумала не XMLHttpRequest, а ActiveXObject(Microsoft.XMLHTTP).
В любом случае спасибо за поправку.
не будь XMLHttpRequest - был бы аякс через фреймы :)
Отчасти так - первыми реализацию такого метода сделали в Microsoft, но действительно использовать его стали только через несколько лет. Я думаю, это следствие развития стандартов, в частности, того же DOM. Так что если бы к моменту созревания потребности в AJAX не было XMLHttpRequest, его бы всё равно сделали. :)
Конечно, его стали использовать сразу, а не через несколько лет, это получил распространение он через несколько лет, так как 99% веб-программистов не интересуются возможностями браузеров. Лично я использовал XMLHttpRequest и VML очень давно — ещё когда занимался интранетами (там было возможно сказать «используйте только этот браузер»).
Ну да, я имел в виду "получил распространение".
По-моему он сильно получил распостранение после того, как крупные игроки начали его использовать, а все остальные просто пошли за ними. GMail был, вроде, первым веб-приложением сильно использующим AJAX. нет?
Прости, господи, неужели он блюет в ноутбук?
Не соглашусь что обязательно нужно знать Javascript для использования AJAX. Можно вполне заменить его тем же PHP, есть библиотеки типа Projax которые переводят PHP код в JS.
GWT и прочее безобразие....
Они к сожалению дают перегруженные приложения... которые бонально медленно работают - ибо содержат много лишнего..
Для разработки AJAX приложения в промышленных масштабах обязательно знание JavaScript
Не думаю что простейшее преобразование которое выполняет библиотека ($projax->remove('box') => Element.remove('box')) как-то влияет на скорость. Да и потом, никто не мешает посмотреть потом исходный код страницы и скопировать получившийся JS код - таким образом и Javascript как раз можно выучить :) Я именно так сейчас и делаю.
Неправильно вы делаете, откройте, хотябы, сайт JavaScript Tutorial и прочитайте. Самого языка javascript - раз два и обчелся + DOM немного подтяните, так вы будете знать все изнутри. Откуда вы, например, уверены, что ваш кодогенератор генерирует скрипт самым оптимальным образом?
Вот именно про неоптимальность кода от таких вещей я и говорил....
Я просто говорю о том, что это лучший вариант для человека, коотрый знает PHP, но не знает JS. Лучше использовать такие вот "мосты" и иметь работающий и возможно немного кривой AJAX (хотя я в кривости очень сомневаюсь - prototype js framework настолько четкий и понятный что трудно что-то там сделать криво), чем не иметь его вообще. Не у всех есть время вникать.. Оптимальностью кода можно заняться и потом, первоочередная задача - рабочий проект!
Первоочередная задача в любом проекте - это
1) Корректное проектирование плана работ по проекту с оценкой трудоемкости
2) Привлечение всех необходимых специалистов (Клиентской стороной не должен заниматься PHP-шник)
3) И только потом реализация проекта...

Но, я говорю про коммерческий проект... а если на уровне "Поиграться" - то можно и поиграться... )))
Опять же Google - тоже был забавой )
если проектом занимается один человек - все намного проще :)
Значит все таки Google ;) Стартап тобишь ;)
Клиентской стороной не должен заниматься пхпшник.

В корне согласен. Серверный скрипт, что выдает страничку на выходе изначально имеет иную ориентацию, иной подход, нежели Javascript, выполняющийся на клиентской стороне - у последнего проблема утечки памяти стоит гораздо актуальней, плюс взаимодействие и порядок выполнения асинхронных запросов. Для непривычного человека это может обернуться адом.
Я отвечал на конкретно эту вашу фразу:

таким образом и Javascript как раз можно выучить :) Я именно так сейчас и делаю.
На самом деле, спасибо за ссылку на учебник :) уже кое-что новое для себя там узнал
а во что тут вникать? в синтаксис? Вы же не сможете теже event'ы сначала на php писать, а топом в js конвертить, а если сможете, то точно один синтаксис :)
А еще надо голову подстроить под то, что JS - statefull, PHP - stateless.
Вы уже второй раз пишете, не смог удержаться.

Правильно писать бАнально, если вам уж так нравится это слово :)
Я думал я параноик - а за мной и вправду следят )))
Сайты можно и в Ворде делать, правда же?
Потому, если вы хотите написать грамотное во всех отношения Ajax-приложение, вам придётся писать на JS - по другому никак.
UFO just landed and posted this here
Другим кроссбраузерным вариантом был когда-то IFRAME-лоадер.
Ммм... странная кроссбраузерность - не так много есть браузеров с поддержкой IFRAME и без XMLHttpRequest. Разве что Opera старых версий - но она никогда особенно актуальна не была. А для Netscape 4.x (когда это было актуально) нужно использовать полноценные FRAME...
В одном проекте делали асинхронную загрузку как раз через FRAME (у приложения была фреймовая структура, так что лишний фрейм с нулевым размером никому не мешал). Всё прекрасно работало.
UFO just landed and posted this here
Кроме одного косяка, что в 2000 году флеша было крайне мало на просторах Интернета.
UFO just landed and posted this here
И все таки - это унитаз - или просто у меня что то с фантазией? ;)
Самому интересно. Наверное, зависит от разработчика.
Владельцы ФФ, в предыдущем сообщении вы видете альт от кртинки, криво вставленной с «народа», сорри. Вот прямой линк: http://homm86.narod.ru/files/ajax.jpg
Владельцы Safari только не видят картинку.
Я бы еще 1 совет добавил: Не изобретайте велосипедов. Используйте библиотеки (jQuery, Prototype и др). Они кроссбраузерны, гибкие и удобные
Совет номер два... Не используйте визуалку из библиотек(ExtJS, Backbase и проч.). Делайте свою - а ядро лучше не изобретать.
Потому что они все из себя красявые - но когда вам заказчик скажет - а хочу "красненькую" а визуальный компонент не сможет - придется переписывать половину кода.....
Так они же легко скинуются CSS-ом (по крайней мере, в YUI - ExtJS ещё не смотрел).
Под "красненькой" я имел не только цвет.. а какие нить принципиальные заскоки которые ye просто умереть-не-встать нужны клиенту...
Складывается мнение, что Вы не достаточно хорошо знакомы, допустим, с тем же ExtJS.
В нем созданы БАЗОВЫЕ "классы" интерфейсов. Надо "красненькое" - расширяй, улучшая и дописывай. API открыт. Впрочем, это касается каждого из фреймворков.

Мне дорого мое время, как и большиству здравомыслящих разработчиков.
Может быть... Просто был опыт с BackBase ... не очень удачный....
Никогда не понимал смысла библиотек. Какая разница что учить - библиотеки или сам язык?
Не узнаешь, пока не попробуешь... Мой совет - попробуй
а что в аяксе такого не кроссбраузерного? создание объекта, да баг ие6 с for in для аттрибутов. про гибкость библиотек в плане аякса спорить не буду, но скажу, что в этом плане у них имеется только наработанный материал.
Статья неактуальна. AJAX уже миллион раз обсудили и давно используют.
Советы малоактуальны, т.к. большинство (я так думаю) использует готовые классы или фреймворки, где всё уже итак оптимизировано по максимуму.

Кроме того, я считаю, что использование XML в AJAX-транзакциях в 95% случаях нерационально. По двум причинам:
1) XML сложнее и дольше парсить, чем JSON или YAML. Соответственно, возникает неоправданная нагрузка и на серверный, и на клиентский скрипт.
2) XML больше по объему, что опять же неоправданно.

Стоит XML использовать в реально больших приложениях со сложной логикой работы, что и составляет 5%.

Сам я использую JSON, ибо благодаря Json.Remote в mootools код занимает пару строк =)
UFO just landed and posted this here
Спасибо, буду знать.
Но всё-таки, я уверен, я не сильно ошибся в терминологии.
UFO just landed and posted this here
В принципе, можно последнюю X в аббревиатуре AJAX расшифровать как XHTML - получится то же самое. :)
недавно надо было переписать с флеша на аджакс довольно сложное приложение - (livesupport чат)
мне как php девелоперу джаваскрипт всегда был противен и в 90% случаев вызывал лишь рвотные рефлекс. по'тому перспектива разработки довольно крупного приложения на языке который я не знаю меня естественно совсем не радовала. Но все оказалось намного проще - я посвятил несколько дней на пролистывания джаваскрипт библии, потом взял jQuery, сделал несколько тестовых приложений.. И сегодня могу с уверенностью сказать - аджакс в 90% случаев это легко и просто. на сегодняшний день не нужно изобретать колеса, благодаря доступным фреймворкам работа с аджаксом приносит огромное удоольствие!

(но на обьектную модель в джаваскрипте все так же, хочется блевать)
а я не запаривался с библиотеками, я сидел в чистом жаваскрипте... и о чудо! рвотные рефлексы прошли :)
А чем не нравится объектная модель?
Он по привычке пытается искать классы и интерфейсы среди объектов и прототипов :)
нда, задачка :) особенно если учесть, что в php до 4.3 (я не ошибаюсь?) объекты были абсолютно деревянные.
да конечно :) но времена меняются и в php скоро будет все прекрасно!
Ой нескоро, судя по Changelog из CVS.
да впринципе примитивизм и не понравился. отсутствие статических переменных тоже не понравилось, область видимости тоже первое время не нравилась
JavaScript — чудесный язык! Нужно только «уметь его готовить» )

Сначала сам плевался и считал, что ни на что, кроме простецких скриптов он не способен, потом почитал 38, 39 и 40 статьи куроводства и, спустя пару-тройку скриптов, изменил свое мнение. Это очень своеобразный язык, но вполне симпатичный и удобный в своей своеобразности (ИМХО, конечно. И простите за каламбур).

Фреймворки — это хорошо. Когда понимаешь, что происходит внутри фреймворка и как можно выполнить задачу без него — еще лучше. Для некоторых задач использование фреймворков просто не оправдано.
Ссылка на куроводство: http://dklab.ru/chicken/nablas/
Неужели в 2008м году кто-то все еще не знает, что
Это действительно JavaScript
Sign up to leave a comment.

Articles