Alex Mitin
Почему же? Слово "хайп" я вполне понимаю. Собственно, сейчас я радуюсь, что не начал изучать Ruby, как мне советовали, а продолжил с PHP.
Еще считаю самым рациональным подход, где под каждую задачу свой инструмент.
Ну и языки, на которых написано кучи легаси, быстро не вымрут.
Java - выпущена в 1990г.
PHP -выпущен в 1994г.
JavaScript - Выпущен в 1996г.
О, да. Стильные, модные молодежные вещи на JAVA и JS - это вам не то же самое, что древний и замшелый PHP:)
Но самое интересное, что интерпритаторы всего перечисленного (кроме, возможно Go и Java) написаны на свежих и вечно молодых C(1972) или C++(1983). Как и большинство веб-серверов и операционных систем.
6. Так же не согласен с утверждением, что система не производительна и очень требовательна к хостингу.
Все зависит от конкретного проекта. Как ни крути, но при повышении нагрузки вы рано или поздно упретесь в то, что все элементы всех инфоблоков хранятся в одной таблице. А если разработчики не особо расчитывали на высокие нагрузки, то к этому добавится так же то, что все пользовательские свойства всех элементов хранятся еще в одной таблице (или двух? не помню точно).
В результате выборки из базы станут медленнее просто в силу количества данных.
Потому что ЗАКАЗЧИКА интересует магазин как можно быстрее. И чтобы с 1с его можно было связать как можно проще. А уж на чем его делать - его не волнует.
Ну а дальше мое предположение: там, где на битриксе нужно слегка подправить напильником всякие экспорты/импорты с 1с или яндекс.маркетом, на других системах нужно придумывать другой путь.
Потому что это может быть в контенте, в php-коде и в массе других мест. А кто поместил это все в такие места? Сам битрикс? Или разработчик, который сайт делал?
Деплой, версионность, нормальный шаблонизатор - это все далеко от Битрикса.
Какие сложности с деплоем и версионностью файлов?
Вот с версионностью БД - полностью согласен.
Шаблонизатор. Каких функций шаблонизатора лично вам не хватает в компонентах битрикса?
Вы путает ядро битрикса и клиентский код.
У меня несколько комментариев по сравнительной таблице:
Шаблонизация. В битриксе действительно не используется ни паттерн MVC, ни какой-либо шаблонизатор. Но у битрикса есть своя система построения страницы, которая предполагает как общий шаблон сайта, так и шаблон каждого компонента. Так что, шаблонизация как таковая в битриксе есть, а вот шаблонизаторы да, не используются.
Кастомизация готовых компонентов. То, что указано в таблице, полностью и безоговорочно относится только к КОМПЛЕКСНЫМ компонентам. Простые компоненты кастомизируются так же довольно просто. Особенно если шаблоны и фронтенд писать самостоятельно с нуля. Более того, механизм result_modifier.php позволяет манипулировать результатом работы компонента до передачи его шаблону, а component_epilog.php, соответственно, после отработки шаблона.
Независимость от разработчика. Я счиатю, тут с Laravel все одинаково. При условии документации и соблюдения соглашений (да, у битрикса тоже есть соглашения по стилю кода) все будет независимо от разработчика.
Документация. Неполная - так и есть. Особенно плохо документирован внутренняя JS-библиотека. Устаревшая - не совсем так. Но абсолютное большинство компонентов и классов, требующихся для повседневной работы документированы в достаточной степени. У Laravel документация более подробна. У битрикса более ориентирована на русскоязычного пользователя.
Простота использования для редактора. Про жесткие ограничения - чушь. Админка битрикса предоставляет множество механизмов кастомизации. Кроме того, собственные модули могут содержать любую бизнес-логику и любой интерфейс.
Требуемая квалификация разработчика. Тут мне, конечно, сложно судить. Но я знаю такое название как Интерволга. Рекомендую посмотреть их сайт. Требования к разработчикам, решенные кейсы в блоге и статьях. Если это программисты максимум среднего уровня и не талантливые, то я впаду в депрессию из-за синдрома самозванца.
Единая концепция разработки. Как ни крути, но битрикс - это MVC. Модель (модули), Контроллер (компонент) и Вид (шаблон компонента) - присутствуют.
Если у вас файлы представляют свалку HTML, JS, CSS, то Laravel вас не спасет. Вы и там свалку разведете. К тому же, проблема "толстого контроллера" в Laravel распространена не меньше. То, что в битриксе нет единой точки входа - правда. Но ведь она и не требуется этим паттерном. Зато не нужен роутинг на каждом хите.
Микросервисная архитектура. Мне сейчас кажется, что я прочитал какую-то чушь про битрикс. Во-первых, микромонолит. Это что за зверь такой? Я его не представляю. Во-вторых, о реализации микросервисной архитектуры на битриксе я хотел бы узнать больше. Буду благодарен автору за описание его опыта на эту тему в отдельной статье. Потому что в моей картине мира микросервсная архитектура на битриксе - это извращение сродни написанию сайта на ассемблере: вроде и можно, но для данной задачи существуют и лучшие решения.
Соблюдение принципов ООП. D7 вполне себе соблюдает ООП. В остальном же с Laravel все одинаково: качество кода зависит от квалификации разработчиков. Никто не мешает вам использовать объекты в битриксе. Как самописные, так и те, что сможете найти в composer.
Возможность организации итерационной разработки. Хотелось бы получить более развернутую информацию, что же мешает организовать ее на битриксе?
Производительность. Структура БД и вправду неоптимальна. Более того, в битриксе в качестве БД можно использовать только mysql. Так что если вы целитесь в highload, где важна каждая микросекунда, то я не назвал бы битрикс оптимальным решением. Сайт моей компании держит 2500 запросов/сек. Без кластеризации (сейчас в планах) и микросервисов. У Интерволги тоже есть кейсы с хайлоадом на битриксе. Но, по моему мнению, это уже попытка натянуть сову на глобус.
Популярные альтернативы. А вот тут я не понял. Почему в альтернативах Laravel фреймфорки на других языках? Где yii(хоть его и ругают, кажется, не меньше битрикса)? От себя так же добавлю, что порог входа в Symfony выше, чем в Laravel, хотя Laravel под капотом и использует довольно много компонентов Symfony.
Все так, как вы и написали. Но до определенного предела. У меня на новостном сайте не получается сделать реальный архив новостей просто потому что все элементы всех инфоблоков хранятся в b_iblock_element. Партиционирование так же идет лесом.
Еще буду вам благодарен если расскажете о том, как вы решаете проблемы с версионированием БД (в Laravel для этого миграции).