У меня не работает on:click={handleClick} в теги img, это нормально?

не получается. к томуже они от ребенка к родителю вызываются

Попробуй on:click={() => handleClick()}

Спасибо, я узнал про css свойство pointer-events и забыл что его поставил )) но может кому полезно будет - "Свойство pointer-events позволяет управлять тем, как элементы будут реагировать на события мыши"

через css можно отключить реакцию, чудеса

а реакцию через таб+пробел\ентер не отключить =)

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

Все отлично работает, работа с инпутами точно такая же как при разработке на веб-компонентах где тоже нет никаких фреймворков. Это в реакте <input .../> в шаблоне является не нативным дом-элементом а специальным враппером со своей специфичной стейтфулл логикой из-за чего рано или поздно возникают нюансы (вроде сброса каретки и т.д).

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

Нет там никакой сложной системы коммита. Не нужно ничего оверинжинирить. Это в реакте постоянно все усложняют (а юзеру потом учить всякие нюансы).
Например реакт разпознает что в строчке <div style={{width: 100}}/> значение 100 нужно сконвертировать в строчку и добавить суффикс "px" потому что браузеры не понимают числа в стилях. Но при этом есть свойства которые являются unitless (например flex-grow) для которых при конвертации в строку суффикс "px" добавлять не надо. И вот сорцах реакта есть список этих unitless-свойств по которым он сверяет свойства при диффе. И вот выйдет какое-то новое css-свойство и нужно ждать обновления реакта потому что он может неправильно с ним работать. И это только один из примеров, подобных нюансов с реактом еще много.
То есть проблема реакта в том что он слишком сильно пытается залезть и заврапить своим апи нативную систему html/css/dom-дерева (прикрываясь удобством) из-за чего новичку который знает html приходится учить всякие нюансы самого реакта.
Но так ли это нужно? Разрабатывая приложения на вебкомпонентах ты работаешь с нативным дом-деревом и свойствами и знания универсальны. А разрабатывая на реакте нужно постоянно учитывать и подучивать определенные нюансы самого реакта. Почему бы просто не просто не предоставить юзеру возможность самому установить любое css-свойство на сам дом-элемент?
Если посмотреть на тот 22-строчний "фреймворк" в демке (https://codesandbox.io/s/hungry-star-0r2y8?file=/src/index.js) то там нет ни строчки про коммит различных аттрибутов, и различий между html-аттрибутами и свойствами и нет даже поддежки css-свойств.

А все потому что этот хелпер не пытается заврапить всю работу с дом-деревом. Ни одному приложению не нужно использовать все 500 css-свойств или 100 html-тегов и аттрибутов. Обычно пишут некоторый набор атомарных компонентов (причем еще под дизайн-систему) а потом уже из этих компонентов собирают приложения.
И вот для этих атомарных компонентов ты сам пишешь diff нужных css-свойств - и это 1 или 2 строчки кода - то есть простая diff-функция которая будет вызываться с передачей объекта-состояния и дальше просто проверяешь на равенство и устанавливаешь новое значение. Очень просто и при этом ты работаешь с нативным домом без всяких оберток. Вот пример атомарного компонента Box под какую-то дизайн-систему где сам делаешь diff нужного css-свойства

const Box = ({padding = 0, ...}) => {
 return h({
  diff: (context, state = {padding}) => {
   if (padding !== state.padding) context.el.style.padding = `${state.padding = padding}px`;
   ...
 })
}

Да чуть менее удобно чем в реакте но с другой стороны ты это пишешь один раз внутри атомарных компонентов а потом уже собираешь приложения из атомарных компонентов декларативно, примерно так

const Component = ({prop1, prop2}) => {
 return Box({
   width: prop1,
   height: 500,
   background: `#edeef0`,
   border: `1px solid blue`,
   padding: 20,
   children: [
    Box({
     height: 30,
     background: `gray`,
     border: `1px solid gray`,
     padding: 10,
    }),
    AnotherComponent({prop2})
   ]
 });
};

И при этом работаешь с нативной системой дом-дерева без всяких оберток и сам выбираешь юзать свойства или аттрибуты (ну и доступны все возможные css-свойства без необходимости ждать поддержки чего-то в фреймворке)

const Box = ({padding = 0, ...}) => {
 return h({
  diff: (context, state = {padding}) => {
   if (padding !== state.padding) context.el.style.padding = `${state.padding = padding}px`;
   ...
 })
}

const Component = ({prop1, prop2}) => {
 return Box({
   width: prop1,
   height: 500,
   background: `#edeef0`,
   border: `1px solid blue`,
   padding: 20,
   children: [
    Box({
     height: 30,
     background: `gray`,
     border: `1px solid gray`,
     padding: 10,
    }),
    AnotherComponent({prop2})
   ]
 });
};

Ну извините, вы зачем то даете дифф вручную самому применять. Если вы понапишите автоматическое правильное применение этого дифа для любого случая жизни, то у вас получится реакт дом.

В реакте нет работы с дифом напрямую и нет работы с домом напрямую. Потому что он собрал все изменения которые произошли пока клик погружался до таргета и поднимался до документа, а затем применил к дому за 1 проход.

Что будет у вас если висит обработчик 'change' на инпуте, а потом обработчик 'change' на форме выше. Вы из одного места уже будете видеть примененные изменения в другом месте. А если вам нужно что-то обмерить (getBoundingClientRect) то ваш дом уже инвалидирован неатомарными изменениями и вы будете вызывать форс рефлоу.

const Box = ({padding = 0, ...}) => {
 return h({
  diff: (context, state = {padding}) => {
   if (padding !== state.padding) context.el.style.padding = `${state.padding = padding}px`;
   ...
 })
}

const Component = ({prop1, prop2}) => {
 return Box({
   width: prop1,
   height: 500,
   background: `#edeef0`,
   border: `1px solid blue`,
   padding: 20,
   children: [
    Box({
     height: 30,
     background: `gray`,
     border: `1px solid gray`,
     padding: 10,
    }),
    AnotherComponent({prop2})
   ]
 });
};

Ни разу за 4 года не встретил ситуации когда какое-то цсс проперти недоступно для установки. Может таких ситуаций не бывает? Все таки кастом проперти это вообще любая строчка и они работают без проблем

Зачем тебе свелт для лендинга то?

Скучно лендинг просто так писать...

Реквестирую пояснение за архитектуру svelte: как получить значения пропсов из DOM? Пример: расширение для для сайта, сделанного на svelte, нужно по-быстрому что-то вытащить. То есть если есть virtualdom и тд, то в реакте это делается через <element>.__ReactInternalInstance, в angular через <element>.__ngContext__, а как (и можно ли) в Svelte?

bind:this?

Нет, либо я не понял, но по-моему не я

У меня уже есть допустим готовое приложение, запущенное в браузере. Как я могу, например, из консоли, получить список и значения пропсов интересующего меня компонента? (И могу ли)

Все свелт приложение это IIFE и оно ничего в глобале не оставляет

Можно только внутри приложения пропсы используя restProps например отобразить

Понятно, спасибо