Серьезно? Т.е. для нуба CMS это "делать сложно." и надо нанимать дорогого спеца. А взять "бэкенд-фреймворк" и все становится "ясно и просто"? Вы реально так думаете или это просто троллинг?
Я очень поверхостно знаком с джумлой, но что то сильное подозрение, что этот "готов разбираться" - "не смог разобраться".
При этом, обратите внимание, вы написали "нуб оставляет"... т.е. если этот нуб берет лару то он начинает резко все красиво сооружать и у него на выходе сайт-конфетка? Мне почему то кажется, что этот самый нуб (даже если "готов разбираться") на ларе и симфони, создаст куда более кривой сайт чем на любой достаточно популярной cms
Ну т.е ни какой конкретики.
Т.е. вы считаете, что если некий разработчик переведет решение с условного WP на условную симфу то у него резко пропадет количество вопросов? Или вы сравниваете криворукого "разработчика" на ВП и реального Профи на симфе? И как так сложилось (по вашему) что CMS это проблемы ,а фреймворки это их отсутствие.
В реальности все зависит от:
1. По прежнему определяется объемом задач, которые закрывает готовое решение. И при одинаковой квалификации разработчика, если cms покрывает больше - то ее применение правильное решение. Если разработчик косячит с CMS, ну я бы опасался ему доверить и на фреймворке, даже если его знания подтверждены, т.к. это будет означать что он "программист [название_конкретного_фреймворка]", а не программист. И может где то не достаточно погрузиться в тему.
2. И, вынесу отдельным пунктом, квалификацией. У меня вот наглядный был однажды пример очень яркий. Обратились с просьбой решить проблемы с битрикс сайтом. Стал разбираться: оказалось просто кто то не читал доку. Основная проблема была в кеширвоании. Так вот это некто реализовал очень грамотное решение - все по феншую. Но есть нюанс: он не знал как работает кеширование в битриксе, в итоге одно накладывалось на другое и получалась невообразимая хрень.
Есть и еще один момент. Вот вы пишите на неком фреймворке, собирая то, что есть уже в некоей CMS из кучи компонентов через композер. все как бы ок. Но. Это ваш проект зависит уже не от одного вендора, а от многих. И это тоже может доставлять дополнительные задачи. Не сталкивались? А я вот, например, столкнулся что пришлось "взять на обслуживание" достаточно популярный vue компонент, потому что его поддержка закончилась активная, и форки тоже не решали проблемы, в общем свой форк и вот уже я имею дополнительную задачу. (да, конечно, он мне хлопот не доставляет, но тем не менее)
Все должно определяться субъективными для проекта целями, задачами и условиями (не каждый проект может себе позволить штат программистов, или дополнительный бюджет на подробную документацию, дополнительное тестирование и написание тестов). Где то вполне может быть оправдано вообще написание реального "самописа" для существующего решения, но все равно это удорожание.
И что в этом такого? По хорошему при использовании фреймворков вы точно так же не должны тащить внутрь своей бизнес логики чужие решения. А подключать их условно на уровне инфрастурктуры. Если конечно нет объективной необходимости поступить иначе. В любом случае исходите из реалий конкретного проекта и стараетесь обезопасить себя макссимально от сильной завязанности на чужой код
Глупо. Вот так вот как "в общем для всех задач". Надо смотреть какой объем задач снимает то или иное решение, и уже основываясь на этом действовать. Таким образом можно применять WP, Битрикс или любую другую CMS. А уже какойто уникальный функционал создавать в качестве модуля к оным. И тут уже все зависит от вашего желания (надеюсь размуного) - можно брать на вооружение и те же сифу или лару или уии... (да хоть другой ЯП).
Дело лишь в квалификации. Если "адаптировать", условно для вас, какую то сущность сложнее чем написать и поддерживать админки, и прочее и прочее. Ну пишите - вполне вероятно, что в вашем случае это оправдано... Мне лично тратить время на рутину лень...
Вон например один микросервис я на симфе написал, так он отстает от всего проекта теперь. Т.к. версию симфы надо поднять... Да не особо сложно, но все равно время дополнительное. Так что у всего есть своя цена и однозначных типовых решений для всех нет.
Обычно в готовом решении есть много лишнего, а тот функционал который есть часто приходится адаптировать.
Плюс готового решения - быстрый старт. Все работает из коробки. Сразу. Больше ничего.
Поэтому более естественно, когда со временем проекты уходят от готовых решений к самописам.
вы так думаете или причастны к каким то проектам?
Приведу пример из собственной практики: проекты моих клиентов. Модули которые разрабатываются конкретно под их нужны достаточно объемны и время много уходит на разработку, и идей еще много. Используется Битркис. Да там много чего "лишнего". Но оно каши не просит. При этом где то позволяет вообще не привлекать меня как разработчика к решению задач.
Да есть, например, проект где в силу количества посетителей уперлись в точно "излишняя гибкость" приводит к заметным проблемам с производительностью. Но просто вынесли это из "гибкого решения" (в виде инфоблоков) в свои таблицы (или, при необходимости, вообще в отдельный микросервис).
У меня свой проект, по сути САПР. Нахрена мне еще переписывать на свое. Зачем? У меня сайт работает, платежи принимаются, доступ предоставляется. Все что не нужно тупо отключено. Какую задачу решит уход к самопису?
По-моему, за 15 лет можно и функциональность магазина "навелосипедить". Не обязательно же прямо все самому писать. Есть вполне достойные и легко переносимые библиотеки.
Возможно, вы просто не разработчик (программист по профессии).
По вашему может быть. А если подумать:
1. Функционал создавался по мере необходимости. И магазин мне был не нужен. (более того большую част времени этого я разрабатывал ПО на сях и делфи.
2. Если бы вы внимательнее читали, то заметили, что я к этому и вел. И как итог взял готовое решение, которое покрывало большинство функционала, что позволило сконцентрироваться на более узкой (и при этом объемной задачи)
Во первых экономия времени в конечном итоге. (естественно при условии, что инструмент знаете). Я имею ввиду именно в долгосрочной перспективе. Возвращаясь раз за разом, что то подправить и т.п.
Пройдено на собственном опыте :) . Была своя CMS в течении 15 лет, и однажды пришло понимание, что много трачу времени на то что уже везде сделано, а у меня нет. (и начиналось то все с простенького хомяка ради развлечения) Но когда потребовалось уже и, по сути, магазин (вот такая вот метамарфоза примерно на 15ом году сайта) - плюнул взял Битрикс и доволен вполне. (уже прошло 10 лет). Теперь трачу время именно на уникальный функционал...
Тут понятно "общими словами" трудно описать - все размыто.. но вот именно в деталях, в мелочах, набегает - короче ну его нафиг велосипеды. (если вы конечно не уверены что через годик выкините этот сайт) :)
Но, опять же, надо оценивать сколько задач покрывает этот сторонний инструмент, и выбирать в соответствии с этим. (т.е. может вам достаточно роутинг взять или туже ОРМ, а остальное навлесипедить.
Ну если вы на свой дом повесите камеру видео наблюдения - то точно так же становитесь оператором ПД. (при этом это самое "безобидное" условие для владельца камеры :) )
в любом случае, в плане "веса" на современных страницах все эти символы не так много добавляют. Как то попросили оптимизировать страницу по весу. Но там была она достаточно загруженная со сложной версткой. К тому же динамически собиралась из множества блоков, каждый из которых формировался своим модулем/шаблоном... убрал регуляркой лишние пробелы и переносы строки. страница похудела килобайт на 200.... так размер кода отвечающего за копирайт - капля.. :)
Сам на сайтах с однобайтовой кодировкой (когда таковые были) использовал именованное представление. Сейчас UTF символом, в шестнадцатиричной (десятичной) форме - не читаемо. только если нет выхода. (как правило в css)
В utf-8 размер символа занимает от 1 до 4х байт
Да верно, но речь про этот символ. я потому и указал это. Полагаю прочие подобные достаточно "часто употребляемые" символы так же занимают два байта.
В любом случае проверять не сложно. Открываем реадктор пишем символ смотрим размер (не забывая о возможности всяких концах строки и прочих... лучше в hex)
