Ну все разные. Я например с 2009 года на битрикс (правда только с 13го полностью в веб нише, до того это было на уровне доп "развлечения" :). Ведь дело то не в Битрикс/не битркис, а в решаемых задачах. По сути у меня сейчас проекты в которых основное это некий модуль большой.
Опять же это речь о программистах. Но здесь, как я понимаю, больше речь про СЕО.
Хм. не видел такого. Видимо это осталось за пределами этого обсуждения. ок. В любом случае наверняка это было в контексте их задач. И сомневаюсь, что FastApi помогла бы им при прочих равных.
Ну это попахивает высокомерием. Вполне ожидаемо что капитализация проектов типа вайлберис, авито, вк, и прочих продуктовых большая и не сопоставима с большинством сайтов. Но такие проект и не нужны в больших количествах. Какая нафиг разница сколько продукт занимает на рынке? Что от этого нельзя получить достойный доход конкретному человеку? Давай сравним тогда спейс икс и твой рабочий проект - смысла нет, но наверно в космической нише бюджет чутка повыше.... ты уже считаешь себя нищебродом? ;)
Ну т.е. вся беда апоннентов в том, что у них другой круг задач?
Ну судя по названию задачи кеширование вполне рабочее решение. Т.е. вся суть, кака я понял, найти дубли. Если там есть динамические тайтлы, то их надо все вычислить и куда то сложить. Если товаров очень много и все это в памяти накапливать то вполне может быть что в один прекрасный момент все отваливается. Ну а если скидывать в кеш (не важно как реализованный) - это выход. (но тут конечно нужно знать детали задачи)
Первый вопрос и мешает все в кучу. Там противопоставляется FastApi и ВП. Что уже в корне некорректно. Т.к. тут сразу несколько тем для баталий: питон/пхп, фреймворк/CMS, синхронное/асинхронное. Т.е. FastApi логичнее сравнивать с фреймворк + road ranner например..
Далее. Исходя из моего опыта холиваров (там где сходились Битрикс vs ВП) - в Битрикс должно быть в твоем сравнении все еще хуже :) (и именно в обсуждаемом направлении). По этому я думаю, что обобщить в CMS вполне допустимо.
А так же в тех же холиварах сталкивался с теми к то "когда то что то делал на битрикс", а сейчас уже давно сидит в большом продукте и примерно понимаю "источник" их позиции (и их позиция ОЧЕНЬ похожа на твою). :)
И что? Спроси у GPT что такое инфоблоки в Битрикс. Вся эта цитата мне понятна. "Кастомные поля" - в битрикс это пользовательские поля инфоблков. Эта мега удобно для расширения сайта без привлечения программиста. Но. Сайт с 10тысячами товаров и с 3мя тысячами свойств может работать тормознее чем сайт с 150 тыс товаров + 150тыс торговых предложений (в ВП судя по твоему сообщению выше тоже есть аналог ты говорил что то типа "вариации"). Там даже если глянуть запрос: там пипец какая портянка. И на это заточены все компоненты того же каталога. И так же есть мнение что все "жостко". Но в реальности ни что не мешает нам в каких случаях какие то данные перенести в отдельные таблицы. И взаимодействовать с ними хоть без ОРМ битрикс, хоть вообще не используя битриксный коннект к БД. Да потребуется сделать свои компоненты, потребуется доработать индексацию для умного фильтра. Но весь вопрос в том что в конкретном проекте "дешевле": переписать все или достаточно только какую то часть реализовать. В общем, судя по твоим же сообщениям, в этом плане много общего в битркис и вп (что в принципе логично) потому я и думаю, что в данном сравнении вполне норм объединить в CMS. Или хочешь сказать что в ВП, как то технически смогли работать с базой данной на прямую и нет возможности создавать свои модификации компонентов?
А ну вот и ответ.
Ну т.е. тут речь вообще не о ВП? Просто тут речь про пользователей конкретно этого форума? (который, скажем так, не совсем про программистов). Думаешь если говорить о таковых "пользователях ВП" они ринуться фигачить на FastApi ? :) Согласись в таком разрезе сравнение вообще не корректное.
Ну так в этом и суть. Все зависит от решаемых задач конкретного проекта. Как выше и говорили: если CMS решает значимую часть задач проекта, то почему бы и нет? Для примера сайт эльдорадо на Битрикс. Там уже точно так же дофигища кастома. Но тем не менее они так и не ушли с него окончательно. Хотя там и товаров (правда сейчас в принципе как то эльдорадо уже не тот) и свойств товаров, и посещаемость думаю в лучшие времена была "значимая". (в общем то я знаю инсайды и других крупных магазинов - то что так же решающих точечно вопросы производительности)
Это не обязательно решать переходом на лару полностью. И архитектура тут тоже не причем. Надо понимать, что абсолютно любая CMS это всего лишь набор готовых решений, который ни как не ограничивает. Если тот же ВП решает большую часть задача зачем переписывать все? Ни когда не поверю что на ВП нельзя написать модуль, который будет по своему хранить информацию. А значит все узкие горлышки можем реализовать как потребуется. Мне кажется я писал, но повторюсь: с ВП я не имел дело, но уверен, что ситуация не сильно отличается от Битрикс. Так вот на проекте где встали вопросы нагрузок, мы просто часть информации вынесли из инфоблоков (а это гибкое, но тяжелое решение, как раз таки про хранение данных) в сосбственную историю хранения. Тут же и денормализованные данные в той же БД, часть данных перенесли в отдельную БД, а часть данных стали писать в кликхаус. Так же, надо понимать что есть и другие инструменты в наличии, те же FFI, да хоть что то на микросервисы убрать а там хоть Go, хоть франке пхп...... Да хоть даже на той же ларе можно спокойно написать.. Это же php - CMS не накладывает ни каких ограничений. Единственный "минус" - старт ядра. Не знаю как в ВП, в Битриксе это "тяжелое"... Но надо понимать и почему оно тяжелое. (Опять же ни кто не мешает выделить что то в микросервис - там хоть на асме ваяй :) ).
В общем тут вообще вопрос не спора ВП/не ВП. Если есть проект 90% задач справляется ВП, зачем переписывать все, если нужно только часть? Там в ВП нет кеширования совсем что ли?
Ну такое себе. Это не на этом форуме если серьезно обсуждать. И по опыту баталий подобных про Битрикс, практически уверен, что именно программист постоянно работающий с ВП на хорошем, глубоком уровне, спокойно все обоснует и докажет... Все же если мировую стату брать то ВП среди CMS популярный, не думаю что он был бы таким популярным, если был бы на столько плох, а битрикс не мог бы его по мировой стате обогнать... :)
ЗЫ Опять е все упирается в конкретику. Уверен подавляющее большинство сайтов из категории где CMS достаточно. Вопрос только в том, какой объем задач проекта она решает
Ну и тем не менее - фразу про пробелы я пожалуй мог бы сказать. Да я называю отступы отступами, но условно если бы только что в разговоре говорили о пробелах, я, думаю, что смог бы сказать "пробелы" в значении отступов и не счел бы это ошибкой. Ведь изначально это направлении темы пошло с фразы: "К тому же мне органически не нравится, что в Питоне пробел - значимый символ. " я вполне понял, что имелось ввиду. И считаю такую интерпретацию в разговоре непрофессиональных программистов (и не на собесе) вполне допустимой (тем более я использую для отступов в пыхе именно пробелы, а не табы). Т.е. для того хочет для себя программировать это уже мишура на которую нет смысла особо обращать внимания.
Максимум, уже если хочется "чистоты терминологии", я бы совершенно точно не стал бы говорить "таким не место", просто на уровне рекомендаций: если хочешь быть понятным всем - лучше говорить об отступах. Ведь кто-то вполне может и не знать, что можно табуляцией.
Ну уж ты совсем начинаешь душнить :)
Имхо программист не обязательно тот кто зарабатывает, но и тот использует программирование как средство решения своих задач. Знаю вполне не единичные "примеры" когда хоть гуманитарий хоть кто решал свои маленькие задачи при помощи того же питона. Вполне понятно о чем шла речь при упоминании в пробелов. По этому даже не один холивар можно найти на разных площадках в тематике "какой ЯП лучше". по этому вполне себе мнение, которое есть, в том числе, и среди программистов.
Мне собственно тоже не место по такому критерию в программистах. Есть куча моментов которые я понимаю как работают, зачем созданы, но не всегда могу дать феншуйное определение или назвать "научным" термином :)
