По SPA приложениям и современным реалиям
 

Народ, всем привет.

Просидел все это время на бэкенде.
Но сейчас (а может и даже совсем не сейчас, а давно) все популярнее подход со SPA, когда бОльшая часть приложения создается например на vue, а бэкенд чисто через rest данные из базы выдает.


Это у меня вызывает несколько вопросов:
1) А что уже не требуется чтобы "сайт" работал в том числе и с отключенным JavaScript?
2) Что насчет индексирования таких сайтов?
3) Или это не для "сайтов" вовсе, а там для админок или приложений?
4) Посмотрел например начало Vue, они там довольно специфичным способом реализуют ту задачу, которая элементарно всегда решалась на php - вывод шаблона
5) Ну допустим то что раньше на php всегда делалось, теперь на vue/js, что с последним JavaScript, появились в нем куча удобных функций по работе со строками/массивами и т.д., как на php или это надо дополнительными библиотеками решать?
6) или 5-ый пункт принято решать вообще каким нибудь препроцессором типа TypeScript?
7) А что там например для vue, такой же огромный выбор всяких плагинов как у jQuery или их предлагается совместно использовать?


p.s. Впечатлило что pgAdmin (pg-постгрес), тот что недавно поставил, тоже уже из браузера работает.

8) Ну и вопрос конечно безопасности. Того что js не защищен от вмешательства в работу, в отличие от php. И сколько там не валидируй на фронте, все равно все это надо дублировать на беке.

1) кроме жуликов вряд ли кто-то будет отключать javascript
2) делается на стороне сервера SSR (server side rendering)
3) для сайтов тоже, SSR опять таки
4) javascript не php, подход другой
5) обычного функционала javascript вполне хватает, (map, filter, forEach, reduce, every, includes ...)
6) без TypeScript можно жить, с TypeScript лучше работает autocomplete
7) jquery не нужен в фреймворках типа react, angular, vue ... плагинов то много, но постоянно выходят новые версии фреймворков, всякие библиотеки должны тоже обновляться, а то могут быть не совместимы с новыми версиями
8) с таким же успехом можно бэк на js написать, и общую валидацию расшарить с клиентом

p.s. уже VS Code в браузере запускается...

Не могу понять как получается что:
- вот эти современные фреймы , как Vue, очень стали востребованными на фронте. Постоянно в требованиях они, даже в требованиях к backend программистам, фулстака по сути требуют
- Но при этом на профильных форумах, по этим продуктам, очень большая тишина.
Даже взять если официальный форум Vue, постоянно темы без ответов. Или вот этот наш форум.
Где все эти люди, которые эти фреймворки используют?

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

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

В этих фреймворках основная проблема это SSR + CodeSplitting, на мой взгляд ни один фреймворк, на данный момент, не предоставляет это из коробки... да, оно в каком-то виде есть, типа запросите все данные перед рендером страницы, и будем вам счастье... или бандл мегабайт... но нам же надо чтобы вложенные компоненты были асинхронными и рендерелись как stream + SSR + CS, для разработки еще и HMR, здесь и начинаются проблемы...

Все это (SSR) нужно в основном для SEO, здесь придется раскашелиться еще на VPS/VDS.

В корпоративном сегменте (Сбер, и т.д.) SSR для внутренних программ не нужен, но там будут другие проблемы: тесты, typescript, генералы и генералисимусы... :)

"Постоянные требования" - тот еще вопрос, один хрен, рано или поздно в голове созреет мысль, что тебя использовали и выкинули )) а ты как был нищебродом хоть за 300, так ты им останешься...

Если б это было так, то и не нужны были бы форумы по ларавел или Yii, но это же не так.
Фреймворки добавляют кучу своего кода, логики, магии и идей и вот по ним неплохо было бы иметь обратную связь.
Я например в Vue, после прочтения документации, даже не понял того момента, что Vue на лету новые объекты делает реактивными(когда присваиваешь их св-ву реактивного объекта), качество документации страдает. Или вот человек спрашивает интересный логический вопрос, а в ответ тишина.
Наверное все таки это.

если бы все было так плохо и не понятно, вряд-ли бы кто-то пользовался этим )

человек больше спрашивает про организацию проекта, и то что он спрашивает не относится к vue в целом, так любой фреймворк бери, и будет тот же вопрос.

https://vuejs.org/v2/guide/state-management.html
https://github.com/vuejs/vuex/tree/d.../shopping-cart
https://vuex.vuejs.org/guide/structure.html

https://apollo.vuejs.org/

https://github.com/vuejs/awesome-vue

Ну то не мой вопрос был, но даже сразу вот по вашим ссылкам, если не считать awesome-vue, в которой надо непонятно как искать:
Эти ссылки не проясняют его вопрос, vuex то он уже выбрал, а в нем этот момент не объяснен.
Вопрос то у него законный: если использовать вот этот паттерн для хранения состояния, то где лучше запускать эти vuex события?
Когда компонент состоит из компонентов, состоящих из компонентов, каждая ли мелочевка должна выстреливать эти события, что проще, но делает их непереиспользуемыми. Или поднимать эти события вверх, уже к логическому компоненту. Может для фронт девелоперов это и очевидные вещи, но мне, например, пока ответ не очевиден.

Делать нужно так, чтобы задача решалась ), на мой взгляд, вот здесь https://www.apollographql.com/blog/d...ement-solution, хорошо описаны все текущие проблемы с управлением состояния (local, remote) пусть там не про vue и vuex, в целом про запросы, кэш, инвалидация, optimistic update и т.д.
Building data layer infrastructure is expensive
и подход заключается в том, есть только один достоверный источник состояния, и хранится он как flat array (все вложенные и связанные объекты хранятся в плоской структуре), и из любого места приложения можно вызвать query, mutation, и не важно переиспользуемые или непереиспользуемые компоненты.