Oleg

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

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

Это, я не знаю, как спросить "хочу быть столяром, какую отвёртку мне изучать, крестовую или шлицевую?".

Изучать, ради карьеры, надо столярное ремесло целиком. В данном случае - программирование. Принципы, на которых устроены фреймворки. Одного этого хватит на те же лет 5. Зато потом не будет проблемы адаптироваться к неизбежным изменениям.

А если считать пределом мечтаний клепание говносайтов на некоем идеальном фреймворке на все времена, то может так случиться, что через 5 лет к условным "ларавельщикам" будут относиться так же, как сейчас к вордпрессникам.

И кстати для изучения принципов симфони подходит лучше

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

Да, и самое главное я тоже забыл сказать. Коллега xfg в самую точку написал в комментарии:

Фреймоворк - это на самом деле тонюсенькая прослойка над приложением. Это, по сути, система подай-принеси, принять запрос с фронта и отправить ответ. А что именно будет в ответе - решает не фреймворк, он здесь уже не при делах.

Очень на эту тему прочищают мозги доклады и видео Дмитрия Елисеева. У него на сайте как раз появился доклад с PHP Russia 2019, который я горячо рекомендую.

На ту же тему был и доклад Томаша Вотрубы, кстати. Что фреймворки, по сути, можно менять как перчатки, при желании. И у него есть даже инструмент для этого. Но в данном случае речь не об инструменте а о том, что фреймворк- далеко не главная часть приложения, и упираться в изучение фреймворков это все равно что в изучение отверток.

1) на запущенный процесс РНР
2) Память выделается блоками (с запасом), так как РНР не строготипизированный язык, и данная переменная может (неожиданно) стать булиневой или вобще массивом
3) С большей вероятностью увеличение (которое вы наблюдаете) это не резервирование блока памяти для данных, а занимаемая память для ссылки на блок памяти (в которой и хранятся данные), и возможно под сами данные память используется из уже зарезервированной области

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

Уберите в линках к статике http оставьте

//foo.bar/main.css
//foo.bar/static/main.png

Я стараю придерживаться простого совета: один метод - одно действие. Т.е. каждый метод класса должен выполнять строго одну функцию. Число строк одного метода - не более 20.

Онлайн лучше.
1. Объяснить сложный принцип действия, когда видео действительно подспорье. Например, рассказать в динамике о том, как работает сложный шифропротокол.
2. Рассказать о простых стандартных задачах. Впрочем, и в этом я не уверен.
3. Ткнуть носом в нужное место интерфейса.

Печатный материал лучше.
1. Когда нужно посидеть и осознать. Первые шаги в вашем первом языке программирования, когда даже синтаксис стена. Практически всё, что относится к алгоритмам.
2. Работа с низкоуровневыми библиотеками наподобие OpenGL или SDL, которые производят кучу кода.
3. Небольшой справочник.

Рекурсия - это отличное решение для отдельных задач. Такое же, как использование case вместо if, или использование sql вместо массивов данных.

Просто используйте их там, где рекурсия работает лучше других решений и все. Есть множество задач, где рекурсия будет best practice.

Чтоже касается того, что "в каких-то языках это плохо работает", так пока не попробуете - не узнаете.

Добавили, чтобы вы jquery спагетти не использовали. Vue (как и другие js фреймворки) сокращает количество кода на клиенте и уменьшает его запутанность.

Для примера вы создаете админку для магазина. У вас есть следующие варианты:
1. Делать статическую страницу. На клиенте никакой логики, все вычисляет сервер. При новой покупке администратор должен будет обновить страницу.
2. Писать динамический фронтэнд с использованием vue, angular и чего угодно остального. Бэкэнд шлет вам уведомления через вэбсокеты о новых заказах без перезагрузки страницы.
2.1 Вы берете jquery и сначала все идет хорошо. Первые полчаса. Затем ваш код обрастает огромным количеством обработчиков событий. Если товар заканчивается на складе, его надо убрать из таблицы, затем если заказ отменяется, его надо вернуть в таблицу. Вы его вернули, но почему-то кнопка в строке с ним, вызывающая модальное окно перестала реагировать на события, потом еще что-то случилось и еще. Проблемы с jquery растут как снежный ком и вы проклинаете свое решение создать динамическую админку.
2.2 Вы используете современный js фреймворк. Vue в этом плане хорош низким порогом изучения. Вы загружаете определенные обхекты и в зависимости от их свойств vue сам строит таблицы (с проданными и непроданными товарами), скрывает лишние элементы (не показывать такую-то кнопку, если товар всего 1), отправляет плагинам команды на обновление при изменении объектов и следит за тем, чтобы события, которые отваливались при jquery подходе работали.

Я не сказать что спец в javascript, но (именно поэтому) меня vuejs на текущем проекте очень выручает.

Ну станьте этим самым компетентным разработчиком в своей команде.
Если уйти нет возможности, тяните команду, чтобы самому не "утонуть".

// отключаем индексы
ALTER TABLE db.my_table DISABLE KEYS;
// Затем загружаем огромный файл
LOAD DATA INFILE 'price.csv' INTO TABLE db.my_table;
// включаем индексы
ALTER TABLE db.my_table ENABLE KEYS;

придумайте себе число в голове , подумайте выполните ли вы эту работу за это число , если нет увеличивайте пока не передумаете

summaUSD = X
happy = true

if  summaUSD >= happy
profit

Магическая формула поможет всегда :)