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

А вот я не готов реально сравнивать одну итерацию по объекту с одним булевым сравнением

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

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

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

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

отмечаем основные моменты

«Основные моменты» игнорируют упомянутые проблемы, что не компенсируется восторженными эмоциональными фразами.

не знаю что может быть проще и эффективнее
не считаю проблемой

Ок, в данной части ваша позиция ясна. Можно было сэкономить кучу времени, если не выдумывать про бандлер, эджкейсы и т. п.

опцию immutable: true (которую кстати мы всегда используем)

В таком случае информация про опцию, которую "мы всегда используем" вместо некорректного дефолтного поведения, и необходимость копировать объект при каждом изменении, должна была находиться в шапке каждого поста. А если псевдо-иммутабельность нужна всегда, то…

реальные проекты

Столько слов о мифических «реальных проектах» не сопровождены ссылками. Вдруг они великолепно покажут, насколько хорош именно svelte. Или в них такие же дыры и они покажут обратное.

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

вы не демонстрируете даже базовых навыков адекватности

То есть вместо понятного разработчикам языка, надо было начать ветку следующим комментарием: «вот реальный (тм) серьезный (тм) проект, у него больше уников, чем у всех ваших svelte-проектов в сумме, поэтому всем делать, как я сказал». И вы бы такой: «человек выглядит авторитетным с реальными проектами, пойду выполнять указания». Такая адекватность мне не близка.

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

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

Ловлю на слове. Так и быть, вот один из вариантов в строке: ''. Не идеальный, но вполне рабочий. Сколько времени понадобится на разбор по полочкам популярного интерпретатора/компилятора JS на выбор? Где косяки в алгоритмах и генерируемом коде? С удовольствием предоставляю вам простую возможность поумничать со стороны.

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

Итерирование вообще сильно дороже выходит, чем аналогичное количество булевых if-ов.

Но ведь количество булевых if-ов не аналогичное, не так ли?

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

Внутри Svelte примерно это и делает

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

Вставленная инвалидация:

obj.prop = 'value'; $$invalidate('obj', obj);

Функция сравнения:

function safe_not_equal(a, b) {
  return a != a ? b == b : a !== b || ((a && typeof a === 'object') || typeof a === 'function');
}

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

вы теотерик и практика для вас лишь миф

Раз уж продолжаете настаивать

Мы используем
На практике, пока не удавалось, хотя мы активно используем
По моему опыту
мы всегда внимательно относимся
тесты и практика
Практика — это непосредственно моя, моей компинии
на практике таких багов не бывает
вы теотерик и практика для вас лишь миф

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

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

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

Видите проблему — откройте issue, ее исправят, а вам скажут большое спасибо. Так работает open-source.

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

Фибоначчи на собеседовании

Объекты в JS — это хэш таблицы, а хэш таблицы хранятся не так как вы говорите — там нет никакой сортировки

Свойства объектов в JS отсортированы в порядке добавления, по меньшей мере, они перечисляются в таком порядке, за исключением свойств с беззнаковыми 32-битными целочисленными ключами (в спеке начиная с ES2015).

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

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

Если это изменение должно быть засинкано в DOM, то операция становится в разы сложнее

textNode.nodeValue = count

Невероятная сложность.

Опять же тесты и практика

Это называется не «тесты и практика», а картинка, бессмысленность которой понимает даже автор обсуждаемого «фреймворка».

компилятор подскажет

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

Svelte этого не делает, потому что это делает бандлер. Не уверен, что вообще существует кейс, когда код компонента будет просто выброшен в глобал

Баг совсем не в том. И слово бандлер не спасет. Вот такой «компонент» svelte:

<script>
let namе = 'test';
$: double = name + namе;
</script>
<h1>{name}</h1> {double}

Подключается так:

import App from './App.svelte';
export default new App({
  target: document.body
});

Он скомпилируется и будет читать заголовок из window.name. Проброс через переменные верхнего уровня компонента — архитектурная ошибка того же начального уровня, что и остальные.

как не красиво

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

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

По вашему засинкать стейт и DOM — это простейшая операция

Простейшая операция — инкремент.

Не мой код

Думаю, всем окружающим очевидно, какой комментарий относится к какому куску кода. Не вижу смысла еще раз объяснять вам лично.

По поводу Svelte — работает прекрасно, баги бывают крайне редко. Говорить вы можете сколько хотите, но мы Svelte практикой проверяем и она говорит об обратном.

Сайт вашей конторы говорит, что там лапша из смеси голого JS и jQuery.

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

Исходя из этого, не думаю что это проблема.

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

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

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

В реактивном фреймворке реактивность написана невнимательно или некомпетентно.
Если хочется скорости и компактности, выкинуть и писать нормальный JS. Хочется фреймворк — react/vue/angular/другое. Но мнение, конечно, может быть любое.

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

без лишних затрат и сложности использования прокси или аксессоров. Это просто переменная.

Зато добавился закулисный вызов функции и компилятор. К инкременту. Если он внутри цикла, лишний код будет в каждой итерации.

let name = 'test';
<input type="text" bind:value={name}>

Объявление переменной может отсутствовать или в нем может быть опечатка.
Будет читаться из window.name со всеми вытекающими.

if (changed.name) {
  set_data(t1, ctx.name);
}

Поскольку changed/$$.dirty в svelte инициализируется не с нулевым прототипом, такие проверки будут протекать, например, обновлять переменную constructor, когда не надо.

Очень сырой фреймворк. Ради минималистичности можно было как раз оставить set() и сделать явный update(), выкинув все остальное, а не наоборот.

Интервью с Владимиром Лихачевым, отцом Николая Лихачева, более известного как Крис Касперски

Столько текста ради описания сортировки подсчетом.

Принципы построения REST JSON API

Уязвимость 10+ летней давности с перезаписыванием Array

Особенности использования типа данных Symbol в JavaScript

Конечно
1) В качестве константы
2) В качестве уникального ключа для сохраненного состояния объекта
3) iterator/asyncIterator

Как система типов улучшает ваш код на JavaScript

Однако он уязвим для многочисленных ошибок во время исполнения (рантайм)…
После получения списка данных вы обнаруживаете, что определенное поле не существует в одной из записей. Это приводит к сбою в работе приложения, если этот случай не отлавливается

Если в рантайме пришли неверные данные, типизация их не починит. У нее есть свой ограниченный диапазон полезности.

Ваша IDE не знает, какие методы и свойства доступны для модулей и библиотек

IDE плохо работает?

Решаем задачу из интервью Google на JavaScript: 4 разных способа

function findPairOfAddendsBySum (array, requiredSum)
{
  let lower = 0
  let upper = array.length - 1

  while (lower < upper)
  {
    const currentSum = array[lower] + array[upper]
    const middle = Math.floor(lower + (upper - lower) / 2)

    if (currentSum < requiredSum)
    {
      if (array[middle] + array[upper] < requiredSum)
        lower = middle;
      ++lower
    }
    else if (currentSum > requiredSum)
    {
      if (array[lower] + array[middle] > requiredSum)
        upper = middle;
      --upper
    }
    else
    {
      return [array[lower], array[upper]]
    }
  }

  return []
}

В лучшем случае алгоритм аналогичен двоичному поиску O(log n), в худшем — O(n)

Как реализовать язык программирования на JavaScript. Часть 1: Парсер

регулярка не найдя совпадение в нужной позиции

У регулярок есть флаг «y».

Стажёр Вася и его истории об идемпотентности API

Сервер атомарно с изменением увеличивает версию при любых изменениях заказов
И если это состояние заказов (версия) расходится с тем, что хранится на сервере

Нельзя ли в таком случае вместе с запросом отправлять с клиента просто хеш от известного списка заказов, а на сервере сравнивать с хешем актуального серверного списка.

12 концепций JavaScript, о которых нужно знать

let n = array.length
while (n--) {
  if (array[n].removed) {
    const swap = array.pop()
    if (array.length != n)
      array[n] = swap
  }
}

Так будет эффективнее, хотя порядок элементов изменится.

12 концепций JavaScript, о которых нужно знать

{
const Node = (next, value) => ({next, value})
const array = [1, 2, 3, 4]

// create a linked list from the array
const listA = array.slice().reverse().reduce(Node, null)

// a better way of doing it:
const listB = array.reduceRight(Node, null)
}

20 игр, чтобы научить ребёнка программированию

А вот как (с его слов) видит

Только опытный глаз видит в скобках и отступах структуру. Другие, возможно, и вот так:

整數接觸LED ? 13 ?
整數聯繫按鈕 ? 5 ?
設置程序 ?? ? 接觸模式 ? 接觸LED ? OUTPUT ? ?
接觸模式 ? 聯繫按鈕 ? POWER SUPPLY ? ? ? 程序週期 ??
? 布爾是按下=數字讀取 ? 聯繫按鈕 ? ?
if ? ?Press ? TRUE ?
? 數字錄音 ? 接觸式LED ? HIGH ? ? ?
否則 ? 數字錄音 ? 接觸式LED ? LOW ? ? ? ?

Надёжный JavaScript: в погоне за мифом

типы данных кто будет описывать

Строка конвертируется в число, как и было задумано. Здесь не ошибка типизации.

примеры приводит вообще никак не связанные

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