Крушения AJAX, грань между серверными и клиентскими сценариями

Question

Я занимаюсь разработкой своего первого веб-приложения уже около двух месяцев (я студент младших курсов, который в основном имеет опыт работы с C и Python, а также с некоторым количеством Java, добавленным для загрузки). До сих пор моя страница работала как тонкий макет HTML (тонкий означает очень простой макет, то есть менее 50 строк HTML), который интенсивно обрабатывается AJAX, в основном с использованием jQuery. AJAX генерируется через. PHP в сочетании с манипулированием SQL. Это веб-приложение будет использоваться максимум 6-10 клиентами (EDIT: пользователи), и кросс-браузерная совместимость является лишь бонусом; кажется, IE7 - самое слабое звено.

Хотелось бы знать:

1. Каковы недостатки использования такого подхода с большим количеством клиентов по сравнению с большим количеством «загрузок» браузера (обратите внимание, что я использую bbq, чтобы справиться с нарушением AJAX back / forward / reload / bookmark / history). Как я, будучи новым программистом, стараясь выработать хорошие практики, должен ли я сосредоточить свои усилия на принципах AJAX?
2. Действительно ли будущее веб-разработки движется к браузеру так же сильно, как и к платформе, как мне кажется? Исходя из моего опыта, кажется, что клиентская часть сценариев в JS делает наполовину приличный инструментарий GUI, а AJAX поддерживает его как простой в использовании слой доступа к данным.
3. Очевидно, что сценарии на стороне сервера всегда будут иметь место. Где действительно сияет сторона сервера? например: а) создание XML, который будет введен через. JS и DOM б) генерирование HTML, который будет введен напрямую (без манипуляций с DOM) c) создание полных страниц, которые можно использовать в iframe.

Я пытаюсь найти баланс, и кажется, что все, что я до сих пор читал, лишено сбалансированной перспективы и просто выдвигает AJAX как конец всего и быть всем.

Answer 1

Вау, это серьезная тема, и так много ответов возможно.

В отрасли Ajax и использование сценариев на стороне клиента представляют собой проблему производительности и удобства обслуживания в качестве графического интерфейса или инструмента удобства использования.Иногда легче (особенно в среде сервера MVC) получить только часть контента, более качественную, чем весь контент.Но это почти вопрос точки зрения

Я постараюсь ответить на ваши 3 вопроса, просто помните, что я похож на вас в том смысле, что я думаю, что во многих статьях или книгах действительно не хватает баланса (очевидно, я тоже):

1. Для меня основным недостатком использования тяжелого JavaScript на клиенте (например, создание всего графического интерфейса в JS) по сравнению с обслуживанием HTML-страниц с сервера является отсутствие контроля над ошибками, малографические ошибки, различия в среде и т. д. В конечном итоге вы действуете как поставщик программного обеспечения, распространяющий настольные приложения, и вы не можете получить реальный контроль над удобством использования на стороне клиента.Конечно, этот недостаток можно почти полностью устранить, используя агонистическую среду браузера (такую ​​как jQuery) и проводя тесты рендеринга во многих средах.Вы должны попробовать оба метода, использование Ajax не всегда лучше и иногда может спасти вам жизнь (создайте динамическое дерево с несколькими вариантами выбора и миллионы ветвей только с HTML).В целом, я применяю это правило: если пользователь меняет экран (то есть между списком и формой), я перезагружаю всю страницу, если не использую Ajax.

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

3. Серверная сторона светитна всех этапах, о которых я говорил ниже, но что касается формата передачи данных, я предпочитаю передавать напрямую HTML в браузер или использовать JSON для любых других структурированных данных, которые мне нужно передать.Использование XML кажется немного многословным для облегченных клиентов.Если вы можете избежать iframe, сделайте это, нет никаких причин использовать их в 99,9% случаев, которые я видел.

В заключение, вы студент, учитесьвещи, которые интересны.Если вы предпочитаете улучшать свои знания на стороне клиента, сделайте это, здесь есть чему поучиться (парсеры HTML, DOM и JS apis, внутренняя часть браузера меня действительно интересует).

Но в компаниях, на которые я работал, вы должны знать, что Интернет - это два значения: общение и поддержка графических интерфейсов бизнес-приложений.В настоящее время я работаю с веб-приложениями (интранет), мы - 3 внешних разработчика, занимающихся PHP и javascript, в то время как 20 человек занимаются серверной Java.Просто чтобы дать вам место, занятое GUI в профессиональных широкомасштабных приложениях.