Подход для обработки JavaScript на больших проектах?

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

Проверьте эту книгу, в основном главу 10 http://jqfundamentals.com/book/index.html#chapter-10

Answer 4

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

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