В настоящее время существует несколько подходов к созданию веб-приложений:

1. Только на стороне сервера

Это классический подход, при котором вы отображаете страницы на сервере с помощью веб-фреймворка, такого как Ruby on Rails, Django, Express, Play! Рамки и т. Д.

Типичный рабочий процесс . Создайте всю свою бизнес-логику, модели и шаблоны представления на сервере в рамках вашего выбора.

2. Клиентский + REST API

Относительно недавно веб-сообщество в целом начало создавать клиентские приложения в Angular, Backbone, Ember и нескольких десятках других сред JavaScript MV *. И теперь у нас есть React.js, вступающий в партию.

ОБНОВЛЕНИЕ : Там нет недоразумений. То, что я имел в виду только на стороне клиента, это полное разделение интересов. У вас есть сервер REST API и клиентское приложение, которое взаимодействует с этим сервером. В зависимости от вашего варианта использования, скорее всего, у вас никогда не будет истинного клиентского приложения, которое не подключается к серверной части ни для аутентификации, ни для сохранения данных.

Типичный рабочий процесс : потратьте часы, выбирая Angular против Backbone против Ember против X. Затем вы строите свои маршруты, модели, представления, контроллеры на клиенте. После того, как вы закончите, теперь собирайте модели, контроллеры, маршруты на сервере. Таким образом, вы выполняете двойную работу.

3. Гибрид

Я не очень разбираюсь в использовании этого подхода, но если бы у меня возникло предположение, вы представляете свои представления (представление инфраструктуры MVC) на сервере. В результате вы получаете поддержку SEO и более быструю загрузку страниц.

На Гибридная фронте есть AirBnB в rendr , что якобы объединяет позвоночник и выразить вместе.

Эрик Флоренсо написал сегодня в своем блоге: React: Наконец, отличный веб-стек для сервера / клиента .

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

Я думаю, что вы совершенно не поняли «Только на стороне клиента».

Во-первых, он должен быть помечен как «Ориентированный на клиента». Весь этот аспект фреймворков, таких как Angular, заключается в том, что части VC MVC полностью реализованы в браузере в Javascript. Логика более высокого уровня «M» части «M» - Модель - реализована в браузере, а логика «CRUD» нижнего уровня реализована на сервере.

Бизнес-логика разрабатывается один раз. Логика представления разрабатывается один раз. Логика управления разрабатывается один раз - и все это в рамках выбора Javascript. Логика доступа к данным также разрабатывается только один раз, но на этот раз в любой среде RESTy или SOAPy, которую вы выбираете на стороне сервера.

В крайних случаях вы можете реализовать Модель полностью на клиенте, если допустимо получить доступ к данным только из одного браузера на одном компьютере и получать данные каждый раз, когда выбрана опция «Очистить куки».

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

Мне посчастливилось побывать на выступлении несколько лет назад, где я услышал нечто, что действительно застряло во мне: «вы выбираете дизайн, чтобы соответствовать требованиям, а не требованиям, чтобы соответствовать дизайну». Поэтому, когда вы сталкиваетесь с таким вопросом, вам нужно выяснить, что действительно нужно людям, которые просят вас создать это программное обеспечение.

Ваша задача - объяснить плюсы и минусы каждого подхода.

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

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

Это позволяет нам выбирать лучшие инструменты для выполнения работы, и наш выбор может развиваться независимо.

По общему признанию, я не использовал Angular или Backbone, поэтому я не могу давать какие-либо опытные рекомендации. Мой текущий базовый стек состоит из самой тонкой серверной части mvc или остальных служб, которые я могу найти. В основном доставка шаблонов и данных. Данные визуализируются и / или последующие данные извлекаются на стороне клиента, используя в основном просто старый javascript, jquery и css.

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