F+ Flaptop R — несколько мощных ноутбуков на AMD Ryzen

Ubuntu 23.04 поставилась как родная, все устройтсва работают из коробки. Кроме санера отпечатков, на него драйверов вроде нет: ID 2808:9338 Focal-systems.Corp FT9201Fingerprint.̚

F+ Flaptop R — несколько мощных ноутбуков на AMD Ryzen

Конечно, не всем будет достаточно 8 Гбайт оперативки (тем более что в моделях F+ Flaptop она не расширяется).

Расширяется, и не просто расширяется - там два полноценных слота под память и один свободен во всех модификациях.

Вышла elementary OS 6.1 Jólnir: обновленный центр приложений и многое другое

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

Переиспользуемый компонент Svelte: чтобы никому не было больно

Найс, тогда я погляжу еще внимательнее. Все порываюсь переписать svelte-docs, там такой парсер очень нужен.
Можно сделать CLI поверх sveltedoc-parser, который при запуске в папке проекта, по полю "svelte" в "package.json" нашел бы компонент(или компоненты, если это библиотека), и нагенерил этот index.ts.d =)

Переиспользуемый компонент Svelte: чтобы никому не было больно

JSDoc хорошо использовать "для себя" внутри подкомпонентов для подсказок в IDE, но наружу, в переиспользуемом компоненте, все же лучше руками написать index.d.ts, поскольку там обычно все несколько сложнее, чем просто описание пропсов. Например, там еще может быть описание переменных которые получаются из слота, либо какие-то, кастомные типы и интерфейсы. Врятли это получится нагенерировать автоматически.
PS: почитал про sveltedoc-parser — они уже значительно развитее, чем я смотрел последний раз. Может и получится сделать генератор.

Переиспользуемый компонент Svelte: чтобы никому не было больно

JSDOC в Svelte-комопнентах не пользуется особой популярностью, т.к., например, в ES6 модуле он скорее всего будет утрачен при компиляции. Полезнее создать index.d.ts файл в папке проекта(пакета), где описать какие пропсы экспортирует компонент. Этот файл подхватится IDE и будет давать подсказки независимо используется ли модуль или голый компонент svelte. Ну и те, кто пишет на typescript смогут использовать ваш комопнент полноценно, с типами.

Например для комопонента часов из статьи файл index.d.ts будет иметь примерно такой вид:

export default class {
    $$prop_def: {
      /**
       * Color of sign
       * @default "white"
       */
      color?: string;

      /**
       * Card background color
       * @default "black"
       */
      background?: string;

      /**
       * Border color
       * @default "grey"
       */
      border?: string;
    };
  }

Переиспользуемый компонент Svelte: чтобы никому не было больно

Подумал, все-таки исправил по вашему совету, только, кажется, уместнее написать "svelte": "3.x".
Но, к сожалению, проблему более вероятную это все равно не решит, 3.1 от 3.30 скорее всего отличается тоже(не могу точно сказать) по работе с штуками из "svelte/internal". Если начнутся проблемы с совместимостью, то лучше импортировать модуль IIFE по полному пути с небольшой оберткой. И смириться что в проекте возможно будет забандлено два свелта. А еще лучше кинуть исуса автору пакета, чтобы он обновил его для работы с актуальной версией.

Переиспользуемый компонент Svelte: чтобы никому не было больно

Аналогично в Vue. Пример тут.

<template>
  <SvelteClock color="gold" />
</template>

<script>
import toVue from "svelte-adapter/vue";
import Clock from "svelte-clock-demo";

export default {
  components: {
    SvelteClock: toVue(Clock),
  },
};
</script>

Переиспользуемый компонент Svelte: чтобы никому не было больно

В общем, как ни крути, а заголовок статьи с преувеличением — кому-то все таки больно может и быть =)

Переиспользуемый компонент Svelte: чтобы никому не было больно

Вероятность того, что где-то будет собираться новый проект на Svelte2 стремится к нулю. Можно там указывать версию(скопировать с соответствующего поля в devDependency), поскольку даже в текущих версиях возможны вариации, но это может привести к тому, что те кто будут использовать комопонент импортируя из "svelte" поля(а таких большинство), получат, что скомпилированый компонент будет импортировать фунции из другой версии Svelte, что может вызвать проблемы, поскольку получится, что у каждого компонента своя версия рантайма, что может конфликтовать(я сталкивался).
Со звездочкой в peer-зависимости аналогичные проблемы возможны у тех кто использует ES6 модули. Но скорее всего, ничего страшного пока не будет, рантайм фреймворка останется в единственном экземпляре, даже если несколько компонентов будут использовать.

Переиспользуемый компонент Svelte: чтобы никому не было больно

Лучше всего воспользоваться специальным адаптером(он же подойдет и для аналогичного встраивания в Vue).

Тогда код получится таким(см. пример на Codesandbox):

import React from "react";
import ReactDOM from "react-dom";
import toReact from "svelte-adapter/react";
import  Clock from "svelte-clock-demo";

const SvelteClock = toReact(Clock);

const App = () => {
  return (
    <div>
      <SvelteClock background="white" color="black" />
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById("root"));

Чем «фрагменты» могут помочь в Веб-разработке на примере Malina.js

Малина — компилируемый фреймворки(аналогично Svelte). На выходе для каждого компонента там создается некоторое количество бойлерплейта обслуживающего стейт, реактивность и прочее. Т.е. нужно понимать, что если хочется вынести кусок шаблона в отдельный компонент, то это не будет просто кусок шаблона в бандле, а полноценный код компонента со всем этим бойлерплейтом. Фрагмент решает эту проблему, когда нужно иметь переиспользуемый кусок шаблона в компоненте, но не нужно делать из него полноценный компонент.

Оптимальный способ работы с DOM

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

Зря на Svelte наговариваете:

Svelte benchmark

Svelte, исчезающий фреймворк, который уже не исчезнет

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

Svelte, исчезающий фреймворк, который уже не исчезнет

Через адаптер разве что. Но соглашусь пример не очень контекстный вышел, хотел сказать, что ничто не вечно и подходы работавшие много лет(приносящие деньги, позволившие стать популярными за 3 года и прочее по тексту) тоже переосмысливаются и заменяются. Svelte3 смог радикально поменять свою парадигму за счет немногочисленности его использования до v3. Изначально предполагалось написать тулинг для конвертации компонентов, но никто не просил и забылось. Если доживем до предпосылок необходимости v4, то такой фокус провернуть уже не получится.

Svelte, исчезающий фреймворк, который уже не исчезнет

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

Эм, на то они и мажорные. По вашему, как завезли хуки в React или composition api в Vue3 — сразу вон с продакшена эти нестабильные фреймворки/библиотеки?

Svelte, исчезающий фреймворк, который уже не исчезнет

Следующий митап должен был быть в Питере в апреле-мае, но пандемия внесла свои коррективы в наши планы.

Зарубежные коллеги завтра (26.04.2020) организуют очень обширный онлайн-митап — https://sveltesociety.dev/. Спикеры со всего мира, включая создателя фреймворка.

Svelte, исчезающий фреймворк, который уже не исчезнет

В вашем сравнении, я бы сказал, что это скорее колесо от 18-wheeler. Минимальный кирпичик, легко кастомизируемый под совершенно разные задачи. Реализаций сторов миллион, и Svelte совсем не обязывает использовать коробочный вариант, можно и MobX использовать. Для коробочного варианта фреймворк предлагает "сахар" в своих компонентах в виде автоподписок, но этот же "сахар" будет работать со всем observable-подобным(т.е. любой объект с методом subscribe), например популярный RxJS.

Svelte, исчезающий фреймворк, который уже не исчезнет

svelte/store никак не связан с механизмом реактивности Svelte. Это минималистическая реализация сторов аля Observable, работает в рантайме, т.е. спокойно можно использовать отдельно от Svelte, в своих проектах.

Svelte, исчезающий фреймворк, что всё никак не исчезал

Ещё вы не знали, что Svelte умеет компилировать свои компоненты в web-компоненты(custom elements), которые нативно используют Shadow DOM для организации слотов и инкапсуляции. Повторю, это не фреймворк — это нативная фича web-компонентов.
Соответственно, никакого Shadow DOM при обычной компиляции нет и в помине.
Расскажите, как вы сравниваете Shadow DOM vs Virtual DOM, если утверждаете, что от одного можно прийти к другому?