Dev подходит к сложным пользовательским интерфейсам JavaScript [закрыто]

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

Я не уверен, что маркировать этот класс приложений, возможно тяжелый AJAX или RIA (но не плагины, такие как Flash / Silverlight). Я имею в виду веб-приложения со следующими характеристиками:

• Эмулируйте богатый / собственный рабочий стол UX в JavaScript
• Содержит большинство / все поведение в JS на стороне клиента, используя сервер в качестве API данных (JSON / Html-Templates).

Это в отличие от использования веб-сервера для рендеринга пользовательского интерфейса, производящего весь HTML в модели обновления страницы.

Вот некоторые примеры:

• Документы Google / Gmail
• MindMeister
• Pivotal Tracker

По мере продвижения к HTML5 я вижу, что этот стиль разработки RIA с тяжелым JavaScript становится все более распространенным и необходимым для конкуренции.

ВОПРОС: Итак, каковы общие подходы к управлению этими тяжелыми разработками JS?

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

Google подошел к этой проблеме, создав GWT, который компилируется из языка более высокого уровня (Java) в JS, опираясь на существующую инфраструктуру разработки, которая есть в языке более высокого уровня (Eclipse, инструменты строгой типизации, инструменты рефакторинга), наряду с абстрагированием совместимости браузера и другие вопросы от разработчика.

Есть и другие инструменты, такие как Script # для C #, которые делают нечто подобное. Все это ставит JS больше в роли IL (Intermediate Language). то есть. «Ты никогда больше не пишешь на этом« низкоуровневом языке »».

Но эта «компиляция в JS» - не единственный подход. Не очевидно, что GWT является доминирующим подходом ... или действительно станет им.

Что люди делают с JavaScript для богатых клиентов? Некоторые ориентировочные вопросы:

• Большинство магазинов изготавливают JS вручную (поверх библиотек, таких как jQuery и др.)?
• Или существует много разных подходов, но нет четкой передовой практики?
• Неужели большинство магазинов избегают разработки в масштабе RIA в пользу более простой для разработчика модели на стороне сервера / перерисовки страницы? Если так, это будет продолжаться?
• Может ли компиляция в JS стать будущей тенденцией? Или это просто неправильно?
• Как они управляют сложностью и рефакторингом клиентского JS?
• Модуляризация и распределение работы между командами?
• Применение, применение и тестирование шаблонов на стороне клиента, таких как MVC / MVP и т. Д.

Итак, каковы новые тенденции в нашем будущем с тяжелыми JavaScript и HTML5?

Благодарность!

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

Весь смысл GWT (и подобных многоуровневых языков) заключается в том, что JavaScript слишком ненадежный / слишком хрупкий / слишком изменчивый для использования «настоящими программистами». Но если у вас есть фреймворк, обрабатывающий нестабильные / хрупкие / изменяемые биты для вас, то нет никаких причин добавлять этот дополнительный уровень сложности.

Просто мое мнение ...

Я бы сказал, что GWT рискованно. Как только вы решили использовать его, вы застряли с ним. По сути, это означает, что вы рассматриваете свою разметку, DOM и некоторые аспекты CSS как среду выполнения. Сложно смешивать написанный вручную JavaScript с GWT, так как ваш клиентский код становится все более изощренным. GWT имеет собственные методы, но они весьма ограничены с точки зрения возможного применения. Это большой компромисс, и это большая ставка.

Google пытается продать GWT как очень быструю среду выполнения X-платформы с достойной интеграцией на стороне сервера. Но, как уже отмечали другие, это уже не так - JQuery и YUI работают так же быстро, если не быстрее. И намного проще профилировать и оптимизировать ваши страницы, когда они собираются вручную, так что вы имеете полный контроль над CSS, разметкой и JavaScript.

GWT пытается скрыть от вас основную платформу, которая может быть неправильным способом сделать что-то. Многие так называемые компонентные веб-фреймворки делали то же самое. Вы должны были написать неоднозначный производный от XML код с добавленными EL и пользовательскими тегами. Результатом был бы беспорядок плохо сформированного HTML с маленькими кусочками дрянного JavaScript, разбросанного повсюду. Страницы были медленными, глючными и совершенно не поддерживаемыми.

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

Я люблю JQuery с его отношением к скорости и простоте. Я люблю YUI3 за модульность и комплексные виджеты. Я люблю YUI CSS за то, что он обеспечивает согласованность во всех браузерах. Я люблю JavaScript для хороших деталей. Я люблю Java за то, что позволил мне получить работу.

Просто поцелуй, и все будет хорошо!

Я слышал, что они называются «Одностраничные приложения».

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

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

Код переднего конца был javascript. Мы использовали jQuery для манипулирования элементами страницы, Pure для шаблонов и RequireJ для разбиения кода на модули. (Инструмент сборки RequireJs был использован для обеспечения более оптимальной загрузки.)

Мы написали наши тесты, используя qUnit , и имели тест jUnit, который использовал htmlunit для запуска каждого теста qUnit, затем очищал выходные данные для результатов и проходил или терпел неудачу в зависимости от состояния прохода / неудачи qUnit. Они были добавлены в наши тесты jUnit для серверной части и добавлены в наш ci, используя Hudson / Jenkins .

Я работаю над таким приложением, созданным на основе Ext JS. Приложение организовано по модульному принципу. Различные модули реализованы в виде автономных компонентов, которые очищаются после удаления из иерархии компонентов Ext. Загрузчики по требованию загружают дополнительные компоненты непосредственно перед их необходимостью (один файл js = один компонент).

Я обнаружил, что этот подход не так сложно масштабировать. Единственные реальные ограничения, с которыми я столкнулся, связаны с наличием слишком большого количества элементов DOM в дереве одновременно в IE. Решение заключается в стратегической выгрузке скрытых частей приложения. Поскольку все манипуляции с DOM происходят через иерархию компонентов Ext, DOM практически полностью абстрагируется, и разработка остается простой.

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

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

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

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