TL;DR. Актуально ли при создании современного веб-приложения использовать сервер для обработки запроса и рендеринга HTML, в том числе использовать тег form со всеми его возможностями, или от этого стоит отказаться в пользу сервера, реализующего статику и API, а на клиенте использовать асинхронные запросы/websocket?
Когда-то в веб-приложениях для отправки данных на сервер можно было использовать только HTML-формы. Известно, что они ограничены лишь запросами GET и POST. Но, к примеру, в Rails для осуществления методов PUT/PATCH/DELETE используется задание соответствующего значения полю _action, которое приходит на сервер вместе с данными. И сервер занимается рендерингом страниц, обработкой запросов и всем остальным, клиенту достаточно показывать интерфейс пользователю. Позже стали добавлять асинхронные формы и всякие turbolinks, которые на тех устройствах, которые это поддерживали, обеспечивали более быструю работу за счет того, что страница не загружалась полностью, а загружались лишь необходимые данные, причем асинхронно, и отображались без обновления страницы. Но и для старых устройств всё осталось доступным и работало как и раньше.
Сейчас в 2017 году модно создавать веб-приложения, рендеринг которых происходит на стороне клиента, а сервер нужен лишь для отдачи статики и обеспечения API. Я тоже создавал подобное приложение, и использовал тег form лишь потому что этого требовал Bootstrap.
Меня интересует вопрос: нужно ли использовать формы в современном frontend? Я могу одинаково хорошо использовать формы с полем _action для указания необходимого действия (и не только PUT/PATH/DELETE), и Ajax-запросы, и взаимодействие через websocket. Нужны ли формы только для обратной совместимости со старыми устройствами, или у них есть ещё какое-то предназначение? Обратная совместимость добавляет работы: сервер должен одинаково реагировать на пользователя, который может получить ответ мгновенно в виде JSON, а отображением займётся клиентский фреймворк, и на того, для которого нужно отрендерить HTML-страничку, потому что в его браузере выключен JavaScript. Но настолько ли это актуально сегодня?
В настоящее время я работаю над приложением с использованием библиотеки vue.js на фронтенде, мне не особо нужна поддержка старых устройств, но я вижу преимущества рендеринга некоторых частей страницы на сервере: гораздо проще обрабатывать авторизацию, нет "мигания" содержимого страницы, когда оно прогрузилось, а фреймворк ещё нет, что особенно заметно на медленном интернете (вы ведь тоже вставляете все свои скрипты в конце элемента body?) и другие вещи.
Что же лучше использовать в наше время? Понятно что и у того и у того подхода есть преимущества и недостатки, поэтому логично использовать симбиоз: что-то рендерить сервером, а что-то клиентом. Но нужно точно понимать кто за что отвечает. Например взять тот же тег form, нужен ли он в наши дни, или его лучше заменить асинхронными запросами к API?
Как вы считаете, что должен делать сервер, а что клиент? Как бы вы проектировали своё приложение? Моё приложение достаточно простое, но есть люди, которые разрабатывают большие приложения, я думаю им эта тема также будет интересна. Хочется узнать ваше мнение.
То, что вы описали называется SPA. Я сейчас делаю только SPA с API на back и клиент приложением на front.
Мигания можно избежать поставив например при начальной загрузке заглушку лоадер
А вообще для Vue уже есть SSR.
Вы сами ответили себе на вопрос - все зависит от задачи. У всего есть плюсы и минусы. Также нужно учитывать скорость разработки.
Сегодня, впервые пробовал обработку форм во Vue как раз. Стало откровением, что не нужен тег form))) С удовольствием прочитал вопрос и подпишусь. Спасибо.
yurygolikov: правильно написал. Просто дополню, что авторизацию и регистрацию лучше кидать на чистый рендеринг backend. Зачем человеку который случайно зашел на сайт, или просто хочет зарегистрироваться грузить весь проект. Ну и от тэга form не нужно отказываться, хотя бы ради того, что пробегаясь глазами по коду сразу видно где форма работающая с backend, а где просто input, select или другое, что дают некую обработку на "фронте"
да вы просто жжете напалмом отсутствия собственного мышления.
да, я тоже не сразу все знаю, но либо делаю как делается, либо уже знаю в деталях, а в любом случае не спрашиваю черт-ти у кого как НАДО в сферическом вакууме.
Например взять тот же тег form, нужен ли он в наши дни, или его лучше заменить асинхронными запросами к API?
нужны ли сейчас старые автомобили, или лучше заменить их новыми автоприцепами?
Impeeeery: в своём вопросе я указал, что могу написать и так, и так, и есть опыт разработки как одних, так и других приложений. Но вопрос решил задать чтобы узнать мнение сообщества, сталкивались ли они с подобными проблемами и, если да, то как их решили. Конечно ко всему можно прийти самому, заново изобретая велосипед. Но ведь можно прочитать книгу, статью, задать вопрос, и не тратить время на придумывание решения проблемы, которую уже решили до вас.
yurygolikov: SSR не подходит, тк у меня сервер не на nodejs, а отдельно держать инстанс node для SSR, плюс настраивать взаимодействие с имеющимся сервером, мне кажется довольно проблемно.
По поводу SPA: погуглил и понял, что я уже делал такое приложение, там действительно была одна index-страница и набор template-ов для фрагментов страницы. Там и роутинг и авторизация была на клиенте. И я понимаю как можно сделать чтобы для неавторизованного пользователя не тянулся весь проект (как написал Иван Стройкин), а только нужная часть. Но вопрос в том, стоит ли делать именно так? Сейчас я делаю не одностраничное приложение, хотя основные части у каждой страницы будут похожи – тот же header, footer, набор скриптов будет отличаться одним-двумя. Вот в этом и вопрос: стоит ли всё это хранить как разные страницы на сервере, или всё же рендерить на клиенте?
Alik Send: Например на Vue можно компоненты загружать по мере надобности.
На счет отключенного JS. Вы пробовали вообще работать с отключенным JS? Большинство популярных сервисов не работают с отключенным JS. И тут вопрос в контингенте людей - ваших пользователей. https://caniuse.com/#search=es5
По миру в 97% браузеров есть поддержка ES5!
yurygolikov: Вот и я об этом. Но не всё же теперь рендерить на клиенте. Вот вопрос в том, что нужно делать на серве, а что на клиенте? Вернее даже, что должен уметь сервер? Статика+API, или рендеринг шаблона HTML-страницы (для последующего до-рендера клиентом), или рендер страницы полностью? большинство (я в том числе) склоняются ко второму варианту, но нужно понять, что именно должен обрабатывать сервер, а что клиент?
Alik Send: Для SEO лучше рендерить целиком на сервере при первом запросе. А далее уже идут только запросы к API сервера ну и можно еще компоненты клиентского фреймворка отдавать(чтобы грузить фронт фреймворк по частям).
Как по мне, лучше все делать на сервере. Зачем нагружать и садить батарею смартфона/ноутбука, если с этим может справится сервер где-то в нидерландах за 5 баксов в месяц? Да и тем более, у многих "китайфоны", которые после двух месяцев эксплуатации еле дышат.
У меня уже был спор по этому поводу с фронтендщиком, но в итоге каждый остался при своем мнении. Возможно я чего-то не понимаю
Уже писал в ответ teke teke. Я согласен что рендеринг на сервере самое "стабильное" решение, но очень похоже что это устарело в наше время, сейчас вебом правят клиентские библиотеки, с клиентским рендерингом, а сервер нужен только для обмена данными. К тому же так меньше трафика идёт по сети (я думаю это более критично для мобильных телефонов, чем зарядка), соответственно сайт работает быстрее, сервер меньше нагружается и т.д.Так что в обоих подходах есть как плюсы и минусы, но мир всё больше переходит к рендеру на клиенте. И мой вопрос в том, что же стоит обрабатывать на клиенте, а что лучше на сервере?
сейчас вебом правят клиентские библиотеки, с клиентским рендерингом
Может вы примеры приведете, или покажете какие-то авторитетные источники? Сейчас хайп вокруг SPA-ориентированных фреймворков - это да. И чуть ли не каждый второй студент пытается писать свой лендинг на реакте или блог на ангуларе.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.