В данном случае это вряд ли бы сильно помогло. Говорю как человек, который разбирал одну не полную версию проекта (которая таки была на гитхабе), а потом получил и полную версию на каком то этапе и даже попробовал собрать на ней что то... :)
Начинатся все с того. что у ТС свое видение к стилю кода.. ну а далее принцип "только свои велосипеды" + "доку не читать, все познавать исключительно экспериментами" ... :)
Не только на асме. И делфи и паскаль... да вообще на любом. Проблема жеж была у тебя на дискете (и хорошо если у тебя жир в виде дискеты на 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 это лишь следствие того самого выбора
Да щас... На пользователей вываливались эти их разборки... Я конечно писем не сохранил, но тем не менее.
От чего ж. Цена был по сравнению с другими, на сколько я помню, ниже. а так хостинг как хостинг. Не было каких то таких "вау круто".
Безусловно он отразился, если б он не отразился, то и не вспоминали бы. Вопрос в злопамятности и соотнесении уровня "гнева" к реальному уровню потерь: как материальных, так и душевных.
Уровень, как мне кажется, несоразмерен. Вот и задаюсь риторическим вопросом, почему так. Вопрос риторический, потому что ответа на него нет.
Почему вы решили, что есть какой то гнев?
Сложилась конкретная ситуация, владельцы повели в ней себя максимально не правильно. Это не гнев, повторюсь это штрих в их портрете, который, на мой взгляд, стоит учитывать. И не более. Я даже, по большому счету, не агитирую "не пользоваться". Просто есть инфа - я ей поделился. Есть и о других хостерах негативные "штрихи". (Правда этот,пожалуй, самый жирный - хотя ситуации были разные). И там ведь ситуация не только в том, что случился сам конфликт, но и как они работали с клиентами во время и после...
Вспоминают не конфликт - а как он отразился на клиентах. Если бы владельцы не повели себя как в детском саду, клиенты бы, возможно, и не заметили бы ни чего...
вы не внимательно прочитали мое сообщение. Различные "нехорошие" ситуации на хостинга случаются. Жизнь есть жизнь. но на нормальном хостинге ситуация разруливается, а удар по клиентам минимизируется. Так зарабатывается деловая репутация. Но вот то как именно вели себя оба владельца - показывает, что они не умеют "не расплескать". Между тем выбор хостеров есть. И такой маркер - всего лишь один из доводов, который можно положить на одну из чашей весов...
Был бы тут разговор про недвижку - возможно бы и про застройщиков вспомнили.
Про застройщиков... так многие из тех сидят... чего их вспоминать? :)
