Мнения на стороне сервера против клиентской веб-платформы

Question

Мне очень интересно мнение сообщества относительно серверных платформ (таких как Django и RoR) и клиентских платформ (таких как SproutCore и ExtJS).

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

Только для примера: использование опыта в 2 разных языках, 2 разных API и 2 различных синтаксисах фреймворка для достижения единой цели ужасно неэффективно.

Стратегия, которая мне подходит, состоит в том, чтобы выбрать один клиентский ИЛИ серверный фреймворк в качестве основного, а затем дополнить при необходимости чем-то очень легким с другой стороны. Например, используйте RoR на сервере в качестве основного, дополненного на клиенте jQuery. Или используйте ExtJS на клиенте в качестве основного, дополненного PHP на сервере.

Прямо сейчас я не уверен, на какую сторону забора падать, и мне интересны мнения и опыт сообщества.

Answer 1

Согласен с Dragontamer. Платформы на стороне сервера и на стороне клиента решают различные проблемы.

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

Сервер приложений (ASP, PHP, ColdFusion и т. Д.) Будет M и C в приложении MVC и будет обслуживать букву «V». Инфраструктура на стороне клиента сделает V красивым и добавит функциональность на стороне клиента (например, манипулирование данными, предоставляемыми сервером приложений, такими как сортировка данных таблицы без обновления страницы).

Два совершенно разных животных, которые служат двум совершенно разным целям.

Answer 2

То, что ИМХО это больше, чем вопрос, это проблема. В любом случае, вам придется переписывать код с одной стороны на другую, потому что вы вдруг поймете, что для добавления чего-то к этой функциональности на сервере вам нужно что-то от клиента и наоборот, после некоторых изменений вы поймете, что ваша функциональность в клиенте будет работать лучше на сервере или наоборот, поэтому вы будете переписывать код обратно с сервера на клиент и наоборот.

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

Это можно сделать.

Answer 3

Это полностью ложная дихотомия. Они решают разные подзадачи цели. Тем не менее, очевидно, что Microsoft ASP.NET хорошо интегрирует клиентскую часть с серверной (однако я сам никогда не использовал ее, поэтому, пожалуйста, исправьте меня, если я не прав).

Клиентские библиотеки ориентированы на представление данных пользователю.

Серверные библиотеки должны быть сосредоточены на функциональности CRUD (создание, чтение, обновление, удаление) и аутентификации пользователя. Когда данные должны быть централизованы, они должны обрабатываться на сервере.

Ни одна серверная библиотека никогда не будет иметь функции перетаскивания или доступности. Ни одна клиентская библиотека никогда не будет иметь реализации MySQL и Access Control List.