marsdenden

Посмотри на MaxSite CMS. Получаются очень шустрые сайты, плюс UniCSS намного логичнее bootstrap'а.

Я в таких случаях делаю просто - переменная, куда получаем данные для компонента по умолчанию null и компонент оборачиваю в div c v-if="abc!==null". Все. Как только загрузились данные с сервера - так и отрендерился компонент

Вопрос в принятии правил REST. Я тоже поначалу так думал - что нафиг нужно всякие GET, PATCH, PUT. Зачем, если есть POST и в нем все прекрасно можно передавать в теле запроса и разбирать тоже. Однако, сейчас делаю приложение совсем с нуля и бэк пилю на Yii по всем правилам - GET - получение данных, POST - создание и т. д.
Если разобраться с конкретным фреймворком - создание такого API становится намного проще, когда количество функции этого API переваливает за пару десятков. А для простеньких на пяток-другой можно и правила понарушать.
Но когда приходит время разбираться, почему что-то пошло не так и/или надо что-то добавить/переделать - такой "простой" API превращается в кошмар. Да и документировать его сложнее

Nginx - web сервер. Отсюда вытекает многопоточность, возможность повесить множество сайтов на один ip, ну и прочие плюшки.
Нода однопоточна, всякие прибамбасы вроде вебворкеров - костыли, нормальный продакшн под высокую нагрузку сделать можно, но сложно (имхо).
Пробуйте, тестируйте, нагружайте, почувствуйте разницу

Статический IP адрес, который виден из интернета, а дальше - покупка доменного имени и настройка DNS у того же продавца доменного имени.
Как правило не имеет особого смысла для того, чтобы просто "друг из соседнего дома заходил на сайт" из-за определенных финансовых затрат на
1. статику
2. стоимость доменного имени

Залогинится суперпуперадмином, у которого будет секретная кнопочка, которая в localStorage запишет непонятную абракадабру. Далее логиниться суперпуперзаказчиком вместе с абракадаброй - если абракадабра пришла на сервер вместе с логин-паролем - ОК, иначе - "ой, что-то пошло не так".
Реализовать просто - в форме сделать hidden input, куда при загрузке формы авторизации скриптом записывать localStorage.getItem('supersecretabrakadabra') - если ее на данном компе в хранилище нет, то она и не дойдет до сервера.
Единственный минус такого решения - необходимость логиниться админом. Но идея может развиваться и дальше - к примеру, на сервере в БД юзеров добавить поле "привязан", если поле чистое, то при первом логине заказчика так же прописывается абракадабра в localStorage и передается на сервер, сервер в записывает ее в поле "привязан" и все следующие попытки залогиниться обламывает, если абракадабра не совпадает. Ну а о том, что абракадабра должна генериться каждый раз уникально, говорить, думаю, не стоит.
Дальше - больше. Заказчику можно предоставить две кнопки - "привязать" и "отвязать", первая будет просить сервер привязать к новой абракадабре, вторая - очистить поле "привязан", соответственно разрешить логин с другого устройства. Само собой, кнопка "отвязать" должна присутствовать только в случае уже существующей привязки. Тогда админа сервера для ручной очистки поля "привязан" придется дергать только в случае исключительных ситуаций, к примеру смерти винта на привязанной машине

Рискну предположить, что куки, которые выставляет auth.php при ajax запросе браузером не воспринимаются и в локальное хранилище не записываются. Поэтому запрос авторизации в варианте с куками делается по старинке - через form-submit, когда в ответ прилетает не результат ajax, а полноценный html, вместе с которым приходит и нужная кука.
Ищите способ сохранить куку в браузере по результату выполнения скрипта. В консоли разработчика можно ее увидеть на вкладке Network при просмотре ajax запроса. Для начала неплохо бы почитать здесь, потом начинать изучать какой-нибудь JS-фреймворк, мне понравился vue.js, достаточно низкий порог входа, весьма логичен. Со временем понимаешь, что на jquery далеко не уедешь, так что переход к фреймворку - вопрос времени

А чем собирается проект? У меня webpack прогоняет через babel и все работает в IE
Кусок конфигурации webpack.config.js

module: {
		rules: [

			{
				test: /\.js$/,
				loader: 'babel-loader',
				exclude: /node_modules/
			},

Vue.JS + Vue.Router - легко и просто.

Жалею, что не разобравшись, поставил в продакшн сервер с systemd. За три месяца огреб столько проблем, сколько их не было за три года на sysVinit. Да и для десктопа преимущества сомнительные. Особенно, когда начинает сыпаться корневая ФС, а он fschk на ней сделать не в состоянии...

А из IDE не программируется? Если да, то подсмотреть, что IDE прописывает для дудки

Несколько лет назад пробовал юзать mysql на win server 2003. Не понравилось. И дело было не столько в скорости, сколько в стабильности. База была в локалке и открыта наружу. Клиенты - 1с с самописной компонентой для прямого доступа. Так проблем я огрёб столько, что зарёкся больше никогда так не делать. Клиенты постоянно теряли связь, что приводило к необходимости для каждого (!) запроса делать коннект к базе. Запросы могли просто уйти в никуда, что критично на insert/update. При этом могло даже не быть сообщений об ошибках. С базой на линуксе такого нет, запустил 1с, она один раз приконнектилась и весь день этим коннектом пользуется. Ну и скорость тоже не устраивала. На тот момент сервер виндовый был на core2duo i3, а линуксовый поставили на обычном пентиуме (не помню модельку точно, но современник i3). Нагрузка у обоих была не сильно большая, но скорость и стабильность линукса порадовали.

Используйте heredoc <<<
https://ru.wikipedia.org/wiki/Heredoc-%D1%81%D0%B8...

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

Все просто. На любом языке формируете http запрос с указанием, что передаете json (Content-type: application/json) и в теле запроса передаете сам json, а у ж там что хотите - хоть массив, хоть объект. Для экспериментов можно использовать Postman, чтобы формировать запросы и Telerik Fiddler для изучения анатомии запросов и ответов.

Начать надо с vue.js как такового. Свойства, вычисляемые свойства, компоненты, vuex, написание плагинов и т. д.
Потом уже вкуривать в nativescript. Причем не получится взять код vue для webapp и просто сбацать нативное приложение, поскольку nativescript-vue совсем не то же самое, что vue.js. Это просто братья, но не близнецы. Хотя бы потому что в nativescript шаблоны vue строятся совсем по иному принципу - это, скорее, оболочка на Android SDK, главный плюс которой - некое приведение к общему стандарту для Android и iOS. Но по граблям потанцевать придется, поскольку нет полной документации и нет исчерпывающих туториалов, приходится рыться на гитхабе.
Но Playground - просто отличная вещь для попробовать