VRack2 — Кот аристократ в мире локальной автоматизации

Если вы считаете не безопасным то- что одновременно может произойти 2 запроса - то вы можете просто проверить "очередь".

Не то чтобы я как-то особым образом считал :), - сделал вывод из Ваших описаний,
про очередь видимо упустил. Тем не менее, если есть такая потребность - лучше локализовать ближе к сокету, - во избежание.

Тогда уж если занудничать вам нужно использовать once для подписки на "data", в противном случае у вас будет утечка памяти.

тут признаю - лоханулся, время позднее было, на коленко в слепую накидал

С таймаутами вы тоже перемудрили. Вы вроде как локализуете запрос но при этом используете внутренний таймаут сокета который кстати сделан немного для других вещей. Тут лучше использовать обычный setTimeout.

Не, не согласен, норм - рабочая тема :).
Для каких других вещей сделан таймаут?
В чём преимущество "обычного"?

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

VRack2 — Кот аристократ в мире локальной автоматизации

С асинхронкой всё понятно, немножко напряг сам код, он выглядит не безопасно, что если кто-то вызовет его не через await, а например использует then, тогда можно схватить неожиданное поведение, для запросов к синхронным девайсам предложил бы использовать что-то вроде (извиняюсь за занудство)

/**
 * 
 * @param {Socket} socket 
 * @param {*} request 
 * @param {number} timeout 
 * @returns 
 */
async function rpc(socket, request, timeout = 1000) {
    return new Promise((resolve, reject) => {
        if (!socket.writable) {
            reject(new Error('the socket is not writable'))
            return
        }
        if (socket.timeout) {
            reject(new Error('the socket is busy'))
            return
        }
        socket.setTimeout(timeout, () => {
            socket.setTimeout(0)
            reject(new Error('timeout'))
        })
        socket.on('data', (data) => {
            socket.setTimeout(0)
            resolve(data)
        })
        socket.write(request.data, request.encoding || 'binary', (error) => {
            if (error) {
                reject(error)
                return
            }
            console.log('data sent')
        })
    })
}

VRack2 — Кот аристократ в мире локальной автоматизации

Очень круто, всегда знал что JS для таких вещей наиболее подходящий инструмент.
Решение впечатляет

По статье - немного не понял пример с сокетом, вроде стандартный сокет взывает коллбэк и на этом все приседания заканчиваются

Вопросы к UI. Шаблон компонента. Основная часть

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

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

Вы попробуйте - в любом случае это не повредит.

Вопросы к UI. Шаблон компонента. Основная часть

Вы спрашиваете - чего не хватает в DOM.

Называю.

Вы - ну этого нет в спецификации!

Ну конечно нет, раз этого нет среди фич)

Ещё разик напишу, если Вам не удалось прочитать с первого захода ;)
- Если Вы считаете что какая-та функциональность необходима, - Вы можете обратиться в группу разработки стандартов.

Придётся обосновать необходимость и сделать внятное предложение.

Работа со стилями - предполагаемое поведение от дом. Он должен давать все возможности необходимые для реализации всех аспектов верстки через js.

Предполагаемое поведение DOM - это работа с нодами, и она вполне адекватно реализована, включая и работу со стилями элементов.

Работа с классами CSS реализована в API CSSOM и там (как Вам уже справедливо указали) можно и классы создавать и псевдо классы к селекторам навешивать.

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

Вопросы к UI. Шаблон компонента. Основная часть

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

Но как Вы сами заметили

Тут есть сотни нюансов

Вопросы к UI. Шаблон компонента. Основная часть

Мне почему-то больше понравился конечный результат, чем исходник, в чём профит такого подхода?

Вопросы к UI. Шаблон компонента. Основная часть

С DOM в том и проблема, что в него заложено крайне мало возможностей по работе с элементами. Либо сделано это как-то криво, недоработано, не покрывает всех функций.

Хм, крайне спорно, DOM - это такой турбо composite, которого больше нигде нет. Не могли бы Вы привести пример возможности по работе с элементами, которой нет в DOM?

Каких функций не хватает?

Вопросы к UI. Шаблон компонента. Введение

Да думаю многие просекли, просто непонятен результат ваших изысканий, всё-то Вам не нравится: SGML Вам колючий, React душный, CSS слишком отдельный...

Будут конкретные предложения?

Не томите :)

Народный браузер — каким он мог бы быть?

Инструменты разработчика -> вкладка сеть

Вопросы к UI. Шаблон компонента. Введение

Заинтриговали, жду следующего доклада

Вопросы к UI. Шаблон компонента. Введение

Как я понял, вы говорите уже о какой-то конкретной реализации, и вашем опыте с ней.

Ну а был бы смысл говорить о чём-то не конкретном? ;)

Но дьявол в деталях, нужно целиком отсматривать предложенное вами решение, анализировать проекты. активно писать на нем.

Весь дьявол в DOM API, думаю Вы с ним знакомы не понаслышке, библиотека просто даёт возможность масштабировать наиболее очевидное совмещение HTML и JS

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

Здесь нет синтаксиса - его вовсе нет.

И мне он не кажется хоть сколько то привлекательным. Если он правда такой, - заманчивей писать на вью. Субъективщина

Субъективщина :)

Вопросы к UI. Шаблон компонента. Введение

Макеты - не шаблоны, клея 2k (с lazy loading модулей 3.7k), работаем прямо с DOM
живых объектов, как в детстве :)

Как не жонглируй троицей технологий, и всеми подобными подходами, в среднем получится что-то вроде ...

других технологий нам браузер не предоставил, они привычные и достаточно наглядные

Вопросы к UI. Шаблон компонента. Введение

Декларативный HTML/XML макет, императивно (ручками :) шатаем из прямо связянного с макетом скрипта

--hello-world component
<div beans-as="hello-world" beans-shadow="mode=closed;delegatesFocus=true">
	<h1 beans-body></h1>
	<input beans-ref="input" placeholder="type your name here">
	<h2>Hello <span beans-ref="name">Anonymous</span>!</h2>
	<script>
		$ref.input.oninput = (e) => {
			this.beanUpdate($ref.input.value)
		}

		this.onBeanUpdate = (data) => {
			$ref.name.innerText = data || 'Anonimous'
		}
	</script>
</div>

--root of app
<div beans-as="double-hello-world">
		<hello-world>Hello first</hello-world>
		<hr>
		<hello-world>Hello second</hello-world>
</div>

• как-то так, здесь два компонента, один использует другого

• всё это заливается в фабрику

• из фабрики берётся скриптом и монтируется туда, куда нужно

Вопросы к UI. Шаблон компонента. Введение

Основной посыл статьи - поставить под сомнение текущие реализации шаблонов.

Поставил бы под сомнение шаблоны как таковые.

Новый фронтенд-фреймворк?

как всегда - хотелось бы увидеть реализацию "стандартного" приложения, чтобы было с чем сравнить https://todomvc.com/

А что, так можно было?

Извиняюсь конечно, но опять скажу - использовать CustomElements как единственную основу для декомпозиции - это приблизительно как использовать js без модулей и closures

А что, так можно было?

W3View ? ванильные компоненты без магии

А что, так можно было?

а ведь можно и

<button onclick="increment()">Click me!</button>

так тоже было можно ;)

А что, так можно было?

ну так-то можно конечно, но придётся добавить пару аргументов и превратить эту красоту в вырвиглазную зубодробильню :)