Svelte 3: Переосмысление реактивности

Привязка декларативна, я имел ввиду сам обработчик. Что за "программная логика"?

<button on:click={handleClick}>
    Clicked {count} {btnText}
</button>

<script>
  let count = 0;

  $: btnText = count === 1 ? 'time' : 'times';

  function handleClick() {}
</script>

Видимо у нас очень разные определения тупиковости. Потому что мне время (первые минут 30) уже все показало. Например, когда для оптимизации, нужно в shouldComponentUpdate внести то, что и так очевидно из render-функции. Или необходимость указывать key-property при рендере массива. Или перечислять значения вторым аргументом в useCallback. Эти проблемы нужно решать в фундаменте, а не плагинами к бабелю. Тогда будет архитектура, а не набор костылей.

Не подскажете, в чем там проблема? Приходится явно указывать ангуляру, что данные обновились?

Не убедили. «Svelte просто хорошо работает» звучит примерно как «у нас никогда не бывает багов».

Надеемся на лучшее, но на случай проблем должны быть предусмотрены какие-то действия, особенно если в проекте работает несколько разработчиков, с разным уровнем квалификации

Я про ф-ии которые зависят от контекста, или вы в js только чистые ф-ии пишите?

Очень простой и очевидный пример где функция зависит от контекста («c» зависит от «a» через «b»).

let a = 1;
let b = () => a + 1;
$: c = b() + 1;

let a = 1;
$: b = () => a + 1;
$: c = b() + 1;

Но Svelte это не может осилить, когда тот же ангуляр (да и реакт*) без проблем (как и в нативном JS).

Или вот ещё пример который не работает:

<script>
  let user = {name: 'linux'};
  $: user2 = user;
</script>
<input type="text" bind:value={user.name} />
<h1>Hello {user.name}!</h1>
<h1>Hello {user2.name}!</h1>

Тут нужно вручную привязку делать чтобы заработало (опять же в ангуляр и реакт нет этой проблемы).

это «болевые точки» всех фреймворков основанных на «observable», я как раз поэтому и привел эти (не единственные) примеры.

Вместо одной проверки и присваивания он запускает сгенерированную портянку, которая линейно сканирует все отслеживаемые переменные и свойства на изменения.

<script>
  let name = 'test';
</script>

<input type="text" bind:value={name}>
<h1>{name}</h1>

input = element("input");
t0 = space();
h1 = element("h1");
t1 = text(ctx.name);
attr(input, "type", "text");
dispose = listen(input, "input", ctx.input_input_handler);

function instance($$self, $$props, $$invalidate) {
	let name = 'test';

	function input_input_handler() {
		name = this.value;
		$$invalidate('name', name);
	}

	return { name, input_input_handler };
}

if (changed.name && (input.value !== ctx.name)) input.value = ctx.name;
if (changed.name) {
  set_data(t1, ctx.name);
}

set_data(text, data) {
  data = '' + data;
  if (text.data !== data) text.data = data;
}

Если отойти от уровня примеров и завести в компоненте простенькие структуры, при изменении свойства объекта, «фреймворк» опять же целиком инвалидирует объект (похоже что и вызываемая при инвалидации функция сравнения некорректна, всегда возвращает true для объекта или функции) и тоже запускает портянку.

Является ли дискуссионным, что нормальные функции сравнения могут выглядеть по-разному, но не так? Такое невозможно использовать сколько-нибудь продолжительное время и не напороться.

function not_equal(a, b) {
  return a != a ? b == b : a !== b;
}

Ненормально частые упоминания «практики», не сопровождаемые конкретикой, вызывают подозрения, что у вас какие-то серьезные проблемы с практикой.

И вот эти высокомерные указания комментаторам темы (volch/jsmitty/lega) то нажимать кнопочки, то смотреть материалы и преждевременные предположения, что именно они чего-то не поняли, с чем-то незнакомы или не разобрались.

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

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

Что-то вы как раз не демонстрируете даже базовых практических знаний. Тогда становится понятно, зачем нужен генератор JS.

Точно хотите гнуть такую линию дальше?

Если что-то является решетом, от архитектуры до реализации, зачем такое использовать.