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

19

Я пытаюсь понять ландшафт различных подходов и лучших практик, связанных с разработкой сложного клиентского 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?

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

Фил Кокфилд
источник
Zimbra в значительной степени полагается на js на стороне клиента для эмуляции настольных сред.
frogstarr78
Благодарю. Вы знаете, как они развивают свой JS? Ручной или инструмент более высокого уровня?
Фил Кокфилд
Этот ответ на аналогичный вопрос довольно хорошо суммирует варианты: stackoverflow.com/questions/218699/…
Виктор Сорокин
1
Я считаю, что Google+ - это интенсивное использование GWT (что ожидается ... учитывая, что это от Google)
jamiebarrow
Жаль, что этот вопрос был закрыт :( ... ИМХО его надо открыть
'15

Ответы:

6

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

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

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

Дори
источник
Я сомневаюсь, что любой фреймворк может устранить «хрупкость» javascript. Его динамическая природа очень затрудняет обеспечение согласованности и подвержена ошибкам во время выполнения. Достаточно того, что атрибут json был переименован где-то и не был отражен весь путь, чтобы сломать вещи. ... Это не проблема для типичных небольших сценариев, но в сложных RIA с тысячами LOC это может произойти быстро и быстро остаться незамеченным. Никакая структура не может этого избежать.
dagnelies
5

Я бы сказал, что 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 за то, что позволил мне получить работу.

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

Андрей Андрей Листочкин
источник
2
И кстати, Google не использует GWT для GMail - они используют свою библиотеку Closure.
Андрей Андрей Листочкин
1
Очень ценю этот анализ рисков, связанных с GWT, и компиляцию из языков более высокого уровня в целом.
Фил Кокфилд
2
Я думаю, что я согласен с Эндрю. Вам не нужны платформы более высокого уровня, если вы понимаете JavaScript. Например, ASP.NET WebForms - это такая структура, которая использует XML и пользовательские теги для создания таких вещей, как мастера и всплывающие окна, для более простой парадигмы программирования для тех, у кого мало опыта работы в Интернете, но больше опыта работы с Windows Forms. Чтобы попытаться сохранить парадигму. Но ASP.NET MVC становится популярным и стандартным IMO, потому что он ближе к Интернету - его парадигма соответствует реальности.
jamiebarrow
3

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

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

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

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

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

Шон Макмиллан
источник
2

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

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

Джори Себрехтс
источник
ExtJS действительно интересно посмотреть (спасибо), поскольку Sencha создает как собственные JS, так и GWT-библиотеки (ExtGWT). Кажется, они хеджируют ставки.
Фил Кокфилд
0

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

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

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

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

FinnNk
источник
Вот хороший пост о TDD с JavaScript, который может быть интересен [ msdn.microsoft.com/en-us/scriptjunkie/ff452703 ]
jamiebarrow