Почему jQuery так широко применяется в сравнении с другими структурами Javascript? [закрыто]

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

Я лично одобряю MooTools , но некоторые из моих команд, похоже, хотят перейти на jQuery, потому что он более широко принят. Этого для меня недостаточно, чтобы разрешить миграцию.

Я использовал оба jQuery и MooTools . Это конкретное эссе имеет тенденцию отражать то, как я отношусь к обоим рамкам. jQuery отлично подходит для DOM Manipulation, но, судя по всему, он помогает вам в этом.

Мудрый, как jQuery, так и MooTools позволяют легко выбирать DOM и манипулировать :

// jQuery
$('#someContainer div[class~=dialog]')
    .css('border', '2px solid red')
    .addClass('critical');

// MooTools
$('#someContainer div[class~=dialog]')
    .setStyle('border', '2px solid red')
    .addClass('critical');

Как jQuery, так и MooTools позволяют легко AJAX :

// jQuery
$('#someContainer div[class~=dialog]')
     .load('/DialogContent.html');

// MooTools (Using shorthand notation, you can also use Request.HTML)
$('#someContainer div[class~=dialog]')
     .load('/DialogContent.html');

И jQuery, и MooTools позволяют легко анимацию DOM :

// jQuery
$('#someContainer div[class~=dialog]')
    .animate({opacity: 1}, 500);

// MooTools (Using shorthand notation, you can also use Fx.Tween).
$('#someContainer div[class~=dialog]')
    .set('tween', {duration: 500}) 
    .tween('opacity', 1);

jQuery предлагает следующие дополнительные функции:

  • Большое сообщество сторонников
  • Репозиторий плагинов
  • Интеграция с Microsoft ASP.NET и VisualStudio
  • Используется Microsoft, Google и другими

MooTools предлагает следующие дополнительные услуги:

  • Объектно-ориентированная структура с классической эмуляцией OOP для JS
  • Расширенные нативные объекты
  • Более высокая согласованность между браузерами для поддержки собственных функций.
  • Более простое повторное использование кода
  • Используется Консорциумом World Wide Web, Palm и другими.

Учитывая это, кажется, что MooTools делает все, что делает jQuery и многое другое (некоторые вещи, которые я не могу сделать в jQuery, и я могу в MooTools ), но jQuery имеет меньшую кривую обучения.

Итак, вопрос в том, почему вы или ваша команда выбрали jQuery над другой инфраструктурой JavaScript?

Примечание. Хотя я знаю и признаю, что jQuery - отличная инфраструктура, есть другие варианты, и я пытаюсь принять решение о том, почему jQuery должен быть нашим выбором в сравнении с тем, что мы используем прямо сейчас ( MooTools )?

javascript,jquery,frameworks,mootools,

71

Ответов: 20

62 принят

Это странный вопрос ... У меня создается впечатление, что ...

  1. вы хорошо знакомы с mootools и в полной мере пользуетесь своей моделью OOP, что упрощает управление и поддержку вашего кода.
  2. вы понимаете, что цель jQuery несколько отличается и настраивается на манипуляции с DOM и AJAX, и что mootools делает все, что делает jQuery, а затем и некоторые.
  3. звучит так, как будто вам не нужно много использовать 3-х сторонних плагинов, что делает точки популярности и поддержки jQuery немного менее важными.

Итог, это шумиха? jQuery превращается в один из этих магических маркетинговых слов, таких как «AJAX», .NET и Web 2.0, что отлично подходит для них, но почему вам нужно оправдывать пребывание в среде, которая так хорошо работает для вас? Есть также бизнес-соображения, которые, как я полагаю, будут охватывать такие вещи, как:

  • долговечность каркаса, или это mootools, которые, вероятно, уйдут перед лицом растущего jQuery - очень сомнительны, поскольку они только что выпустили 1.3 beta 1 и имеют 2.0 в конвейере для выхода к концу года.
  • стоимость персонала и их обучение (я думаю, поиск программистов mootools будет более сложным, чем эти, которые пощечины jquery на их CV / резюме).
  • времени (и стоимости) для поддержания и расширения ваших систем в каждой структуре с учетом ваших ресурсов.

Обе структуры великолепны, но я считаю, что ваши интересы лучше всего подходят для отдыха с mootools.

60 ов

Лично, jQuery делает именно то, что мне нужно.

Я стараюсь делать большинство своих материалов в своем серверном коде, который хорошо структурирован: он имеет надлежащие ООП, слои и архитектуру MVC. Когда мне нужно что-то сделать с Javascript, я нашел (до сих пор), что у jQuery есть то, что мне нужно. Честно говоря, это относится к трем категориям:

  • Простое манипулирование DOM , обычно показывающее / скрывающее материал без попадания на сервер.
  • Аякс звонит , сказал Нафф.
  • UI , в том числе модальные всплывающие окна, анимации, затухающие переходы из / в скрытые / показанные. Я хардкорный бэкэнд-кодирующий парень, и я сосать в UI. Мне очень нравится, что jQuery позволяет мне программно создавать вещи, которые выглядят привлекательно.

Кроме того, библиотека плагина jQuery огромна, и я нашел немало библиотек, которые упрощают работу на стороне клиента. Хорошая вещь.

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

Я думаю, это подводит итог, почему он так популярен, особенно здесь. По большому счету, мы являемся людьми типа backend code-y, и jQuery позволяет нам сделать привлекательный пользовательский интерфейс программным путем и позволяет нам сосредоточиться на нашем базовом ядре.

16

Я не поклонник наложения классической объектной ориентации на JavaScript. Существует так много способов сделать это, что один программист JavaScript может использовать Base2 для OO, в то время как другой использует Prototype или Moo или JS.Class или Joose. Ресиг сознательно решил не добавлять классы в jQuery, и это побуждало людей находить более собственные JavaScript-способы решения проблем.

В результате мне легче читать JavaScript, написанные другими авторами jQuery, и писать код jQuery, который легче читать другим. Обычно я не пытаюсь эмулировать класс ООП в JavaScript. Вместо этого я создаю объекты «на лету» и передаю их, и у меня много массивов объектов. Это так легко понять, что я даже обнаружил, что переношу это мышление на языки ООП!

Насколько я знаю, Moo может очень хорошо догнать jQuery или превзойти его. Но я не могу тратить время на отслеживание 6 или 7 великолепных библиотек JavaScript, чтобы увидеть, какая лошадь впереди.

Я думаю, что это в основном вопрос времени. Когда массы программистов вскочили в AJAX, jQuery стала горячей новой крутой вещью, которая решила их проблемы.

Другие библиотеки в значительной степени догнали. YUI, ExtJS, Dojo, Moo - все отлично. Но я не могу использовать их все.

Я работаю достаточно трудно , пытаясь выяснить последствия новых функций библиотеки я действительно использую. Например, jQuery добавил Live события с 1.3. Это фактически позволяет мне вырезать код со многих страниц. Представляет ли Му это и сейчас, и как я должен это знать, если это так?

Я уверен, что Moo потрясающе. Мне бы хотелось узнать время. Но вы посмотрели на Додзе? Я должен был использовать его в одном проекте и обнаружил, что он втянул большинство замечательных идей из jQuery. И у него есть pubsub и хорошая поддержка Comet.

Я сочувствую вам. Но ваши программисты говорят о смысле. Изучение jQuery хорош для их карьеры, и есть больше книг, примеров и программистов-соседей, которые просят помощи, если они используют jQuery.

Если вы решите пойти jQuery в конце концов, подумайте, прежде чем принимать решение о том, следует ли придерживаться библиотеки OO. Есть несколько классных (например, JS.Class или Joose), но принятие этого шага означает выделение себя из того, как программируется большинство программистов JavaScript.

11 ов

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

Я - тот, кто использует оба метода. JQuery на работе (принят, потому что он был «более широко принят») и Mootools в личных проектах. В результате я постоянно ощущаю себя калекой при использовании JQuery; Будь то с поддержкой JSON, созданием элементов, обработкой событий ... и так далее. На работе я нахожу, что пишу цепочки 75 событий ... и я чувствую себя грязным в результате.

Моя основная общая говядина с JQuery, однако, заключается в том, что существует недостаток согласованности или практики, когда речь идет о плагинах и сторонних разработчиках. Анекдот «Дополнительные плагины доступны» действительно не помогает мне, когда нет согласованности между плагинами, структурно или иначе. Мне потребовалось несколько недель, чтобы изучить «приемлемую» модель подключаемого модуля, и даже тогда я адаптировал свой собственный прагматический стиль, поскольку я нахожу ошибку и неэффективность в существующих структурах. Можно сказать, что это «Pro», в который каждый может вскочить и запустить JQuerying. Тем не менее, я более склонен называть это «Кон», потому что вы увидите 30 разных способов добиться чего-то, и трудно прикрепить принятый стандарт.

Итак, что значит «Знать JQuery», означает ли это, что вы знаете, как немного качаться .hide (). Show (). FadeIn (). FadeOut ()?

Когда мне нужно заводить гангстера на моем JS на работе, я скучаю по мне, Mootools. Я имею в виду отсутствие поддержки Native JSON? Да ладно......

В ответ на «Широко принятый» ответ, мы все знаем , OSCommerce является наиболее « Широко принятой » корзиной для покупок, и все мы знаем , что куча дерьма , что есть. Я никоим образом не сравниваю JQuery с OSCommerce. Я просто указываю на ошибку «Широко принятый» ответ.

Что касается плагинов, то в магазине приложений для яблока есть что ... 100 тыс. Приложений? 50 000 - пердуны. Конечно, в JQuery много плагинов, но соотношение мусора и стоимости - отлично.

7 ов

jQuery предоставляет вам доступ к четким и сжатым функциональным методам программирования. С момента выпуска цепочки методов в (LINQ) в C # 3.0 это очень хорошо работает для .NET-программистов. Таким образом, поток от одного языка к другому легко. Чтобы иметь возможность запрашивать DOM для объекта или список объектов, для нас работает намного лучше. Это первая функция выбора jQuery, которая делает ее такой привлекательной, а затем ее расширяемость и, конечно же, все встроенные функции, которые приходят с ней, хороши. Кроме того, сообщество позади замечательно, потому что я сначала смотрю, чтобы увидеть, что кто-то что-то сделал, а затем попытаться сделать это сам, если решение не найдено. И последнее ... но, конечно же, не в последнюю очередь ... тот факт, что Microsoft собирается включить в Visual Studio 10 и поддерживать его отлично. Moo Tools, Prototype и т. Д. Просто не могут конкурировать со всем вышеперечисленным.

JavaScript, JQuery, рамки, MooTools,
Похожие вопросы
Яндекс.Метрика