Плюсы и минусы только HTML / JavaScript веб-приложения [закрыто]

35

Я пришел из ASP.NET формы фона и нашел кодирование на стороне сервера очень мощным в прошлом. Однако в последнее время я хотел постепенно отказаться от серверного кода внешнего интерфейса и заменить его чистым HTML / JavaScript, который обращается к данным через веб-сервисы JSON. У меня нет никакого реального опыта в этом, и поэтому я хотел бы услышать, является ли это проверенной и испытанной моделью. Кроме того, каковы подводные камни, окружающие это?

Я считаю, что пользовательские элементы управления ASP.NET очень полезны, поэтому я хотел бы оставить теорию позади, храня шаблоны разметки в отдельных файлах HTML на сервере. Они будут получены и использованы через JQuery AJAX и плагин HTML-шаблонов jQuery соответственно.

Любой вклад будет чрезвычайно признателен.

PS Извините за вопрос noob, но является ли этот тип веб-архитектуры тем, что называется web-2.0, или я совершенно не в курсе?

hofnarwillie
источник
1
Хотите заменить элементы управления asp.net HTML / JavaScript или предоставить всю бизнес-логику (проверку и т. Д.) Внешнему интерфейсу?
Шлякер
1
Хороший вопрос. Я думаю о создании интерфейса только в html / javascript, чтобы осветлить страницу, чтобы она была быстрее на мобильных телефонах / планшетах. Так что, вероятно, просто замените элементы управления asp.net. Все обращения к серверу через веб-сервис, поэтому сервис wcf должен как-то справляться с проверкой и т. Д. Как вы думаете, это возможно?
hofnarwillie
Я
задаю
@hofnarwillie для проверки, я думаю, вы должны использовать JS на стороне клиента.
smwikipedia
1
@smwikipedia Спасибо, но я считаю, что проверка на стороне клиента должна использоваться только для удобства пользователей. Настоящая проверка должна быть сделана на стороне сервера. Проверка на стороне клиента делает ваше приложение удобным для пользователя, а проверка на стороне сервера обеспечивает безопасность и достоверность, потому что проверка на стороне клиента может быть легко отключена.
hofnarwillie

Ответы:

31

Я использовал эту технику исключительно для веб-приложения, над которым мы работаем. Мой бэкэнд размещен в Google App Engine с использованием Java SDK, а мой интерфейс использует HTML, CSS и JavaScript (с jQuery).

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

Преимущество: работа с веб-дизайнерами

Основным преимуществом этого метода является то, что веб-дизайнер, который знает некоторый PHP, но не считает себя программистом, может работать без ограничений в HTML и CSS без необходимости разбираться с бесчисленными строками JSP, тегами taglib и другой серверной частью. разметка, о которой нам говорили в течение многих лет, должна значительно облегчить жизнь фронтенд-разработчика.

Без всей разметки на стороне сервера мы были бы более гибкими. Веб-дизайнер напрямую поменялся и пересмотрел свой оригинальный дизайн 3 или 4 раза, с небольшими изменениями с моей стороны.

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

Серверный код и HTML / CSS Handoffs

В предыдущих проектах ему приходилось передавать HTML и CSS разработчикам Java, которые затем брали его HTML и CSS и полностью переписывали его, используя технологию JSP. Это займет много времени и, как правило, приведет к тонким, но важным различиям в фактическом рендеринге страниц, а также в его валидации в валидаторе W3C.

В целом, мы оба очень довольны этой техникой, и у меня все еще есть ноль JSP-страниц или серверный код в моих HTML-страницах.

Подводные камни техники REST / JSON

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

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

Преимущество: другие приложения могут быть построены на платформе

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

Один из наших сотрудников хотел попробовать проверить концепцию в другом приложении, и благодаря моим службам RESTful мы смогли создать совершенно другой интерфейс приложения для решения совершенно другой проблемы. Быстро разработанное доказательство концепции использовало собственные HTML, CSS и JavaScript, но использовало сервисы RESTful в качестве бэкэнда и источника данных.

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

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

jmort253
источник
2
Спасибо. Это полностью отвечает на мой вопрос. Цените время, которое вы потратили, чтобы дать четкий и краткий ответ. +1
hofnarwillie
2
Я работаю в компании, где все внутренние веб-приложения работают в формате html / js только с бэкэнд-сервисами, которые обслуживают данные, закодированные в формате json. Это действительно хорошо работает и намного быстрее создает новые приложения с использованием этой модели, а также потому, что бэкэнд и внешние разработчики работают в параллельно. Вы должны действительно попробовать это.
nohros
@ jmort253 Большое спасибо за отличный ответ. Я думал о точно такой же архитектуре, и ваша практика позволяет мне быть уверенным в этом. Я задавал подобные вопросы здесь: stackoverflow.com/questions/33934101/… и здесь: stackoverflow.com/questions/34020543/… .
smwikipedia
12

Это, конечно, жизнеспособная стратегия, но это не серебряная пуля.

Pros :

  • если все сделано правильно, приложения, разработанные таким образом, очень отзывчивы
  • у вас есть четкое разделение логики (на сервере) и представления (на клиенте); сервер вообще не должен заниматься презентационными аспектами приложения
  • потенциально более эффективное использование пропускной способности сети (вы отправляете только необработанные данные, а не демонстрационный шаблон)
  • проще разрабатывать десктопные графические интерфейсы, поскольку вы меньше зависите от парадигмы запрос / ответ

Минусы :

  • Вы должны написать свой клиентский код на Javascript или на языке, который может компилироваться в Javascript, потому что это единственное, что доступно в браузере
  • использование ресурсов на клиенте может быть выше, поэтому приложение может не работать на некачественных устройствах (например, в мобильных браузерах и т. д.)
  • это не будет работать вообще с отключенным JavaScript; если у него есть общедоступный веб-сайт, вы должны хорошо подумать, готовы ли вы пойти на этот риск (особенно если вы рассматриваете SEO и доступность - подход с большим количеством javascript обычно разрушителен для этих двух направлений)
  • много логики должно быть написано дважды: один раз на клиенте и еще раз на сервере (потому что вы никогда не можете доверять клиенту)
  • параллелизм может быть адом, поэтому вам нужно очень тщательно разрабатывать свой код на стороне клиента и быть готовым ко всем видам проблем параллелизма
tdammers
источник
2
Спасибо. Можете ли вы привести пример проблем параллелизма, которые будут вызваны этой моделью?
hofnarwillie
3
Пример. Если пользователь нажимает «Голосовать вверх», а затем быстро нажимает «Голосовать вниз» до завершения вызова сервера «Голосовать вверх», сколько будет голосов?
JBRWilkinson
@JBRWilkinson Логический флаг, который проверяет состояние, время ожидания или интервал?
Альпер Туран
1

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

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

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

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

gbjbaanb
источник
1

Одним из недостатков является необходимость дублирования некоторой логики в JavaScript и ASP.net. Это не может быть большой проблемой для вас в зависимости от вашего приложения. Это часто происходит потому, что вам не нужно просить сервер проверять каждую мелочь («Разрешено ли пользователю нажимать эту кнопку или выбирать эту опцию в этой ситуации?»), Но вы также не хотите зависеть на клиенте, как единственном, выполняющем проверку, так как пользователь имеет контроль над клиентом.

Кен Фелинг
источник
0

Если вы все еще используете ASP.NET WebForms и хотите ускорить свои приложения, вот что вы должны сделать:

  • Разработка приложения с SOLID в виду
  • Отключить ViewStateна всех страницах и пользовательских элементах управления
  • Не используйте серверные элементы управления

    <%: VeiwModel.Title%> вместо <asp: Literal id = "Title" runat = "server">

  • В бэкэнде переопределите метод OnInit и выполните там всю инициализацию:

    защищенное переопределение void OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (е); }

  • Сожмите все файлы .css и .js в 1, используя SquishIt

  • Ленивая загрузка изображений
  • Кэшировать сложные объекты

Наконец, проверьте www.porsche.se. Разве это не чертовски быстрый сайт?

šljaker
источник
Это действительно быстрый сайт. Большое спасибо за вклад. Очень признателен.
hofnarwillie