Фёдор

Самое время познакомиться с темной стороной программирования.
Начинающие вайтишники искренне думают, что программист - это типа такой художник. Берет мольберт, поллитру, кисти и начинает ВАЯТЬ. Потом отходит на шаг, любуется делом рук своих, и снова. Ваять. А потом сразу заказчику, за большие деньги.

Так вот, в реальности это всё не так.
Большую часть времени программист не пишет код.
А пытается разобраться, почему он не работает.

Так что мы будем сейчас учиться это делать.
Тем более, что это в принципе несложно.
Главное не думать, что чем-то поможет сидеть и тупить в свой кодик. И приглашать других людей потупить в него тоже бессмысленно. Потому что причина может быть совсем не в нем. но даже если проблема и в коде, то искать её всё равно надо по-другому.
В код не надо тупить. Его надо ЗАПУСКАТЬ.
И выводить промежуточные результаты. Проверять его работу.
Заранее выяснить, какие должны быть значения у переменных, и проверять их на каждом этапе.
Где не совпадут - там и проблема.
В идеале IDE сама покажет содержание всех переменных при трассировке, но если пишешь код в блокнотике, то даже тупо писать var_dump($bar1,$var2,$var3...); и смотреть что там лежит.
Условия проверять еще проще, тупо echo 'зашли в условие if (!empty($user))';
И если лежит не то, или эхо не выводится - вот тогда уже смотреть в код и думать, почему так получилось.

В частности, при авторизации надо проверить две вещи:
1. Находится ли юзер по логину
2. если находится, то проверить корректность хэша. Для этого при регистрации надо вывести полученный через password_hash пароль и записать на бумажке
потом запросить сохраненный из БД и сравнить

Кроме того
Разумеется, отладка невозможна без сообщений об ошибках.
В половине случаев РНР человеческим голосом сообщает в чем проблема.
Поэтому всегда, в любом окружении должно стоять error_reporting(E_ALL);
плюс на домашнем компике полезно прописать ini_set('display_errors', 1); чтобы сразу видеть ошибки на экране.
На боевом сервере разумеется поставить 0 вместо 1, и добавить ini_set('log_errors', 1);

У меня только один вопрос.
Какой смысл вообще делать парольную защиту, если любой придурок сможет спокойно авторизоваться через SQL инъекцию?

Это вот это.

{} // литерал объекта
[] // литерал массива
'' // литерал строки
"" // тоже литерал строки
`` // ещё один литерал строки
/./ // литерал регулярного выражения (конкретно для примера - любого символа)

парень. Всё равно ты будешь использовать ту терминологию, которую используют на работе. Если там под замыканием подразумевается замыкание с инкапсуляцией, то после того как тебе сказали что "твой код - говно", было два варианта: 1)поговорить о терминах либо со ссылкой на официальную документацию, либо вместо с собеседником вывести определение исходя из смысла понятия, не прибегая к авторитетам вообще. 2) Сказать о том, что прочитал такое определение у %авторитет%, и сказать, что готов использовать то, которым пользуетесь вы на работе.

По поводу выведения определения: есть смысл замыкания. Его нужно чётко озвучить согласиться с ним. Например, ты хочешь сказать, что смысл замыкания это ничто иное как "повесить ссылку на переменную с которой окончена работа до объявления функции, для сейва от мусорщика". Спросить - согласен ли с этим собеседник, или есть дополнения/возражения. Если согласен - значит "функция, являющаяся замыканием - любая функция, которая ссылается на переменную вне своего тела, в случае если переменную иначе удалил бы сборщик." Далее нужно договориться, что "иначе удалил бы" можно опускать как лишнюю сущность, которая усложняет определение такой функции, и упростить до - "функция, ссылающаяся на переменную вне своего тела."

Есть второй вариант: собеседник тебе говорит: "Ахтунг! Замыкание используется не просто для того, чтобы спасти переменную от удаления! Это ещё и способ сокрытия данных: замыканием можно использовать локальную глобальную переменную, вместо того чтобы использовать просто глобальную переменную, или же городить отдельный класс."
В этом случае всё твое определение идёт в пешее эротическое, и ты соглашаешься, что для этого придётся обернуть функцию в функцию, чтобы у тебя была функция с локальными переменными, которые будут глобальными для этой функции в функции.

Вообще такого ресурса нет, но есть несколько полезных ресурсов на которых стоит пастись постоянно. Это:

css-live.ru - сделали два моих знакомых, люди очень увлечённые вёрсткой, там в основном переводы зарубежных статей (статьи подбираются вручную, только самое интересное), но есть и оригинальные статьи

tympanus.net/codrops/category/blueprints - это сборник концептов, далеко не все решения кроссбраузерны, но зато там можно найти неисчерпаемый источник вдохновения не только верстальщикам, но и дизайнерам.

alistapart.com - это наверное старейший ресурс в мире, посвящённый веб-технологиям, ведёт свою историю с 1997 года, из простой рассылки превратился в серьёзный журнал. Даже своя страничка на Википедии имеется.

https://css-tricks.com/ - тоже ресурс, не нуждающийся в особом представлении, сборник туториалов, небольших статей, справочников, тематических блогов, сниппетов, в общем всего.

.footer
  .footer__columns
    .footer__column .footer-info
      .footer-info__logo .logo
      .footer-info__author
    .footer__column .footer-nav
      .footer-nav__heading
      .footer-nav__list
        .footer-nav__link
    .footer__column .footer-nav
      .footer-nav__heading
      .footer-nav__list
        .footer-nav__link

Settings -> Editor -> Appearance -> Show right margin
или
Settings -> Editor -> General -> Appearance -> Show right margin

a проще в настройках вбить Show right margin в фильтр.

Смешались в кучу кони, люди, GSAP, React, Three.js... Стоит немного систематизировать инструменты хотя бы по задачам, которые они решают. Не привязываясь к конкретным фреймворкам из большой троицы, у нас есть несколько классов инструментов в теме креативных сайтов:

• Про готовые CSS-анимации - animate.css, Wow.js, и.т.д. Там много динозавров из времен jQuery. Такие штуки часто бывают не в тему дизайна, но стоит посмотреть и забыть. Хотя для сайтов в духе дизайнерской дичи, вроде той, что успешно делают в студии Артемия Лебедева - может быть и ок.
  
• Про интерполяцию всего и вся. Тут обычно выбирают между GSAP и Anime.js. Первый вариант - более замороченный, есть полезные плагины, второй - попроще, но тоже хорош, в некоторых кругах даже более популярен. Для совсем простых задач - можно свой инструмент написать.
  
• Про скролл, в основном в контексте CSS-анимаций. Тут Locomotive Scroll рулит.
  
• Про переходы между экранами. Грубо говоря прокаченный роутер. Самый популярный - Barba.js. Раньше еще был Highway.js, но в последне время что-то про него мало говорят.
  
• Про экспорт готовых анимаций из софта для анимаций. Тут нужно отталкиваться от софта. Обычно вопрос возникает в контексте AE и простых мультиков - тут Lottie, говорят, неплох. Но нужно дизайнера заранее консультировать по теме, чтобы лишнего не намалевал.
  
• Про визуализацию данных. Тут полезно знать про d3.js, в основном ради готовых примеров.
  
• Про трехмерный WebGL, чтобы не писать все руками. Самый популярный вариант - Three.js, в основном за счет экосистемы и горы готовых решений, но есть и альтернативы на любой кус и цвет. Для 2D -эффектов вообще ничего не нужно в большинстве случаев.
  
• Плюс не стоит забывать про всякие вспомогательные штуки вроде WebFontLoader, Hammer.js, LeaderLine, и.т.д. К анимациям они не относятся, но в работе могут быть полезны, чтобы не писать все самому.
  

Но самое интересное то, что эти инструменты не делают работу сами по себе. Они - лишь вспомогательные штуки, чтобы не писать самому некоторые шаблонные куски проектов. Очень часто можно заменить одно на другое в рамках конкретного класса задач и сложность конечной работы, которую нужно сделать, не изменится никак, потому что реальная сложность заключается в необычной верстке, где нужно сначала понять, что там вообще нужно сделать, а как именно - уже не важно, в хитрых математических расчетах, в адаптивности, где нужно впихнуть невпихуемое, в вопросах доступности в контексте конкретного дизайна, в производительности и способности предотвратить проблемы с ней еще на этапе дизайна, в исправлении проблем кроссбраузерности, которые появляются совершенно внезапно, и.т.д. Эти вещи не особо автоматизируются.

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

Мода есть, несомненно, но не только в ней дело!

стоит вопрос делать его как 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 запрос или вывести кнопку с модальным окном и формой, потому что очень часто тупо юзают бутстрап и собрать подобные блоки просто, или же просто вывести новое поле с текстом или ещё чем-либо.
   
   

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

view - active editor - use soft wraps
это для вебшторма, но думаю в phpstorm тоже самое

Не надо паниковать. В JavaScript все объекты передаются по ссылкам со всеми вытекающими.
Это значит, что после вывод в консоль значение массива изменилось. И когда ты разворачиваешь, чтоб посмотреть что внутри, ты видишь актуальные значения на момент раскрытия.

Просто выполни код в консоли, и раскрой потом.

const arr = [false, false, false];
console.log(arr);
arr[2] = "test";