Почему ответ на каждый javascript-вопрос заканчивается "jQuery",

Ответ 1

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

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

Если jQuery должен был заменить эти DOM API, тогда это будет спецификация, потому что разные поставщики браузеров не могут просто взять свои код и засунуть его где-нибудь и сделать все хорошо. Механизм браузера может быть в C, С++, Java или GolfScript, поэтому абсолютно необходимо, чтобы это была спецификация, а не реализация.

Как только jQuery API станет стандартом де-факто и будет выложен в спецификации, он столкнется с той же проблемой, с которой сейчас сталкиваются спецификации. Вы не можете просто быть компилятором, который исправляет проблему за одну ночь и выпускает новую версию 1.4.3 спецификации. Спецификация была обсуждена, согласована, изменена, выпущена, и все разработчики должны обновить свою кодовую базу для соответствия, что замедляет весь процесс. Он также теряет способность исправлять кросс-браузерные причуды, потому что он не может контролировать это, поскольку он работает на более высоком уровне в пищевой цепи.

Затем, из-за того, что он является спецификацией и движется медленно, вы всегда можете придумать свою собственную библиотеку *Query, которая еще больше упрощает спецификации API, устраняет проблемы с перекрестным браузером и продвигается гораздо быстрее.

Вот почему jQuery не может заменить DOM API, потому что если он это сделает, он будет застаиваться довольно быстро, как лучше, более инновационно и конкурирует с абстракциями spring каждый день.

Ответ 2

Нет, jQuery не заменяет JavaScript, потому что он является JavaScript. Но это очень помогает, особенно при выборе элементов и применении функций на элементах.

Вероятно, самый важный аргумент для использования jQuery: вам не нужно думать о совместимости между браузерами.
Серьезно, разные реализации JavaScript в браузерах сводят меня с ума.

Но я также не думаю, что jQuery следует использовать для всего. Это зависит от того, где (например, какие браузеры) используется JavaScript и что вы на самом деле делаете.

И поскольку я уже ответил на другой вопрос, вы можете только мастер jQuery, если вы понимаете JavaScript. Очень плохо писать код jQuery, если вы не понимаете, как это работает.

Update:

Фактически в современных браузерах вы уже можете делать вещи, которые вы обычно использовали для jQuery, например, с помощью селекторов или each(), изначально в JavaScript, с помощью document.querySelectorAll() и метода массива forEach().
Но в этом проблема: в современных браузерах. jQuery гарантирует, что вы можете использовать один и тот же API и не должны заботиться о версии браузера.

Ответ 3

У меня есть предвзятость против jQuery. Это мой единственный проигнорированный тег:)...

На мой взгляд, людям неуместно публиковать другие вопросы, говорящие: "Могу ли я использовать jQueries?" когда другой человек находится в "обычном" JavaScript.

Я считаю, что каждый должен учиться "простой" обработке javascript + dom перед тем, как идти в jQuery, вроде как вы не должны прыгать прямо в DirectX, когда вы изучаете С++; вы не можете работать с jQuery без ноу-хау JavaScript...

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

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

Ответ 4

Как я вижу, JavaScript уродливый, подверженный ошибкам и боль. Мне нравится гибкость, которая позволяет использовать такие подходы, как jQuery, prototype.js и т.д. Однако появление этих библиотек доказывает мою точку зрения. Не все это ошибка JavaScript. Некоторые из них связаны с веб-браузерами.

Чтобы лучше ответить на реальный вопрос:

jQuery просто упрощает работу, как и любая хорошая библиотека/структура. Именно по этой причине его так много предлагают. Это проще сделать в jQuery, чем обычный JavaScript. Попытка объяснить все мелочи, чтобы получить простой JavaScript для работы в самых разных ситуациях, может быть серьезной болью.

Это, я согласен. Если кто-то ищет только решение для JavaScript, это то, что они должны получить. Тем не менее, они должны понимать, что это может быть сложный процесс, и не у всех есть время/интерес к этой проблеме.

Ответ 5

Ну, я не могу говорить для всех, но jquery просто упрощает javascript-задачи. Не говоря уже о том, что они протестированы в нескольких браузерах, так что меньше проблем с кросс-совместимыми проблемами.

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

Просто мое мнение.

Ответ 6

Я не могу говорить о предвзятости к определенной структуре, но обычно использую фреймворк козыри ванильного javascript, когда дело доходит до того, чтобы сделать что-то и сделать правильно. Дэвид Уолш сказал, что лучше всего здесь:

http://davidwalsh.name/6-reasons-to-use-javascript-libraries-frameworks

Ответ 7

Является ли jQuery заменой JavaScript в целом?

Единственное, что я никогда не видел в этом потоке, это: jQuery не может заменить Javascript,, есть Javascript. Это не что иное, как сборник предварительно написанных функций в Javascript, который заботится о множестве часто используемых и желательных требований многих разработчиков.

Допустим, вы всегда делали свою собственную бумагу (рубите древесину, ее мякоть, сушите, украсьте и т.д.), прежде чем делать свои специальные бумажные вырезы. Однажды, делая бумажные вырезы из своей домашней бумаги, кто-то указывает вам чудеса из предварительно сделанной бумаги (О, счастливый день), и говорит: "Не нужно создавать свои собственные... получите право на веселье делая бумажные вырезы". Вы никогда не использовали предварительно приготовленную бумагу... для вас, бумага - результат много времени, проведенного с деревом. Итак... теперь, когда вы обнаружили Acme Paper, спросите, заменила ли Acme Paper дерево? Конечно, нет... это сделано из дерева. Вместо этого вы внезапно подумали бы об Acme Paper как о экономии времени, как о том, как добраться до конечного результата создания вырезов без всякой работы с деревом, чтобы сделать бумагу самой.

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

Я еще путал проблему?

Ура!

Ответ 8

Если вы просто используете JavaScript для управления DOM и делаете AJAX, почему бы не использовать фреймворк для выполнения тяжелой работы и работы?

JavaScript выходит за пределы веб-страниц и DOM. См. node.js для некоторой серьезной удивительности. Для небольшого загляните в это сообщение сообщение в блоге (хотя оно более впечатляюще с большим количеством людей сразу).

Ответ 9

Это то же самое, что и спрашивать, почему предпочтение отдается любой инфраструктуре, такой как MVC.net, CakePHP и т.д. Скорость, гибкость, повторное использование и т.д.

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

Ответ 10

Для меня jQuery похож на Cocoa для Mac. Я прочитал, что структура Cocoa состоит из множества "низкоуровневых" команд Unix, которые являются базой для Mac OS. Поэтому, когда вы делаете что-то столь же простое, как выделение памяти, эти просроченные простые команды запускаются.

Я бы не удивился, если бы прогрессия от Unix до Cocoa произошла с Javascript в jQuery - в конце концов, было бы проще вызвать команду jQuery, которая внутренне выполнила 10 основных действий Javascript (особенно если команда была обычно используется). Лично я против, потому что это ограничивает свободу разработчика. В то время как другие могут утверждать, что это позволяет больше творчества, потому что проще/быстрее создавать новые/лучшие вещи, люди будут полагаться на него и в конечном итоге станут зависимыми и забыть о базовом ядре Javascript.

Что делать, если конкретная "удобная, готовая и готовая к использованию" функция для того, что вы хотели не существовало в веселом "простом" мире jQuery? Если разработчики полагаются на jQuery, они будут в полной мере проигрывать. По-моему, разработчики должны оставаться независимыми и создавать собственный код, хотя использование готового материала little тоже не повредит.

Ответ 11

В следующем много говорится об API или Framework. В целом, больше пользователей будет иметь тенденцию создавать лучшую документацию. Документация может пройти долгий путь в процессе принятия.

jQuery имеет свои ограничения, по крайней мере, во время написания этого ответа. Например, сегодня я хотел протестировать функциональность с помощью xhr, который остается в readstate 3 большую часть времени. Я решил, что лучше написать собственный плагин jQuery вместо использования $.ajax, который обычно используется. Это было бы не так уж плохо. Тем не менее, я пришел к пониманию того, что jQuery тестируется во многих версиях многих разных браузеров. Я могу поразить целевую аудиторию юзабилити, используя только одну инфраструктуру.

В конце концов, я мог бы экспериментировать с $.ajax beforeSend, чтобы узнать, есть ли способ привязать обработчик для readystate 3, но документация, которую я читал, привела меня к мысли, что это было бы больше работы для задача, которую я должен выполнить.

В целом, я должен сказать, что я наслаждался jQuery больше, чем другие рамки, которые я пробовал. Когда что-то еще придет, я тоже попробую.

Ответ 12

Я заметил то же самое в последнее время. Этот jQuery - но принимает любые другие рамки - разрушает аналитическое мышление. Разработчики рассматривают сценарии браузера как Duplo Lego, когда это на самом деле Technics.

jQuery, в то время как отличный инструмент для манипулирования пользовательским интерфейсом - не охватывает все аспекты JS-программирования высокого уровня. Как насчет данных, например? В этой области jQuery довольно беден, но все же, когда возникает проблема, связанная с сортировкой или фильтрацией, мы немедленно начинаем искать плагин jQuery.

jQuery не будет, не может заменить JS в целом.

Ответ 13

jQuery стал стандартом defacto, способ, которым C или Java предназначен для мира настольных программ - все это знают или должны, поскольку он предоставляет общий язык. Обычно каждый запускается на jQuery, а затем узнает о Javascript из своего опыта и может искать в другом месте.

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

Некоторые другие действительно популярные - MooTools и SproutCore - оба из которых имеют ОГРОМНУЮ поддержку. jQuery - это как тренировочные колеса для javascript, MooTools - полностью OO, а SproutCore - для настольных приложений в облаке. Как и любой язык программирования или фреймворк, вы изучаете самый простой способ начать работу, а затем, когда вы поправляетесь, вы понимаете, что разные языки и рамки лучше для разных вещей - или, по крайней мере, вы должны понимать это;-) хе-хе.