Михаил Р.

2)не меньше постов о том, что это на самом деле это крайне скучная и однообразная работа. У меня вроде как более менее реальные представления, что это больше программирование (знаю, что большинство не относит front end к программированию,но не знаю как по другому сформулировать), нежели полет фантазии, но насколько это увлекательно или скучно именно для вас?

Мне не скучно, вот уже 8 лет. Но мне интересен сам процесс разработки кода, не важно на чем и не важно что, буду писать, дайте только компьютер. Но знаю много людей, которым это скучно, или загораются они реально от чего-то нового и интересного, а не от обычной разработки, а новое бывает очень редко, поэтому такие часто перегорают или со временем теряют интерес. Если вы для себя сейчас не поняли, что вам интересно писать код, читать материалы по программированию, то вам будет сложно нормально влиться. Совет для любой профессии: вваливайтесь только в том случае, если вам интересна эта область.

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

Каждый человек индивидуален, кто-то учит целый день то, что другой за час поймет.

стоит ему на месяц заболеть или иным образом отстраниться от этой сферы, резко вылетит в трубу, так как за этот месяц появиться куча нового и он уже будет никому не нужным, так ли это или все немного утрировано?

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

не жалеете, что занимаетесь front end и почему?

Как начну жалеть, пойду в другую область. Раздражает только отношение других программистов к front-end'у, многим кажется, что тут одни "макаки", хотя сами они об этой области не имеют никакого представления. Но такие вещи происходят и в других языках или профессиях, поэтому не нужно обращать на это внимание.

$a = 10;
$a = $a - 1; // 9
$a = $a + $a; // 18
echo $a;

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

Разумеется, только в БД.

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

Или, если сформулировать короче, то данные должны лежать в базе, а в РНР файлах - только код.

interfaces.pro - живые
froala.com/design-blocks - шаблоны

убрать enter между code и var тыц

Я давно знал что dreamveaver лучше вообще обходить стороной. Но так и не успел перейти на phpstorm.

Если Вы юзаете dreamveaver, то вероятно Вам нужен не phpStorm, а webStorm.

Или может проблема в коде?

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

Ох! Чтобы изучить laravel вам нужно изучить php (сюда же базы можно приплести) и, как я понял из контекста вопроса, js. Отвязывайтесь от изучения фрэймворков, а то к финалу изучения laravel+vuejs выяснится что они уже депрекейтед и будете опять наблюдать картину типа "Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery"

1 – удобно
2 – наверное придется, но если вы хорошо знаете js то процесс миграции во vuejs будет безболезненным
3 – ни плохим и не хорошим. Вы должны прочувствовать все фичи которые дает laravel из коробки, а их набор настолько не большой (в базе), что будет достаточно сделать каки-то наброски абстрактного приложения

1) хз
2) А тут по подробнее:
- vue - это маст хев на ближайшие годы не зависимо от laravel.
- vue не исключает использования jquery, хотя я уверен, что любой плагин можно найти и на чистом js.
- судя по тому, что Вы пишите, Вы явно не видели варианты со сборкой vue из компонентов. Там в html лишнее не попадает, не больше, чем с jquery
3) Если от легкого к сложному, то явно не интернет магазин. Вначале блог или новостной сайт, потом каталог "чевачупчичей", а потом уже сами поймете куда двигаться.

ПС. Я не верен. Что изучение laravel и vue стоит совмещать. Наверное кашка может получиться. Лучше вначале освоить vue + сборщики, хотя бы азы, до состояния "дочитал до конца документацию, но хрен что запомнил", а потом вникать уже в laravel.

1) На сколько удобны Homstead + Vagrant, которые они рекомендуют использовать? Посмотрел информацию по его установке, использовании. Разве это удобнее всем привычного openServer?

Насколько удобен конкретно именно этот стек, и насколько он удобен будет лично для Вас - сказать затрудняюсь, но в общей сложности, использование "родной" среды при разработке приложения - практика весьма правильная. Думаю что в данный момент, большинство моих эпитетов на тему "почему оно так и зачем" Вам будут не очень интересны, но, есть простой пример из реальной жизни: в *nix, чаще всего, файловые системы чувствительны к регистру имён файлов, в Windows [NTFS] (и OpenServer в частности) - такой чувствительности нет, что влечёт за собой потенциальные ошибки в самый неподходящий момент (когда Вы будете выгружать сайт на хостинг) и исправить их "по быстрому" удаётся не всегда, по этому, я бы рекомендовал использовать "родной" Linux при разработке. Какой стек взять - сакрального значения не имеет, мы используем: Docker (Hyper-V), VirtualBox + настроенную самостоятельно вирт. машину и различные другие варианты (среди которых, OpenServer проскакивает крайне редко).

2) Прямо из коробки Laravel поддерживает Vuejs, но посмотрев их курсы на Laracasts и ещё пару примеров компонентов для него, мне показалось, что он не совсем подходит для того, чтобы делать на нём те же слайдеры, системы частиц и подобные вещи.

VueJS - это JS фреймворк, волей судьбы "встроенный" в Laravel. Как мы знаем, JS относится к области вёрстки, что в целом с фреймворком серверным связано крайне слабо. Какие элементы в вёрстке использовать лично Вам - дело - лично Ваше. Из собственного опыта могу сказать, что мы в своей работе не гнушаемся ни VueJS, ни jQuery, ни различными готовыми слайдерами и вообщем всем, что может быть уместно в рамках конкретных требований конкретного проекта. По сему - я думаю Вам не стоит забивать себе этим голову. Насколько и чем хорош VueJS - можно узнать из массы уроков по оному.

Вообще не понравилось, что в HTML-разметке вставляются ивент-слушатели, как в стандартном JS прям (@click, onclick). Мне это напомнило встраивание CSS прямо в тэги. Мне нравится в jQuery то, что все ивенты вешаются прямиком в скрипте, не заглядывая в HTML-разметку.

На вкус и цвет все фломастеры разные. Какой подход "лучше" - покажет только время. В данный момент, мы используем оба из них и особо не паримся по этому поводу.

Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery, только Vuejs. Отсюда и вопрос, то есть мне нужно переписать свои слайдеры, системы частиц под Vuejs? Часто встречал сообщения о том, что переплетать эти две технологии плохая затея. Либо то, либо то. Посмотрел предложенные готовые слайдеры, вообще не впечатляют.

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

3) Хорошим ли является планом, чтобы сделать воображаемый интернет-магазин для обучения и освоения Laravel? Или как лучше изучать эту технологию от легкого к сложному? Всегда была проблема с тем, чтобы структурировано изучать ту или иную область разработки. Чтобы не тупо копировать, а понимать, как всё устроено и как работает.

Что бы понимать что-то структурно - нужно понимать истоки. В области веб-разработки таковыми "истоками" могут являться например, протокол HTTP, фундаментом которого будет протокол TCP/IP, в основе которого лежат другие технологи... чем лучше Вы будете понимать как всё работает изначально, и в результате чего появилась, например, такая парадигма как MVC, как работает composer так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.

Процитирую сам себя:

У enterprise-приложений есть три основных качества:

1. Большая и сложная кодовая база;
   
2. Высокие требования по надёжности и производительности;
   
3. Длительный срок эксплуатации.
   

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

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

Без SVG, картинок и псевдоэлементов,
CSS only

то, что вы ищите - usleep

В остальном ваш код доводит до слез этого кота

words.replace(index, 1, word.charAt(0));

Метода replace у массивов нет. Есть splice.

как реализовали бы данную задачу вы?

// собираем новый массив
const newWords = words.map(n => n[0] || '');

// обновляем существующий
words.forEach(([ n = '' ], i, a) => a[i] = n);