Александр Ме

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 скорее всего не нужен.

Устанавливаешь Vite получаешь готорый Hello World с SFC + script setup
https://qna.habr.com/answer?answer_id=2119668#answ...

Несколько онлайн примеров из моих предыдущих ответов:
https://qna.habr.com/answer?answer_id=2120126#answ...
https://qna.habr.com/answer?answer_id=2109080#answ...
https://qna.habr.com/answer?answer_id=2097528#answ...

Здесь jQuery не нужен, делай так:
new URL(location).searchParams.get('q');

Привет, Матвей! Очередной раз отвечаю на свой же вопрос сам. Такая жизнь, такая жизнь.

Ладно, в общем суть тут следующая: В компоненте можно выкинуть вообще vue-socket.io, как и vue3-socket.io.
Соединение можно открыть локально при помощи "чистой" либы. Иногда сверкает ее упоминание в документации vue-socket.io, но почему-то она не устанавливается самостоятельно с vue-socket.io.
Поэтому проверните на всякий:
npm install socket.io-client
Теперь отдельно импортируем уже в КОМПОНЕНТЕ
import SocketIO from 'socket.io-client'
Ну и теперь для соединения танцуем так:

this.sessionSocket = SocketIO('',{
          path: '/bot/socket.io/'
        })

Я использую пустой адрес и изменяю patch, т.к. проксирую это все дело через vite с целью избежать проблемы с CORS при тестировании.

Ну и как это дело использовать:
Отправить сообщение:
this.sessionSocket.io.emit('test')
А подписаться на событие:

this.sessionSocket.on('test',()=>{
          console.log('Hello World)
        })

Полная документация по этим танцам: https://socket.io/docs/v4/client-api/

функция возвращает массив игроков. этот массив записывается в переменную cats и потом выводится в консоль

вообще плохой тон использовать одну и ту же переменную для разных целей. Лучше было бы написать

let players = runGames(gameRuleset, cats);
console.log(players);

Не нужен там неймспейс

use App\Http\Controllers\Admin\Post\IndexController;

Route::prefix('admin')->group(function() {
   Route::get('/post', IndexController::class)->name('admin.post.index');
});