Каковы аргументы против использования JavaScript Framework для компании по разработке веб-сайтов? - PullRequest
5 голосов
/ 07 августа 2009

Наша компания занимается созданием сайтов и веб-приложений. Мы небольшая фирма, и наша команда разработчиков всегда создает функции javascript с нуля или копирует с других сайтов, созданных нами. Каждый раз, когда я привожу слово стандартизация и использую JS-фреймворк, такой как JQuery, Prototype или любой другой, мне говорят, что в качестве аргументов против этого у Frameworks есть три пункта:

  • В основном для людей, которые не знают достаточно JS
  • Ограничение фреймворков для разработчиков Javascript
  • Фреймворки раздувают фактический код разработки множеством вещей, которые не используются.
  • Мы не используем достаточное количество Javascript в наших приложениях для того, чтобы нам потребовалась среда JS

Мне кажется, что Frameworks дают нашей команде хорошую отправную точку, документацию, сообщество и всегда возможность расти на вершине платформы. Могут ли некоторые пользователи Framework продолжить разработку?

РЕДАКТИРОВАТЬ 1:

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

Ответы [ 9 ]

13 голосов
/ 07 августа 2009

С точки зрения ваших коллег, .NET и JAVA предназначены для людей, которые не знают достаточно сборки.

Каркасы существуют по причине. Они позволяют сосредоточиться на проблеме, а не на повторяющемся коде. Они позволяют вам быть уверенными (при условии, что вы используете хорошо протестированные фреймворки), что определенные части вашего кода надежны и хорошо протестированы.

Если ваши коллеги против фреймворков, я бы серьезно подумал о том, чтобы двигаться дальше.

8 голосов
/ 07 августа 2009

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

Что касается этого:

  • В основном для людей, которые не знают достаточно JS

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

А что касается этого:

  • Лимит рамок Javascript Разработчики

Это может перевести на «Фреймворки значительно затрудняют написание кода для спагетти, и это то, что я умею лучше всего» * ​​1018 *

Это не аргументы, а оправдания.

7 голосов
/ 07 августа 2009

Аргументы против:

  • Рамки не позволяют вам заново изобретать колесо
  • Каркасы обычно содержат хорошо проверенный код
  • Фреймворки хорошо поддерживаются сообществом
  • Фреймворки заставляют вас сосредоточиться на бизнес-проблеме, которую вы пытаетесь решить

  • Frameworks может иметь лицензию, с которой вы не согласны / с которой не можете работать
6 голосов
/ 07 августа 2009

Несколько плюсов для фреймворков javascript (например, JQuery).

  1. Они обеспечивают стандартизацию в пользовательском интерфейсе элементы.
  2. Сократить время на разработку комплекса интерфейсы и эффекты.
  3. Нормализуйте усилия, предоставляя функции, которые уже кросс-браузер совместим.
  4. Благодаря усилиям на кресте совместимость документации больше полезно в рамках, как вы можете использовать API фреймворка как канон вместо поиска неизвестного поддержка различных / проприетарных Функции JavaScript.
  5. Уменьшенная кривая обучения для новых разработчики делают их продуктивными на ваше программное обеспечение быстрее.

Я полностью не согласен с тем, что фреймворк ограничивает разработчиков javascript. Совсем наоборот. Большинство фреймворков предоставляют расширенные механизмы плагинов, в которых фреймворк можно расширять с помощью необработанного JavaScript, используя хуки в самой фреймворке.

5 голосов
/ 28 ноября 2012

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

Многие фреймворки (особенно jQuery) слишком монолитны и недостаточно модульны.

Хотя зависимость от хорошо протестированного стороннего программного обеспечения часто более чем оправдана, «фреймворки», как правило, предоставляют вам гораздо больше функциональных возможностей, чем вам нужно в данный момент.

Во многих проектах мне очень нравится удобство, которое дает мне jQuery для выбора наборов элементов (например, с помощью $ (". Classname")). Но, если я не использую сколько-нибудь значительное количество AJAX, мне не нужны утилиты AJAX, предоставляемые jQuery.

Программное обеспечение должно делать одну вещь и делать это хорошо, и программное обеспечение, написанное на JavaScript, не является исключением. Большинство фреймворков, на которые вы ссылаетесь, пытаются сделать все , что приводит к ненужной сложности.

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

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

Если вы используете утилиту, которая выполняет одну вещь, то вы точно знаете, какие функции этой утилиты вы используете. Здесь только один. (Если вы вообще не используете эту утилиту, это легко определить. Такое определение будет означать, что вы можете безопасно удалить ее из своего проекта.)

Я за использование хорошо проверенного стороннего кода. Но если он пытается сделать слишком много (то есть, если это скорее фреймворк, чем утилита), вам, вероятно, следует искать альтернативу. Если он пытается сделать слишком много (как jQuery пытается сделать слишком много), то у него есть серьезные фундаментальные недостатки в дизайне, которые, вероятно, вернутся, чтобы укусить вас.

3 голосов
/ 01 апреля 2012

Я удивлен, что никто не упомянул это:

  • Многие веб-разработчики по умолчанию используют JQuery, не рассматривая альтернативы
  • И, наконец, добавив его на веб-страницу, чтобы выполнить несколько тривиальных задач, которые легко можно выполнить в чистом JavaScript
  • В результате пользователи должны ждать загрузки всей библиотеки, и это замедляет просмотр веб-страниц

Также:

  • Некоторые веб-разработчики увлекаются дизайном веб-страниц и заканчивают тем, что разрабатывали излишне сложные веб-страницы из-за мощи JQuery
  • То, что JQuery позволяет создавать сценарии с хорошей кросс-браузерной совместимостью, не означает, что конечный результат можно использовать на разных устройствах / интерфейсах
  • Я бы также поспорил о совместимости между браузерами, потому что видел случаи, когда webkit не играл хорошо с JQuery
  • JQuery поощряет «быстрые» сценарии - но если вы спешите, вы, вероятно, что-то упустили
  • Писать на JavaScript с нуля медленнее - но я считаю, что в итоге вы получите более полное решение, более точно соответствующее потребностям пользователей
  • Использование JQuery может сместить фокус веб-разработчика на создание веб-сайтов с высокой графической и визуальной привлекательностью, тогда как акцент должен быть сделан на функциональности и удобстве использования
  • JQuery - не серебряная пуля для веб-разработки

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

2 голосов
/ 07 августа 2009

Аргумент против библиотек - ПОДДЕРЖКА БРАУЗЕРА. Большинство библиотек поддерживают только подмножество браузеров. Здесь - это пример того, как BBC развертывает свою собственную систему вместо использования чего-то вроде jquery.

1 голос
/ 07 августа 2009

Существует множество веских причин для подозрений в отношении фреймворков в целом, которые, конечно же, сбалансированы множеством причин, по которым они стоят.

Сейчас я использую jquery, и, честно говоря, через час обучения он понял, что он так хорошо подходит для работы, что если бы его не было, я бы в конечном итоге реализовал нечто очень похожее на себя, только это было бы хорошо или как кроссплатформенный.

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

1 голос
/ 07 августа 2009

Мне понравился ответ ПБ +

В основном для людей, которые не знают достаточно JS

Я считаю, что это слишком сложно для них, поэтому они используют это оправдание. FW позволяет создавать гораздо более сложные приложения.

Ограничение фреймворков для разработчиков Javascript

фигня

Рамки раздувают фактические разработка кода с большим количеством вещей которые не используются.

что сегодня лишних 100к-200к? особенно если вы используете версии CDN (например, в Google). И это при условии, что вы ничего не используете в FW.

...