Pull to refresh

Comments 63

В принципе, эти советы подходят ко всем аспектам web-разработки)
Да, выкинуть пару советов (или сделать их более общими), и будут подходить почти ко всем аспектам )
Вот и я также — ожидал что будут написаны советы в духе — используйте json вместо XML для передачи данных — а получил [b]типичные советы для начинающего веб-разработчика[/b].
В принципе эти советы подходят для любой разработки )
Пункт 5 и 6 лишние, не какого отношения к Ajax.
Почему? Мне кажется, что эти два пункта имеют самое непосредственное отношение к Ajax'у. Пусть и не всегда применимы, но тем не менее.
Проверка данных относится к php (ну или кто на чем пишет) на сервере и javascript на клиенте, и то это только для юзабилити, где здесь Ajax?
Ajax = Asynchronous Javascript And XML… слово JavaScript в этой аббривеатуре присутствует
Остальные тоже имеют слабую специфику для аякса. Обычные прописные истины. Американцы их любят.
Пункты 5 и 6 совершенно никогда не лишние ©
Фреймворки, естественно, ускоряют процесс разработки приложения, но зачастую просто необходимо разрабатывать не универсальные системы, а системы «точечные», узкоспециализированные, оптимизированные под конкретную ситуацию. Правда?
Безусловно — если задача точечная — фреймворки только помешают.
для каждой задачи можно подобрать свой фреймверк, не все они массивные, есть и маленькие наработки, по сути фреймверк — основа, а не готовый продукт
планирование — одно из самых важных правил
Причём в любой области, будь то разработка приложения, или поход в кино с девушкой.
Согласен!
Главное не начать планировать как лучше все спланировать)) Как в том фильме.
в каком, кстати, фильме?

Вообще первый этап проекта — планирование. Первая, скажем, фаза планирования — планирование планирования. Так в умных талмудах пишут, на деле, конечно, потом всё сводится к оперативному выходу из штопора, прямо начиная со второго этапа, но идея хорошая.
Однажды в Вегасе, если не ошибаюсь.
неплохо было бы написать ссылочки еще к пару пунктам
Всё что было на Вики — оформил в виде ссылок.
Спасибо!
Внёс в топик.
Да, ссылок там хватает. Дело в том, что по хорошему, надо бы дополнить эти ссылки ссылками на русскоязычные сайты, но время поджимало, так и забыл :(
По-моему, в пункте 4, среди стандартов несколько пунктов лишние.
XML и XHTML например.
Если XHTML и спорный вопрос, то XML отнюдь не лишний.
Наверно таки наоборот ;)
Насчет XML вы погорячились ;-)
absolvo, croatian:
Для аякса, не вижу его преимуществ перед JSON-ом.
Без XML AJAX уже не AJAX, а какой-нить AJAJ…
А, ну, да. Раз уж он так называется, нам ничего не остается, кроме как использовать XML…
Думаю, скорее так исторически сложилось — передавать можно было хоть HTML для вставки сразу в элемент, но всеобщее XML-помешательство тогда было сильно:)
Вот и я о том же. Помешательство и сейчас еще есть, хоть и поменьше.
И XHTML из той же серии «давайте еще куда нибудь ввернем xml, это же так круто!».
Хм, хоть это и из другой оперы, но для меня теги в стиле
это такой же анахронизм, как и … Поэтому из HTML и XHTML я выбираю последнее:)
Или я, или парсер чего-то недопоняли. =)
XHTML нужен хотя бы для XSL преобразований, чтобы из XML получить веб-страницу.
Ну это вынужденный XHTML. Не развалидировать же его!

XSL — инструмент для преобразования любого XML в любой XML. В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто». А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.

Вам не кажется, что в этой логике есть какой-то изъян? =)
В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто».

Категорические утверждения редко бывают верными.

А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.

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

Например, используя XML я могу получить данные из хранимой процедуры в MS SQL 2005 в виде XML документа, затем применить к полученным данным XSL шаблон и получить XHTML документ, который посылается пользователю. В данном случае, производители БД, серверных библиотек и клиентского браузера поддержили один и тот же стандарт, что позволяет мне делать сложные вещи просто.

Если бы это был бы не XML, а JSON или вообще какой-то бинарный протокол, я бы не возражал, главное чтобы стандарт поддерживался как можно более большим количеством участников IT индустрии.

Разумеется, выбирая что-то в качестве стандарта для широго круга задач, невозможно выбрать что-то, что будет наиболее оптимальным для каждой конкретной задачи. Это может дать возможность говорить, что этот стандарт «плохой», а повсеместное использование стандарта называть «помешательством», как вы изволили написать выше, но я бы обратил внимание, что именно повсеместное использование и делает стандарт стандартом и позволяет единообразно работать с довольно разными системами.
Ловите плюс в карму. Приятно читать грамотные комменты грамотного человека.
В вашем случае, конечно, против XMLа выступать глупо.

Но я же говорил не про ваш случай. Если в нем заменить MS SQL 2005 на «обычный порошок» то вся стройная картина, увы, рушится. Да и редко бывает, что бы результат запроса к БД можно было без дополнительно обработки отправлять в js.

Я же не предлагаю использовать JSON везде и всегда, я предлагаю думать головой (что конкретно вы, по-видимому, и делаете), а не использовать XML везде и всегда. И утверждаю, что для большинства задач, от использования XML нет ни какой пользы, акромя вреда.

Про «помешательство»: стандарт не бывает плохим. Но бывает, что он становится настолько раскрученным, что многие его начинают использовать не для упрощения, а наоборот. И как назвать поведение этих многих?
Про «помешательство» не вы писали, прошу прощения
xslt трансформация на клиенте, явное преимущество
Куда важнее для ajax-разработчика знать, что
1) JS-ссылки должны работать и с выключенным JS.
2) Должна работать кнопка «Назад».
3) Полезный «ajax-контент» не должен быть скрытым для поисковиков.
4) Отображать индикацию процесса.
А то, что в топике — это не про ajax.
ещё
5) кеширование в браузере
6) должна быть озможность востановления состояния по ссылке (очень удобно использовать location.hash)
7) используйте utf
8) обрабатывайте исключения, хотя это частично относится к индикации

последний) не злоупотребляйте ajax
Чтобы мой бэкэнд скрипт не валили обычными пост запросами я в него втыкаю такой код:

if($_SERVER['HTTP_X_REQUESTED_WITH'] != 'XMLHttpRequest') die(«Ай нанэ нан»);

Ну это «защита» от ленивых хакеров. умный всегда найдет)
Что за профессия такая, ajax-разработчик? Я понимаю web или javascript, но ajax… Это типа человек который не знает js, но знает как работает XmlHttpRequest?
Вот справа смотрю на вакансии вижу там PHP-программист, С Developer, python developer.
Почему-то никто не ищет stdio.h-разработчиков или UserString-разработчиков.
AJAX включает в себя не только JavaScript, поэтому тонкости технологии XML, протокола HTTP и ещё разные другие вещи не менее важны, чем непосредственно знание JavaScript. Хотя AJAX-разработчик я тоже редко встречаю, чаще frontend-developer.
XML нужно знать ровно настолько чтобы перестать использовать его без крайней на то необходимости (тот же JSON в большинстве случаев будет удобнее и быстрее). Если уж XML так необходим, то объяснить программисту, что это такое можно за несколько минут. В рамках использования его в ajax — это всего лишь еще один формат хранения данных, не более.
Тонкости HTTP? Большинство сегодняшних «ajax-разработчиков» не смогут на бумаге написать корректный http-запрос, о каких тонкостях может идти речь?
В статье нет ни одного пункта напрямую относящегося к ajax, а названа она так лишь потому, что сейчас модно везде вставлять аяксы и прочие вебдваноли.
Setti все правильно сказал. Можно еще добавить пункт «кэшируйте запросы, которые возможно». Загрузка за секунду отличается от мгновенной.
используйте сжатие, это позволит сократить время работы скрипта

Интересно, как сжатие может сократить время работы скрипта?

Я не совсем корректно выразился, однако фраза:
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных.
Должна вам объяснить, что имелось ввиду.
Ответ от бакэнда в gzip сделать просто, а как произойдет распаковка / обработка его клиентским скриптом? Можно ссылку на описание или рабочий пример?
Смотря что включать в такой показатель, как время работы скрипта:) Если количество занятых процессорных тактов, то да, даже увеличится(ведь надо сжатые данные ещё распаковать), если время от вызова функции до возвращения ею какого-то значения, то(если, конечно, у пользователя не гигабитный интернет), время сократится, ведь данных придётся передавать меньше. В большинстве несложных JavaScript-скриптиков юзающий XmlHttpRequest главный bottleneck есть получение информации от сервера. Если мы сокращаем время получения этих данных за счёт снижения их размера — мы уменьшаем время работы скрипта. И, думаю, накладные расходы на сжатие(дополнительный заголовок HTTP, распаковка и т.д.) действуют только на сверхмалых(считаные байты) размерах. Поэтому, имхо, этот совет очень оправдан.
Повысил бы вам карму, если б мог, но уже когда-то это сделал.
просто вы не умеете его готовить :)
зачем минусовать-то?
Хотел бы добавить «Проверяйте входящие данные».
Лучше устроить двойную проверку валидности данных — на клиентской стороне и на сервере (от любителей FireBug)
Чем Вас пункты 5 и 6 не устраивают?
тока подтвердил статью.
Ну в принципе ничего нового, но за напоминание спасибо =)
Простите, а «с кондачка» — это как?
Only those users with full accounts are able to leave comments. Log in, please.