MODX, jquery, ExtJs vs Vue и NodeJs
Когда-то в 2015 году мне предложили сделать сайт вентиляции. В принципе программировать я умел, но во первых особого опыта у меня не было и во вторых я ленив и делать велосипеды вроде авторизации пользователей и базового функционала интернет-магазина меня никак не вдохновляет :-). В поисках на чем делать сайт наткнулся на MODX и он оказался буквально спасением. То есть есть весь нужный базовый функионал и в то же время сделать не допилить не стандартный нужный функионал легко. Так я начал программировать на MODX и получать за это деньги.
Но вот сейчас при разработке нашей системы управления производством у меня есть некоторые проблемы. Для их решения думаю перейти на какую-нибудь другую эко-систему. Думаю насчет Vue и NodeJs. У них я думаю есть некоторые преимущества. Под катом подробнее…
Во первых, Vue и NodeJs современные и популярные системы. На ярлык современные и популярные было бы пофиг если бы не одна вещь.
Над нашей EPR я работаю один и времени на многое не хватает. Нам нужно сделать больше функционала за меньшее время. Как впрочем думаю и всем програмистам :-). В программировании разработчики часто делают для себя программы(фреймворки, библиотеки и т.д.) которые значительно и бывает в разы ускоряют разработку программ. Например, я когда-то сделал компонент getTables и разработка редактирумой таблицы вместо 3-6 часов на ExtJs стала занимать 5 минут. Ускорение в 50-100 раз :-). С учетом того, что таблиц у нас стало много, такой функционал, что у нас есть я бы на ExtJs никогда бы не написал.
Так программисты создают упрощающие себе и другим разработку библиотеки и фреймворки. Современные фреймворки — это тысячи сэкномленных часов разработки для тех кто ими пользуются. И чем современнее фреймворк, тем по идее больше у него возможностей писать быстрее и лучше. Не всегда вот и с переходом думаю надо быть аккуратнее.
Сейчас меня достает проблема с дизайном. Я не развивался как верстальщик и оформить приложение красиво проблема. А дизайнеры фрилансеры либо делают не айс, либо если они хорошие, то постоянно заняты. Думаю, лучше все-таки делать самому, но на UI фреймворках. Думаю, если, например, делать фронт на quasar, то сделать красиво будет значительно проще. UI фреймворки на jquery, насколько я понимаю, сейчас не развиваются. Современный UI фреймворк — это что то на основе Vue. Такой как quasar.
В MODX очень удобная система чанков и сниппетов, но сейчас мне приходиться генерировать html отправляя запрос на сервер и получая html код с сервера. Часто было бы удобнее сгенерировать, например, форму на фронте через js, но чанки написаны на fenom, а феном только на сервере. Вот и приходиться каждый раз писать запрос на сервер. Думаю, перевод чанков в компоненты Vue здесь облегчит работу и добавит моим приложениям много интересных возможностей. Но тут для компонентов придется писать гораздо блольше API. Большая часть приложений это редактирование таблиц в базе данных. Над API я сейчас работаю и принципе сделал компонент для автоматизации генерации АПИ в MODX, но пока еще не пробовал в работе. Как накоплю опыт работы и проверю его опубликую.
Если перейти на Vue, то мне не нужны будут чанки и сниппеты MODX и так как это основа MODX, то и собственно не особо нужен будет и сам модекс. Реактивные фреймворки, такие как Vue делают контент прямо в браузере и у них возникает проблемы с поисковыми системами, так как когда поисковая система запрашивает контент, то контента еще нет. Для того чтобы контент был применяют SSR генерацию js компонентов на стороне сервера. Естественно php и модекс не умеет обрабатывать js на стороне сервера. У нас основной сервер внутри компании и не индексируется. Пока не критично, но рано или поздно надо будет пилить внешний сервер и тогда SSR потребуется. Ну и соответственно потребуется сервер умеющий обрабатывать js. Такой как NodeJs.
Так же если перейти на ноду, то и сервер и фронт будут на одном языке и можно будет перетаскивать какой-то код туда сюда с сервера на фронт.
Вот вкратце причины перейти на Vue и NodeJs. А какое у вас мнение? Мне будет интересно его узнать.
Но вот сейчас при разработке нашей системы управления производством у меня есть некоторые проблемы. Для их решения думаю перейти на какую-нибудь другую эко-систему. Думаю насчет Vue и NodeJs. У них я думаю есть некоторые преимущества. Под катом подробнее…
Во первых, Vue и NodeJs современные и популярные системы. На ярлык современные и популярные было бы пофиг если бы не одна вещь.
Над нашей EPR я работаю один и времени на многое не хватает. Нам нужно сделать больше функционала за меньшее время. Как впрочем думаю и всем програмистам :-). В программировании разработчики часто делают для себя программы(фреймворки, библиотеки и т.д.) которые значительно и бывает в разы ускоряют разработку программ. Например, я когда-то сделал компонент getTables и разработка редактирумой таблицы вместо 3-6 часов на ExtJs стала занимать 5 минут. Ускорение в 50-100 раз :-). С учетом того, что таблиц у нас стало много, такой функционал, что у нас есть я бы на ExtJs никогда бы не написал.
Так программисты создают упрощающие себе и другим разработку библиотеки и фреймворки. Современные фреймворки — это тысячи сэкномленных часов разработки для тех кто ими пользуются. И чем современнее фреймворк, тем по идее больше у него возможностей писать быстрее и лучше. Не всегда вот и с переходом думаю надо быть аккуратнее.
Сейчас меня достает проблема с дизайном. Я не развивался как верстальщик и оформить приложение красиво проблема. А дизайнеры фрилансеры либо делают не айс, либо если они хорошие, то постоянно заняты. Думаю, лучше все-таки делать самому, но на UI фреймворках. Думаю, если, например, делать фронт на quasar, то сделать красиво будет значительно проще. UI фреймворки на jquery, насколько я понимаю, сейчас не развиваются. Современный UI фреймворк — это что то на основе Vue. Такой как quasar.
В MODX очень удобная система чанков и сниппетов, но сейчас мне приходиться генерировать html отправляя запрос на сервер и получая html код с сервера. Часто было бы удобнее сгенерировать, например, форму на фронте через js, но чанки написаны на fenom, а феном только на сервере. Вот и приходиться каждый раз писать запрос на сервер. Думаю, перевод чанков в компоненты Vue здесь облегчит работу и добавит моим приложениям много интересных возможностей. Но тут для компонентов придется писать гораздо блольше API. Большая часть приложений это редактирование таблиц в базе данных. Над API я сейчас работаю и принципе сделал компонент для автоматизации генерации АПИ в MODX, но пока еще не пробовал в работе. Как накоплю опыт работы и проверю его опубликую.
Если перейти на Vue, то мне не нужны будут чанки и сниппеты MODX и так как это основа MODX, то и собственно не особо нужен будет и сам модекс. Реактивные фреймворки, такие как Vue делают контент прямо в браузере и у них возникает проблемы с поисковыми системами, так как когда поисковая система запрашивает контент, то контента еще нет. Для того чтобы контент был применяют SSR генерацию js компонентов на стороне сервера. Естественно php и модекс не умеет обрабатывать js на стороне сервера. У нас основной сервер внутри компании и не индексируется. Пока не критично, но рано или поздно надо будет пилить внешний сервер и тогда SSR потребуется. Ну и соответственно потребуется сервер умеющий обрабатывать js. Такой как NodeJs.
Так же если перейти на ноду, то и сервер и фронт будут на одном языке и можно будет перетаскивать какой-то код туда сюда с сервера на фронт.
Вот вкратце причины перейти на Vue и NodeJs. А какое у вас мнение? Мне будет интересно его узнать.
Поблагодарить автора
Отправить деньги
Комментарии: 11
Доброго времени суток ✌
Думаю, как и многие здесь, начал разработку сайтов благодаря курсам, заметкам и пакетам, созданными @Василий Наумкин. Лично я стал зарабатывать первые деньги именно благодаря MODx и Василию. Дай Бог Вам здоровья! ?
Сейчас же, Василий создал несколько курсов (в данный момент в бесплатном доступе на bezumkin.ru) по своей новой системе VESP: Vue + Eloquent + Slim + Phinx. Статьи, где упомнут такой выбор стека, к сожалению, не нашёл, помню, что выбор пал из-за того, что PHP хорошо знаком (мягко говоря) и переход на более современные тенденции более плавный. Мне эта идея понравилась и, изучая курсы, стал сразу работать над новым проектом, используя новую систему. Легче задышалось! Вы сами выбираете, где и что как должно работать, система вас не ограничивает! Рекомендация к прочтению: bezumkin.ru/sections/projects/3075
Понимаю, что создание того же (а именно агрегатор для бань с календарем и массой нестандартных решений) на MODx, несмотря на имеющийся Agenda, котрый покрывал 80% моих задач, был бы сплошной мукой. Даже простые вещи, как например, доабвить в календарь вывод номера телефона, ведь пришлось бы править исходники или выдумыать, как инетгрироваться в пакет без правок.
API на PHP, причём некотрые вещи, типо миграций и управление базой данных идентичны Laravel, а он в свою очередь имеет огромное сообщество, дополнения, инструкции и т.д. А управление фронтендом перенеслось на Vue + Nuxt для серверного рендера.
Выбор стека может быть любым: будь то полный переход на JS, как вы описали, или же React + дополения для роутинга и т.д. Vue — фреймворк, React — библиотека, и разница в том, что во Vue и Nuxt за вас уже решили (стандартизировали, можно сказать) структуру и архитектуру, не нужно придумывать велосипед. В React же выбор остается за программистом и стек может быть очень разным, как структура проекта, так и используемые технологии. Думаю, многие оценили прелести линтеров и преттиеров для js. Бесят, но зато разбираться в своем/чужом коде, оформленным по определенным правилам, куда проще ?
Выбор за вами :) Если полный переход на JS вас не пугает, как совершенно новое, чему придётся учиться с нуля — вперёд, всё получится! ?
Думаю, как и многие здесь, начал разработку сайтов благодаря курсам, заметкам и пакетам, созданными @Василий Наумкин. Лично я стал зарабатывать первые деньги именно благодаря MODx и Василию. Дай Бог Вам здоровья! ?
Сейчас же, Василий создал несколько курсов (в данный момент в бесплатном доступе на bezumkin.ru) по своей новой системе VESP: Vue + Eloquent + Slim + Phinx. Статьи, где упомнут такой выбор стека, к сожалению, не нашёл, помню, что выбор пал из-за того, что PHP хорошо знаком (мягко говоря) и переход на более современные тенденции более плавный. Мне эта идея понравилась и, изучая курсы, стал сразу работать над новым проектом, используя новую систему. Легче задышалось! Вы сами выбираете, где и что как должно работать, система вас не ограничивает! Рекомендация к прочтению: bezumkin.ru/sections/projects/3075
Понимаю, что создание того же (а именно агрегатор для бань с календарем и массой нестандартных решений) на MODx, несмотря на имеющийся Agenda, котрый покрывал 80% моих задач, был бы сплошной мукой. Даже простые вещи, как например, доабвить в календарь вывод номера телефона, ведь пришлось бы править исходники или выдумыать, как инетгрироваться в пакет без правок.
API на PHP, причём некотрые вещи, типо миграций и управление базой данных идентичны Laravel, а он в свою очередь имеет огромное сообщество, дополнения, инструкции и т.д. А управление фронтендом перенеслось на Vue + Nuxt для серверного рендера.
Выбор стека может быть любым: будь то полный переход на JS, как вы описали, или же React + дополения для роутинга и т.д. Vue — фреймворк, React — библиотека, и разница в том, что во Vue и Nuxt за вас уже решили (стандартизировали, можно сказать) структуру и архитектуру, не нужно придумывать велосипед. В React же выбор остается за программистом и стек может быть очень разным, как структура проекта, так и используемые технологии. Думаю, многие оценили прелести линтеров и преттиеров для js. Бесят, но зато разбираться в своем/чужом коде, оформленным по определенным правилам, куда проще ?
Выбор за вами :) Если полный переход на JS вас не пугает, как совершенно новое, чему придётся учиться с нуля — вперёд, всё получится! ?
Могу высказать свое, личное и не объективное мнение.
Считаю что даже в 2023 году ни node ни vuejs все еще не доросли до такого уровня, чтобы их использовать как основной стек для крупных, серьезных проектов. К самой ноде особых притензий нет, но поскольку она всегда идет в связке с каким то vuejs или react то и говорю о них как об едином целом.
Почему я так говорю. Ну во первых из последнего опыта. Долгие годы работали с классическим стеком технологий для веба, последние два проекта решили делать «модными». Тем более что это были закрытые crm системы и там не нужно было думать о сео и как следствие о ssr.
Наняли специально фронтендщиков, которые в грудь себя били что ничего лучше vuejs в мире не бывает и что они любую задачу там решат. И что в итоге — полный провал по всем срокам, все задачи выполняются в 4-10 раз дольше. Постоянные проблемы с тем, что никто не хочет писать ничего своего, все из готовых vue компонентов собирается и оказалось, что сложные вещи делать на vue очень сложно. Все привыкли какой-то туду лист по примерам сделать и считают что все — теперь на vuejs могу любой сложности проекты делать. А потом приходит заказчик, говорит, мол отличная таблица с данными, только встройте в нее такой то функционал и вот такой то, разработчики пытаются один готовый компонент впихнуть в другой, возникает кучу проблем. Короче говоря, то, что я могу сделать на чистом js/html/css за день (при условии что я бекендщик) на vue занимает недели. А учитывая, что заказчик очень переменчивый и может каждый день менять решения, то внести визуальные и логические изменения становится нашим фронтендищикам все сложнее и сложнее.
Можно и нужно конечно сказать, что это нам так не повезло, что мол есть фронтендщики которые делают любой сложности задачи и быстро. Может и есть, но у нас это уже третий опыт, третья попытка нанять опытных фронтедщиков и третий раз она заканчивается полным срывом сроков.
Но это мой опыт, но есть и другие звоночки, что сама идея современного фронтенда (рендеринг на клиенте) не была гениальной и может в скором времени быть признана неперспективной. Видели новый next.js? В нем разработчики делают шаг назад и постепепенно отказываются от рендеринга на фронте. видео
Мой вывод (очень субъективный) — на 2023 год vuejs все еще интересный, но не продакшен реди инструмент, на котором легко делать простые вещи (туду лист и прочее) но сложно и долго делать сложные вещи.
Считаю что даже в 2023 году ни node ни vuejs все еще не доросли до такого уровня, чтобы их использовать как основной стек для крупных, серьезных проектов. К самой ноде особых притензий нет, но поскольку она всегда идет в связке с каким то vuejs или react то и говорю о них как об едином целом.
Почему я так говорю. Ну во первых из последнего опыта. Долгие годы работали с классическим стеком технологий для веба, последние два проекта решили делать «модными». Тем более что это были закрытые crm системы и там не нужно было думать о сео и как следствие о ssr.
Наняли специально фронтендщиков, которые в грудь себя били что ничего лучше vuejs в мире не бывает и что они любую задачу там решат. И что в итоге — полный провал по всем срокам, все задачи выполняются в 4-10 раз дольше. Постоянные проблемы с тем, что никто не хочет писать ничего своего, все из готовых vue компонентов собирается и оказалось, что сложные вещи делать на vue очень сложно. Все привыкли какой-то туду лист по примерам сделать и считают что все — теперь на vuejs могу любой сложности проекты делать. А потом приходит заказчик, говорит, мол отличная таблица с данными, только встройте в нее такой то функционал и вот такой то, разработчики пытаются один готовый компонент впихнуть в другой, возникает кучу проблем. Короче говоря, то, что я могу сделать на чистом js/html/css за день (при условии что я бекендщик) на vue занимает недели. А учитывая, что заказчик очень переменчивый и может каждый день менять решения, то внести визуальные и логические изменения становится нашим фронтендищикам все сложнее и сложнее.
Можно и нужно конечно сказать, что это нам так не повезло, что мол есть фронтендщики которые делают любой сложности задачи и быстро. Может и есть, но у нас это уже третий опыт, третья попытка нанять опытных фронтедщиков и третий раз она заканчивается полным срывом сроков.
Но это мой опыт, но есть и другие звоночки, что сама идея современного фронтенда (рендеринг на клиенте) не была гениальной и может в скором времени быть признана неперспективной. Видели новый next.js? В нем разработчики делают шаг назад и постепепенно отказываются от рендеринга на фронте. видео
Мой вывод (очень субъективный) — на 2023 год vuejs все еще интересный, но не продакшен реди инструмент, на котором легко делать простые вещи (туду лист и прочее) но сложно и долго делать сложные вещи.
Именно, вам не повезло или вы так специалистов выбирали. Например, не могу порекомендовать себя на данный момент в этом стеке, т.к. сам учусь в процессе.
Сколько людей, столько и мнений, возможно, вам этот подход не подходит, а может не разобрались толком, а может используете не там, где надо, а может «спецы» такие и т.д. Есть масса задач, для которых CMS подходят куда лучше, ибо нечего велосипед изобретать, а есть такие, реализуя которые на CMS сталкиваешься с массой сложностей и ограничений. Василий отлично описал это в статье, упомянутой выше в комментарии. В мире MODx — это ExtJS, это конфликтующий сам с собой Composer (а точнее разные версии дополнений, необходимые для разные дополнений) и т.д. Сравните реализацию одного и того же на Vue и ExtJS.
Такая компания, как Сбер, наприимер, использую не по наслышке React, не жалуется ?
Ух, где же Вы, Николай Ланец, вас в этом обсуждении очень не хватает :)
Сколько людей, столько и мнений, возможно, вам этот подход не подходит, а может не разобрались толком, а может используете не там, где надо, а может «спецы» такие и т.д. Есть масса задач, для которых CMS подходят куда лучше, ибо нечего велосипед изобретать, а есть такие, реализуя которые на CMS сталкиваешься с массой сложностей и ограничений. Василий отлично описал это в статье, упомянутой выше в комментарии. В мире MODx — это ExtJS, это конфликтующий сам с собой Composer (а точнее разные версии дополнений, необходимые для разные дополнений) и т.д. Сравните реализацию одного и того же на Vue и ExtJS.
Такая компания, как Сбер, наприимер, использую не по наслышке React, не жалуется ?
Ух, где же Вы, Николай Ланец, вас в этом обсуждении очень не хватает :)
Всем привет! Я пока не осилил всех лонгрид-комментов в этом топике, но точно знаю, что @Fi1osof лучше вот так призвать, более технологично, и может даже сработать :)
Да, такой способ работает :)
Ух, где же Вы, Николай Ланец, вас в этом обсуждении очень не хватает :)Честно сказать, неочень хочется обсуждать все это, потому что верно сказано: сколько людей, столько и мнений. И выше человек тоже реальные примеры приводит с тем, как все это быстро меняется, и я во многом согласен. Но я бы сказал иначе: все это совсременное не только лишь для всех, а точнее для тех, у кого очень много денег, потому что маркетинг требует и делать это надо, но все это сложно и как правило команда нужна. Я работаю в таком проекте, и да, все сложно, и на все это есть деньги. А не делать это нельзя, потому что «мы так хотим». Но могу точно сказать: все то, что мы делаем, на старых технологиях это просто не сделать (я бы именно сказал, что никак). Так что мы в той точке развития, когда назад уже не пойти и остается только ждать когда все это устаканится и будут выработаны best practices.
Vue/React не делают шаг назад. Добавили серверного рендеринга, чтобы банально быстрее грузилось, чтобы пользователь быстрее мог увидеть интерфейс, а не белый лист с индикатором загрузки.
Проблемы с расширяемостью готовых Vue/React/Svelte компонент действительно существует, проблема не решается в лоб. Но об этом знает любой front-end разработчик с релевантным опытом.
Проблемы с расширяемостью готовых Vue/React/Svelte компонент действительно существует, проблема не решается в лоб. Но об этом знает любой front-end разработчик с релевантным опытом.
Очередной крик души)
Мне знакома твоя ситуация, я сам был в ней 2 года назад и вот к чему пришел в итоге поисков я:
Мне знакома твоя ситуация, я сам был в ней 2 года назад и вот к чему пришел в итоге поисков я:
- MODX, действительно, скажем честно, вряд ли ожидает новый взлет популярности — всему причина нежелание разработчиков кардинально менять движок, но с другой стороны он как решал прекрасно свои задачи 10 лет назад так и решает их сейчас. Если Web-мастеру становится тесно с ним жить, то значит он перерос этот движок, что хорошо на пути развития как специалиста.
- Куда двигаться дальше? Мой путь: Laravel, Spiral Freamework — просто «миллиарднократный» скачок в плане Developer Experience, всё по полочкам, всегда знаешь где, когда и откуда растут ноги у малейшей ошибки в коде, мониторинг запросов и ещё куча всего всего, просто на голову выше качество кода самих фреймворков — есть чему учиться.
- PHP или Nodejs — бесспорно нода за последние годы выросла и на ней можно реально делать хорошие, сложные проекты, но мне гораздо легче оставаться в рамках знакомого языка, который полностью покрывает потребности проектов, что мне достаются. И тут замечу, что php умеет обрабатывать js на стороне сервера, а то меня это смутило как-то в твоем крике души, вопрос лишь гугления. Если просмотреть внимательно тенденцию реактивных фреймворков — до них всех начало доходить, что всё делать на клиенте не самый лучший путь, отсюда как грибы у всех начали появляться Server Actions — многие «старики» даже ржут с этого, так как по сути эти «реактивисты» возвращаются к тому же с чего уходили, то есть к серверному рендерингу, просто с последующей гидратацией. С другой стороны классические движки наоборот переняли многое от реактивщины и сегодня можно комфортно писать привычные шаблоны на бекенде прямо в виде SFC как например во Vue и это всё уедет на клиент отрендеренное. Хороший обмен опытом между двумя путями.
- Ну и чуть приближенней к твоей задаче из моего личного опыта: такие вещи как CRM и ERP системы нужно писать на очень зрелых технологиях, проверенных временем и как правило такие системы пишутся и состоят из 2 частей отдельный проект API, и отдельный проект это клиентские приложения, на чем бы они не были написаны. Сегодня ты делаешь сайт, завтра понадобится мобильное приложение под android и под ios, а послезавтра уже десктопный софт на винду и macos. Когда есть API с хорошей документацией, развивать проект гораздо удобнее и легче. ERP это один из самых сложных по структуре проект из всех что мне доводилось встречать, куча асинхронщины, что многих php-шников сразу вводит в ступор, но тут появляется Spiral Framework — чудо мутант PHP + GO, целью которого как раз являются такие вот сложные, многослойные проекты, вот собственно его я и выбрал и подробно в нем копаюсь последний год, пока впечатления только положительные.
Но тут есть важный аспект — развиваться как фрилансер или как наемный работник. Прокачаться полноценно можно только в более менее развитой компании с современной инфраструктурой. Это моё личное мнение. Изучить Spiral в качестве повышения скила будет полезно, но применить его (фреймворк) в компании вряд ли получится. Ибо я как техлид не взял бы этот инструмент из-за одной простой причины — очень сложно найти разработчиков под него и усложняет дальнейшую поддержку. Да и как заказчик не стал бы заказывать свой проект у фрилансера на Spiral. Именно по той же причине — проблемы в дальнейшей поддержке. Хотя я этот фреймворк пробовал и мне он понравился. Но с практической точки зрения ему нет применения.
Поэтому я бы советовал смотреть вакансии в интересных компаниях и прокачивал бы соответствующие скилы.
Это чисто моё мнение.
Поэтому я бы советовал смотреть вакансии в интересных компаниях и прокачивал бы соответствующие скилы.
Это чисто моё мнение.
Последний проект нвчинал делать на MODX с ZoomX + Vue с Quasar. В MODX не очень удобно создавать таблицы в базе, поэтому экспериментировал с Eloquent. Наверное получилась странная связка, и для бэка лучше было бы взять Laravel, но времени его изучать не было
Если надо быстро, то Uikit3 + Hotwire Turbo + Laravel.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.