мне кажется ты что-то путаешь.

> смысл в том, что его пытаются популяризировать

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

> но при этом когда дело доходит до нюансов

везде и всегда дело в нюансах и до них всегда доходит

> устраивают жесткую политику

все так делают, без этого будет лебедь, рак и щука

> кладут болт там где люди ожидают что класть болт не будут

почему люди этого ожидают? что за люди? надо бы уточнить, не понятно что имеешь ввиду

> в итоге снижает популярность

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

> в итоге не понятно просто направление

а где направление понятно? по-моему кода Дэн вышел в хуками все тоже прихерели мельца. как пример

> не было бы хвалебных статей, никто бы не бомбил

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

> а так вводят в заблуждение в какой-то степени, потом ты узнаёшь нюансы, и осадочек остаётся

нюансы есть везде и они зависят от проекта, от человека и еще от кучи всего. мне например передача классов не нужна и я не считаю это “стандартной вещью”, поэтому не вижу смысла об этом упоминать каждую секунду. опять же это возврат к вопросу “стандартных штук”, который так любит поднимать @Constantine2017

> когда на людей кладут, они кладут в ответ

так кто кладет? вот тебе реальный пример: https://twitter.com/AdamRackis еще год назад чувак писал в основном про реакт, а теперь почти каждый день фантанирует по свелт

Но я всё же опишу что произошло, слишком много времени потрачено было, что бы отпустить это просто так:
у нас есть это:
<div >
      {#each #each files as file}
           <File {file}/>
      {/each}
/each}
</div>
Всё нормально, всё отображается как надо. Далее мы меняем содержимое files полностью, при этом было files.length = 2, стало files.length = 3, что происходит:
<div >
      {#each #each files as file}
         //первая-вторая итерация: не удаляется компонент File, но ему пробрасывается новый объект file, соответственно не выполняется всё что в теге <script>
         //третья итерация: о, новый объект, добавляем новый компонент File в котором запускается скрипт и всё как надо
           <File {file}/>
      {/each}
/each}
</div>
Далее мы меняем содержимое files полностью, при этом было files.length = 3, стало files.length = 1, что происходит:
<div >
      {#each #each files as file}
         //первая итерация: не удаляется компонент File, но ему пробрасывается новый объект file, соответственно не выполняется всё что в теге <script>
         //остальные компоненты всё же удаляются
           <File {file}/>
      {/each}
/each}
</div>
Я то думал что всё пересоздаётся. Ну норм опыт такой) Наверное для многих это очевидно, но я удивлён. Хотя понятно, что так быстрее всё работать должно

для этого каждый раз key должен быть случайный, чтобы пересоздавалось
а если там ссылка на объект совпадает у предидущего file со следующим, то свелт будет переиспользовать компонент и кормить ему новые данные

т.е. делаешь

{#each files as file (Math.random())}
  <File {file} />
{/each}

Или можно так написать в дочернем компоненте:
let name = file.name;
$: name = file.name;
как работать будет быстрее?
У меня дочерних компонентов в теории могут быть сотни.
Если не пересоздавать дочерний компонент, а только лишь поменять свойства передаваемые ему, то по идее быстрее должно быть. Но я не знаю внутреннюю кухню свелт

Или можно так написать в дочернем компоненте:
let name = file.name;
$: name = file.name;
как работать будет быстрее?
У меня дочерних компонентов в теории могут быть сотни.
Если не пересоздавать дочерний компонент, а только лишь поменять свойства передаваемые ему, то по идее быстрее должно быть. Но я не знаю внутреннюю кухню свелт

тут дело не в быстрее, а в том что первое будет выполнено при создании инстанса компонента и больше никогда, а второе по мере обновления переданного компоненту объекта
можно ещё заспредить этот объект файл в компонент <File {...file} />
и экспортнуть все поля как пропсы в File

проверил, заспредить можно, но не всё равно не работает без Math.random()

ну да, ведь маппит данные к компонентам each
то я просто к тому, чтобы не делать $: name = file.name;
а просто писать export let name и использовать сразу это name

Небольшой оффтоп.

Мы с дизом воюем, как правильно говорить: "уменьш непрозрачность" или "увеличь прозрачность"

Аргументов c обоих сторон нет, подсобите пожалуйста 😅

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

Когда ты думаешь: "У меня здесь 30% прозрачности установлено", и тебе говорят "сделай где то 40% непрозрачности", то это путает жуть

А обоим отучится сложно)

Диз как говорит?

Он за непрозрачность, я за прозрачность)

Ну вообще-то странно, ведь у разрабов как раз всегда непрозрачность выставляется)
Кроме полной прозрачности в виде значения transparent