Является ли простой ванильный JavaScript лучше, чем использование фреймворков, таких как jQuery или MooTools? [закрытый]
Мне интересно, хорошо ли полагаться на такие фреймворки, как jQuery или в MooTools или мы должны просто использовать обычный JavaScript?
помимо избежания повторного изобретения колеса, добавляют ли они какое-либо конкретное значение?
поскольку рамки открыты для общественности, может ли быть возможность использования каких-либо дыр в безопасности, которые могут появиться (конечно, непреднамеренно :) ) в рамках?
есть ли какие-либо другие моменты, которые учитываться при выборе фреймворка или иным образом?
6 ответов
фреймворки решают кросс-браузерные ошибки, которые обычно стоят часов вашего времени, поэтому вы можете сосредоточиться на функциональности, а не беспокоиться о какой-то ошибке браузера edge.. вместо того, чтобы тратить 4-5 часов устранение ошибок провести это время с семьей.
фреймворки, такие как jQuery, довольно загружены такими вещами, как анимация, селекторы, манипуляция html, поэтому обычно есть какая-то функциональность, уже встроенная в библиотеку, снова сохраняя вы больше времени и API делает его очень легко на самом деле сделать сложные вещи.
интерпретаторы и браузеры только становятся все быстрее и быстрее, поэтому я не особенно думаю, что это огромная проблема загрузки всей библиотеки. Кроме того, благодаря Google et al мы получаем очень быстрые cdns, и в настоящее время многие сайты используют тот же самый точный URI, чтобы вытащить скрипт, что означает более высокую скорость кэширования и повторного использования скрипта на другом сайте.
вместо каждого веб-разработчика, имеющего свою собственную библиотеку, гораздо эффективнее, когда тысячи людей сосредоточены на улучшении нескольких библиотек, поэтому ошибки кросс-браузера документируются и исправляются.
конкуренция хорошая вещь, результат испытаний slickspeed привел к гораздо более быстрым двигателям селектора, таким как Sizzle. Разработчики не беспокоясь о тривиальных ошибок дом означает создавать более сложные библиотеки ежедневно, что означает, что разработчики начального уровня имеют доступ к очень мощным плагинам.
что касается безопасности, jQuery, например, обнаружит, способен ли браузер анализировать JSON изначально, и если да, полагайтесь на это. Обычно любой современный браузер будет иметь это, и это намного безопаснее, чем eval... поэтому jQuery стремится сначала использовать более безопасные и безопасные методы. Это будет только используйте eval, если нет JSON.метод Parse доступен.
An важно помнить, что в jQuery помните, что вы все еще кодируете в Javascript. Обычно люди слишком увлекаются методами с сахарным покрытием и обертыванием все на $, Я думаю, что важно знать, что вы все еще можете сделать this.href вместо $(this).attr('href') Если вы хотите абсолютно нормализованный uri, например.
не преуменьшайте важность избежания повторного изобретения колеса. Вы не изобретаете новый компьютер каждый раз, когда хотите написать новую программу.
но кроме того, библиотеки JavaScript обеспечивают лучшее кросс-браузер поддержка. Это очень полезно, как быстрый взгляд на QuirksMode будет демонстрировать.
JavaScript фреймворки делают много вещей легче. Посмотрите документацию jQuery, и вы увидите, как легко это сделать много причудливых вещей.
рамки JavaScript были расширены многими людьми, поэтому есть много высококачественных jQuery Плагины (например-это фреймворк, который я знаю лучше всего), который вы можете использовать без необходимости писать их самостоятельно.
маловероятно, что фреймворки JavaScript будут вводить дыры в безопасности, поскольку они не предоставляют больше функциональности, чем вы можете сделать с простым JavaScript.
фреймворки предоставляют кросс-браузерный API для JavaScript, поэтому большую часть времени они очень полезны, даже если они приходят с небольшой потерей скорости. Но JS-двигатели получают быстрое почти каждое обновление, так что это не проблема. Существует также очень много плагинов для фреймворков, поэтому они не только предоставляют API, но и новые кросс-браузерные функции. Но это зависит от того, что ты хочешь сделать.
Я не придаю большого значения аргументу "открытый исходный код очень уязвим для проблем безопасности". Я вижу пользу многих хороших парней, читающих код и замечающих такие проблемы. Если бы это было проблемой, нам нужно было бы отказаться от Linux, Apache, MySql и большинства библиотек Java.
рамки обычно экономят очень много усилий, я вижу их именно как заранее изобретенное колесо. Им не нужна никакая другая ценность.
Это зависит от того, для чего вы используете JavaScript. Если вы хотите иметь возможность показывать и скрывать панели, анимировать материал,присоединять события к нескольким элементам, делать Ajax и т. д. тогда вам нужно рассмотреть кросс-браузер вопросы.
jQuery устраняет необходимость думать о проблемах кросс-браузера и позволяет некоторые действительно аккуратные функции, такие как выше, а также модальные диалоги и т. д.
поэтому это зависит от того, что вы хотите от JavaScript.
Я никогда не использовал MooTools, поэтому не могу комментировать это, но jQuery упрощает многое.
- выбор коллекций объектов по классу, имени, частичному идентификатору и т. д.
- упростить вызовы Ajax.
- обработчики событий Wireup для обработки onclick, mouseover, mouseout и т. д. и назначьте элементам на основе общих селекторов, чтобы логику можно было использовать повторно.
- тонны переходов и других визуальных вещей, чтобы довольно впереди конец.
есть много больше, но это, как правило, упрощает/ускоряет развитие. Одно дело следить за тем, если вы используете тонну селекторов в одной функции (цикл, который повторяется по DOM 40+ раз), это waaay более эффективно использовать vanilla JavaScript.
поэтому я бы посоветовал закодировать передний конец с помощью фреймворка, а затем оптимизировать неэффективные части, добавив в vanilla JavaScript.
кроме того, я не вижу, как jQuery или MooTools могут представлять угрозу безопасности, поскольку они являются клиентскими фреймворками, а не серверными. Не забудьте всегда проверять входные данные на стороне сервера в дополнение к любой проверке на стороне клиента и правильно параметризовать SQL-запросы, построенные на стороне сервера.