LINUX.ORG.RU

JQuery 1.3

 ,


0

0

Вышла новая версия замечательного JS-фреймворка, использующегося на множестве сайтов в интернет.

Среди основных особенностей данной версии разработчики отмечают прежде всего бОльшую скорость работы (заявлено улучшение на 49% по сравнению с предыдущей версией). Попутно, разумеется, появилось множество новых функций и селекторов, правда, к сожалению, некоторые были объявлены устаревшими, например больше нельзя писать $('имя[@атрибут]'), теперь знак @ надо опускать.

Разработчики надеются, что переход на новую версию не будет болезненным :)

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

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

В общем качаем, обновляем, читаем.

>>> Подробности

mootools для риальных пацанов. jquery для тупых девак!!!

anonymous
()
Ответ на: комментарий от anonymous

> На нормальных сайтах давно всё выдирается. Див с классом, внутри него дивы. На руби даже около 3 библиотек для этого есть.

Я всегда знал, что рубисты в принципе не понимают сути семантической разметки.

anonymous
()
Ответ на: комментарий от anonymous

>HTML был низкоуровневым ещё в эпоху статического веба, у каждого, кто его писал руками, рано или поздно возникали мысли о всяких SSI, шаблонах, генерилках.

>А что касается JS... он вроде и расширяем, почти как лисп, ага, или как ассемблер.


>Поди-ка попиши на голом JS без единой библиотеки. Да невозможно им пользоваться в чистом виде, в нём нет ничего, а если есть, то пользоваться им нельзя.


>Ну ладно бы, но ведь в нём и модулей никаких не предусмотрено, и на чистом JS их эффективно не реализуешь


>Ибо вся гуёвая логика сосредоточена на сервере, и повторять её на ява-скрипте было бы дуростью.


у меня волосы на руках дыбом становятся от такой метанации..

volh ★★
()
Ответ на: комментарий от volh

Аргументируй или в лужу перднул.

anonymous
()

а кто-нибудь измерял насколько снижается нагрузка на сервер в случае исп. JS, когда есть статические HTML/CSS/JS шаблоны и данные страниц отсылаются в виде JSON/XML, которые выдираются прямо из базы ?

anonymous
()
Ответ на: комментарий от anonymous

> А как только начинаются наши, к свиньям, любимые веб-приложения с аяксом и хитрыми виджетами, так оказывается, что этот ява-скрипт, отвечающий за GUI, проще генерить на стороне сервера, и использовать как высокоуровневый промежуточный язык. Ибо вся гуёвая логика сосредоточена на сервере, и повторять её на ява-скрипте было бы дуростью.

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

anonymous
()
Ответ на: комментарий от anonymous

> а кто-нибудь измерял насколько снижается нагрузка на сервер в случае исп. JS, когда есть статические HTML/CSS/JS шаблоны и данные страниц отсылаются в виде JSON/XML, которые выдираются прямо из базы ?

Врядли: те, кто выдирает клиенту данные прямо из базы, не кешируя их на сервере приложений, обычно не сильно понимают в вопросах производительности :)

anonymous
()
Ответ на: комментарий от anonymous

>Поди-ка попиши на голом JS без единой библиотеки.

И чего тут сложного? Просто времени уходит больше.

Хотя есть на свете "программисты", которые и ajax запрос без jquery сделать не могут.

anonymous
()
Ответ на: комментарий от anonymous

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

/me зопесал: gmail непопулярен.

anonymous
()
Ответ на: комментарий от anonymous

> И чего тут сложного? Просто времени уходит больше.

> Хотя есть на свете "программисты", которые и ajax запрос без jquery сделать не могут.

Ты считаешь, что программист - это тот, кто вызубрил XMLHttpRequest? Нашёл, чем гордиться, клоун.

anonymous
()
Ответ на: комментарий от anonymous

>Ты считаешь, что программист - это тот, кто вызубрил XMLHttpRequest?

Да.

Кто не знает, что это такое - тот не программист, а кодер.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Кто не знает, что это такое - тот не программист, а кодер.

Кодер - это кто кроме бездумно использовать чужие (кривые) интерфейсы ни на что другое не способен. Копипастить boilerplate-код из букваря и медведя можно научить. А умный программист посмотрит на этот XMLHttpRequest, поймёт, что это полуфабрикат, и сделает вокруг него человеческую обёртку. Которая его код сократит в 5 раз. Вот jQuery и писали умные люди для других умных людей, а тебе, видно, с умными людьми не попути.

anonymous
()
Ответ на: комментарий от anonymous

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

Дык это... Сессии как бы не нужны.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

> Дык это... Сессии как бы не нужны.

Совершенно верно, для проверки всяких атрибутов пользователя, общих для всех запросов, нужно на каждый HTTP-запрос ходить в базу.

anonymous
()
Ответ на: комментарий от anonymous

> Совершенно верно, для проверки всяких атрибутов пользователя, общих для всех запросов, нужно на каждый HTTP-запрос ходить в базу.

Можно же кэшировать эти дела.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

>> Совершенно верно, для проверки всяких атрибутов пользователя, общих для всех запросов, нужно на каждый HTTP-запрос ходить в базу.

> Можно же кэшировать эти дела.

Вот допустим, у тебя миллион пользователей на сайте, каждый из них имеет привилегии доступа, личные атрибуты (типа мальчик/девочка, чтобы можно было писать "уважаемый" или "уважаемая" а не уважаемый(ая), возраст, что бы не подпихивать эдалтный контент несовершеннолетним, какая-то серверная аналитика предпочтений пользователя и т.п.), персональные настройки самого пользователя - тема отображения, подписи в его сообщениях и т.п., какая-то динамическая информация, действительная только для текущего сеанса работы (например о том, что провека капчи пройдена)) - ты предлагаешь это всё кешировать в памяти для всех юзеров? А зачем, если у тебя одновременно на сайте больше сотни человек одновременно не бывает?

anonymous
()
Ответ на: комментарий от wfrr

> ага хранить в кукисах список покупок пользователя и флаг аутентификации

Куки кстати тоже не нужны, вася... А вообще речь об UI на асинхронных запросах, без перегрузки страницы. Короче, man REST и диссертация Филдинга.

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

> ты предлагаешь это всё кешировать в памяти для всех юзеров? А зачем, если у тебя одновременно на сайте больше сотни человек одновременно не бывает?

Я предлагаю выгрузить это при аутентификации ОДИН раз на клиент и больше не рефрешить страницу! А кэширование, если оно и надо, должно быть прозрачным на уровне базы.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

>А вообще речь об UI на асинхронных запросах, без перегрузки страницы.

Человек нажал F5?

>Короче, man REST и диссертация Филдинга.


Ссылочку на русском?

wfrr ★★☆
()
Ответ на: комментарий от wfrr

> Человек нажал F5?

Ну люди же разумные существа, что-нибудь можно придумать, не? :) Алерт какой с yes/no.

> Ссылочку на русском?

http://en.wikipedia.org/wiki/Representational_State_Transfer

и внизу смотри ресурсы. На русском не видел. :(

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

> Я предлагаю выгрузить это при аутентификации ОДИН раз на клиент и больше не рефрешить страницу!

Как это будет работать, скажем, на примере ЛОРа?

anonymous
()
Ответ на: комментарий от anonymous

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

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

>общих для всех запросов, нужно на каждый HTTP-запрос ходить в базу.

А memcached отменили? :) А то, так, пользователю в сессию «общий для всех запрос» сохраним, а он поменяется. И будет пользователь со старыми данными ходить...

KRoN73 ★★★★★
()
Ответ на: комментарий от Bohtvaroh

>Ну люди же разумные существа,

Чем больше я вижу людей тем меньше верю тому что во вселенной есть разум, хотябы один.

> что-нибудь можно придумать, не? :) Алерт какой с yes/no.


Это как пытаться через ссш воспрепятствовать нажатию ресета.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Прочёл статью. Материал отличный.

Ну, допустим, формираовние страниц будет реализовано через JS, обмен данными через AJAX/JSON, а сервер только значения БД скидывать. Что делать, если браузер всё-таки не поддерживает/криво поддерживает JS (Konqueror, Opera Mini)?

Есть ли JS-архиваторы, чтобы сэкономить траффик?

По сабжу: посмотрел jQuery и Dojo. Потрясён до глубины души. Джонни, ты крут!

DarkAmateur ★★★★
()
Ответ на: комментарий от DarkAmateur

>Есть ли JS-архиваторы, чтобы сэкономить траффик?

mod_deflate

KRoN73 ★★★★★
()
Ответ на: комментарий от DarkAmateur

> Ну, допустим, формираовние страниц будет реализовано через JS, обмен данными через AJAX/JSON, а сервер только значения БД скидывать. Что делать

Что делать.. Писать бинарные приложения вместо джаваскриптовских, которые будут исполняться более эффективно.

anonymous
()
Ответ на: комментарий от KRoN73

> А memcached отменили? :) А то, так, пользователю в сессию «общий для всех запрос» сохраним, а он поменяется. И будет пользователь со старыми данными ходить...

Зачем ещё один демон если предполагается наличие сервера приложений? И опять же будет лежать переменная сессии где-то в memcached или с переменной - суть от этого не меняется, сессия остаётся.

anonymous
()
Ответ на: комментарий от anonymous

> Зачем ещё один демон если предполагается наличие сервера приложений? И опять же будет лежать переменная сессии где-то в memcached или с переменной - суть от этого не меняется, сессия остаётся.

Вот дуралей же. А если у тебя несколько серверов приложений?

anonymous
()
Ответ на: комментарий от anonymous

>Вот дуралей же. А если у тебя несколько серверов приложений?

Вот дуралей, а сервера приложений в большинстве поддерживают репликации и миграции сессий. Нахера memcached нужен? Пользоваться надо правильными технологиями.

anonymous
()
Ответ на: комментарий от DarkAmateur

>Что делать, если браузер всё-таки не поддерживает/криво поддерживает JS (Konqueror, Opera Mini)?

Такие браузеры идут лесом, ибо веб приложения пишутся для внутреннего пользования если ты не гуголь, а клиенту достаточно сказать: мы рекомендуем фаерфокс, остальные браузеры могут работать не не будут поддерживаться.

wfrr ★★☆
()
Ответ на: комментарий от anonymous

Проблема как всегда в деньгах. Если ЛОР будет отдавать XML/JSON/XHTML/whatever для парсинга программами, кто же будет видеть баннеры и читать рекламу, которую и из plain html режут?

Karapuz ★★★★★
()
Ответ на: комментарий от volh

Ты хочешь сказать, что JS/HTML - это не низкоуровневые языки? Тогда приведи пример низкоуровневого, предназначенного для платформы "браузер"

EmStudio
()
Ответ на: комментарий от anonymous

> > Хотя есть на свете "программисты", которые и ajax запрос без jquery сделать не могут.

> Ты считаешь, что программист - это тот, кто вызубрил XMLHttpRequest? Нашёл, чем гордиться, клоун.

Я вот через фреймы могу подгрузить данные. Как это было за 5 лет до появления слова "аякс". Или через флеш - будет еще эффективнее, чем через XMLHttpRequest, ибо сокет можно не разрывать и не плакать о возможном кешировании. Сам XMLHttpRequest ниасилил, ибо оно (грязная проприетарщина) не нужно

EmStudio
()
Ответ на: комментарий от KRoN73

> Кто не знает, что это такое - тот не программист, а кодер.

А кто не знает, как заставить работать XMLHttpRequest в конке - это кто? А фреймы то в нем работают...

EmStudio
()
Ответ на: комментарий от anonymous

> Вот дуралей, а сервера приложений в большинстве поддерживают репликации и миграции сессий. Нахера memcached нужен? Пользоваться надо правильными технологиями.

"Репликации и миграции сессий" - это по вашему правильные технологии? :D

Bohtvaroh ★★★★
()
Ответ на: комментарий от wfrr

Толстый? Тролль? Еще раз, для тех, до кого долго доходит. RSS на LOR есть. Но LOR не будет отдавать XML/XHTML, как и любой другой сайт, пока единственная возможность оплатить хостера - реклама с баннеров

Karapuz ★★★★★
()
Ответ на: комментарий от Karapuz

Да ты шо. )) А я думаю, просто этим некому заниматься, вот если сделают, оплачу лору год хостинга - мне не впадлу. :D

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

имхо в сесси достаточно хранить кусок информации о аутентификации и ид, и механизм нотификации о жизненном цикле сесси. Ибо чудная технология описанная в статье не реализуема пока, хотя идеи оттуда можно тиснуть.

wfrr ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.