AJAX для новичков

ИМХО, книга отлично подходит для новичков. Я сам ее прочитал, не имея малейшего представления о том, что такое Ajax, и после этой книги свободно отправлял и обрабатывал Ajax запросы без использования сторонних фреймворков. Потом на практике стал применять Prototype, т.к. он позволял в разы сократить код.

Jensi, Очень рекомендую, когда-то разбирался именно по это статье

http://www.ibm.com/developerworks/ru/library/wa-ajaxintro1/index.html

http://www.ibm.com/developerworks/ru/library/wa-ajaxintro2/index.html

http://www.ibm.com/developerworks/ru/library/wa-ajaxintro3/index.html

Но JS нужно именно понимать, а не знать... И еще, не опускайтесь до уровня фреймворков, там и так все очень-очень просто

А зачем учить именно AJAX ? почему просто не понять принцип JS и использовать либы (JQuery Prototype), для дальнейшей работы ...... это лучший вариант за короткий срок и понять само JS (точнее самый-самый базис) и уже что-то творить на уровне новичка. (естессно не изобретая велосипед)

bomber, нужно четко представлять, как работает Ajax и в каких местах его стоит использовать, а в каких нет. А использование фреймворков придает удобство написания кода и кроссбраузерность (жаль что не на 100%).

потому что именно от непонимая принципов, появляются желание использовать эти очень кривые (ИМХО для больших поклонников) фреймворки. Если не понимаешь принципов, не стоит заниматься чем либо. Читайте подпись

T.R.O.N, а в чем кривость либ?

Оказалось, что AJAX не так уж и тяжело учить, нужно просто понять его и знать DOM:)

Я реально понял только по этой ссылке . Есть сразу примеры, всё объясняет человек, а не бредогенератор (как тут). Я смог работать с XML и PHP & MySQL :)

JS я знаю (более-менее). Что-то творить на уровне новичка я явно не собираюсь, т.к.

- Это не интересно

- Мало-функционально

- Зачем останавливаться на этом уровне?!

Не всегда, часто люди ленятся и начинаю использовать готовое/почти готовое

Ваш код, но не код Prototype!

желание использовать фреймворки аналогичны желанию использовать языки высокого уровня, и RAD-средств, вместо написания велосипедов на ассемблере.

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

Хотя по эффективности кода они проигрывают. Если код небольшой, программист высококвалифицированный, и пишет не с нуля, а использует свой собственный фреймворк, который в сто раз лучше и безглючнее опенсорсовского, или MS/Yahoo/Google

К счастью на Richard Cornford свет клином не сошелся. Например MS интегрировали jQuery в состав .NET. Теперь у .NET разработчиков есть альтернатива более старой и родной ajax-библиотеки Atlas. Которая три года назад была страшно кривой. А сейчас говорят почти без багов.

естественно. Кто же против. Ведь сам .NET основан на фрейворках.

Вот с этим соглашусь.

И еще, говоря о сопровождении, почему-то почти все имеют ввиду простенькие скрипты, которые только и делаю что десяток обращений к методам из объектов/классов фреймворка...

Теперь посмотрим в корень. И гквери и прототип расчитаны на работу именно с ДОМ. Т.е. частично решают вопрос построения интерефейса. Если же скрипт в своем функционале имеет интересные новые идеи, для которых интерфейс это только вспомогательная часть, то при уходе программера наступают те-же проблемы, при всей огромности документации на фреймворки. Если же программер нормальный, и делает все "как для себя", то и в самом коде и в построении интерфейса разобраться будет не сложно.

Так ведь и php-программисты медленно но верно, переходят на опенсорсовские фреймворки. А там тоже самое - встраивают prototype и jquery (Например yii)

Теv кто сидит на Phyton и Ruby проще - у них фреймворки практически с самого начала были.

Такие сайты вообще мало кто сопровождает.

Я всегда считал, что интерфейс всегда первичен. Все остальное - клиентские скрипты или серверные - вторичны. В конце концов асинхронные запросы можно выполнять без всякого Ajax.

Если бы это было так параллельно аббревиатуре RTFM была бы аббревиатура RTFСode

Даже если в договоре есть пункт о составлении докуменатции, документация написанная среднестатистическим программистом никогда не сравнится с мануалами, и учебниками, которая сопровождает наиболее ходовые фреймворки типа jquery/prototype