Вижу как эта тема болит у вас :) Я сам сталкивался с редакторами и даже пробовал написать свой по молодости но быстро понял насколько это не подьемная задача. Моя идея была в том, что бы дать пользователю возможность выделить текст независимо от редактируемых блоков, тоесть переключить в режим просмотра без блоков. Не уверен можно ли будет реализовать удаление в этом режиме, но как минимум можно будет скопировать часть текста.
В основном это нужно для продажи рекламы. У рекламодателей бывают спец кейсы за которые они платят больше если пользователь попадает под них. Чем больше ты знаешь о пользователе тем лучше можешь его идентифицировать, узнать интересы и тд. и тем дороже ты можешь продать просмотр рекламы.
Ну и GDPR только в EU работает.
Во первых нужно отличать код который будет вызыватся при иницализации модуля и код который будет вызван при событии запроса. Сначала у вас происходит регистрация колбеков а потом уже сервер может принимать запросы.
И второй момент, важно понимать что весь код внутри колбека тоже синхронный, и существует такая вещь как очередь колбеков т.е пока не выполнится весь код внутри функции следующий колбек не сработает.
Насколько я помню у них система организованна с помощью Real Time Bidding тоесть кто больше денег выставил за клик того и показывают первым. Но вам не обязательно было выставлять максимальную цену за клик достаточно было бы указать приемлимую для вас цену за клик и лимит дневного бюджет, система всеравно выводила бы ваше обьявление пусть реже и не на первом или втором месте.
Ну тогда можно не использовать компоненты Laravel не вижу тут проблемы :)
Мой месадж был о том что какраз эта прибитая гвоздями организация кода и позволяет командам писать код в пределах фреймворка который будет понятен всем. Когда при кастомном решении новому человеку пришедшему на проект надо будет вникать во все ньюансы самописного решения и думать как ему встроить что то новое чтобы не сломать старое.
Ну потащит окей, некоторые компоненты зависят от других и код реиспользуется. Это вроде как стандартный подход, любой компонент имеет какие-то свои зависимости.
В чем вам легче будет разобратся в самописном коде, или в коде который был написан по стандартам фреймворка? А если код был написан не самым опытным программистом? Вам захотелось бы разбиратся в той архитектуре? А в случае с фреймворком если человек который писал код следовал стандартам, у вас уже будет более менее ясное представление о приложении. А насчет Laravel впервые слышу что там что то прибито гвоздями, наоборот при желании вы можете взять любой компонент и он будет работать отдельно от фреймворка.
Осталось добавить сюда минимум то без чего не обойтись в минимальном приложении это ORM, миграции, валидацию, обработку шаблонов для email, отправку email, file storage и… получим то что Laravel предоставляет из коробки.
Без фреймворка хорошо писать только в целях саморазвития для своего личного проекта где вы будете сами это все поддерживать, но для коллективной разработки лучше всетаки использовать фреймворки так как они вносят свои стандарты построения приложений.
Гениально... получить миллионы за дизайн нескольких страниц а тестирование переложить на читателей хабра. Волшебная идея.
Ну и GDPR только в EU работает.
И второй момент, важно понимать что весь код внутри колбека тоже синхронный, и существует такая вещь как очередь колбеков т.е пока не выполнится весь код внутри функции следующий колбек не сработает.
Мой месадж был о том что какраз эта прибитая гвоздями организация кода и позволяет командам писать код в пределах фреймворка который будет понятен всем. Когда при кастомном решении новому человеку пришедшему на проект надо будет вникать во все ньюансы самописного решения и думать как ему встроить что то новое чтобы не сломать старое.
Без фреймворка хорошо писать только в целях саморазвития для своего личного проекта где вы будете сами это все поддерживать, но для коллективной разработки лучше всетаки использовать фреймворки так как они вносят свои стандарты построения приложений.