Разработка Web-интерфейса с пользователем.

К примеру, вряд ли можно назвать квалифицированным программистом того, кто норовит писать абсолютно все задачи исключительно на Си. Си-программистом — это да (возможно даже супер Си-программистом)

Это спорно. Создаётся впечатление, что Вы в курсе моего отношения к C :-) С другой стороны, нельзя назвать квалифицированным программистом того, кто не владеет C. Ну кто-то там может быть и может считать себя программистом, не владея C, но это его личное дело, пусть считает :-)

Тот же Vue.js предоставляет такие возможности

А где гарантии, что Vue/Angular/React не осчастливит меня своими багами, которые я потом буду вынужден править, отсылать пулл-реквесты и ждать, ждать, пока эти пулл-реквесты не примут? Ну это ясное дело, оупен-соурс, комьюнити, во благо общего дела, миру мир, дружба и т.д. Но мне бы хотелось оперативно решать свои проблемы, а не проблемы хайпового фреймворка.

Настоящий программист должен принимать во внимание полный жизненный цикл разрабатываемого ПО.

Ага, и поэтому настоящий программист должен сторониться хайпо-технологий как огня. Никто не знает, чем закончится история с тем же Vue, и что с ним будет лет через 5. Завтра выйдет версия 3 с новыми кулл-фичами, а версия 2 будет предана забвению (покладут на неё с прибором, образно говоря), например. Я вот это и принимаю во внимание как настоящий программист со своим пафосом.

А где гарантии, что Vue/Angular/React не осчастливит меня своими багами

Гарантия есть: осчастливит.

Завтра выйдет версия 3 с новыми кулл-фичами, а версия 2 будет предана забвению

Безусловно. И придётся делать тяжкий выбор - портировать свой работающий сайт на новую версию, для чего нужно будет проделать труд, а затем сайт начнёт тормозить или сломается, или оставаться без обновлений, в т.ч., безопасности.

Но это не значит пока что, что фреймворки не нужны. Я просто пока не врубился, правильно ли устроен вуй.

А может кто-нибудь сказать, есть ли хорошая обзорная книга по современному вебу. Хочу предпринять вторую атаку на веб. Меня многие упрекали, что взяв вуй для своего сайта, я стал забивать гвозди микроскопом. Не совсем верно, учитывая, что из запланированного была сделана лишь часть. Но в целом мне не понравился результат. То же самое я мог бы сделать на jquery и т.п. за 1/10 затраченного времени, и страницы весили бы 1/10 того, что получилось в итоге.

Т.е. нужен какой-то путеводитель, чтобы я ориентировался в трудозатратах, сегментах рынка, специализациях и т.п. Чтобы было ясно: вот Вордпресс - для того, PHP - для сего, вуй - для третьего.

Понимаю, что прошу нереального, т.к. это как раз та инфа, знание которой отличает неудачников от удачников, но всё же... Вдруг...

Вот та самая херь о чем ты, произошла с первым ангуляром в свое время.

Но это не значит пока что, что фреймворки не нужны. Я просто пока не врубился, правильно ли устроен вуй.

У меня есть подозрения, что правильным он может быть только с точки зрения тех, кто: не знает толком JavaScript и DOM; не знает толком общих техник программирования; тревожится делать что-то самостоятельно, успокаивая себя чем-то вроде «со фрэймворком надёжнее, это же фрэймворк, его вон сколько используют, проверенно, наверное».

А может кто-нибудь сказать, есть ли хорошая обзорная книга по современному вебу.

Вряд ли. Хотя, Mozilla MDN, весьма неплохо повествует :-)

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

Вот смотри, вчера считалось круто использовать Ruby On Rails. Помню, были какие-то серверы с пассажирами, без пассажиров. И многие смотрели на Твиттер как на удачную компанию. Говорит ли это о том, что нужно использовать Ruby On Rails? :-)

Я бы и вчера не стал использовать RoR. vue сам по себе не позволяет решать задачи создания сайтов, а лишь позволяет структурировать свою деятельность по созданию сайтов, не отменяя нужды в знании html/css/dom/js.

Mozilla MDN попадалась уже. Но это явно недостаточно.

Т.е. нужен какой-то путеводитель, чтобы я ориентировался в трудозатратах, сегментах рынка, специализациях и т.п. Чтобы было ясно: вот Вордпресс - для того, PHP - для сего, вуй - для третьего.

Вам все на блюдечке надо?) Так не бывает, тем более в вебе, где все меняется очень быстро. Интернет есть информацию найти проблемы нет вообще никакой.

Найти можно только в случае, если уже знаешь, что искать :) А для общего обзора и понимания, что вообще есть, существует такое понятие, как образование, высшее и специальное. Чтобы избежать забивания гвоздей микроскопом. Пока шарю по курсам... Но по-моему, это злобный офтопик, извините, больше не буду :)

К примеру, вряд ли можно назвать квалифицированным программистом того, кто норовит писать абсолютно все задачи исключительно на Си. Си-программистом — это да (возможно даже супер Си-программистом)

Это спорно.

Это не спорно. Я ж про «программиста» с большой буквы - того, кто головой думает прежде чем приступить к программной реализации очередного проекта, а не хватается за те инструменты, которыми он владеет на текущий момент времени. И еще раз повторяю: настоящий программист должен принимать во внимание полный жизненный цикл разрабатываемого ПО.

Создаётся впечатление, что Вы в курсе моего отношения к C :-)

Да нет - я просто привел пример языка достаточно низкого уровня, которым я хорошо владею и понимаю, когда его можно использовать, а когда - нет )

А где гарантии, что Vue/Angular/React не осчастливит меня своими багами, ... мне бы хотелось оперативно решать свои проблемы, а не проблемы хайпового фреймворка.

Ну т.е. вы на гольном JavaScript/CSS/HTML/DOM напишите SPA-сайт прям надежно и понятно - так, что какой-нибудь Вася, которому достанется ваш «код» на сопровождение, не будет вас потом материть и проклинать ))) Не смешите меня... Это приблизительно так же «неразумно», как настаивать на том, что прикладные задачи лучше писать на Ассемблере ).
Ну а ошибки - они везде есть. Пользуйтесь стабильной версией и храните у себя её исходники - вот и все. Никто не заставляет вас постоянно всё апгрейдить.

Можно сколько угодно ругать Vue.js или что другое, но без этого вы вообще ничего реально жизнеспособного не сделаете по части SPA.

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

Программист с большой буквы - такой же исполнитель, как и программист с маленькой буквы. Для того и для другого есть один фактор, с которым приходится считаться - это время. Хорошо, конечно, когда можно изучать альтернативные технологии и подходы, попивая кофе, сидя, облокотившись спиной к мощному стволу тенистого дуба, иногда поглядывая на спокойную реку, что в 30-ти метрах от комфортного места самообучения. Но такой кайф даётся не каждому, поэтому приходится часто, закатив рукава и в поте лица сидеть в жарком офисном кресле, пописывая на том, чем владеешь.

И еще раз повторяю: настоящий программист должен принимать во внимание полный жизненный цикл разрабатываемого ПО.

Ещё раз повторяю: несомненно. Поэтому надо убедиться, что какой-нибудь Vue протянет весь этот жизненный цикл, не отбросив коньки.

Ну т.е. вы на гольном JavaScript/CSS/HTML/DOM напишите SPA-сайт прям надежно и понятно - так, что какой-нибудь Вася, которому достанется ваш «код» на сопровождение, не будет вас потом материть и проклинать )))

Если код написан аккуратно, то сферический вася будет спокойно с ним работать. Или Вы так в себе не уверены, что считаете, что без какого-либо Vue Вы не способны написать стройный код? Ну меня то Вы не знаете, как Вы можете судить? Поэтому, видно, Вы о себе сейчас говорите?

Можно сколько угодно ругать Vue.js или что другое, но без этого вы вообще ничего реально жизнеспособного не сделаете по части SPA.

А как же Марк Цукерберг или Павел Дуров без Vue.js написали свои сервисы? Ах да, это исключения, а большинство пусть пишет в обнимку с Vue :-)

Ну т.е. вы на гольном JavaScript/CSS/HTML/DOM напишите SPA-сайт прям надежно и понятно

А вы написали на vue прям надёжный и понятный сайт? Я столкнулся с рядом проблем: при нажатии F5 глюки. При наличии кириллических URL-ов глюки. С историей глюки (только не помню, связаны ли они с кириллическими URL-ами или вообще). Три вида шаблонов, хотя хватило бы одного-двух. Некоторые вещи делаются костылями (вот прям сейчас вспоминаю: «если хотите вставить свой JS скрипт в тело скрипта, то вставьте его в заголовок, с пометкой, что на самом деле его нужно вставить не в заголовок, а в тело»).

Это я не только докапываюсь, но и пытаюсь вот так нахаляву стяжать жемчужину мастерства :)

Т.е. не в тело скрипта, а в тело строницы. Очепятка :)

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

Вот именно - есть такой фактор как «время». Порой бывает оптимальнее по времени освоить новый, более подходящий для задачи инструмент, чем пытаться сделать всё по-старинке, чтобы потом выбросить за ненадобностью.

...Поэтому надо убедиться, что какой-нибудь Vue протянет весь этот жизненный цикл, не отбросив коньки.

Застолбили стабильную версию и работайте на ней. Исправляйте ошибки, если нужно. Вы, похоже, невнимательно читаете комментарии.

Если код написан аккуратно, то сферический вася будет спокойно с ним работать.

Сразу видно, что вы не имеете реального представления об объеме и сложности кода, который вам придется накропать при реализации SPA. Вы, видимо, клепали какие-то свои UI-компоненты для обычных, классических сайтов и по инерции считаете, что и в SPA всё так же просто и незатейливо - а там объем «низкоуровневого» кода будет просто неподъемным для дальнейшего сопровождения другими людьми. Через пару-тройку лет, когда у вас всё вылетит из оперативной памяти, вы сами не сможете работать с собственным кодом - про «сферического васю» я уж не говорю.

А как же Марк Цукерберг или Павел Дуров без Vue.js написали свои сервисы?

А что, они писали SPA-сервисы? Видите, вы уже тут по ходу дела забываете, о чем собственно идет речь - непрофессионально...

Вот именно - есть такой фактор как «время». Порой бывает оптимальнее по времени освоить новый, более подходящий для задачи инструмент, чем пытаться сделать всё по-старинке, чтобы потом выбросить за ненадобностью.

Время - это один из факторов, но самый главный. И как мне выбрать из десятка фреймворков, когда через пару месяцев мне нужен результат? Чтобы остаться программистом с большой буквы, следует подойти к делу со всей серьёзностью - изучить все имеющиеся готовые решения, сравнить и сделать вывод о самой подходящей технологии. Так? Или вот надо прям сказать себе «Vue!», или «React!»? А как же остальные фрэймворки? Но ведь на это надо время. Мой вывод такой - лучше писать самому.

Застолбили стабильную версию и работайте на ней. Исправляйте ошибки, если нужно. Вы, похоже, невнимательно читаете комментарии.

А что, в стабильных версиях ошибок нет? Любая стабильность - это всегда условность.

Сразу видно, что вы не имеете реального представления об объеме и сложности кода, который вам придется накропать при реализации SPA.

Да, мне не приходилось ещё делать SPA Web-приложение. Но где я вообще говорил про SPA? В топике не говорил, ну да ладно.

Вы хотите сказать, что DOM API - это настолько сложно?

Вы, видимо, клепали какие-то свои UI-компоненты для обычных, классических сайтов и по инерции считаете, что и в SPA всё так же просто и незатейливо - а там объем «низкоуровневого» кода будет просто неподъемным для дальнейшего сопровождения другими людьми.

Нет, когда-то давно я делал компоненты на JavaScript. Подход был таким - класс - это компонент. Никаких бредней в стиле MVC (кошмар, да, представление и модель смешивались в одном классе).

Через пару-тройку лет, когда у вас всё вылетит из оперативной памяти, вы сами не сможете работать с собственным кодом - про «сферического васю» я уж не говорю.

А с Vue не вылетит?

А что, они писали SPA-сервисы? Видите, вы уже тут по ходу дела забываете, о чем собственно идет речь - непрофессионально...

Ну а Вы топик не осилили прочитать. Я про SPA ничего и не говорил. Это во-первых. А во-вторых, дело не в том, в рамках какой парадигмы/подхода писали Дуров с Цукербергом, в том, что они писали свой код сами. Без фреймворков. Зато сейчас миру явлен React, «без которого никак» :-)

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

Если речь идет о SPA, то с вашими подходом лучше не браться за такие задачи - за два месяца вы всё равно ничего путного не успеете сделать.

Да, мне не приходилось ещё делать SPA Web-приложение. Но где я вообще говорил про SPA? ...

Ну вы же вступили в дискуссию в ответ на моё замечание: «... Только вот SPA-сайт чисто на таком наборе уже не сделаешь - для этого и служат «тяжелые» фреймворки типа Vue.js и пр.» Это же ваши слова: «Почему не сделаешь? ...». Собственно, с этого разговор и пошел. Где логика?

А с Vue не вылетит?

А с Vue вы будете иметь компактный, читабельный код, с которым можно будет работать и вам (когда все забудете) и другим программистам.

дело не в том, в рамках какой парадигмы/подхода писали Дуров с Цукербергом, в том, что они писали свой код сами. Без фреймворков. Зато сейчас миру явлен React, «без которого никак» :-)

Ну так почему появились React, Vue и пр.? Просто при реализации современных веб-интерфейсов люди - замечу, весьма профессиональные - упёрлись в определенные границы сложности, когда стало очевидно, что без новых инструментов дальше «никак». А вы как раз утверждаете, что можно и дальше пилить по старинке.

... Хочу заметить, что я нисколько не пытаюсь отправить «в топку» обычные, классические сайты, где HTML-ка генерится на сервере. Более того, прежде, чем хвататься за SPA, нужно хорошо подумать и взвесить все за и против.

... Хочу заметить, что я нисколько не пытаюсь отправить «в топку» обычные, классические сайты, где HTML-ка генерится на сервере. Более того, прежде, чем хвататься за SPA, нужно хорошо подумать и взвесить все за и против.

Да вот я уже и думаю, а не наклепать мне компонентов хотя бы на том же цепепе.

Я столкнулся с рядом проблем: при нажатии F5 глюки. При наличии кириллических URL-ов глюки. С историей глюки (только не помню, связаны ли они с кириллическими URL-ами или вообще).

Что касается глюков с F5 и историей - пользуйте HTML5 History Mode. Всё должно работать - естественно, за исключением старых веб-обозревателей, где нет поддержки history.pushState().

Что касается кириллических URL-к, то это, скорее всего, результат вашей неправильной работы с ними в среде веб-обозревателя. В HTTP-запросах они ведь бегают в закодированном виде - с процентиками, а не в UTF-8. А router вы программируете в Javascript-е уже в UTF-8. Наверное, здесь что-нибудь не срослось - нужно «ручками» переводить в UTF-8. Но это мои догадки...

Три вида шаблонов, хотя хватило бы одного-двух

Используйте то, что более технологично и удобно :) Это вообще смешная претензия.

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

Единственное, что стоит еще отметить: если вы решаете использовать Vue.js, то вы отсекаете поддержку старых веб-обозревателей. Об этом нужно вежливо предупреждать соответствующих посетителей сайта.

Я не такой уж и ярый апологет Vue.js - просто пришлось работать с чужими исходниками и это не вызвало отторжения. Штука весьма элегантная - очень хорошо продумана. Ничего особо лишнего нет, всё по делу - именно то, что и нужно для frontend-части. Сразу видно, что Vue.js проектировал человек с незашоренными мозгами - нет всякой притянутой «за уши» лабуды типа MVC )))

Более того, прежде, чем хвататься за SPA, нужно хорошо подумать и взвесить все за и против.

А почему вообще пришли к SPA? (Если не принимать в расчёт разгрузку серверов за счёт клиентских мощностей.) Ведь даже поисковые боты до сих пор с SPA работают не ахти.

А почему вообще пришли к SPA? ...

На самом деле, это очень удобный вариант чисто в организационном плане. Есть backend-программист, есть frontend - между ними заранее проработанная спецификация API и изначально спроектированная схема базы данных. На эти участки работы спокойно можно подряжать независимых разработчиков - не требуется какой-то плотный контакт между ними.

Кроме того, SPA можно довести до уровня продвинутого web-приложения, практически ничем не отличающегося от мобильного приложения - не нужно тратится на всякие дополнительные мобильные примочки к сайту.

По части SEO - это да, пришлось повозиться. Тем не менее, удалось проиндексировать сайт во всех основных поисковиках - роботы бегают, в выдаче идут нормальные URL-ки без всяких hashbang-ов.

Вот исходники моего сайта, чтобы говорить предметно: https://bitbucket.org/budden/ppr

Что касается глюков с F5 и историей - пользуйте HTML5 History Mode.

Спасибо, если ещё вернусь к нему, то попробую.

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

Нет.

https://github.com/vuejs/vue/issues/5655

https://github.com/vuejs/vue-router/issues/838

В последнем вроде есть какой-то workaround, но он появился уже после моих копательств.

Используйте то, что более технологично и удобно :)

Нет. Это не то, что «присоедините к vue свой любимый шаблонизатор», хотя для какого-то из случаев, может быть, такое и есть. Для разных вариантов использования нужны разные виды шаблонов, деталей уже не помню.

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

Это я понимаю. Потому и спрашиваю :)

если вы решаете использовать Vue.js, то вы отсекаете поддержку старых веб-обозревателей

Это, кстати, мне тоже сильно не нравится. Потому что это «обновите ваше ПО» - это мафия, которая пришла за деньгами всех пользователей, в т.ч. и за моими. Хотя понятно, что какие-то «2%» всё равно придётся отсечь. Но я бы хотел создавать как можно более совместимый код, и vue мне это не даёт делать.

Есть backend-программист, есть frontend - между ними заранее проработанная спецификация API и изначально спроектированная схема базы данных. На эти участки работы спокойно можно подряжать независимых разработчиков - не требуется какой-то плотный контакт между ними.

Не уж то этого же самого нельзя достичь путём использования HTML/JSON-шаблонов на стороне сервера? Будет, опять же, договорённость о переменных в шаблонах. Ну и у frontend-разработчика будет возможность делать Ajax-запросы как за готовым HTML (для .innerHTML), так и за JSON.

Кроме того, SPA можно довести до уровня продвинутого web-приложения, практически ничем не отличающегося от мобильного приложения - не нужно тратится на всякие дополнительные мобильные примочки к сайту.

Это аргумент, конечно. Но зависит от приложения. Если это нагромождение форм (аля очередной магазин), то тут Vue/React и др. рулят. А если это какая-то игра или 3d-модель на WebGL? Тут я не берусь судить зачем вообще нужны фреймворки типа Vue.

По части SEO - это да, пришлось повозиться. Тем не менее, удалось проиндексировать сайт во всех основных поисковиках - роботы бегают, в выдаче идут нормальные URL-ки без всяких hashbang-ов.

Мне приходит на ум лишь генерация статической версии сайта. Опять же, всё равно 2 версии сайта - для SEO и для десктопа/мобильника. Так что я даже и не знаю теперь, а что уж такого крутого в SPA.

На эти участки работы спокойно можно подряжать независимых разработчиков - не требуется какой-то плотный контакт между ними.

Несмотря на отсутствие у меня большого опыта в области web-разработки, я, тем не менее, не верю в эти разделения и отсутствие плотных контактов. С организационной точки зрения я считаю это даже глупым (т.е. я бы не стал разделять команду на сектора frontend-разработчиков и backend-разработчиков - давайте ребята, каждый сектор сам по себе, гребите). Как раз таки все должны быть в курсе обо всём. Это один из принципов SCRUM, который я считаю очень правильным. Я полагаю, что если все работают над одной и той же системой, то все должны быть хотя бы иметь представление о том, что и как творится в на стороне клиента и сервера. Постоянные контакты и общение не только нужно ограничивать, а, наоборот, способствовать. Вся эта идея разделить труд и сделать из программистов маленьких и взаимозаменяемых винтиков исходит из экономической целесообразности. Однако же, даже с этой точки зрения, можно увидеть недальновидность подхода - творческие люди не горят желанием быть «винтиками», что сказывается на результате, особенно, если в ход идёт и ещё какой-нибудь KPI (кстати, из того же огорода, что и подход с разделением труда). Но платить то им всё равно надо, несмотря на результат.

https://github.com/vuejs/vue/issues/5655
https://github.com/vuejs/vue-router/issues/838

Попробуйте:

const routes = [
  { path: encodeURI('/роут1'), name: 'foo', component: Foo },
  { path: encodeURI('/роут2'), name: 'bar', component: Bar }
]

Ну и во втором примере аналогично. Только там еще добавить:

template: '<div>{{decodeURI($route.path)}}</div>',

Тогда все работает.

Не уж то этого же самого нельзя достичь путём использования HTML/JSON-шаблонов на стороне сервера? Будет, опять же, договорённость о переменных в шаблонах. Ну и у frontend-разработчика будет возможность делать Ajax-запросы как за готовым HTML (для .innerHTML), так и за JSON.

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

Несмотря на отсутствие у меня большого опыта в области web-разработки, я, тем не менее, не верю в эти разделения и отсутствие плотных контактов.

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

По части SEO - это да, пришлось повозиться...

Мне приходит на ум лишь генерация статической версии сайта. Опять же, всё равно 2 версии сайта - для SEO и для десктопа/мобильника.

Ну, версия сайта одна :). Просто для поисковых ботов на сервере автоматически (непосредственно в момент запроса) формируются статические варианты соответствующих страниц (HTML-снапшоты) путем использования headless-броузера - HTML-ки извлекаются из него после отработки frontend-части, когда весь нужный DOM уже сформирован. На эту тему я ссылочки выше уже приводил. Это, конечно, дополнительная суета...

Ну я сделал какой-то свой workaround, у меня работает. Сейчас уже не помню деталей. Но статус проблемы 838 - «открыто», т.е. проблема на сегодня полностью не решена. Возможно, осталась проблема, что нельзя назвать файл с компонентом в кириллице. Это некритично, но неудобно.

Просто для поисковых ботов на сервере автоматически (непосредственно в момент запроса) формируются статические варианты соответствующих страниц (HTML-снапшоты) путем использования headless-броузера

Так вот как раз вуй и претендует на решение этой проблемы с помощью SSR (насколько я понял, SSR основан на абстракциях, заложенных в vue, а не на headless-браузере). Что затрудняет его использование. Поскольку контекст в браузере и на сервере - разный. Т.е. да, дополнительная суета. Идеальное техническое решение - такое, которое максимально автоматизирует эту суету и делает удорожание минимальным. Вуй пытается это сделать, но я пока далёк от понимания, насколько хорошо это получилось. Учитывая текучесть всего в вебе, я бы строго предпочитал простые решения.

И опять же, если смыслом SPA является сокращение трафика, то не факт, что эта цель вообще достигается. У обычного веба тоже есть кеширование, которое позволяет не подгружать картинки по много раз.

Зато страница SPA при первой загрузке получается во много раз тяжелее простой страницы. Из серии «весь день промучаемся, а потом за 5 минут долетим». А поскольку эта технология ещё и очень сложная, то надёжность должна пострадать.

Ну, версия сайта одна :)
Это, конечно, дополнительная суета...

В общем, из того, что я понял: - если существует необходимость в создании навороченного пользовательского web-интерфейса, то фрэймворки типа Vue могут быть полезными, т.к. позволяют упорядочить исходники и сделать их проще для понимания. - если необходимости в создании навороченного пользовательского web-интерфейса нет, то фреймворки типа Vue не нужны; - в любом случае можно делать простые Ajax-запросы, на каждый из которых должен существовать обработчик на стороне сервера; - в любом случае необходимо писать серверную часть и в случае с Vue, и в случае без Vue. Объём серверной части в случае с Vue незначительно меньше, чем без Vue - ко всем тем же обработчикам запросов просто добавляется ещё и генерация HTML для отдельных страниц.

Учитывая, что большинству пользователей абсолютно не важно, будет ли сайт сделан как SPA или MPA, а также с учётом того, что SPA создаёт определённые проблемы с поисковиками, а также утяжеляет код страниц (одаривая его попутно возможными багами фрэймворков), можно прийти к выводу о нецелесообразности применения SPA-архитектуры, если нет особой необходимости в создании навороченной клиентской части, либо в маскировании web-приложения под нативное мобильное приложение.

Так вот как раз вуй и претендует на решение этой проблемы с помощью SSR

SSR - это уже лишнее. Проблему пререндеринга для поисковых ботов правильнее решать другим способом - независимо от Vue. Это моя такая субъективная точка зрения. Как-то обошлись без вуевского SSR.

И опять же, если смыслом SPA является сокращение трафика ...

Смыслом SPA не является сокращение трафика. Cмысл SPA - в приближении пользовательского веб-интерфеса по качеству к десктопному.

Зато страница SPA при первой загрузке получается во много раз тяжелее простой страницы...

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

SSR - это уже лишнее.

Ну я понял твою идею с headless браузером, но SSR - это одно из рекламируемых преимуществ вуя. Т.е. твоя точка зрения не обязательно разделяется всем рынком. И оно не только для SEO, но и для ускорения загрузки. Представь себе, к примеру, что пинг около секунды. Это реальность для меня - я иногда использую спутниковый канал связи :)

Смыслом SPA не является сокращение трафика. Cмысл SPA - в приближении пользовательского веб-интерфеса по качеству к десктопному.

Как я понял, по сути, чтобы страничка не смаргивала при каждом нажатии кнопки. И только что узнал, что оказывается всякие там mail.ru и gmail - это SPA. Но я помню и то, что чем позже версия, тем она тормознее :( Меня не напрягало смаргивание при открытии письма, а вот общие тормоза меня напрягают.

Меня не напрягало смаргивание при открытии письма, а вот общие тормоза меня напрягают.

Теперь вместо смаргивания крутят спиннер. Это победа. В агитках пишут, что жс молоть на клиенте быстрее, чем грузить и отрисовывать новую страницу на каждый чих. Так бы оно и было, если бы вебельщики писали на winapi dom api. Но тут на сцену выходят фреймворки, и пошла плясать губерния. И еще, ожидание ответа от сервера никуда не делось, так что работать как с локальным гуем не выйдет в любом случае.

Да, причём спиннеры последнее время пошли какие-то гадкие, нужно больше действий мышью, чтобы куда-то попасть. Но это уже вопрос неправильного проектирования, я так думаю. Или можно так, по конспирологически: людей стало много, девать некуда. Войну страшно. Сначала придумали 7-летку, потом 10-летку, потом 11 лет и 5 лет ВУЗ. Потом придумали пилинг, спа, спорт-бары и кайтинг. Но людям всё равно было нечего делать. Тогда придумали веб-интерфейс и гендер. Первый занял оставшееся время, а второй наконец-то должен решить проблему численности населения.

если бы вебельщики писали на winapi dom api.

Что это?

SSR - это одно из рекламируемых преимуществ вуя. Т.е. твоя точка зрения не обязательно разделяется всем рынком. И оно не только для SEO, но и для ускорения загрузки. Представь себе, к примеру, что пинг около секунды. Это реальность для меня - я иногда использую спутниковый канал связи :)

Насчет SSR - время покажет... Мой прогноз - SSR не покатит. Это избыточно лишнее усложнение процесса веб-разработки + плюс избыточно лишние сервисы на стороне сервера, участвующие в обслуживании каждого HTTP-запроса, причем, сервисы неизвестной степени надёжности (а требования к надёжности работы серверной части совсем другие...). В определенных частных решениях такой подход, конечно, будет использоваться - именно там, где супер-ускорение загрузки первой страницы ну очень критично. Основная же общественность просто продинамит всех посетителей с двухсекундным пингом :) Ну и есть классическое сайтостроение...

Более конструктивное решение для большинства в плане SPA - это что-то вроде Prerender.io. Как только до Гуглов и Яндексов дойдет, что в случае SPA аналоги HTTP-кодов (404, 30X и пр.) логичнее и правильнее получать непосредственно от frontend-части, они сами начнут выполнять те же функции, что сейчас выполняет Prerender.io и аналогичные сервисы. Всё встанет с головы на ноги. По сути, поисковики уже заявили о таком своём намерении, им не хватает сообразиловки сделать последний логичный шажок.

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

Это слишком примитивное понимание. В случае SPA вы можете писать вполне полноценные веб-приложения, которые частично потеснят традиционные мобильные приложения. В этом плане сейчас идет активное наращивание и стандартизация броузерных API-шек.
Это извечная борьба парадигмы тонкого и толстого клиентов и чисто серверных решений для всяких пользовательских приложений.
Всё, как всегда, развивается по спирали... )))

на ЛОРе есть раздел Web-development. не засоряйте основной Development вебнёй, пожалуйста.

и модераторы могли бы это перенести куда следует.

на ЛОРе есть раздел Web-development. не засоряйте основной Development вебнёй, пожалуйста.

Если это всё, что Вы можете сказать по данной теме, то счастливого пути. Работка web-приложений - это очень сложная, ёмкая и интересная тема. Ничем не уступает скучным, банальным и однообразным каким-нибудь аллокаторам или убогим шаблонам цепепе.

и модераторы могли бы это перенести куда следует.

Ахаха :-)

вот и обсуждайте это своё «сложное-ёмкое» в соответствующем разделе. а тут не надо засирать.

вот и обсуждайте это своё «сложное-ёмкое» в соответствующем разделе. а тут не надо засирать.

Открывайте свой ЛОР и там командуйте. А тут есть кому это делать.

Я уже устал сыпать смайликами в скучные темы ламерков про банальные проблемы убожества Си и цепепе. Тут хоть есть о чём новом поговорить, не то, что про какие-нибудь проблемы ламерков в части исключений против кодов ошибок в 10050000 раз.

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

а если есть желание просто трепаться - в толксы.

А почему вообще пришли к SPA? (Если не принимать в расчёт разгрузку серверов за счёт клиентских мощностей.) ...

Забыл еще один момент пояснить. Дело в том, что изначально предполагалось сделать публичный сайт и специализированные мобильные приложения под Android и iPhone, предоставляющие определенный сервис бизнесу, которые собственно и должны были обеспечить монетизацию. По ходу дела стало ясно, что денег на всё это не хватит - вариант с веб-приложением оказался более практичным и бюджетным. В общем-то, веб-приложение полностью обеспечило необходимый функционал.

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

вот и делайте это в соответствующем разделе.

Буду делать это там, где сочту нужным :-)

но я захожу в девелопмент и вижу... вебню

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

а если есть желание просто трепаться - в толксы.

Ну так отправляйтесь туда скорее :-)

вариант с веб-приложением оказался более практичным и бюджетным

Даже с учётом того, что пришлось обеспечивать нормальную индексацию поисковиками?

а так ли уж нужно клепать именно мобильные приложения?

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

Даже с учётом того, что пришлось обеспечивать нормальную индексацию поисковиками?

Ну, для веб-приложения индексация вообще не требовалась - там вся логика за логином. А для сайта это не настолько напряжные трудозатраты: аккуратно написать скрипт на Javascript для PhantomJS, написать вызывалку PhantomJS на PHP и сделать соответствующую настройку в NGINX, ну и во фронте обеспечить формирование соответствующих метатегов.

Если на клиенте выполняется множество вычислений, то ... Ну а если приложение - это просто интерфейс к витрине интернет-магазина ...

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

аккуратно написать скрипт на Javascript для PhantomJS, написать вызывалку PhantomJS на PHP и сделать соответствующую настройку в NGINX, ну и во фронте обеспечить формирование соответствующих метатегов.

Мне в таком подходе не нравится: а) зависимость внешних облачных сервисов; б) есть ощущение, что все подобные сервисы устареют намного быстрее, чем классический подход MPA.

Прелесть в том, что вы сразу получаете приложение, которое работает на всех платформах.

Так вот же, заманчиво!

Мне в таком подходе не нравится: а) зависимость внешних облачных сервисов; б) есть ощущение, что все подобные сервисы устареют намного быстрее, чем классический подход MPA.

Так мы не связывались ни с какими облачными сервисами - просто сами реализовали тот же самый сервис чисто для себя. По тем же соображениям - так оно надежнее... Все крутится на одном сервере.

Я не понял. Откуда Prerender.io возьмёт этот статический HTML? Он загрузит страницу в headless browser и возьмёт из неё свойство asHtml или как оно там называется, сериализовав полученный DOM в виде html?

Я не понял. Откуда Prerender.io возьмёт этот статический HTML? ...

Именно так. Загрузит, дождется установки frontend-частью спец-флажка (типа, можно уже) и «снимет» DOM. Во фронте вы можете слегка кастомизировать логику под это дело на основе анализа User-Agent (к примеру, лишнее не генерить, типа, гео-карт всяких). Ну и при сборке frontend-проекта нужно Javascript через транспайлер пропускать - у PhantomJS движок староватый. Я еще у себя из HTML-снапшотов вообще все <script>-теги удалял - чтобы при просмотре страниц из гуглового кэша Vue повторно не запускался и не портил страницу.

там вся логика за логином

Я хотел делать приложение типа википедии. Чем отличается залогиненная страница от незалогиненной? Мало чем: тем, что в уголке нарисовано, что я - это я, и нажав на «меня», можно получить доступ к дополнительному функционалу. Т.е., напрашивается как наиболее эффективный, такой метод генерации этой страницы для слова, допустим, «operator».

Что в этом случае делать? Ведь напрашивается же генерация всей странице на сервере в виде статического html, а к нему приделывается отдельным скриптом (или отдельным макропроцессором) обёртки для добавки меню пользователя. Не?

Как это укладывается в SPA? Страницы, по сути, статические. Индексировать их нужно. С точки зрения трафика много не на экономишь - при переходе на другую статью почти весь контент нужно заменять.

И тут я столкнулся с тем, что вуй скорее мешает, чем помогает. Но это всё же не просто «каталог», а «каталог с довеском».

Загрузит, дождется установки frontend-частью спец-флажка (типа, можно уже) и «снимет» DOM

Т.е. ненадёжность SSR заменяется ненадёжностью Prerender.io + PhantomJS, которую, однако, можно вынести в другое место, где она повредит только работе ботов? Ну, вполне может быть, что так и правильнее.