Стоит ли писать веб-приложение используя только yii2 + jquery?

Question

[Ольга Пономарева]

Всем привет!

Я веду проект, который был написан на php (без фреймворков) + jquery + html + css. Это проект я переписала на yii2, используя базовый шаблон на bootstrap. Теперь код стал более структурированным и понятным, но у меня закрадывается впечатление, что мой проект пахнет нафталином, т.к. интерфейс генерируется на сервере и не используется никаких angular-ов или vuejs-ов. Проект предназначен для внутреннего использования и нагрузка на сервер не очень большая (максимальное количество пользователей - 500). Начальству нравится этот проект и не считает, что нужно его переводить на фронтенд фреймворк и делать restfull api. Но я так не считаю, т.к. со временем делать интерфейсные решение становится всё сложнее - jquery не очень удобен в данном случае.

Поделитесь мнением пожалуйста, стоит ли потихоньку реализовывать spa-приложение и развиваться как фуллстак-разработчик, или стоит углубиться в бекенд-разработку. Знаю, что вопрос кажется плаксивым и глупым, но мне больше некому посоветовать. Надеюсь на ваши пинки и советы. Заранее спасибо.

Comments

[alex-1917]

Вообще-то эта новомодная фича - перекладывать нагрузку с сервера на клиента - пошла от цукермана или как там его)) Который зажмотил на серверах для своего FB. Теперь все , кто на планшетах 2016 года - ОРУТ!
Если упомянуть тех кто на планшетах 2014 года -ихний ор слышно на Юпитере.
Погуглите, это не мои придумки, увы и ах...
Просто чтобы не прослыть п8888болом, откройте на планшете айпад4 страничку любого отчета в гугл-аналитикс...

[Ольга Пономарева]

Забугорная мода, но что поделать ;)

Answer 1

[Михаил Бобков]

А нужен ли вам перевод системы на SPA?
Если хочется больше интерактива на странице - можно взять vue и сделать на нем динамические элементы.

Не советовал бы без опыта сходу браться за переписывание всей системы.
Скорее всего сильно затянется + будут текущие работы по проекту, который нужно будет делать на старой версии.
В результате получится каша.

Comments

[Ольга Пономарева]

Спасибо =) Я солидарна с Вами. Это наверное будет не такой болезненный переход, тем более, что javascript знаю не так хорошо, чтобы использовать все плюшки vuejs и делать полноценный SPA.

[alex-1917]

Ольга Пономарева, а взяли бы и поделились с коллективным разумом своим проектом!! Можно сказать точно одно - не ВСЕМ проектам одинаково полезно переходить на фронт!! Если массив информации достаточно велик, php-вариант всяко быстрее и смартфоны не будут тихо плакать в уголке!

Answer 2

[Александр]

Поделитесь мнением пожалуйста, стоит ли потихоньку реализовывать spa-приложение и развиваться как фуллстак-разработчик, или стоит углубиться в бекенд-разработку.

Да, думаю стоит. Тем более что обслуживать проект вида "независимый фронтенд + API для него" гораздо легче. Получается двойная польза: более лёгкое обслуживание и масштабирование и, как вы уже сказали, саморазвитие себя как fullstack-разработчика

Comments

[Ольга Пономарева]

Это конечно весомый довод - более легкое обслуживание и масштабирование. Но отношение к фронтенду не очень хорошее, т.к. там много всякого. Например, устанавливая простой проект vuejs я поразилась изобилию непонятных библиотек, когда на yii2 все намного проще. В package.json около 15 строчек в графе devDepencies и проект изначально весит 120 мб. Неужели это все нужно?

[Ольга Пономарева]

Это был риторический вопрос =)

[Александр]

Ольга Пономарева, вы можете просто использовать CDN.

<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.5.17/vue.js"></script>

[Ольга Пономарева]

Артём Петренков,

devDependencies на 120 Мб — это минификаторы и транспиляторы кода, и они в сборку сами не попадут.

Но ведь этим необходимо уметь как-то пользоваться, а это довольно обширная область знаний. Мне нужно здраво оценить сложность моего фронтенда и задуматься о сложности интерфейса. На мой взгляд, там довольно простые вещи, но некоторые требуют повторного использования. Скажите пожалуйста, а может ли мне помочь чем-то Twig или Smarty?

[Александр]

Ольга Пономарева, поможет

Answer 3

[xmoonlight]

includeHTML - решение всех проблем в плане SPA и предотвращение полной перезагрузки страницы при обновлении одного/нескольких блоков!

Основные преимущества:
0. Всего ОДНА ФУНКЦИЯ!
1. Вставка любой HTML-разметки через HTML-тег или через JS-функцию.
2. Асинхронная и синхронная загрузка (по желанию).
3. Рекурсивная загрузка всех вложенных зависимых блоков.
4. Создание своей функции-обработчика после окончания загрузки нужного блока.
5. Возможность любой компоновки блоков (включая бесконечную вложенность одних в другие!) на одной странице.
6. Возможность многократного повторного использования блока(-ов) на разных страницах.
7. Возможность создания своих представлений интерфейса (layouts) в зависимости от целей конкретного пункта в главном (или второстепенном) меню раздела/категории/страницы.

Comments

[Ольга Пономарева]

Очень интересно! =)))

[Александр]

Ну его... Лучше тогда уж jQuery

[xmoonlight]

Александр,

Ну его... Лучше тогда уж jQuery

ты глупый что ли?!
Одна строка с АСИНХРОННОЙ и РЕКУРСИВНОЙ! загрузкой весом 1,5кб против старинного jquery, все функции которого являются дополнительным слоем логики, который грузит процессор и занимает время на обработку при рендеринге, и к тому же УЖЕ ВСЕ! функции jquery повторяют 1-в-1 функции "чистого" js ES2015(ES6)?!

[Александр]

xmoonlight, includeHTML просто загружает код из других файлов и делает это с помощью запросов. В малых и небольших приложениях это может быть удобно, но всё равно это не очень хороший подход. Поэтому всё-таки намного лучше использовать даже ту же jQuery. Даже несмотря на то, что она повторяет ES6, всё равно она так или иначе облегчает кодинг на JS

[xmoonlight]

Александр,

В малых и небольших приложениях это может быть удобно, но всё равно это не очень хороший подход.

Объясните конкретно: на каком основании/фактах/опыте был сделан вами такой вывод?

[Александр]

xmoonlight, факт, как я уже сказал ранее - это просто импорт кода из других файлов через асинхронные запросы. Но зачем? Это ведь неудобно. Лучше с помощью запросов получать JSON с сервера, делать из него JS-объект и на его основе потом делать что-либо ещё. А приложение, где прямо берутся и импортируются файлы HTML из одного в другой будет, как минимум, неудобно поддерживать

[xmoonlight]

Александр,
1. Если мне нужно поменять страницу/панель - мне проще загрузить сразу готовый блок с разметкой.
2. При загрузке других панелей на странице - мне не нужно следить за этим: будет сделано всё автоматически, т.к. поддерживается рекурсивная связка блоков.
3. Если мне нужно поменять меню - я ставлю замену меню в обработчик загрузки блока.
4. Никто не мешает получать JSON с сервера тогда, когда это действительно нужно (для виджетов, например), но сами виджеты (HTML-разметку) - также проще грузить из заранее подготовленного кода HTML. А запрашивать JSON - обработчиком (callback) сразу после загрузки HTML-разметки.

Что здесь НЕ УДОБНО?

[Danila]

xmoonlight, тем, что в современном мире бекенду не место на фронте

[xmoonlight]

Данила, так никто и не собирается "отбирать кусок хлеба" у фронта... :)

[Александр]

xmoonlight, зачем разделять то, что разделять не нужно? И зачем подгружать целую разметку, когда можно просто загрузить JSON и на его основе уже отрендерить то что нужно?

[xmoonlight]

Александр, Рендер на фронте - это время, загрузка CPU и энергия (батарейка на смартах). Зачем рендерить то, что можно хранить уже готовым и просто наполнить динамическими данными (через тот же JSON в обработчике загрузки блока)?

[Александр]

xmoonlight, понятное дело, что рендер на фронте тратит ресурсы. Но я говорю о том, что подгружать аж целую разметку неудобно. Лучше и легче подгрузить JSON, а разметка уже будет на странице. К тому же, никто не собирается рендерить прям всю разметку с помощью JS, если на то пошло. Если какая-то разметка и будет рендериться через JS, то это будет максимум лишь какой-нибудь список или таблица

[xmoonlight]

Александр, Если мне нужно 2/3 (или половину) блоков не трогать, а остальные - заменить на другие типы блоков (по клику во вкладке, например). То как тут быть (каким образом лучше сделать)?

[Александр]

xmoonlight, расскажите подробнее. Каким образом заменить? И что имеется ввиду под "другим типом"?

[xmoonlight]

Александр, Пример: есть сбоку меню и сверху - панель сортировки/фильтрации.
Мне их трогать не нужно.

Под панелью, наполнение блоками: блок1 (таблица), блок2 (ротатор/слайдер), блок3 (голосовалка).

Теперь, я кликаю в пункт меню и получаю новое наполнение (под панелью) вместо предыдущего (заменяется предыдущее): блок2(ротатор/слайдер), блок4(текстовый контент), блок7(блок похожих материалов)

и т.д. с другими пунктами меню...

[Александр]

xmoonlight, если данные внутри блоков не меняются, то можно просто по клику показывать нужные блоки, а не нужные скрывать

[xmoonlight]

Александр, Нужных блоков - пока ещё нет на странице (не требовались они...).
А данные в них - всегда разные (зависят от объектов из меню), и функциональность блоков - унифицирована по цифрам (блок1, блок2 и т.д.).

[Александр]

xmoonlight, тогда рендерить

[xmoonlight]

Александр, ну вот. А если применить includeHTML - то мы тянем нужный ГОТОВЫЙ свёрстанный блок и заполняем его инфой через функцию-обработчик после загрузки.

[Александр]

xmoonlight, но ведь для этого необязательно использовать именно includeHTML. И это займёт чуть больше времени, чем получение JSON и рендеринг на клиенте на основе этого самого JSON-а. Да и по-сути это тот же рендеринг

[xmoonlight]

Александр, больше - не займёт, т.к. вы будете тянуть сначала один блок, потом другой, создавать из json DOM-ветки для каждого блока, заполнять их и т.д.

А тут - все блоки получает параллельно и туда вставляет только данные.
А если сервер вернул готовые блоки с нужными данными - то вообще не нужен JSON и ничего с ними делать: сразу размещаем HTML-блок (готовую ноду) в нужный контейнер и всё...

[Александр]

xmoonlight, ну сервер не должен возвращать готовую разметку, это неправильно.

Всё равно тянуть готовую разметку в контейнер - это тот же рендеринг. Тем более что в неё ещё будут вставляться данные

[xmoonlight]

Александр,

Всё равно тянуть готовую разметку в контейнер - это тот же рендеринг

Нет. Это ПРЯМАЯ ВСТАВКА НОДЫ в DOM (одной JS-функцией) без обработки: мы не создаём никаких узлов внутри, не проставляем свойства, и т.д.
Это в несколько раз быстрее, чем создавать через JSON+JS ту же ноду.

Answer 4

[Ольга Пономарева]

Ребят, спасибо Вам огромное за советы =)) В итоге, благодаря вашим ответам, накопленного опыта в проекте и мыслей о перспективе я решила:

0. Пока довольствоваться jquery.
1. Подтянуть знания по javascript (знания есть, но не такие сильные как хотелось бы), чтобы иметь возможность понимать как использовать VueJS.
2. Ознакомиться с документацией по VueJS.
3. Сделать функционал для админов в виде простенького SPA-приложения (у нас есть внешняя часть, где работают сотрудники, и внутренняя часть для админов), которое потом можно будет показать начальству в качестве доказательства, что я справлюсь.
4. Мое положение, в данном случае, безвыходное, т.к. мне просто необходимо узнать javascript лучше, чтобы вырасти профессионально и сделать продукт более масштабируемым и поддерживаемым. А там, кто знает, может быть я без памяти влюблюсь во фронтенд, преодолею страх перед изобилием технологий. Может даже сделаю фронтенд его своей основной специализацией, меня всегда привлекал интерфейс (делаю каждый раз прототипы в moqups - но это уже совсем другая история).

Спасибо Вам огромное ребята, Вы придали мне сил двигаться дальше и думать на перспективу =)

Comments

[Александр]

Удачи

[xmoonlight]

Зря только не оценили мой труд, ну что ж - видимо не умею доносить смысл...
Удачи.

[alex-1917]

xmoonlight, я оценил!