Является ли визуализация пользовательского интерфейса через Javascript хорошей идеей?

«Классический» Подход к веб-разработке был в течение некоторого времени тонким клиентом и толстым сервером: сервер генерирует HTML и выплевывает его для браузера только для рендеринга. Но с текущими браузерами (а также из-за наличия хороших библиотек и фреймворков) Javascript теперь работает. Теперь веб-разработчики могут предположить, что их код Javascript будет работать и перестанет беспокоиться.

Это, безусловно, открыло новые возможности для веб-разработки. Приложения теперь могут состоять в основном из содержимого HTML, возвращаемого с сервера и отображаемого браузером, а некоторые пользовательские интерфейсы выполняются на стороне клиента. Клиент может даже запросить у сервера свежие данные для обновления частей пользовательского интерфейса. Но можем ли мы пойти другим путем? Приложение, безусловно, может быть спроектировано как сервер, который использует только самый минималистичный JSON, склеенный вместе с толстым клиентом Javascript, отвечающим за создание и контроль всего пользовательского интерфейса. Да, этот подход может серьезно сломать URL-адреса до такой степени, что люди больше не смогут отправлять указатели, но, безусловно, можно придумать способ обойти это (а для некоторых приложений, таких как программы чтения электронной почты и фидов, это даже не иметь значение).

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

 Gábor Imre25 нояб. 2014 г., 17:15
Для тех, кто все еще находит эту страницу: взгляните наWeb ComponentsКажется, это будет будущее.

Ответы на вопрос(10)

Google GWT делать то, что вы описываете - визуализировать большую часть клиентской части в JavaScript. Некоторая часть крупномасштабного макета по-прежнему отключается с помощью HTML, но интересные моменты выполняются динамически на стороне клиента.

Но GWT использует сгенерированный javascript, а не рукописный. Делать это вручную больно.

которое, я думаю, очень актуально для вашего вопроса - я настоятельно рекомендую его посмотреть.

Высокопроизводительный JavaScript: почему все, что вы учили неправильно

Название немного вводит в заблуждение, но на самом деле он говорит о тех самых проблемах, с которыми вы сталкиваетесь.

где вы можете управлять рабочим столом, JavaScript имеет смысл.

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

Когда вы говорите, что Javascript сейчас работает только благодаря фреймворкам, это не совсем так. IE 6 все еще широко используется, как и старый Safari. Даже FF 2.x и 1.x в некоторой степени имеют приличную долю на потребительском рынке.

Наряду с этим не у всех есть высокоскоростной интернет, который является в значительной степени требованием для многих из этих платформ. Кроме того, хотя большинство библиотек работают с IE 7, для большинства операций это собака.

Что касается размера библиотеки, у нас есть несколько элементов управления .net, которые любят вводить до 1 МБ JavaScript для клиента. Пытаюсь отправить это бабушке.

Наконец, телефоны воспринимают пользователей как основное устройство доступа в Интернет. К сожалению, размер их кеша невелик, и по большей части эти классные javascript-вещи работают не слишком хорошо.

 04 июл. 2009 г., 18:01
К сожалению, побочный эффект посетителя, попадающего на медленный сайт, заключается в том, что он имеет тенденцию не возвращаться. Если загрузка вашего сайта занимает 5 секунд, большинство людей не вернется, если для этого нет веских причин. Например, если они оплачивают счет за воду через ваш сайт.
 04 июл. 2009 г., 05:28
Несколько опровержений: jQuery (в том числе) прекрасно работает с IE6. Высокая скоростьnot Это требование к инфраструктуре, поскольку первая загрузка может занять немного больше времени, а последующие запросы, скорее всего, будут кэшироваться, если ваш сервер не настроен неправильно. Я согласен с тем, что IE медленно выполняет скрипт, но IMO, как правило, хорошо, пользователиshould получить плохой опыт с этими дрянными браузерами, чтобы заставить их обновить. Элементы управления .NET, которые внедряют 1 МБ JavaScript, который вы выбираете для их использования, не обязательно. А что касается телефонов, iPhone или Opera Mobile, сказал Нуфф.

тся впервые, она должна содержать как можно больше информации из URL / Querystring / Post. И затем любые последующие изменения состояния могут быть запрошены и обновлены с помощью Ajax.

Многие люди склонны использовать подход простой загрузки страницы, а затем позволить javascript / ajax выполнять работу по загрузке. Это приводит к тому, что клиент ожидает загрузки страницы, а затем клиент ожидает загрузки данных.

Гораздо лучше просто позволить серверу выполнить начальную загрузку данных и заполнить все элементы пользовательского интерфейса.

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

По большей части современные наборы инструментов почти устранили большинство причуд браузеров. Хотя вы, конечно, иногда можете сталкиваться с проблемами кросс-браузерного рендеринга, это не такая большая проблема, как если бы вы попытались написать все JS самостоятельно. Скорость должна быть приемлемой даже в IE6, хотя в целом вы получите лучшую производительность в последних версиях Safari, Chrome или Firefox. (Я не знаю достаточно о IE7 или 8, чтобы комментировать).

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

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

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

 29 июн. 2009 г., 21:49
Похоже, что так и будет, и это повредит пользователям.
 04 июл. 2009 г., 18:01
К сожалению, побочный эффект посетителя, попадающего на медленный сайт, заключается в том, что он имеет тенденцию не возвращаться. Если загрузка вашего сайта занимает 5 секунд, большинство людей не вернется, если для этого нет веских причин. Например, если они оплачивают счет за воду через ваш сайт.
 01 июл. 2009 г., 14:32
Если вы не используете фреймворк, веб-разработка - это боль, но при правильной фреймворке разница с разработкой десктопа невелика.
 29 июн. 2009 г., 21:15
Я думаю, что приложения GUI на рабочем столе будут исчезать. Или, по крайней мере, все больше и больше будет сделано с помощью веб-технологий. Просто мое мнение, хотя. Я уже использую некоторые из своих внутренних инструментов в AIR, и я с нетерпением жду возможности сделать несколько Python / JS в Appcelerator Titanium.
 29 июн. 2009 г., 22:15
Это общепринятое мнение. Но я думаю, что проблема в том, что его часто доставляют люди, которые больше всего времени проводят в Интернете. Существуют огромные сегменты индустрии программного обеспечения, для которых интернет никогда не будет основным средством.
 04 июл. 2009 г., 05:28
Несколько опровержений: jQuery (в том числе) прекрасно работает с IE6. Высокая скоростьnot Это требование к инфраструктуре, поскольку первая загрузка может занять немного больше времени, а последующие запросы, скорее всего, будут кэшироваться, если ваш сервер не настроен неправильно. Я согласен с тем, что IE медленно выполняет скрипт, но IMO, как правило, хорошо, пользователиshould получить плохой опыт с этими дрянными браузерами, чтобы заставить их обновить. Элементы управления .NET, которые внедряют 1 МБ JavaScript, который вы выбираете для их использования, не обязательно. А что касается телефонов, iPhone или Opera Mobile, сказал Нуфф.

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

 29 июн. 2009 г., 22:15
Это общепринятое мнение. Но я думаю, что проблема в том, что его часто доставляют люди, которые больше всего времени проводят в Интернете. Существуют огромные сегменты индустрии программного обеспечения, для которых интернет никогда не будет основным средством.
 29 июн. 2009 г., 21:49
Похоже, что так и будет, и это повредит пользователям.
 01 июл. 2009 г., 14:32
Если вы не используете фреймворк, веб-разработка - это боль, но при правильной фреймворке разница с разработкой десктопа невелика.
 29 июн. 2009 г., 21:15
Я думаю, что приложения GUI на рабочем столе будут исчезать. Или, по крайней мере, все больше и больше будет сделано с помощью веб-технологий. Просто мое мнение, хотя. Я уже использую некоторые из своих внутренних инструментов в AIR, и я с нетерпением жду возможности сделать несколько Python / JS в Appcelerator Titanium.
Решение Вопроса

кий интерфейс ExtJS поверх веб-сервисов Zend Framework JSON-RPC, реализующий портал гаджетов, похожий на iGoogle.

Преимущества:

Very responsive UI, ExtJS gives you a great user experience. Very predictable client-server communication. Everything's json (easy to debug). There's standardized error handling inherent in the API (at least that's how I designed it). The front-end is replaceable. I could write a C++ app on top of the same server back-end. Separating front-end and back-end across client-server lines means they're easier to test independently. You get to live and breathe javascript, which is great if you like it.

Недостатки:

You have to live and breathe javascript, which sucks if you hate it. In our case this meant a major retraining of the developer team because we were PHP-heavy. Everything lives in a single long-lived DOM, so you have to stay on your toes with memory management and making sure stuff gets cleaned up correctly. Also, loading too much UI makes IE go "ow, ow, you're hurting my brain". There's no running a quick query to fetch an option in the middle of generating the UI. The program design constraints of living on the client are daunting at first. You get used to it, but it's a bit of a hurdle. Loading all that javascript means your users need to have fast connections and modern browsers.

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

Update (september 2013):

Все еще используя эту архитектуру и все еще думая, что это правильная архитектура, если вы создаете подлинное веб-приложение (а не просто веб-страницу с некоторыми динамическими функциями). Наша команда и продукт теперь намного больше (около 500 000 строк кода), но архитектура масштабируется без проблем. В настоящее время существует много действительно хороших масштабируемых фреймворков javascript (angular, ember, ...), поэтому такой способ работы проще, чем когда-либо.

Поскольку @rwoo спросил, некоторые проблемы, которые у нас все еще есть:

On-demand loading of js code turns out to be a trickier problem than foreseen. It's important to get this part right in your architecture. We have had to integrate automatic jshint validation in a pre-commit hook in subversion because js is way too tolerant of syntax errors and you often don't notice this until the product reaches the customer. Because the database is on the other end of a web service request, you have to carefully design your web service API or you will end up with lousy performance due to waiting for too many XHR requests. This is solvable, but challenging, and it doesn't get easier with time. While with the right framework cross-browser issues are minimized, they don't go away entirely which means that you need to test in all browsers, all versions. This is so much work that you have to automate it using something like selenium, and as it turns out this is more difficult to do with a client-side rendered UI than a server-side rendered UI.
 04 июл. 2009 г., 18:04
Если ваша цель состоит в том, чтобы обеспечить пользовательский интерфейс, подобный настольному, то, возможно, вам следует просто создать настольное приложение. Просто скажи ...;)
 21 янв. 2010 г., 14:34
@Dimitri: опыт отладки значительно улучшился за последние несколько лет. Firebug, Chrome Inspector, инструменты для разработчиков IE 8, они все "достаточно хороши". Я также работаю в Delphi и больше не могу отлаживать больше. Если вы вручную кодируете свой макет в CSS, у вас все еще будет ужасный процесс отладки, но этого можно избежать с помощью соответствующих структур.
 21 янв. 2010 г., 16:03
Это звучит многообещающе! Я изо всех сил стараюсь в это поверить ;-) Спасибо, что поделились своим мнением.
 21 янв. 2010 г., 10:42
Я нахожусь на грани запуска отличного веб-порта, но я продолжаю думать, что приложение HTML / CSS / JavaScript - это ужас для отладки. Как вы думаете?
 05 июл. 2009 г., 22:48
На самом деле я создаю эти веб-приложения для замены программного обеспечения для настольных компьютеров, которое мы уже создали. Наши клиенты хотят размещать приложения в открытом Интернете с быстро меняющимися пользовательскими базами (например, внешними подрядчиками), и поэтому они явно просят нас предоставить веб-приложения вместо настольных приложений, которые у нас уже есть. Моя цель с этой новой архитектурой состояла в том, чтобы позволить нам создавать настольные веб-приложения одновременно с созданием нативных настольных приложений.

ExtJS, YUI, школа дзюдо... фреймворки, которые в основном предлагают приложения для реализации, подобные тем, которые вы описываете

Мы (на моем рабочем месте) успешно использовали такой подход для многих маломасштабные приложения ... В целом, большинство наших приложений основано на ExtJS + jQuery, в некоторых случаях на dojo (Zend Framework(если вы вообще заботитесь о мире PHP) обеспечьте удобную интеграцию с элементами dojo)

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

При правильном дизайне это ни тяжело, ни медленно, как подход как таковой.

что веб-разработчики теперь могут "в значительной степени полагать, что их код Javascript работает" С этим трудно согласиться. По моему опыту, Javascript почти всегда является черной дырой, высасывающей все время и энергию, которую вы можете ее снабдить. Фреймворки, такие как Prototype и Script.aculo.us, сделали вещи НАМНОГО лучше, но они еще не настолько упрочнены, как предполагает ваш вопрос.

Два основных вопроса: поддержка браузера и два - время разработки. Вы полагаетесь на приложение, которое не можете контролировать, чтобы справиться с большей частью рабочей нагрузки вашего приложения. Меня может беспокоить тот факт, что это может быть сломано даже при самом незначительном обновлении браузера. Генерация HTML на стороне сервера в значительной степени снижает этот риск. Разработка богатого Javascript-интерфейса занимает много времени, сложна в отладке и не менее трудна для тестирования в широком спектре доступных браузеров.

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

Я думаю, что есть приложения для пользовательского интерфейса на основе Javascript, если решение по этому пути хорошо продумано. Мы бы не обсуждали это на SO, если бы не тот факт, что потенциал пользовательского интерфейса при использовании этой стратегии огромен. Веб-приложения, использующие веб-данные, являются идеальными кандидатами (RSS, REST Services). Приложения, попадающие в реляционную базу данных или сложные веб-сервисы, будут по необходимости поддерживать более тесную связь с серверной стороной.

Мои 2 цента.

Ваш ответ на вопрос