Если динамически тоже можно скриптом.
Почему вручную? Можно написать скрипт
Посмотрел конец второго стрима.....
Ты серьезно думаешь, что для того, чтобы отправлять на сервер не все элементы формы их надо отключать?!!
Задача примитивнейшая и решается совершенно элементарно. Т.е. отправку формы надо взять действительно "в свои руки" при помощи обработчика, но не заниматься хренью с "дизейбл"... А просто сформировать данные формы для отправки в нужной тебе логике. Это же ванильный JS. Ты ж его изучал. Ну провдеди там как ты любишь 100500 экспериментов.. (но я бы просто почитал доку, на крайняк "погуглил" статей на эту тему 100500, т.к. вопрос популярный достаточно у новичков)
В данном случае это вряд ли бы сильно помогло. Говорю как человек, который разбирал одну не полную версию проекта (которая таки была на гитхабе), а потом получил и полную версию на каком то этапе и даже попробовал собрать на ней что то... :)
Начинатся все с того. что у ТС свое видение к стилю кода.. ну а далее принцип "только свои велосипеды" + "доку не читать, все познавать исключительно экспериментами" ... :)
Не только на асме. И делфи и паскаль... да вообще на любом. Проблема жеж была у тебя на дискете (и хорошо если у тебя жир в виде дискеты на 720кб, или комп с двумя дисководами) должна была уместиться операционка, компилятор, желательно IDE, исходники.... :) По сути я не мог потом от этой "парадигмы" борьбы за каждый байт "екзешника" избавиться пока на делфи не перешел, где +- мегабайт вообще пофиг :)
1 В этой в значительно большей мере.
2.
2.1 ecom не весь студийный. Напомню: я варюсь в этой нише не первый год и не в вакууме.
2.2 Ну т.е. есть студии которые на битрикс проектах выставляют ценник k*Х в час, а на остальных X в час (где K>1). Серьезно? Зачем это им?
3.Что "все"? Приходится, конечно, что то разрабатывать под конкретные проекты, но это уже нечто специфичное, что ни в каких маркетах по определению не может быть. Все остальное решается на уровне шаблонов компонентов. Там где взят готовый шаблон сайта из маркета (конечно от нормального разработчика), там вообще уже только какая то специфика остается. и это на практике не одного проекта. (да и с Битрикс проектами я работаю с 2009 года)
В прочем, вернулся я в эту тему не за этим. Как раз таки попросили OpenGraph внедрить в сайт интренет магазина. На интеграцию на динамических разделах ушло пол часа. Справедливости ради, использовал свою наработку из порядка 20 строк кода - добавим еще полчаса (это с огромным запасом, т.к. там логика максимально тривиальная). Еще на статические страницы - там не более часа тоже потребуется. сейчас просто решают оставить там готовый модуль с маркета или нет: к нему есть некоторые претензии, но у него зато есть дополнительная гибкость. По сути просто использовать highload блок для таких страниц. ну пусть еще полчаса докинем. Итого 3 часа с огромным запасом. С учетом того, что в этом решении нет вообще ни чего "экстраумного". Т.е. даже не нужен особый навык программирования. То справится разработчик с ценником сильно ниже 5000руб.час (если я правильно помню вы говорили про 20000)
Взгляните на вопрос несколько глубже. SSR тут вообще не центральный вопрос.
В первую очередь это разделение разработки бека и фронта. И когда над проектом работает команда, то получается серьезный профит. За счет распараллеливания разработки. Т.е. вначале договорились об АПИ взаимодействия. Создали документ его описывающий и далее ведем разработку параллельно. Ранее грани между фронтом и беком были размыты. Что могло вносить проблемы в разработку (грубо говоря: верстальщик подшаманил в файле, потом бек туда же залез и т.п).
Хороший выход получился со SPA, Но тут возник вопрос, что это не годится для сайтов где есть вопросы СЕО. А таким сайтам уже тоже захотелось такого разделения. Вот и появилось понятие SSR для них. Которое решает эту проблему.
Что до производительности. Да есть профит, и не только в отдаче типа статических html (все равно на том же интернет магазине есть достаточно динамики). Тут есть тонкости в том как отдает страницу нода. (тут лучше почитать об этом более подробные статьи если интересно)
А от разделения у нас есть еще один профит. Теперь фронту по барабану что там на беке захтели с wp переделали на битрикс, захотели вообще на Go или java мигрировали. (или вообще один сервис так другой так)
Сам я фулстек. По сути мне удобнее когда только PHP. Но, скажем, Лк для клиентов (что то типа биллинга) я на своем сайте сделал работающий прототип на реакте, сейчас на чисто на вью пишу. И в принципе тоже есть профит (субьективно). как минимум в дополнительном упорядочивании. Но биллинг как раз тот случай, когда SSR не обязателен.
Короче: SSR нет смысла спрашиать , чем он "лучше PHP". Т.к. сравнение идет несколько в другой плоскости. и SSR это лишь следствие того самого выбора
Да щас... На пользователей вываливались эти их разборки... Я конечно писем не сохранил, но тем не менее.
От чего ж. Цена был по сравнению с другими, на сколько я помню, ниже. а так хостинг как хостинг. Не было каких то таких "вау круто".
