Ответы пользователя по тегу Фронтенд
  • В каких случаях использовать SPA с серверным рендерингом, а когда обычный сайт?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Мода есть, несомненно, но не только в ней дело!

    стоит вопрос делать его как SPA на Nuxt или как обычный сайт с перезагрузкой страниц


    Зависит от бекенда, если бекенд делает для вас api, тогда вам только SPA(не важно на чём), а если по старинке, значит по старинке, с перезагрузкой страниц. Тут как договоритесь.

    Плюсы подхода разделения бека и фронта аля SPA:
    1. Само по себе разделение ответственности. Фронт отвечает за отображение, бек за данные. В этом их суть

    2. Удобство работы. Вы работаете исключительной с той кодовой базой, которая вам понятна, приятна.

    3. Отдельные репозитории. Каждое окружение само решает, как им лучше вносить фичи, без оглядки на друг друга. Фронту не должно быть дела, до обновления фич и решения возможных конфликтов с бекендовым кодом. Вы работаете исключительно со своей кодовой базой

    4. Сами по себе преимущества spa. Обновление только нужных участков html, более быстрое решение рутинных задач, за счёт автоматизации многих процессов аля(vue cli, nuxt и т.п. - там всё уже из коробки собирается и настроено, только пиши код), разделение кода на чанки и т.п., думаю и так понятно

    5. Какая никакая, но архитектура приложения.
      Разворачивая проект через cli, вам уже даётся начальная структура папок, что уже говорит о том, что вам не нужно думать хотя бы об этом. Вы заранее знаете(если у вас есть опыт, если нету, ничто не поможет всё обговнять) что для решения тех или иных фич вам нужны те или те возможности фреймворка.
      Хоть реакт, хоть vue, уж тем более angular.



    Минусы подхода разделения бека и фронта аля SPA:
    1. Настройка всего деплоя приложения на сервере. Настроить gitlab.ci, настроить докер, настроить vps(если уже не готов), настройка nginx(не всегда, но бывает). Или вы думаете, за вас кто-то это будет делать? Бекенд себе всё настроит, а вы сами давайте. Вы же хотели разделение. Дай бог, что у вас в компании есть админ, который занимается подобными вопросами или же просто кореш, готовый вам помочь.


    2. SEO - большая проблема нашего времени. Если SEO, значит ssr, раз ssr, значит nuxt(ну или ручками настраивать, удачи). Тогда тут вступает в силу node.js. Его бы на сервере ещё запустить, на порту повесить и т.п. Просто SPA собрал и всё, а вот SEO, SEO накидывает на нас гемора и работы.


    3. Реализация "модулей" с 0, которые в старом подходе у бека уже можно скачать(из магазина готовых решений например, если это цмс, ну или готовые пакеты у фреймворков) и запустить(корзина товаров, фильтры, каталоги, сортировки и т.п. вещи). На фронте придётся всё делать заново, потому что готовых решений нет.

      Если взять какой нибудь вордпрес или битрикс, где уже имеется огромное кол-во готовых решений, которые подключил и они работают, минимально +- правя стили, то в spa подходе, дай бог что бы эти решения имели rest api для вашего чудо spa. А вы в свою очередь будете клипать вёрстку и логику с 0, мучаясь с кучей запросов, обновлением данных и т.п. вещами.

      А писать оформление заказа с выбором доставки, да и выбором адреса на карте, с последующим выбором кучи других моментов при оформлении заказа, это жесть. Но зато сами напишите, зато SPA, vue. А если ещё и авторизация какая-то будет, да и с заворотами или через какой-то внешний oauth сервер, так вообще красота)))


    4. Сложность понимания, на чьей стороне произошла ошибка. Фронт всегда будет выступать в первых рядах. Все камни полетят к вам. Не вывелось то-то, фронт иди сюда, не отправилась форма, фрооооонт, ауууууу!!!!!
      А как винить за это менеджеров? Они не должны сидеть кликая f12 и анализируя, где и какая ошибка получилась.
      Иногда бек виноват, иногда фронт.

      Да, можно подключить какой нибудь sentry. Но это, на мой взгляд, лишь доказывает, что с наш подход усложняет поддержку и разработку. Теперь у нас появился ещё 1 сайт, где мы смотрим логи фронта, что же у него случилося. У бека всё просто, зашёл на страницу, бац, ошибка sql на всю страницу, всё ясно становится)))

      Я конечно это не вот прям серьёзно, но зерно то есть в этих словах. Sentry хорошая штука, но она станет незаменимой для решения этих проблем. Иначе понять, на чьей стороне происходят не понятные ошибки, которые не ясно как выявить, а логи у ноды лежат чёрти где, если вы или ваш админ не настроили их по людски.


    5. Очень частая зависимость от данных бекенда. Изменилось 1 поле у бека, вам скорее всего нужно идти и править это. Добавилось новое поле, опять бежать и выводить 1 переменную. Мать твою, бек, сам не можешь что-ли переменную вывести??? Ах да, у нас же SPA.


    6. Прикрываясь удобством и модностью SPA можно такого говна наворотить. Сделать компонентики любой дурак сможет, а вот создать хаос из этих компонентов и не понимая, как более менее внятно решать проблему серьёзных задач и организации кодовой базы, это да. Не все осознают, на что подписываются. Иначе вы бы не задавали такие вопросы.

      В то время, когда бы за вас всё бекенд делал, потому как многое у него уже готово, а вы просто вёрстку ему отдали бы и всё. Ну подвёрстывали бы иногда, ну пару скриптиков добавляли.


    7. Ну и последнее, удорожание поддержки такого проекта. Т.к. вместо единой кодовой базы, теперь их 2. Внесение изменений требует большего кол-ва людей, нежели при обычном подходе. Бекендер и без фронта может написать jquery ajax запрос или вывести кнопку с модальным окном и формой, потому что очень часто тупо юзают бутстрап и собрать подобные блоки просто, или же просто вывести новое поле с текстом или ещё чем-либо.



    Я дал вам пищу для размышлений. Всё, что я написал имеет место быть. Задачи могут отличаться, проекты могут отличаться. Но суть моих слов от этого врятли поменяется. В большинстве случаев я за раздельный подход к написанию проектов.
    Ответ написан
    Комментировать
  • Как лучше кешировать полученные данные с сервера?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Кешировать должен сервер, а фронт запрашивать, пускай и одно и тоже.
    Либо запросить 1, а после просто проверять, если данных в переменной нет, запросить.
    localstorage это вам не жёсткий диск на 1тб. Там скудное кол-во данных может быть и держать там некую базу глупо, к тому же, геморнее вносить туда изменения, если нужно поменять 1 элемент.

    К тому же, а если данные на сервере изменились, фронт как должен это понять? На мой взгляд глупое решение, которое ни к чему хорошему не приведёт.
    Ответ написан
  • Когда SPA, а когда MPA?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Гуглил, читал, почти в каждой статье все упирается в SEO.
    это вообще тут не причём, юзаем SSR и всё.

    В целом, зависит от команд разработчиков. SPA на далёкую перспективу на мой взгляд поддерживать проще, чем по старинке.

    Так же, выбором в сторону SPA может быть большое кол-во логики, которое вынесено на клиент или большое кол-во интерфейсов, которые связаны между собой. Или это сайт как яндекс музыка или вк, когда музыка играет, даже если вы переходите по страницам. Потому что страница не обновляется. А клиент получает лишь то, что ему действительно нужно, не обновляя страницу целиком. Это позволяет снизить нагрузку на сервер, но лишь, когда аудитория в много много человек.

    Выбором может быть просто любовь команды разрабов к тому или иному фреймворку/стеку. На мой взгляд, это тоже нормально. Пишут люди на React или бек на php yii2, с чего они должны взять и перейти на другой стек, когда пришёл новый заказ? Им удобно, им нравятся эти инструменты, процессы налажены, код стайл сформирован, готовые для их работы модули или сниппеты уже написаны, профит. Это единство кодовой базы, что позволит достаточно быстро перейти с одного проекта на другой, ведь везде будет одинаковый стек.

    Если это просто фриланс сайт на 1 раз, сверстал, натянул на вп(любую другую похожую CMS) и отдал(и т.п.), то тогда не нужны никакие SPA.
    А если у вас команда разработчиков, то на мой взгляд SPA подойдёт куда лучше.

    P.S. В нашей компании, мы 2.5 года назад полностью перешли на vue(nuxt.js) и не пожалели, выросло кпд и переход с одного проекта на другой стал гораздо проще. А старт новых проектов был отлажен, путём написания уже готовых модулей, которые были выделены в процессе написания прошлых проектов. Что позволило в конечном итоге снизить стоимость(пускай и не так много), но снизить время на написание одних и тех же модулей.
    Ответ написан
    Комментировать
  • Слайдер времени (noUiSlider), что я делаю не так?

    bootd
    @bootd Куратор тега HTML
    Гугли и ты откроешь врата знаний!
    Потому что для него нет стилей
    Ответ написан
  • AdGuard блокирует слайдер на сайте. Как исправить?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    комментарии с словами banners удалите
    Ответ написан
  • Что делает frontend разработчик кроме создание внешнего вида сайта?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Внешним видом как правило занимается верстальщик, frontend разработчик делает свистоперделки. Клики, вывод, обработка данных.
    Разрабатывать мобильные приложения не входит как таковое в обязанности frontend разработчика, но написать приложение на веб технологиях, как по мне, так тоже может входит в эти обязанности, но не все обязаны знать как, т.к. помимо js есть другие вещи, знание платформы, для которой пишешь, знать её api и т.п., но выучить не будет лишним.

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

    Игры в браузере тоже работа frontend разработчика, а с чего нет? В браузере? В браузере. На js? На js.
    Ответ написан
    Комментировать
  • Не зацикливается анимация. Где допущена ошибка?

    bootd
    @bootd Куратор тега CSS
    Гугли и ты откроешь врата знаний!
    from
      {
        opacity: 1; // Замени на 0
      }
    Ответ написан
    1 комментарий
  • Какой Js фреймворк лучше учить с c#?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Любой. Клиентские js фреймворки не работают с бекендом, они работают с данными и это json.
    Ответ написан
    Комментировать
  • Зачем нужно изучать основы вёрстки, если есть webflow?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Вопрос из разряда, зачем изучать математику, если есть калькулятор)))

    Ничто и никогда, никакой конструктор не позволит вам создать CRM, соц. сеть, веб игру, свой гитхаб, какие либо сервисы(тот же самый webflow) и херову тучу других продуктов. Проще говоря, вы уже не сможете создать что-то уникальное, что делают другие, знающие веб языки.

    А так же, создание просто сайта визитки, магазина при помощи конструктора, это удобно и часто быстро. НО!!!

    Всем этим нужно заниматься, далеко не все хотят этим заниматься, изучать веб и т.п. Проще отдать деньги и сказать, как я хочу, чем убить огромное кол-во времени.

    Все могут сами что-то делать для себя, не тратя свои средства, но время и силы, потраченные на создание лично, далеко не всегда равны тому, что бы просто взять и купить или заказать
    Ответ написан
    Комментировать
  • Как сделать авторизацию в React без Redux?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    просто куки для логина, ну а для реги тут хранилище не нужно, вы же на бек всё отдавать будете
    Ответ написан
    3 комментария
  • Зачем нужен frontend, если всю начинку сайта или проекта можно реализовать с помощью backend'a?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    JavaScript, HTML, CSS - в браузере нужны для того, что бы ваши данные визуализировать для пользователя, а phyton, node.js, PHP нужны для того, что бы эти данные предоставить

    1)
    Таких как phyton, node.js, PHP
    - node.js это JavaScript
    2)
    потом интерфейс, добавить анимацию, сделать разметку страницы и т.п
    - а на чём вы собираетесь строить это, кроме как на JavaScript, HTML, CSS

    Вся текущая красота интерфесов react, vue, angular даёт нам возможность разграничить нагрузку. Пускай сервер занимается тем, чем должен, логикой и вычислениями. А браузер, на основе данных бекенда рисует нам странички. Тем самым мы высвобождаем много ресурсов для сервера, что бы ему это всё не генерировать.
    Ответ написан
    2 комментария
  • Сайт грузит оперативку или процессор, почему?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    У меня моментально загрузился, 2 минуты смотрел в диспетчер задач, но не увидел там каких либо аномалий!
    Вкладка с вашим сайтом занимает у меня 4-5% проца и около 150-160мб памяти. Что-то вы придумываете)). В фоне на сайте постоянно работают карта яндекса и его вебвизор, которые постоянно шлют запросы к своим серверам, что нормально, больше ничего такого я не заметил.
    Ответ написан
  • Как вызвать разный JS код при открытии модальных окон?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Воспользоваться событием
    $('#exampleModal').on('show.bs.modal', function (event) {
    console.log($(this))
    })

    или открывать каждое окно при помощи js
    $('#exampleModal')
    .modal('show')
    .on('show.bs.modal', function (event) {
    console.log($(this))
    })

    Доку то вообще читали?
    Ответ написан
  • Почему не адаптируется сайт на bootstap 3?

    bootd
    @bootd Куратор тега CSS
    Гугли и ты откроешь врата знаний!
    а почему, если бутстрап, то сайт обязан адаптироваться? Смешное утрверждение. У сайта задана минимальная фиксированная ширина. Её можно увидеть, если уменьшать сайт в браузере. У вас появится полоса прокрутки внизу
    Ответ написан
    Комментировать
  • Как срезать такой угол?

    bootd
    @bootd Куратор тега CSS
    Гугли и ты откроешь врата знаний!
    Создаём 2 блока, :before, :after. Позиционируем и поворачиваем каждый. Готово
    Ответ написан
    Комментировать
  • Как работает Frontend вместе с Backend?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Создаются компоненты, которые в свою очередь через api и запрашивают нужные данные с сервера, полученные данные уже раскладываются как вашей душе угодно.

    Т.е. имея компонент todo:
    <template>
    <ul>
      <li v-for="item in list">
        <h3>{{item.title}}</h3>
        <p>{{item.text}}</p>
      </li>
    </ul>
    </template>
    <script>
    export default {
      data(){
        return {
        	list: ''
        }
      },
      computed(){
      
    // Запросим данные с сервера и сохраним наш json в data
        fetch('/api/users') // По этому адресу мы получим у сервера данные о пользователях
          .then((response) => {
          	this.list = response // запишем эти данные в data
          })
          .catch(error => console.error(error))
          
      }
    }
    </script>
    Ответ написан
    Комментировать
  • Параллакс с помощью движения телефона в пространстве - возможно ли?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    matthew.wagerfield.com/parallax - открой на телефоне.

    Такая штука доступна, путём получения данных акселератора телефона. Суть такая же, как и с получением координат курсора. Главное что бы в устройстве была возможность для получения данных с акселератора.

    Начиная с этой строки идёт вычисление данных о том, в каком положении находится устройство. Ну и поддержка браузером подобной фичи
    Ответ написан
    1 комментарий
  • Какой слайдер-карусель вы используете с Vue.js?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Юзаю slick. Я с ним уже года 2 работаю
    Ответ написан
    5 комментариев
  • Как сделать такую svg анимацию?

    bootd
    @bootd Куратор тега CSS
    Гугли и ты откроешь врата знаний!
    Ответ написан
    Комментировать