Nikita

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

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

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

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

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

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

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

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

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

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

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

облако - это гибкое управление инфраструктурой.
автоматическое создание нужных инстансов когда они нужны (и удаление их когда они не нужны) с автоматическими балансерами; изменение параметров сервера налету; беспроблемная миграция между разными локациями; всякие сервер-лесс'ы/и т.п./т.д.
трендово: потому что люди лепят этот термин зачастую даже не понимая что он значит.
по факту: хомякам вообще без разницы.

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

composer.json:

"autoload": {
        "psr-4": {
            "App\\": "app/",
            "Modules\\": "Modules/"
        },
    },

document - текущий документ
getElementById() - метод получения элемента используя id
onchange  - свойство элемента для обработчика события
function (event){} - анонимная функция (обработчик события)

event - локальная переменная в контексте анонимной функции
target - таргет он и в африке таргет (целевой элемент, где происходит туса)
parentNode - родительская нода
childNodes[1] - у родителя есть дети
data - у детей есть данные
slice(1) - отхренашить кусочек
 
currentKey - отхренашеный кусочек

С чем может быть связана проблема?

С неустранимой неисправностью видео-карты.

Никакие.
Порядок самообучения для любого языка:
1. Учим базу по официальной документации.
2. Практикуемся (LOOP: 5-10)
3. Учим следующий более сложный раздел
4. Смотрим исходный код лидирующих и актуальных проектов для понимания правильной организации кода (код микрофреймворка для разработки или код простого приложения).
5. Пробуем сделать похожую структуру кода сами.
6. GOTO 2

Классовые компоненты никуда не уходят. Для них осталось несколько удобных кейсов. Например:
1. Удобное получение предыдущих значений свойств и состояний в componentDidUpdate.
2. Доступ к экземпляру компонента в хандлерах, передаваемых в браузерные API.
3. Сложные компоненты с большим количеством методов. Например VideoPlayer.

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

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

Попробуйте использовать в коде преимущественно функциональные компоненты и хуки. Сейчас почти все популярные библиотеки имеют в API довольно удобные в использовании хуки. Там, где покажется, что будет удобней использовать класс, не бойтесь использовать классы.

1. Динамические импорты.
2. Это разные вещи, изучай.

Документацию, поди, не открывал вообще?

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

Вариант 1
Не надо делать ооп ради ооп, просто в класс Message добавь метод getUrl()

Вариант 2
Message это какой-то сторонний класс, и нет возможности его изменить, по этому делаем над ним декоратор.

class MessageDecorator
{
    private $message;

    public function __construct(Message $message)
    {
        $this->message = $message;
    }

    public function getTitle()
    {
        return $this->message->getTitle();
    }
    
    public function getText()
    {
        return $this->message->getText();
    }

    public function getUrl()
    {
        // create url
        return 'url';
    }
}

$message = new MessageDecorator(new Message($title, $text));
$url = $message->getUrl();

Вариант 3
Выносим генерацию url в отдельный сервис

class UrlService
{
    public function getMessageUrl(Message $message)
    {
        // create url
        return 'url';
    }
}

$message = new Message($title, $text);
$urlService = new UrlService();
$url = $urlService->getMessageUrl($message);

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

В конструктор в данном случае передаются на данные, а объект, который будет строить запросы. Это же класс репозитория - он инкапсулирует запросы к БД, но пользуется при этом моделями Eloquent.

class PortfoliosRepository extends Repository {
  public function __construct(Portfolio $portfolio) {
    $this->model = $portfolio;
  }

  // Этот метод, скорее всего, есть в базовом классе
  public function find(int $id): ?Portfolio
  {
    return $this->model->find($id);
  }

  // А это пример инкапсуляции сложной логики
  public function featured(): Collection
  {
    return $this->model
      ->with(['some', 'relations'])
      ->where('field', 'value')
      ->orWhere('other_field', 'value')
      ->orderBy('created_at')
      ->limit(42)
      ->get()
      ->each
      ->append('mutated_attribute');
  }
}

Используется этот класс так:

$repository = new PortfoliosRepository(
  new Portfolio // <- не какое-то существующее портфолио из БД, а "пустой" объект
);

$repository->featured();