Является ли хорошей идеей сделать пользовательский интерфейс на 100% в Javascript и предоставлять данные через API?

19

Моя основная дневная работа - создание приложений HTML. Под этим я подразумеваю внутренне используемые приложения типа CRUD с множеством редактируемых видов сетки, текстовых полей, выпадающих списков и т. Д. В настоящее время мы используем веб-формы ASP.NET, которые выполняют свою работу, но производительность в основном мрачная, и довольно часто вы придется прыгать через обручи, чтобы получить то, что вам нужно. Обручи, которые подвешены к потолку и подожжены.

Поэтому мне интересно, возможно, было бы неплохо перенести весь пользовательский интерфейс на сторону JavaScript. Разработайте надежный набор многоразовых элементов управления, специально предназначенных для наших нужд, и обменивайтесь данными только с сервером. Да, мне нравится парадигма «контроль» (он же «виджет»), она вполне подходит для таких приложений. Таким образом, на стороне сервера у нас все еще будет базовый макет, похожий на нашу текущую разметку ASPX, но тогда он будет отправлен клиенту только один раз, а часть Javascript позаботится обо всех последующих обновлениях пользовательского интерфейса.

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

  • Производительность еще. Сравнительный анализ показывает, что в настоящее время основная задержка происходит на стороне клиента, когда браузер пытается повторно выполнить рендеринг большей части страницы после обновления AJAX. Сгенерированная разметка веб-форм ASP.NET придает новое значение слову «сеть», а богатые элементы управления Devexpress добавляют собственный уровень сложности Javascript в дополнение к этому. Но будет ли быстрее пересчитать все необходимые изменения на стороне Javascript, а затем обновить только то, что нужно обновить? Обратите внимание, что я говорю о формах, которые имеют несколько редактируемых видов сетки, множество текстовых полей, множество выпадающих списков, в каждом из которых содержится полмиллиона фильтруемых элементов и т. Д.
  • Удобство разработки . Теперь было бы намного больше Javascript, и это, вероятно, смешалось бы с HTML-разметкой страницы. Этот или какой-то новый двигатель представления должен был быть произведен. Intellisense для Javascript также намного хуже, чем для кода C #, и из-за динамической природы Javascript его нельзя ожидать намного лучше. Практика кодирования может немного улучшить, но не намного. Кроме того, большинство наших разработчиков в первую очередь разработчики на C #, так что будет некоторая кривая обучения и начальные ошибки.
  • Безопасность . Много проверок безопасности нужно будет выполнить дважды (на стороне сервера и на стороне пользовательского интерфейса), а на стороне сервера обработки данных придется включить намного больше из них. В настоящее время, если вы установите текстовое поле как доступное только для чтения на стороне сервера, вы можете зависеть от того, не изменяется ли его значение в клиенте. Фреймворк уже имеет достаточно кода для обеспечения этого (с помощью шифрования viewstate). С подходом, основанным только на данных, это становится сложнее, потому что вам нужно все проверять вручную. С другой стороны, возможно, дыры в безопасности будет легче обнаружить, потому что у вас будут только данные для беспокойства.

В целом, это решит наши проблемы или ухудшит их? Кто-нибудь когда-нибудь пытался это сделать, и каковы были результаты? Существуют ли какие-либо рамки, которые помогают в этом виде деятельности (за исключением jQuery и моральных эквивалентов)?

Vilx-
источник
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.Вы точно описываете , что такое ASP.NET, что говорит мне о том, что вы, вероятно, используете его неправильно. :) В ваших приложениях ASP.NET, если вы размещаете компоненты на панелях обновления, тогда библиотека javascript ASP.NET будет выполнять асинхронные обратные передачи на стороне сервера и только повторно отображать компоненты, которые вы укажете.
maple_shaft
@maple_shaft - я знаю, но так или иначе это работает медленно. Кроме того, сетки уже делают обратные вызовы. Для всего остального, если есть обратная передача, в подавляющем большинстве случаев вам все равно нужно обновить большую часть страницы, потому что элементы управления изменяют видимость / доступность для записи / и т.д. И это медленно.
Vilx-
3
Каждый раз, когда я вижу приложение ASP.NET, в котором кто-то размещает все на странице в панели «Обновления», мне хочется бросить монитор на стену>. <! Это побеждает в значительной степени всю цель ASP.NET. Для поддержки жизненного цикла и событий приложения на стороне сервера необходимо, чтобы он обменивался данными по всему ViewState страницы. Если у вас есть 200 элементов управления и сетка данных, Джоэл Спольски не предскажет, что у вас будут серьезные проблемы с производительностью. Эд Вудкок и AmmoQ прекрасно все суммировали, поэтому мне не нужно давать вам дополнительный ответ.
maple_shaft
1
@maple_shaft - Извините, но я на самом деле профилировал этот материал. Это было / медленно на локальных компьютерах разработчиков, и Fiddler ясно показал, что HTTP-соединение было открыто менее чем за секунду, в то время как страница появлялась только через несколько секунд, и все это время браузер использовал столько процессора, сколько мог получить и был в основном заморожен. Это не раздутый Viewstate, это раздутый HTML / Javascript.
Vilx-
1
@ Vilx - нет ничего плохого в C # /. NET (кроме Windows / стоимость). Существуют большие проблемы с раздуванием, которое ASP.NET WebForms ставит поверх этого. Как уже упоминалось, попробуйте Нэнси, если вам нравится .NET. Но это совершенно не по теме, это был просто комментарий, что вам будет лучше, если вы перестанете использовать
веб-формы

Ответы:

10

Linkedin делает это для своего мобильного сайта (см. Http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile часть 4), и это, очевидно, было очень полезно для них с точка зрения производительности.

Однако я бы посоветовал вам не делать то же самое по разным причинам.

Во-первых, это удобство обслуживания: C # / ASP.net является серверной средой, независимой от клиента, тогда как Javascript нет (даже с такой средой, как jQuery, вы не получите 100% кросс-браузерную совместимость). , а не на будущее). Я бы сказал, что также легче проверить функциональность статически типизированного приложения, чем динамического, и это то, что вы обязательно должны учитывать при создании крупных сайтов.

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

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

Что касается ваших маркированных проблем:

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

  • Простота разработки тоже не является проблемой, на мой взгляд, есть очень хорошие инструменты, доступные для разработки на JS, не просто включите себя в VisualStudio, потому что вы к этому привыкли! (попробуйте JetBrains WebStorm, например).

  • Производительность движков JS View в большинстве случаев абсолютно хорошая (опять же, по моему опыту), я интенсивно использую их в повседневной работе. То, что я хотел бы предложить, - это избегать более тяжеловесных фреймворков, таких как knockout.js и т. Д., И вместо этого стремиться к чему-то вроде движка микропрограмм Jon Resig. Таким образом, вы можете подключить вспомогательный код так, как вы уверены, что это быстро и надежно.

То, что я сделал бы, если бы я был тобой, действительно изучило бы причины этого перехода; Вполне может быть, что вы просто не используете эффективно .NET и нуждаетесь в улучшении своей игры, WebForms не является особенно медленной интегрированной средой, поэтому, возможно, некоторые из сторонних библиотек вы используете замедляют ваш рендеринг.

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

Эд Джеймс
источник
Нет, как я уже прокомментировал ответ Darknights, это внутреннее приложение, без (ну, мало) общедоступной части, поэтому JavaScript-зависимость в порядке. И я сделал профилирование. На стороне сервера это хорошо. Это клиентская сторона, которая ломается под тяжело сгенерированным HTML (как я уже говорил, сгенерированная разметка ASP.NET мрачна) и Devexpress Javascript.
Vilx-
1
Веб-сайты @EdWoodcock ASP.NET по своей природе основаны на Javascript. Это то, как он обрабатывает асинхронный обмен данными ViewState и рендеринга элемента страницы.
maple_shaft
@ Vilx- Это может быть шоком, но элементы управления, такие как Data Grids, чрезвычайно сложны. Возможно, у вас просто слишком много элементов на одной странице?
maple_shaft
@ Vilx - Возможно, пришло время взглянуть на использование вашего элемента управления, если они генерируют сумасшедшую разметку (в большинстве случаев стандартные элементы управления asp.net этого не делают, если вы используете такие вещи, как Repeaters вместо DataGrids и т. Д.), То, возможно, Вы должны свернуть свои собственные элементы управления (или вместо этого перейти на рукописный HTML в UserControls).
Эд Джеймс
1
@maple_shaft - Или, точнее, Flex, который (как я понимаю) построен именно на Flash именно для таких целей. Это еще одна идея, с которой я играю некоторое время. Но ... как бы я ни пытался упомянуть об этом другим, я получил только отрицательный ответ, поэтому я не могу себе представить, как это протянуть. Это также потребовало бы от всех нас изучения чего-то совершенно нового.
Vilx-
8

Используйте ExtJS если вы хотите пойти по этому пути, не изобретайте велосипед. Но будьте готовы, это означает полное изменение парадигмы. Ваши навыки HTML почти устарели. AJAX везде, сервер в основном предоставляет AJAX API. Вы напишете намного больше javascript, чем когда-либо, поэтому лучше убедитесь, что вы действительно подходите под javascript.

user281377
источник
1
Мне очень удобно с Javascript. Я знаю, что некоторые другие не так.
Vilx-
2
Я делал это в течение нескольких лет на предыдущей работе. ExtJS очень хорош, и вы можете сделать с ним огромное количество.
Захари К
@ZacharyK - Как это работает на действительно сложных формах? Те, которые я там написал, с несколькими видами сетки, панелями табуляции и т. Д.?
Vilx-
2
Довольно хорошо. Конечно, вы должны думать о своих моделях данных. Честно говоря, я стараюсь избегать огромных форм и составляю несколько более мелких элементов. Но это меньше связано с ограничениями ExtJS, чем с хорошим дизайном и т. Д.
Захари К
@ZacharyK - Лень повторяться. Прочитайте мой комментарий на ответ Эд Вудкок. Я не могу сделать это проще. :(
Vilx-
8

Команда, в которой я работаю, решила перейти на ExtJS в конце 2008 года. На тот момент у нас было 200 000-строчное PHP-приложение, которое страдало от внешних проблем. Наша ситуация была намного хуже, чем у вас, потому что у нас была действительно плохая управляемая платформа для управления формами, и мы интенсивно использовали iframes для загрузки разделов страницы (визуальная архитектура началась в 2005 году, и команда не знала Аякса, который рано). В любом случае нам пришлось реорганизовать код, так что было проще принять решение о том, чтобы сильно перестроить кодовую базу в первую очередь на стороне клиента.

На сегодняшний день приложение содержит 300 000 строк, из которых 60 000 строк представляют собой код extjs, и примерно 3/4 функциональности было перенесено в ExtJS. Весь код extjs - это одностраничное приложение, но он все еще встраивает некоторые устаревшие формы в iframes. Сначала мы портировали контейнер навигации, а затем перенесли отдельные области функций по частям. Благодаря такому подходу нам удалось включить миграцию extjs в процесс разработки обычных функций, не сильно замедляя нас.

  • Производительность

    Код ExtJS оказался намного быстрее, чем унаследованный код. Старый код был действительно плохим с точки зрения производительности, но, тем не менее, мы довольны результатами. Весь код пользовательского интерфейса - это статический javascript, поэтому он кешируется действительно хорошо (мы находимся на стадии планирования его передачи в CDN). Сервер не участвует во внешнем рендеринге, что снижает нагрузку на него. Также помогает то, что ExtJS обеспечивает большой контроль над жизненным циклом пользовательского интерфейса (ленивый рендеринг, простая выгрузка невидимых элементов пользовательского интерфейса). Обычно после начальной загрузки кода (архитектура загрузки по требованию) большая часть времени загрузки экрана тратится на вызов веб-службы для извлечения данных. Сетка ExtJS действительно быстрая, особенно при использовании буферизованных представлений для визуализации видимых строк при прокрутке.

  • Легкость развития

    Если честно, это смешанная сумка. ExtJS - это DSL, это не совсем веб-разработка в традиционном смысле. Нашим разработчикам потребовалось много времени, чтобы по-настоящему изучить API фреймворка, и я не вижу, чтобы эта кривая была менее крутой в других клиентских фреймворках. Каждый в команде должен быть «старшим» разработчиком javascript (как правило, книга Крокфорда не должна содержать никаких секретов). Мы сталкиваемся с проблемами начальной загрузки с новыми разработчиками, потому что опыт на стороне клиента не так широко распространен, как вы думаете, а опыт extjs почти нулевой (в Бельгии, где мы находимся).

    С другой стороны, как только вы освоитесь, опыт разработки очень хорош. ExtJS очень мощный, поэтому, если вы находитесь в пазу, вы можете быстро поднять удивительные экраны. В IDE мы используем PHPStorm, который, как я обнаружил, достаточно компетентен в коде ExtJS.

  • Безопасность

    Безопасность является одной из основных причин создания пользовательского интерфейса на стороне клиента. Причина проста: уменьшение поверхности атаки. API веб-службы, используемые в нашем коде ExtJS, представляют собой гораздо меньшую поверхность атаки, чем уровень пользовательского интерфейса на стороне сервера. ASVS в OWASP указывает, что вы должны проверить правильность всех входных данных на сервере перед его использованием. В архитектуре веб-сервисов легко и понятно, когда и как проводить проверку ввода. Мне также легче рассуждать о безопасности в архитектуре пользовательского интерфейса на стороне клиента. Мы по-прежнему боремся с проблемами XSS, потому что вы не освобождаетесь от кодирования в HTML, но в целом мы гораздо лучше относимся к безопасности, чем на старой базе кода. ExtJS упрощает проверку полей формы на стороне сервера, поэтому мы не сильно страдаем от необходимости писать код дважды.

Джори Себрехтс
источник
Я хотел бы сделать больше, чем просто +1 из-за вашего реального опыта!
Vilx-
4

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

Плюсы:

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

Минусы:

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

Лично я думаю, что если вы пойдете по этому пути, ASP.NET UpdatePanels не правильный путь. Они отлично подходят для частичной адаптации существующих веб-приложений, но все равно отправляют HTML через AJAX, и управление состоянием таким способом может быть довольно сложным. Вам лучше пройти весь путь, обслуживая только статический HTML-документ, а затем использовать библиотеку шаблонов javascript для выполнения HTML-рендеринга; сервер вообще не обслуживает динамический HTML, вместо этого клиент выполняет вызовы уровня бизнес-логики на сервер и получает необработанные данные.

tdammers
источник
1

Да можно но ..

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

Так я создаю большинство приложений в стиле "HIJAX".

Темная ночь
источник
Приложения уже загружены JavaScript и не работают без него. Наши клиенты довольны этим и никогда не жаловались. И, честно говоря, я еще не нашел пользователя, у которого отключен Javascript в этот день и возраст. Также обратите внимание, что эти приложения НЕ нуждаются в каком-либо SEO (это было бы катастрофой, если поисковая система могла бы получить доступ ко всей этой конфиденциальной информации), и НЕ предназначены для использования с мобильных устройств. Мы также думаем о том, чтобы сделать что-то подобное для мобильных устройств, но пока это только на стадии разработки, и мы даже не знаем, будет ли спрос.
Vilx-
2
«И, если честно, я еще не нашел пользователя, у которого отключен Javascript в этот день». Ну тогда привет. У меня установлен noscript, поэтому по умолчанию для меня отключен JavaScript при посадке на новый сайт. И если ничего не работает, я обычно просто закрываю вкладку сайта.
Арх
3
@Arkh, ты думаешь, что ты программист, а не пользователь, в общем плане мы считаем небольшое меньшинство. Давайте не будем превращать это в "JS или не JS?" потому что это было сделано до смерти вокруг этих частей :)
Darknight
1
Люди, которые отключают JS, обычно хорошо знают, что при этом они могут столкнуться с сайтами, которые полагаются на него и поэтому не будут работать. Хотят ли они включить его для определенного сайта, это их выбор, но если они намеренно отключают стандартную технологию, я не возражаю, если они не смогут просматривать сайт. С другой стороны, я не знаю о поддержке JS для программ чтения с экрана. Это может быть более серьезной проблемой. И, конечно же, существует проблема индексации. Но когда кто-то хочет создать приложение, которое не нуждается в индексации и которое в любом случае не будет использоваться слепыми людьми, имеет смысл полагаться на JS.
Андреа
1
maple_shaft ты мне нравишься, поэтому я скажу это красиво, давай не будем идти по этому пути :) спасибо!
Темная ночь
1

Мой сайт все еще находится в зачаточном состоянии, но пока все в порядке. Единственная логика сервера, которая существует на внешнем интерфейсе, - это сопоставления моделей и URL-адреса ajax. Сервер вообще ничего не знает об интерфейсе, который для меня очень прост в обслуживании. Если вы заинтересованы, вы можете проверить мой сайт, который написан на ExtJS http://coffeedig.com/coffee/ . У моего сайта действительно нет проблем с безопасностью, но клиент помогает обычному пользователю путем простой проверки. Я знаю, что злонамеренный пользователь может действительно отправить любой ajax на сервер, поэтому вся логика «безопасности» выполняется на сервере.

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

pllee
источник