y0u

1) Просто вызов: оба хендлера последовательно запускаются в одном и том же синхронном коде (в текущем таске), ставят в очередь 2 микротаска.

2) Через клик: на каждый хендлер создается отдельный таск в event-loop, таски отрабатывают по очереди, каждый из тасков создает по одному микротаску, последний выполняется до перехода управления к след. таску.

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

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

const value = {
  val: 1,
  valueOf() {
    return this.val = !this.val;
  },
};

Поэтому был бы благодарен, если бы вы поделились своими твиками для Windows, объясняя почему и зачем.

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

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

Потому что так написано в спецификации.

Базу данных можно выбрать любую. Она не играет роли в realtime приложениях. Позвольте вам немного объяснить. Для передачи данных между клиентом и сервером в браузере существует всего два протокола. HTTP и Websocket. Firebase не магия и также использует их. Если браузером не поддерживается Websocket, то firebase откатывается на HTTP. Используя общераспространенный подход к разработке на PHP у вас не получится использовать websocket протокол поскольку типичные PHP приложения не живут дольше 1 запроса. Соответственно да, в таком варианте остается только ajax. Но точно также работает и firebase если в браузере нет поддержки websocket, так работает facebook, telegram и много всего остального. Они используют long-polling. Клиент отправляет запрос к скрипту на сервер, скрипт в цикле опрашивает хранилище mysql или более продвинутый вариант mysql+redis (чтобы не грузить запросами mysql) и пока данных не будет, цикл так и продолжит крутиться, для клиента это просто выглядит как повисший запрос к серверу. Как только данные появляются, они отправляются на клиент, соединение разрывается, а клиент сразу же отправляет новый запрос.

Есть развитие этой идеи. Называется HTTP Streaming. Отличие от long-polling в том, что после отправки данных клиенту соединение не разрывается, а сервер продолжает отправлять последующие данные по этому же соединению. Соединение разрывается по таймауту. Минус в том, что прокси-сервера могут кешировать небольшие пакеты данных и данные нужно раздувать например пробелами, чтобы пакет данных достигал минимального размера и был способен пробить кеш прокси-сервера. Плюс в том, что если у вас данные для клиента появляются скажем с переодичностью раз в секунду, то не будет происходить постоянного открытия-закрытия соединения как при long-polling.

Есть вариант, когда можно реализовать небольшую прослойку на socket.io. Ваше PHP приложение пишет данные для клиента например в redis. Приложение на socket.io подписывается на redis. Когда PHP что-то отправляет в redis, то socket.io мгновенно об этом узнает и рассылает это событие по websocket протоколу всем подключенным клиентам. Минусы. Раздуваете стек. Нет консистентности данных между записью в основное хранилище (mysql/postgre/mongo/etc) и redis. Соответственно может возникнуть ситуация, когда данные записали, но в redis событие не ушло. Поменяете местами, будет наоборот, событие есть, данных в базе нет.

Вариантов в целом очень много. Всё это называется Comet. Вам проще всего реализовать long-polling.

А реал-тайм база, которая умела пушить данные клиенту по tcp протоколу (но не в браузер) была и называлась она rethinkdb.com. Ныне не развивается. IP в России заблокирован. На сайт можно сходить по VPN.

ну так и пишите на жс, если нет принципиальных ограничений по используемым языкам.
electron в помощь.

решение так себе, но для курсовой вполне сойдёт. особенно за семь дней.

if (code == pass) {
    if(localStorage.getItem('pw')) {
        ...
    } else {
        localStorage.setItem('pw', code)    
        ...
    }
} else {...}

И вешаете обработчик на что хотите, а вообще, это бред какой-то, про jwt прочитать можно, или хотя бы про сессии и хеширование, и не хранить в локалсторе открытые пароли

В:

В чём разница между веб сайтом и веб приложением?

О:

The main difference between a website and a web application is USER INTERACTION. Website is defined by its content. Web App is defined by its user interaction. For example you can consider a news site as a website.

(Надеюсь с англ. нет проблем, иначе гугл/яндекс/иной транслейт)

В:

Почему большинство переходит на веб приложения?

О: Вы уверены, что правильно понимаете понятие "веб приложения"? Ибо если сайт написан с использованием "нечисти" (т.е. впихнут реакт/ангуляр//вью/свелт/и.т.д), это еще не делает его приложением (см.выше)

В:

Какие плюсы/минусы у каждой из технологий

О: Все технологии придуманы для облегчения жизнедеятельности людей. От этого и логика, фреймворк нужен не для того чтобы создать конкретно веб приложение вместо сайта, а чтобы упростить его разработку. Ничего более. Нравится все писать голыми руками и клепать 100500 шаблонных html файлов вместо 1 реюзабельного компонента? Пожалуйста, никто вас не останавливает (если это не оговорено в условиях договора/прочего документа). Плюсы у всех технологий (по крайней мере, задумывалось их создателями), облегчение труда/ускорение работы/уменьшение затрат(разных). Минусы: недоработанность/лишний код(который создается этими фреймворками)/много прочего

В:

неужто статическому интернету капут

О: Скорее нет, чем да. Ибо статика обрела новую жизнь, под названием JAMStack

По своему опыту могу сказать, что при переходе на удалённую работу(10 лет) из офиса(7 лет) мое развитие и производительность увеличились в разы.
1) В офисе ты можешь ничего не делать, а просто показывать лицо и с умным видом рассуждать о полиморфизме. На удалёнке тебя никто не видит, а видят только твои результаты- это обязывает шевелиться быстрее и только по делу.
2) В офисе ты слишком призязан к месту и организации, зачастую тебя берут на какой нибудь вырост, а в последствии могут дать поддерживать старую программку на фортране или на бейсике, или сунут печатать документы и рисовать рисунки и т.п. и ничего не скажешь. На удалёнке тебе легко поменять проект, если закончились твои задачи, ты смотришь на работу не как на что-то вечное и стабильное, а как на проект, на который тебя взяли из-за определенных скиллов, под конкретные задачи и от тебя ждут конкретные результаты.
3) В офисе тебя отвлекают разговорами, совещаниями, теннисом и т.п., купят тот стул и комп, который купят, а не который ты хочешь, на удаленке у тебя отдельная комната - как минимум, кресло и мощный игровой ноут (легко поднимающий виртуальные машины или докер-контейнеры), которые ты сам себе выбрал.
4) Да, экономия на времени, дороге, спорте, месте жительства само собой.
5) В офисе обучение предлагается/навязывается, но так как вроде положение там стабильное то и оно не так и хочется прям учится, на удалёнке ты понимаешь что это твое конкурентное преимущество и без обучения никак, ты ищешь, анализируешь, что в тренде и больше востребовано, и подгоняешь свои скилы под общие требования рынка, а не конкретной организации.
6) в офисе не особо поднимают тебе зарплаты типа никуда не денешься, а попросить неудобно, на удалёнке ты с каждым новым проектом пересматриваешь свою цену и приобретенный опыт. (ну хотя здесь немного вру, в офисе повышали нормально, после удачных релизов )

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

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