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

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

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

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

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

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

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 не является особенно медленной интегрированной средой, поэтому, возможно, некоторые из сторонних библиотек вы используете замедляют ваш рендеринг.

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

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

Команда, в которой я работаю, решила перейти на 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 упрощает проверку полей формы на стороне сервера, поэтому мы не сильно страдаем от необходимости писать код дважды.

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

Плюсы:

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

Минусы:

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

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

Да можно но ..

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

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

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

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