Александр Ме

Set удобен, например, когда нужно оставить из набора данных только уникальные.
Map хорош тем, что ключами в нём могут быть и объекты. Например, HTML-элементы, для которых захочется хранить какие-то данные. И Map запоминает порядок добавления элементов, что может быть полезно при переборе.

1. у видео кодеков ещё масса параметров, влияющих на качество и объем файла. Но самый поверхностный – битрейт. Увеличился битрейт – файл стал тяжелее.

2. качество при каждом перекодировании — падает. Поэтому лучше избегать перекодирования там, где оно необязательно. Например, когда только лишь вырезаете часть по времени, перекодировать не нужно, т.к. картинка остаётся та же самая. Поэтому п.3:

3. просто обрезать видео лучше без перекодирования. Это можно сделать прямо из командной строки могучим инструментом ffmpeg. Примерная команда:

ffmpeg \
  -ss 15 \         # пропустить 15 секунд от начала
  -i Source.mp4 \  # имя исходного файла
  -t 30 \          # продолжительность 30 сек.
  -c copy \        # кодек "копия" - не перекодировать
  Result.mp4       # что получится - в этот файл

только удалите все комментарии – после слешей должен сразу быть перенос строки. Этот вариант, пожалуй, самый быстрый из возможных.

Вопрос если разница в таких записях?

Только в передаваемом значении:

• resolve(script) передаст дальше по цепочке этот script (который никому не нужен, похоже).
  
• script.onload = resolve передаст по цепочке объект события (тоже всем по барабану)
  

почему такой ее вызов дает ошибку script.onload = resolve(script);

потому, что нужна функция, которую вызовут позже, а не мгновенный результат её выполнения.

jQuery с AJAX - прекрасный индикатор того, насколько устарела статья ;)
Пока не сдох Ослик и встречались всякие маргинальные мобильные браузеры, обработку запросов к серверу приходилось подпирать костылями на всякий нестандартный случай, и jQuery с этим уверенно справлялся. Сейчас стандарт устоялся, повсеместно соблюдается и актуальность этой подпорки околонулевая.

Потому, что в setInterval() первым аргументом надо передать функцию (он сам вызовет её потом),
а «без setInterval» — для получения результата надо эту же функцию ещё и вызвать самим.

безопасно.
люди, использующие фреймворки тупо для синтаксиса, а не используя их средства (query builder или модели? не, не слышал) – вообще бессмертные.
правда, недолго.

async function load_page(num) {
  const response = await fetch(...);
  // редактирование html
}
async function go_to_post(post_id) {
  //код
  await load_page(page);
  //код
}

inputElement.addEventListener("input", function() {

Замени это на
inputElement.addEventListener("input", () => {
Должно попустить

Насчёт конкретно подхода о котором вы говорите не скажу, скорее всего это плохая идея. Видел пару примеров несколько лет назад, бОльшая часть этих модульных подходов было нечто среднее между недомикросервисного подохода, с примесью разработки composer пакетов и элементами (концептуальными) плагинов wordpress.
Или другой подход где "модули" laravel разделялись пространством имен и особой структурой, с некоторыми костылями для поддержки разделения кода. Этот подход формально лучше, но по факту обычное не нужное усложнение проекта. Но если вам интересно, можете изучить https://github.com/nWidart/laravel-modules
Но как по мне, если уж и заморачиваться в подобном плане, то скорее наоборот отвязкой максимальной ядра приложения от любого фреймворка framework-agnostic подход.
А так... Главный принцип, в целом кстати во многом пересекается с принципами микро сервисной архитектуры:
есть определенная часть/логика приложения, которая может выполнять свою функцию независимо, которую могут писать разработчики независимо, можно выделить в отдельный пакет. Например, вы придумали свой крутой прокси изображений, и он как-то явно выходит за рамки вашей бизнес-логики приложения, более того возможно он пригодится в ваших других приложениях (или вы хотите поделиться с миром) делайте отдельный пакет.
Ну и конечно у таких пакетов, могут быть зависимости в виде других пакетов.
А вот прям делать декомпозицию приложения на пакеты, ради декомпозиции не стоит. Только если есть конкретный смысл что-то выделить.
Примеры вот хорошие у Spatie https://spatie.be/open-source?search=&sort=-downloads .
Там же можно посмотреть, как пакеты зависят друг от друга, например image от image-optimizer.
Все их, достаточно популярные, пакеты вышли из практики разработки приложений для клиентов.
Ближе к вашему примеру это проект Nova https://nova.laravel.com/ и тоже имеет кучу пакетов https://novapackages.com/ .
Но здесь тоже нужно учитывать, цели самой Nova и почему такая организация. Сама Nova это как бы расширяемый прототип панели управления для CRUD приложений, она универсальная by design, поэтому и нужны доп пакеты, которые закрывают конкретные цели.
Если у вас целевое приложение, то незачем его корневую бизнес логику куда-то выводить.

Смотря для кого. Rust создавался как альтернатива C++ при разработке критичных к безопасности частей кода браузера Mozilla. По бенчмаркам он реально конкурирует с C++ но главное преимущество наверное в том что из него принципиально убрали возможность совершать тупые ошибки такие как использование null-pointers. Тоесть он - безопаснее чем С++. Но мне кажется что решение за использованием Rust - корпоративное а не частное.

Надо просто мониторить появление соотв. вакансий.

Ну а если вы - кодер бизнес-логики на Java/C# то вам Rust скорее всего не нужен.