Почему я наслаждаюсь Svelte?

Как автоматически обновлять зависимости JavaScript

От автора: как человеку, который в первую очередь связан с React как по работе, так и лично для себя, мне часто задают вопросы о том, почему я так много играю со Svelte. Поэтому я записываю их, чтобы организовать свои мысли.

Батарейки прилагаются

Одна из первых вещей, которая, вероятно, поразит вас при первом контакте — это то, что Svelte очень сильно соответствует принципу «Батареи прилагаются», возможно, больше, чем Vue (который, в вою очередь, соответствует намного больше, чем React). (Я не могу сравнить с другими фреймворками, потому что не знаю их.)

Я должен согласиться с Ричем в том, что правильная оболочка внешнего интерфейса должна сопровождаться стилевым решением. Тем, которое позволяет вам просто писать CSS.

Но Svelte идет еще дальше. Переходы и анимации. Управление состоянием. Даже метафрейм рендеринга на стороне сервера является новинкой. Вот список собственных функций Svelte и их сторонних эквивалентов React:

Статическая стилизация диапазонов — <style> vs Linaria / Astroturf / Styled-Components + плагин Babel

Переходы: transition:fn и in:fn/out:fn vs React Transition Group

Анимации: animate:fn vs React Spring / Framer Motion

Управление head: <svelte:head> vs react-helmet/react-async-helmet

Переключение классов: class:name vs classnames

Управление состоянием: Svelte Stores(?)vs Redux / Mobx

A11y линтинг: в компиляторе vs react-axe и eslint-plugin-jsx-a11y

Метафрейм SSR: Sapper vs Next.js

Маршрутизация — заметное упущение обоих. CLI для начинающих по умолчанию также свободно управляются обоими.

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

Чтобы быть справедливым по отношению к React, у них есть собственные решения, которыми Svelte не обладает:

DevTools: https://github.com/RedHatter/svelte-devtools

Portals: https://github.com/romkor/svelte-portal

Suspense: https://github.com/sveltejs/svelte/issues/3203

Lazy/Code Splitting: https://github.com/sveltejs/svelte/issues/742

Mobile / Native: https://github.com/halfnelson/svelte-native

Streaming SSR:

Test Utilities:

Я не уверен, насчет новых событий и нормализованного xbrowser, но, вероятно, React имеет и другие вещи.

Радость от изменчивости

Svelte — это let по сравнению const Реакт. Вот идиоматический счетчик Svelte:

<script>let i = 0</script>
<button on:click={() => i += 1}>count {i}</button>

и идиоматический счетчик React:

const [i, setI] = useState(0)
return <button onClick={() => setI(i + 1)}>count {i}</button>

Рич много говорит о краткости, и это правда, при рефакторингах я заметил, что приложения содержит на 15-30% меньше кода. Но это ни к селу, ни к городу, если компромиссы сводят на нет преимущества экономии символов. (это оспаривается, конечно)

Я думаю, что большее дело — ментальная модель. Прямая манипуляция является основным принципом взаимодействия человека с компьютером. Напрямую проще изменять переменные, устанавливая их, вместо того, чтобы извлекать установщики из среды выполнения и планировать асинхронное обновление (большинство новичков в React даже не знают об этом, и мы научились просто принимать это). Это не просто более кратко, это действительно проще и более знакомо. Рич утверждал, что изменчивость — это основной режим, в котором мы, естественно, хотим взаимодействовать и с DOM.

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

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

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

$ugar $yntax

Двухсторонняя привязка

Формы в React сложны, но есть Formik. Типичная форма React будет выглядеть примерно так:

const submitForm = () => {/* etc */}
const [name, setName] = useState('')
const handleChange = e => setName(e.target.value)
const handleSubmit = e => e.preventDefault() || submitForm(name)
// not real code; needs labels and submit button too
return <form onSubmit={handleSubmit}>
<input type="text" value={name} onChange={handleChange} />
</form>

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

<script> let value = "" const submitForm = () => {/* etc */}
</script>
<!-- not real code; needs labels and submit button too -->
<form onSubmit|preventDefault={submitForm}> <input type="text" bind:value >
</form>

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

React, конечно, обоснованно гордится наличием узкого охвата API. Это сразу упростило совместимость сторонних библиотек и сохранность API, но также перенесло бремя обучения и шаблонов на авторов приложений. Это не критика, это осознанный компромисс — например, это позволило сообществу React исследовать шаблоны проектирования, такие как HoC и Render Props, с нулевым изменением библиотеки.

Хранилища

Я уже писал о своей любви к Svelte Stores. Тот факт, что с помощью синтаксиса $ мы можем читать из хранилищ (и, для этих целей, любого Observable), замечателен, но мы также можем устанавливать их через присваивание! И прелесть в том, что это автоматизирует удаление подписок.

Без сахара, чтобы считать из хранилища Svelte, нам нужно:

<script>
import { onDestroy } from 'svelte'
import { store } from './store.js'
let localVar
let unsub = store.subscribe(v => { localVar = v
})
onDestroy(unsub)
const handler = () => store.set(localVar + 1)
</script>
<button on:click={handler}>{localVar}</button>

С синтаксическим сахаром:

<script>
import { store } from './store.js'
const handler = () => $store += 1
// unsubscribe on unmount is also done for you
</script>
<button on:click={handler}>{$store}</button>

Иегуда Кац недавно написал, что ценность React Hooks заключается в автономном механизме удаления. Это позволяет хукам быть красиво ограниченными абстракциями. Я бы применил эту аналогию ко всем фреймворкам. В конце концов, основная экономия кода при использовании фреймворка вместо vanilla JS заключается в том, что нам нет необходимости писать код для каждого элемента!

В Svelte полно таких вещей. Я еще не упоминал разматывание промисов? Мемоизация? Попробуйте использовать $: a = b + c; вместо useMemo/useCallback!

Да, это много правил синтаксиса, чтобы держать их все в голове. Вот почему так важно иметь…

Качественную документацию

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

Документация API

Руководство

Связанный с Gist REPL

Примеры — посмотрите этот пример Chatbot из 107 строк кода!

Многие люди работают над ними в течение полного рабочего дня. Недавно я смог найти, что actions помогают в моем сценарии использования, даже не зная до того, что они существуют!

Простая внутренняя начинка

Я действительно думаю, что это СУПЕР недооцененный аспект Svelte. Я могу найти исходный код, прочитать его и понять его. Вот это да! Этого нельзя сказать о других фремворках, которые, по общему признанию, имеют совершенно разные цели.

Однако простые внутренние компоненты и простые соглашения позволяют мне быть ЧРЕЗВЫЧАЙНО уверенным в том, как самостоятельно извлекать или писать вручную код. Хранилища и анимации явно спроектированы таким образом, что исходный материал просто включен для удобства, но ожидается, что вы напишите свой собственный, если это необходимо.

В недавнем подкасте Джефф Мейерсон заметил что-то вроде «если бы React пошел в другом направлении, вы могли бы создать форк и поддерживать код». Это не правда. Я попытался внести свой код, и мне было очень трудно держать базу кода React в голове.

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

Нет лишнего багажа

React — очень насыщенная тема. Svelte оказывает гораздо меньшее воздействие, что во многих (не во всех) случаях приводит к меньшим пакетам JS, поэтому с ними лучше экспериментировать.

Потому что я могу

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

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

Svelte — это интересно, но

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

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

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

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

У React есть много чего, и он достаточно хорош для подавляющего большинства людей. Сетевой эффект сам по себе может быть непреодолимым. Они также имеют высочайшее качество выпускаемых версий и работают над удивительными вещами, над которыми не работает ни одна другая платформа. Если бы я сегодня запускал новое рабочее приложение, я бы все равно использовал React. Я также думаю, что для React можно создать слой компилятора, чтобы скопировать некоторые идеи из Svelte.

На данный момент мой подход — «Svelte для сайтов, React для приложений».

Источник: https://www.swyx.io

Редакция: Команда webformyself.