Каковы аргументы против использования JavaScript Framework для компании, занимающейся разработкой веб-сайтов?
Наша компания занимается созданием сайтов и веб-приложений. Мы небольшая фирма, и наша команда разработчиков всегда создает функции javascript с нуля или копирует с других сайтов, созданных нами. Каждый раз, когда я привожу слово стандартизация и использую JS-фреймворк, такой как JQuery, Prototype или любой другой, мне говорят, что у Frameworks есть три аргумента против них:
- В основном для людей, которые не знают достаточно JS
- Фреймворки ограничивают разработчиков Javascript
- Фреймворки раздувают фактический код разработки множеством вещей, которые не используются.
- Мы не используем достаточное количество Javascript в наших приложениях, чтобы нам потребовалась среда JS
На мой взгляд, кажется, что Frameworks дают нашей команде хорошую отправную точку, документацию, сообщество и всегда возможность расти на вершине платформы. Могут ли некоторые пользователи Framework продолжить разработку?
РЕДАКТИРОВАТЬ 1:
Спасибо всем вам за ваши отличные ответы. Я действительно не думал, что это будет такая горячая тема. Я рад, что задал вопрос. Я разместил еще один аналогичный вопрос в следующей ссылке на случай, если вы захотите что-то добавить. Тема нового вопроса связана с CSS. Благодарю.
9 ответов
Аргументы против:
- Рамки мешают вам заново изобретать колесо
- Фреймворки обычно содержат хорошо протестированный код
- Фреймворки хорошо поддерживаются сообществом
- Фреймворки заставляют вас сосредоточиться на бизнес-проблеме, которую вы пытаетесь решить
- Фреймворки могут иметь лицензию, с которой вы не согласны / не можете работать
С точки зрения ваших коллег, .NET и JAVA предназначены для людей, которые не знают достаточно сборки.
Рамки существуют по причине. Они позволяют сосредоточиться на проблеме, а не на повторяющемся коде. Они позволяют вам быть уверенными (если вы используете хорошо протестированные фреймворки), что определенные части вашего кода надежны и хорошо протестированы.
Если ваши коллеги против фреймворков, я бы серьезно подумал о том, чтобы двигаться дальше.
Поскольку никто не упомянул об этом - структура Javascript быстро становится еще одной зависимостью проекта, и в общих чертах, зависимости являются плохими, поскольку они представляют точки отказа.
Что касается этого:
- В основном для людей, которые не знают достаточно JS
Не вдаваясь в подробности, скажу, что если кто-то из наших сотрудников скажет что-то подобное в моем присутствии, я постараюсь проигнорировать это как шутку. Если бы я думал, что они серьезны, мне, вероятно, придется их убить.
А что касается этого:
- Фреймворки ограничивают разработчиков Javascript
Это можно перевести как "Фреймворки значительно затрудняют написание кода для спагетти, и это то, что я делаю лучше всего"
Это не аргументы, это оправдания.
Несколько плюсов для фреймворков JavaScript (например, JQuery).
- Они обеспечивают стандартизацию в элементах пользовательского интерфейса.
- Сократите время на разработку сложных интерфейсов и эффектов.
- Нормализуйте усилия, предоставляя функции, которые уже совместимы с разными браузерами.
- Благодаря усилиям по кросс-совместимости документация более полезна в среде, так как вы можете использовать API среды в качестве канона вместо поиска неясной поддержки различных / проприетарных функций javascript.
- Уменьшенная кривая обучения для новых разработчиков, делающая их продуктивными на вашем программном обеспечении быстрее.
Я полностью не согласен с тем, что фреймворк ограничивает разработчиков javascript. Совсем наоборот. Большинство фреймворков предоставляют расширенные механизмы плагинов, в которых фреймворк можно расширять с помощью необработанного JavaScript, используя хуки в самой фреймворке.
Я буду использовать jQuery в качестве примера, но то, что я здесь говорю, может относиться к большинству фреймворков JavaScript.
Многие фреймворки (особенно jQuery) слишком монолитны и недостаточно модульны.
Хотя зависимость от хорошо протестированного стороннего программного обеспечения часто более чем оправдана, "фреймворки", как правило, предоставляют вам гораздо больше функциональных возможностей, чем вам нужно в данный момент.
Во многих проектах мне очень нравится удобство, которое дает мне jQuery для выбора наборов элементов (например, с помощью $(". Classname")). Но если я не использую сколько-нибудь значительное количество AJAX, мне не нужны утилиты AJAX, предоставляемые jQuery.
Программное обеспечение должно делать одну вещь и делать это хорошо, и программное обеспечение, написанное на JavaScript, не является исключением. Большинство фреймворков, на которые вы ссылаетесь, пытаются сделать все, что приводит к ненужной сложности.
Одно место, которое может вас укусить, это когда вы рассматриваете возможность перехода на следующую версию фреймворка. Это включает в себя обход журналов изменений jQuery для поиска обратно несовместимых изменений и поиск в вашем проекте областей, где используется этот код. Это может быть настоящим кошмаром, особенно если у вас не обязательно есть полный список того, какие функции jQuery вы используете, а какие нет.
Кроме того, jQuery (и другие фреймворки), как правило, заставляют разработчиков запускаться в зависимости от новых функций jQuery, даже не задумываясь об этом, затрудняя определение того, какие функции jQuery использует ваш проект, а какие - нет.
Если вы используете утилиту, которая делает одну вещь, то вы точно знаете, какие функции этой утилиты вы используете. Здесь только один. (Если вы вообще не используете эту утилиту, это легко определить. Такое определение будет означать, что вы можете безопасно удалить ее из своего проекта.)
Я за использование проверенного стороннего кода. Но если он пытается сделать слишком много (то есть, если это скорее фреймворк, чем утилита), вам, вероятно, следует искать альтернативу. Если он пытается сделать слишком много (как jQuery пытается сделать слишком много), то у него есть серьезные, фундаментальные недостатки дизайна, которые, вероятно, вернутся, чтобы укусить вас.
Я удивлен, что никто не упомянул это:
- Многие веб-разработчики по умолчанию используют JQuery, не рассматривая альтернативы
- И в конечном итоге включить его на веб-странице, чтобы выполнить несколько тривиальных задач, которые легко можно сделать в чистом JavaScript
- В результате пользователи должны ждать загрузки всей библиотеки, и это замедляет просмотр веб-страниц.
Также:
- Некоторые веб-разработчики увлекаются дизайном веб-страниц и в итоге разрабатывают излишне сложные веб-страницы из-за мощи JQuery
- Тот факт, что JQuery позволяет создавать сценарии с хорошей кросс-браузерной совместимостью, не означает, что конечный результат можно использовать на разных устройствах / интерфейсах.
- Я бы также поспорил о совместимости между браузерами, потому что видел случаи, когда webkit не играл хорошо с JQuery.
- JQuery поощряет "быстрые" сценарии - но если вы спешите, вы, вероятно, что-то упустили
- Писать на JavaScript с нуля медленнее, но я полагаю, что в итоге вы получите более полное решение, более точно соответствующее потребностям пользователей.
- Использование JQuery может сместить акцент веб-разработчика на создание веб-сайтов с высокой степенью графичности и визуальной привлекательности, тогда как акцент должен быть сделан на функциональности и удобстве использования.
- JQuery не серебряная пуля для веб-разработки
Я пристрастен здесь, потому что я не использую JQuery, но это потому, что я еще не нашел в этом необходимости - возможно, потому, что я больше фокусируюсь на удобстве использования и функциональности, а не на том, чтобы пользовательский интерфейс выглядел симпатично (извините, я знаю JQuery может сделать больше, чем это).
Аргумент против библиотек - ПОДДЕРЖКА БРАУЗЕРА. Большинство библиотек поддерживают только подмножество браузеров. Вот пример того, как BBC выкатывает свои собственные вместо использования чего-то вроде jquery .
Есть много веских причин для подозрений в отношении фреймворков в целом, конечно же, сбалансированных множеством причин, почему они того стоят.
Сейчас я использую jquery, и, честно говоря, через час обучения он понял, что он так хорошо подходит для работы, что, если бы его не было, я бы в конечном итоге реализовал нечто очень похожее на себя, только это было бы не так хорошо или как кроссплатформенный.
Там не так много наворотов, он очень маленький и хорошо спроектированный и ничего не делает, что мешает вам писать любой javascript, который вы хотите для конкретных случаев, которые не соответствуют вашим потребностям.
Мне понравился ответ пб +
В основном для людей, которые не знают достаточно JS
Я считаю, что это слишком сложно для них, поэтому они используют это оправдание. FW позволяет создавать гораздо более сложные приложения.
Фреймворки ограничивают разработчиков Javascript
чушь собачья
Фреймворки раздувают фактический код разработки множеством вещей, которые не используются.
что сегодня лишних 100к-200к? особенно если вы используете версии CDN (например, в Google). И это при условии, что вы ничего не используете в FW.