[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Про jQuery.
Страницы: 1, 2, 3
neadekvat
Свернутый текст
Invis1ble, и тебе smile.gif Работа, учеба, алкоголь -- совсем времени мало.


bestxp, на чистом js писать сложные интерфейсы, на мой взгляд, это прямо-таки.. мазохизм. Впрочем, я, возможно, настоящий рукожоп, потому что еще не написал ни одного более-менее сложного интерфейса, код которого мне бы нравился, а желание "переписать нафиг с нуля" не появлялось.

Особенно это касается вереницы коллбеков, и так с ними, и эдак, а все равно выглядят хреново.
sergeiss
Основной причиной, почему я открыл эту тему, была такая несуразность. Почему-то часто в рассуждениях идет противопоставление "чистый JS" vs jQuery. Мне не понятно, почему так противопоставляется? Даже при "массированном" smile.gif использовании jQuery для JS остается куча работы - при правильном подходе. Тот же ООП в JS - это весьма мощная штуковина, если знать, как с ним работать.
Но зачем разрабатывать свои "костыли" для "велосипедов" в тех случаях, когда уже люди поработали и сделали качественную, кроссбраузерную библиотеку с весьма обширными возможностями?

Как я уже говорил в начале темы, только в одном случае может быть оправдано "ковыряние" в деталях работы JS, тех самых, которые уже "закрыты" jQuery. Если у человека достаточно много свободного времени и он хочет изучить тонкости работы JS.

Как-то давно я ковырялся в ассемблере... Ничего серьёзного не написал smile.gif Но изучение его помогло мне намного лучше понять многие тонкости работы компа. Например, как работают прерывания, как выводятся текстовые и графические данные на монитор. Да-да, раньше использовались и чисто текстовые режимы работы мониторов!!! Это мне в определенной степени помогало потом при работе и с С++, и с ПХП. Так что я не считаю, что изучение ассемблера было пустой тратой времени.
Другое дело, что у меня тогда было время на это изучение.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Invis1ble
Кстати, по теме, меня еще очень умиляют подобного вида скрипты biggrin.gif Обратите внимание, как мастерски юзается jQuery! А вы говорите килобайты... smile.gif

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

neadekvat
Invis1ble, лол, я даже не заметил сначала laugh.gif
killer8080
Инструмент нужно выбирать исходя из условий задачи. jQ конечно хорошо и удобно, но элементарных знаний он не отменяет! И не нужно доходить до маразма, когда вместо this.href, пишут $(this).attr('href'), а когда спрашиваешь нафига, с видом знатока отвечают: ну как же - это кроссбраузерно! biggrin.gif
Т.е. люди просто не знают о существовании стандартных ДОМ свойств.
sergeiss
Цитата (killer8080 @ 13.05.2014 - 09:42)
jQ конечно хорошо и удобно, но элементарных знаний он не отменяет!

Это бесспорно, да :)

Цитата (killer8080 @ 13.05.2014 - 09:42)
вместо this.href, пишут $(this).attr('href')

В этом есть вполне определенный смысл, если копнуть поглубже :) Только смысл не программерский, а скорее в области психологии лежит.
Вот смотри. Сначала аналогию проведу. В JS знак "точка с запятой" ставить не обязательно, а в ПХП обязательно. По себе знаю: если на JS не использовать ";", то достаточно "покодить" несколько часов в таком стиле, и уже в ПХП потом не пишешь. Поэтому я пришел к единственно верному (на мой взгляд) решению: в JS ставлю ";" всегда. Тогда при переключении в ПХП мне не надо думать "писать - не писать".
То же самое и в твоем примере. В одном случае можно не использовать "стиль jQ", но в другом придется пользоваться им обязательно, т.к. альтернатив нет. И вот чтобы не помнить все эти "вариации с исключениями", лучше писать всё в одном стиле. Чтобы не было, как у Райкина "тут читать, тут не читать, тут жена рыбу заворачиала" ;)
Вот это вот, единообразность стилей, я считаю наиболее важным аргументом за то, чтобы если уж использовать jQ, то всё писать в его стиле.

Цитата (killer8080 @ 13.05.2014 - 09:42)
Т.е. люди просто не знают о существовании стандартных ДОМ свойств.

И это тоже возможно в каких-то случаях.

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

Свернутый текст
function getXmlHttp(){

var xmlhttp;

if ( typeof XMLHttpRequest != 'undefined' ){
xmlhttp = new XMLHttpRequest();
}
else{
try{
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
}
catch(e){
try{
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
}
catch (E){
xmlhttp = false;
}
}
}

return xmlhttp;
}

// далее в одной из функций
var r = getXmlHttp();
var l = JSON.stringify({
'g':g,
'id': prms.id,
'city': prms.city,
'channel': prms.channel,
'ts_beg' : prms.ts_beg,
'ts_end' : prms.ts_end,
'ts_fgmTitle' : encodefgmTitle
});

r.open( "GET", "http://*********.ru"+BASE_SUB_DIR+"/rqst_prm_new.php?l=" + l, false );
r.send( null );

if( r.status == 200 ){ // r.status == 200

......


// в другой функции
var request = getXmlHttp();//new XMLHttpRequest();

request.open( "GET", "http://*******.ru"+BASE_SUB_DIR+"/rqst_prm_new.php?city=" + $(this).val(), false );
request.send( null );
if( request.status == 200 ){
var rspn = JSON.parse( request.responseText );
if( rspn !== false ){
var sel_channel = $("#sel-channel");
sel_channel.empty();
for( idx in rspn ){
sel_channel.append('<option value="' + rspn[ idx ].id + '">' + rspn[ idx ].name + '</option>');
}
cur_city = new_city;
}
}




_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.