Блог

Мы хотим написать пользовательский интерфейс, состоящий из HTML, Javascript (jQuery) и CSS. Хотя первоначальная отправная точка будет обслуживаться веб-сервером, никаких шаблонов на стороне сервера не будет. Браузер будет взаимодействовать с сервером через restful интерфейс и отображать его пользовательский интерфейс.

Каковы риски этого подхода?

В идеале я хотел бы хороший, простой javascript OO api, который под ним выполняет http-вызовы на сервер для получения JSON-представлений ресурсов. Есть предложения относительно того, как это можно было бы структурировать?

У кого-нибудь есть опыт работы с шаблонами на стороне браузера?

Существует ли фреймворк, облегчающий этот стиль разработки?

Мы также будем определять ресурсы на стороне сервера, и я думаю следовать соглашениям ruby on rails. Например, если вы определяете пользовательский ресурс в routes.rb, у вас есть 7 шаблонов uri. Есть мысли?

Кстати, функциональность серверной части будет разрабатываться на java.

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

Вам действительно нужно убедиться, что вы освоили Javascript. Ознакомьтесь с современным состоянием, по крайней мере, ознакомьтесь с работами Дугласа Крокфорда, и в первую очередь с JSLint.

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

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

Риски, безусловно, есть. При запуске и раннем переходе я заметил, что «младшим» программистам трудно наверстать упущенное. Для тех, кто не слишком знаком с Javascript, существует очень крутая кривая обучения, и в ней много изяществ.

Другой риск связан с производительностью. Мы советуем нашим клиентам использовать Google Chrome просто потому, что

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

Я бы не советовал использовать jQuery. Я нахожу jQuery скорее «плагином», чем реальной платформой. jQuery действительно великолепен, когда у вас есть веб-сайт и вы хотите добавить немного фантазии. В нем есть несколько очень хороших общих инструментов (манипулирование DOM и все такое), но ему очень не хватает в области бизнес-моделирования.

Я бы также не советовал использовать OO-подход. Для очень небольшого числа доменов OO является идеальным решением. Для большинства компаний это не так. И Javascript способен на гораздо большее, чем просто OO.

Проблема № 1 (и, возможно, единственная проблема) — это поисковая система. Не уверен, насколько хорошо ваш контент будет распознаваться / сканироваться / доступен для поиска. Основная причина заключается в том, что поисковая система не обязательно поймет ваш контент (поскольку он отображается только после выполнения Javascript).

В остальном, это отличный подход. Я пробовал это несколько раз, и это отлично работает (при условии, что вы не боитесь Javascript). Результирующий веб-сайт обычно намного более адаптивный, чем традиционные веб-сайты, поскольку трафик сервер -> клиент довольно мал — передаются только необработанные данные. Весь пользовательский интерфейс генерируется Javascript на стороне клиента.