Подход к обработке javascript для более крупных проектов?

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

Считая несколько блогов и немного обновляясь, я читал о библиотеках, похожих на Backbone.js и JavascriptMVC, которые оба звучат как хорошие альтернативы, чтобы сделать код более модульным и разделенным.

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

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

Спасибо большое

ОТВЕТЫ

Ответ 1

Оба Backbone.js и JavascriptMVC - отличные примеры использования структуры для организации больших проектов разумным способом (SproutCore и Cappuccino тоже хорошо). Я определенно предлагаю вам выбрать стандартный способ обработки данных с сервера, обработки событий из DOM и ответов от сервера и создания представления. В противном случае это может быть кошмар для обслуживания.

Помимо структуры MVC, вы должны выбрать решение для этих проблем:

  • Управление зависимостями: как вы будете компилировать и загружать файлы javascript в правильном порядке? Мое предложение было бы RequireJS.
  • Тестирование: тестирование кода пользовательского интерфейса никогда не бывает легким, но ребята в jQuery делают какое-то время, а их инструмент тестирования QUnit хорошо документированы/протестированы.
  • Minification: вы хотите минимизировать свой код перед развертыванием на производство. Требование JS имеет встроенную функцию, но вы также можете использовать Closure Compiler, если вы хотите получить сумасшедший небольшой источник.
  • Система сборки: все эти инструменты великолепны, но вы должны объединить их все в одну систему сборки, чтобы вы могли запускать простую команду в командной строке и иметь приложение для отладки или производства. Конкретный инструмент для использования зависит от вашего языка выбора - Ruby = > Rake, Python → Напишите свой собственный, NodeJS как инструмент построения (мне больше нравится эта опция) → Jake

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

Ответ 3

Я бы рекомендовал использовать javascript в функциональном стиле, которому могут помочь абстракции, такие как coffeescript и underscore.js.

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

Функциональный код, основанный на событиях, отлично подходит для макроструктуры. Я бы также посоветовал javascript для соединения с DOM. (Опять backbone.js имеет отличный пример того, как модель полностью независима и даже взгляды не зависят от dom. все, что вам нравится, может отображать данные по WebSocket)

Я лично также поклонник иметь один центральный файловый менеджер, а не сложную структуру require/include на каждой странице. Загрузите модули javascript из центрального загрузчика на основе обнаружения функции страницы за страницей. (См. Здесь пример центрального файлового менеджера).

Я также хотел бы пропагандировать растущую возможность хорошего повторного использования через node.js. Есть немало людей, которые работают над переносом кода браузера до node.js или копированием кода node.js в браузер. (см. YUI3, запущенный на nodejs, node.js в браузер, commonJS в браузере По общему признанию, большинство из них являются WIP и нестабильными.)

Ответ 4

Мое предложение состояло в том, чтобы изолировать как можно больше javascript во внешних js файлах вне ваших представлений и просто ссылаться на них в заголовках. Это не только позволяет повторному использованию JavaScript с страницы на страницу, но и отделяет ваши проблемы на справедливом уровне, распространяя ваш код, чтобы упростить отладку (в любом случае, по моим убеждениям). Кроме того, это делает ваш js немного более безопасным, поскольку он не отображается непосредственно на странице браузера. Разумеется, эта безопасность довольно незначительна, поскольку такие инструменты, как firebug или IE Developer Tools, могут обращаться к многоуровневым файлам javascript.

Во-вторых, я бы предложил использовать инструмент, например compress.msbuild, чтобы (при окончательной компиляции для развертывания) сжать все ваши написанные пользователем javascript для whatevertheirnameis-min.js. Мало того, что уплотнение всего на одну строку фактически уменьшает нагрузку и время выполнения для вашего кода, оно также запутывает его в более безопасный. Намного сложнее разобрать файл -min, и тем более найти какие-либо конкретные функции, когда весь код является одной строкой.