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 сервера ну и можно еще компоненты клиентского фреймворка отдавать(чтобы грузить фронт фреймворк по частям).
делайте на формах. не пихайте js везде, где попало. рендерите страницу на сервере. отдавайте клиенту готовую.
javascript может быть отключен, да. более того, мне кажется, сейчас его даже чаще отключают или блокируют js скрипты и запросы, потому как больше людей становится осведомлёнными про уязвимости и потерю приватности при включенном js.
С одной стороны я согласен с вами, но
1. Не так часто сталкиваюсь с людьми, которые работают с отключенным JS. Вернее до сих пор лично ещё не сталкивался. Приватность беспокоит многих, это да, но у большинства дальше беспокойства дело не доходит. Да и не готовы люди перестать посещать нужные сайты, в обмен на приватность – людям нужен контент, они его получают, а приватность уже как бонус.
2. В наше время очень много JS-библиотек, работающих на клиенте, которые по-сути абсолютно бесполезны, если на сайт зайдёт человек с выключенным JS. Очень много разработок, и сайтов где они применяются, будут бесполезны в таком случае. Но ведь люди разрабатывают и применяют.
Alik Send: Зато я встречал людей, которые по умолчанию отключают. И у самого у меня всякие noscript-ы и requestpolicy. И да, многие сайты ломаются нафиг (но не все!), и приходится лезть в настройки и разбираться - что же этот сайт хочет этакое запустить. Но это только в том случае, если этот сайт действительно важен, и альтернатив ему нет.
А вы вот это свое "сейчас в 2017" перечитаете через пару лет, и будет стыдно. Если непонятно почему, попробуйте загуглить вопросы "сейчас в 2016" или "сейчас в 2015" и так далее.
Stalker_RED: Согласен, всё меняется очень быстро, особенно фронтенд разработка. И хочется сегодня написать такое, за что не будет стыдно через пару лет. Поэтому и спрашиваю совета у умных людей.
Вы все тут слегка увлеклись своими новшествами. Я лично так устал от сайтов которые заставляют мой браузер подвисать выполняя какие-либо запросы на моей стороне, на стороне клиента, напичканные тонной анимаций и других js фишек, которые не нужны для просмотра полезной инфы на сайте. Я ваши сайты "работающие на стороне клиента" вертел сами понимаете =). Не заигрывайтесь пожалуйста.
Зависит от задачи.
Ну скажите на милость, зачем вы будете делать сайт фирмы ПродамВсеОптомВам на AJAX, когда туда заходит 3 человека в год?
Что вы там выгадайте, кроме затрат времени рабочего?
По сути вы ставите вопрос:
Стоил ли в 2017 году все сайты делать по технологии одностраничников SPA.
Ответ - НЕТ.
Вопрос - стоит ли вам специализироваться только на SPA, если вы уж так не любите сервера - ваше дело, если если достаточно заказчиков - отчего бы и нет.
Как по мне, лучше все делать на сервере. Зачем нагружать и садить батарею смартфона/ноутбука, если с этим может справится сервер где-то в нидерландах за 5 баксов в месяц? Да и тем более, у многих "китайфоны", которые после двух месяцев эксплуатации еле дышат.
У меня уже был спор по этому поводу с фронтендщиком, но в итоге каждый остался при своем мнении. Возможно я чего-то не понимаю
Уже писал в ответ teke teke. Я согласен что рендеринг на сервере самое "стабильное" решение, но очень похоже что это устарело в наше время, сейчас вебом правят клиентские библиотеки, с клиентским рендерингом, а сервер нужен только для обмена данными. К тому же так меньше трафика идёт по сети (я думаю это более критично для мобильных телефонов, чем зарядка), соответственно сайт работает быстрее, сервер меньше нагружается и т.д.Так что в обоих подходах есть как плюсы и минусы, но мир всё больше переходит к рендеру на клиенте. И мой вопрос в том, что же стоит обрабатывать на клиенте, а что лучше на сервере?
сейчас вебом правят клиентские библиотеки, с клиентским рендерингом
Может вы примеры приведете, или покажете какие-то авторитетные источники? Сейчас хайп вокруг SPA-ориентированных фреймворков - это да. И чуть ли не каждый второй студент пытается писать свой лендинг на реакте или блог на ангуларе.
Код должен быть семантичным. Это на тему того, что если элемент должен представлять элемент формы, то нужно верстать элемент формы, а не то, что вам кажется более подходящим для этого случая.
И вообще Вадима Макеева на вас нет.
"Доступность или смерть(жизнь?)". Вы должны учитывать ситуации, когда js действительно отключён. Это довольно сложно бывает сделать в связи с тем, что торопит бизнес, в связи с тем, что не всё зависит от вас.
Прогрессивное улучшение, постепенная деградация применимы, я думаю, и в этом случае.
Представьте, что у вас есть форма.
При включённом js вы валидируете данные на клиенте, чтобы не делать лишних запросов.
При валидных данных вы отправляете ajax запрос чтобы не перезагружать страницу и сразу показывать пользователю результат.
При этом вы также валидируете данные на сервере.
При выключенном js данные валидируются только сервером и результат отдаётся путём перехода на другую(или эту же) страницу.
На сервере фактически ничего не меняется, но зато для пользователя есть небольшая плюшка в виде отсутствия ожидания пока сервер обработает данные и ваша страница будет загружена заново.
Возможно это звучит слишком олдскульно - "js только для улучшения", но нет, история не об этом.
История о том, что для каждого конкретного случая всё может быть по-разному, но при этом всегда должен сохраняться здравый смысл у разработчика.
Форма это форма. Если вам нужно значения двух инпутов отправлять с помощью js, то не нужно верстать два поля, кнопку submit и вешать обработчик click на кнопку. У всех элементов есть своё назначение. Оборачиваете, как и надо, ваши инпуты и кнопку в form и вешаете обработчик на событие submit. Всё. Никаких проблем. Js у вас или нет - всё будет работать.
Конечно.
И везде я стараюсь писать адекватный семантичный код, так как вам наверняка будет проще разобраться именно в нём, чем в том, что по моему мнению могло бы заменить семантичные элементы.
Кхм.. Попробую по-другому.
React и Vue позволяют рендерить компоненты с примесью логики и хранения состояния. Это не отменяет того, что эти самые компоненты должны быть реализованы также адекватно, как если бы вы просто верстали сайт и добавляли сверху js логику.
Вообще, чем грамотнее и правильнее вы пишете код, тем проще его поддерживать. И это в первую очередь должно волновать вас и ваших коллег.
Простой
