Про FoxPro прям сразу навеяло "дед курил и дожил до 90 лет". Легаси системы типа FoxPro это техдолг с которым мирятся, а не пример для подражания. Никто не пишет новые системы на FoxPro в 2026.
Я не очень понимаю такую сущность как "разделять логику на клиент/сервер", полагаю, что вы имеете в виду разделение на фронтенд и бэкенд. Бизнес-логика всегда живет на сервере. На клиенте ui-логика (показать/скрыть, валидация для UX и т.д.). Это не "разделение логики", а разделение по средам выполнения. Говорить "без необходимости разделять логику на клиент/сервер" значит допускать, что бизнес-логика может быть на клиенте. А она не должна. "Не нужно писать JS отдельно" - это можно преподнести как dx фичу, но "без необходимости разделять логику" это архитектурный антипаттерн. Звучит как маркетинговый лозунг "В нашем авто нет сложного разделения на двигатель и салон! Вы подливаете бензин прямо за рулем, а выхлопная труба приятно греет спину."
DDD != доменный слой. Доменный слой это просто отделение бизнес-логики от представления. Хоть функцией, хоть классом-сервисом. Даже тривиальный Service Layer уже будет доменным слоем. "доменная логика тесно связана с UI" фундаментальное заблуждение - расчет себестоимости, проводка документа, пересчет остатков - все это бизнес-логика, которая никак не связана с тем, как выглядит форма.
Про жизнь без composer. Вы путаете отсутствие зависимостей с отсутствием возможности их подключить. Composer можно юзать и без внешних пакетов, только для PSR-4 автозагрузки. Зависимости не нужны ровно до того момента, когда заказчик попросит "А прикрути-ка сюда генерацию накладных в PDF, парсинг прайсов из Excel и интеграцию со шлюзом оплаты". Я правильно понимаю, в мире LOTIS разработчик уходит в закат писать свой PDF-генератор или качает либу и костылит ее подключение вручную?
У вас невалидные данные о QT. Зачем противопоставлять событийную архитектуру и MVC, это же не взаимоисключающие вещи. Qt одновременно событийно-ориентирован и реализует Model/View (не MVC т.к. это специфика GUI фреймворков как я понял). Неудачная аналогия с WinForms, это же ui тулза которая живет поверх .NET, в котором уже есть и DI, ORM (EF), транзакции, авторизация, тесты и еще куча свистоперделок которые вы так ненавидите.
Про "сложность бизнес задач" трудно не согласиться. Покажите, а чем LOTIS помогает с этой сложностью? Пока единственный бизнес-компонент Stock не умеет банально обернуть массовый UPDATE в транзакцию. Складской учет в котором при обрыве соединения теряются остатки - это конечно, сложная бизнес-задача. Но решенная она после этого не становится.
Давайте так, любой мидл за пару вечером с помощью LOTIS может создать систему учета по типу WMS или CRM с учетом персональных требований заказчика. Назовите еще какие-то инструменты разработки с таким же быстрым входом, позволяющие это делать.
За те же два вечера мидл на Filament (Laravel) получит WMS с авторизацией, RBAC-ролями, миграциями, транзакциями, экспортом в Excel/PDF, аудит-логом и REST API. Вопрос еще в том, что будет на третий вечер, когда заказчик скажет: "а добавь авторизацию", "а сделай так, чтоб если свет моргнет накладная не сохранялась наполовину", "а прикрути экспорт в Excel". В Laravel это composer require и полчаса работы. В LOTIS - экзистенциальный кризис. "Любой мидл за два вечера" не уникальное преимущество LOTIS. Разница в том, что за теми двумя вечерами в одном случае продакшн система, а в другом очень быстро написанная "проблема" заказчика. Вполне реально сделать простую CRM за пару вечеров (в обнимку с LLM за один) и при этом не жертвовать безопасностью, архитектурой и здравым смыслом.
Я стал искать через гугль что то про "WordPress вставляет nbsp в текст." и нашел массу страниц на которых обсуждается это вот уже десяток лет.
Все верно за одним исключением - мы действительно так страдали много лет сидя на TinyMCE (wisywig редактор для WordPress) и его привычке вставлять неразрывные пробелы и весь остальной мусор в код. Это происходит даже без вставки какого-либо контента со сторонних сайтов - двойной перевод строки в режиме визуального редактора и вот у вас в коде уже который при рендере оборачивается в <p>. Но уже лет как 6 это в прошлом т.к. дефолтным редактором в WordPress стал Gutenberg(react) у которого нет всех этих проблем.
Причем у вас там какая-то путаница: на 2-м скриншоте явно видно, что это Gutenberg а не TinyMCE. Это значит, что текст вы вставляли/вставляете не в Gutenberg, а в TinyMCE. Решение простое и очевидное - перестаньте использовать TinyMCE.
Полное отсутствие доменного слоя, вся ваша бизнес логика это анонимные замыкания прямо внутри UI контроллеров. DataView одновременно и ui компонент, и контроллер, и репозиторий.
А так, у вас просто нет даже базовой инфраструктуры для этого:
- нет Composer (как минимум для автозагрузки по psr-4)
- нет router
- нет DI
- нет REST API
- сессии у вас нативные - как будем горизонтально масштабироваться?
- с БД прям беда - нет полноценной ORM, запросы не подготовлены(!), нет миграций, мускуль прибит гвоздями, нет транзакций - в LTS\Stock::update гоним запросы через foreach (другой важный вопрос - почему не одним запросом) и молимся тихонечко, чтоб ничего не упало посередине
- нет кэширования
- нет CSRF, нет санитизации входных данных
- нет даже базовых юнит тестов
Это прям по верхам... Это не фреймворк в общепринятом понимании, а что-то типа RAD для прототипирования crud интерфейсов.
Как вы ловко и непринужденно называете защиту диссертации "формальной работой", упуская из виду, что этот механизм верификации институционально работает в мировой науке уже наверное более 100 лет. Именно эта "синекура", "формальщина" и "геронтократия" обеспечила технологические прорывы в 20 веке.
На каждый установили WordPress 6.7 с темой Astra, создали 16 тестовых постов и 7 страниц. Никаких плагинов оптимизации — только базовое кеширование: LSCache для OpenLiteSpeed, WP Super Cache для LEMP.
Во-первых, WP Super Cache - это именно плагин, и плагин оптимизации. Во-вторых, сама конфигурация/окружение 2 тестируемых инстансов в корне не верна - LSCache это full-page caching engine (его аналог в Nginx fastcgi caching) a WP Super Cache - это плагин, который генерирует статические HTML файлы, кладет их на диск и отдает их при запросе с помощью php. Это совершенно разные механизмы, и сравнивать их напрямую некорректно - в первом случае кеширование происходит на уровне сервера, во втором - на уровне приложения.
Я подозреваю потому, что вы написали "Всё скрины что вы показали делаются буквально за пару минут." а в итоге у вас невнятный и не очень релевантный пример из документации
А с какой радости бизнесу делать API да еще и публичный? Для того, чтоб другие бизнесы (ИИ) обучали нахаляву свои модели а потом продавали доступ к ним ...конкурентам?
А зачем? В любой сети публичной/приватной у вас всегда будет как минимум доступны из вне порты 80/443 для WEB, вот все современные средства обхода блокировок и маскируются под HTTPS траффик - лучше уже не придумаешь.
Про FoxPro прям сразу навеяло "дед курил и дожил до 90 лет". Легаси системы типа FoxPro это техдолг с которым мирятся, а не пример для подражания. Никто не пишет новые системы на FoxPro в 2026.
Я не очень понимаю такую сущность как "разделять логику на клиент/сервер", полагаю, что вы имеете в виду разделение на фронтенд и бэкенд. Бизнес-логика всегда живет на сервере. На клиенте ui-логика (показать/скрыть, валидация для UX и т.д.). Это не "разделение логики", а разделение по средам выполнения. Говорить "без необходимости разделять логику на клиент/сервер" значит допускать, что бизнес-логика может быть на клиенте. А она не должна. "Не нужно писать JS отдельно" - это можно преподнести как dx фичу, но "без необходимости разделять логику" это архитектурный антипаттерн. Звучит как маркетинговый лозунг "В нашем авто нет сложного разделения на двигатель и салон! Вы подливаете бензин прямо за рулем, а выхлопная труба приятно греет спину."
DDD != доменный слой. Доменный слой это просто отделение бизнес-логики от представления. Хоть функцией, хоть классом-сервисом. Даже тривиальный Service Layer уже будет доменным слоем. "доменная логика тесно связана с UI" фундаментальное заблуждение - расчет себестоимости, проводка документа, пересчет остатков - все это бизнес-логика, которая никак не связана с тем, как выглядит форма.
Про жизнь без composer. Вы путаете отсутствие зависимостей с отсутствием возможности их подключить. Composer можно юзать и без внешних пакетов, только для PSR-4 автозагрузки. Зависимости не нужны ровно до того момента, когда заказчик попросит "А прикрути-ка сюда генерацию накладных в PDF, парсинг прайсов из Excel и интеграцию со шлюзом оплаты". Я правильно понимаю, в мире LOTIS разработчик уходит в закат писать свой PDF-генератор или качает либу и костылит ее подключение вручную?
У вас невалидные данные о QT. Зачем противопоставлять событийную архитектуру и MVC, это же не взаимоисключающие вещи. Qt одновременно событийно-ориентирован и реализует Model/View (не MVC т.к. это специфика GUI фреймворков как я понял). Неудачная аналогия с WinForms, это же ui тулза которая живет поверх .NET, в котором уже есть и DI, ORM (EF), транзакции, авторизация, тесты и еще куча свистоперделок которые вы так ненавидите.
Про "сложность бизнес задач" трудно не согласиться. Покажите, а чем LOTIS помогает с этой сложностью? Пока единственный бизнес-компонент Stock не умеет банально обернуть массовый UPDATE в транзакцию. Складской учет в котором при обрыве соединения теряются остатки - это конечно, сложная бизнес-задача. Но решенная она после этого не становится.
За те же два вечера мидл на Filament (Laravel) получит WMS с авторизацией, RBAC-ролями, миграциями, транзакциями, экспортом в Excel/PDF, аудит-логом и REST API. Вопрос еще в том, что будет на третий вечер, когда заказчик скажет: "а добавь авторизацию", "а сделай так, чтоб если свет моргнет накладная не сохранялась наполовину", "а прикрути экспорт в Excel". В Laravel это composer require и полчаса работы. В LOTIS - экзистенциальный кризис. "Любой мидл за два вечера" не уникальное преимущество LOTIS. Разница в том, что за теми двумя вечерами в одном случае продакшн система, а в другом очень быстро написанная "проблема" заказчика. Вполне реально сделать простую CRM за пару вечеров (в обнимку с LLM за один) и при этом не жертвовать безопасностью, архитектурой и здравым смыслом.
Интересное расследование
Все верно за одним исключением - мы действительно так страдали много лет сидя на TinyMCE (wisywig редактор для WordPress) и его привычке вставлять неразрывные пробелы и весь остальной мусор в код. Это происходит даже без вставки какого-либо контента со сторонних сайтов - двойной перевод строки в режиме визуального редактора и вот у вас в коде уже который при рендере оборачивается в <p>. Но уже лет как 6 это в прошлом т.к. дефолтным редактором в WordPress стал Gutenberg(react) у которого нет всех этих проблем.
Причем у вас там какая-то путаница: на 2-м скриншоте явно видно, что это Gutenberg а не TinyMCE. Это значит, что текст вы вставляли/вставляете не в Gutenberg, а в TinyMCE. Решение простое и очевидное - перестаньте использовать TinyMCE.
Такой топорный rage bait, что аж обидно
Начать и закончить можно прям с этого:
Полное отсутствие доменного слоя, вся ваша бизнес логика это анонимные замыкания прямо внутри UI контроллеров. DataView одновременно и ui компонент, и контроллер, и репозиторий.
А так, у вас просто нет даже базовой инфраструктуры для этого:
- нет Composer (как минимум для автозагрузки по psr-4)
- нет router
- нет DI
- нет REST API
- сессии у вас нативные - как будем горизонтально масштабироваться?
- с БД прям беда - нет полноценной ORM, запросы не подготовлены(!), нет миграций, мускуль прибит гвоздями, нет транзакций - в LTS\Stock::update гоним запросы через foreach (другой важный вопрос - почему не одним запросом) и молимся тихонечко, чтоб ничего не упало посередине
- нет кэширования
- нет CSRF, нет санитизации входных данных
- нет даже базовых юнит тестов
Это прям по верхам... Это не фреймворк в общепринятом понимании, а что-то типа RAD для прототипирования crud интерфейсов.
Как вы ловко и непринужденно называете защиту диссертации "формальной работой", упуская из виду, что этот механизм верификации институционально работает в мировой науке уже наверное более 100 лет. Именно эта "синекура", "формальщина" и "геронтократия" обеспечила технологические прорывы в 20 веке.
Я полагаю, что ваше представление о сложной бизнес-логике кардинально отличается от того, что принято таковой считать в отрасли.
Автор на серьезных щщах сравнивает свой аналог "Hello world!" c CMS системами 🤣
Во-первых, WP Super Cache - это именно плагин, и плагин оптимизации. Во-вторых, сама конфигурация/окружение 2 тестируемых инстансов в корне не верна - LSCache это full-page caching engine (его аналог в Nginx fastcgi caching) a WP Super Cache - это плагин, который генерирует статические HTML файлы, кладет их на диск и отдает их при запросе с помощью php. Это совершенно разные механизмы, и сравнивать их напрямую некорректно - в первом случае кеширование происходит на уровне сервера, во втором - на уровне приложения.
Это незаконно или вы с моральной стороны? Я, если что, полностью согласен с вашим доводом.
Я подозреваю потому, что вы написали "Всё скрины что вы показали делаются буквально за пару минут." а в итоге у вас невнятный и не очень релевантный пример из документации
У вас какая-то квота на кол-во символов?
Автор еще упустил, что url может содержать имя пользователя и пароль:
Для заблокированных соединений я бы лучше отдавал 444
Учитывая то, что
и у вас вряд ли один процессор - я бы рекомендовал добавить
reuseportвlistenстрим сервераRedis для WordPress - это объектный кэш в WP (не page caching), так что оба эти инструмента можно использовать одновременно
А с какой радости бизнесу делать API да еще и публичный? Для того, чтоб другие бизнесы (ИИ) обучали нахаляву свои модели а потом продавали доступ к ним ...конкурентам?
Видимо тесты по пхп составлял "специалист" нанятый по результатам тестов на знание пхп
Селфхостинг это домашняя лаборатория (локальная разработка/тесты и т.п.) и/или хостинг "хомяка" на который ходят три калеки в хорошую погоду.
А зачем? В любой сети публичной/приватной у вас всегда будет как минимум доступны из вне порты 80/443 для WEB, вот все современные средства обхода блокировок и маскируются под HTTPS траффик - лучше уже не придумаешь.
Лучше не стало