Svelte — нова дійсність

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Попередній досвід

Моє перше фриланс замовлення я виконав у 2008 році. Це була Joomla з кастомною версткою і це було давно. До того як познайомитися зі Svelte я мав п’ятирічний комерційний досвід розробки на React + Redux + безліч приблуд, таких як redux-saga, re-reselect, і т.п., із величезними бойлерплейтами, але то було прикольно, бо «високий рівень контролю стану», швидкий та зручний дебагінг та ще купа смаколиків. До того ж це модно!

Окрім React довелося трохи попрацювати з Angular від другої до восьмої версії включно. Не скажу, що він був важчий для розуміння, ніж React, але в плані зручності використання і кількості коду для вирішення однієї й тієї ж задачі, Angular здавався дуже застарілим. Як не крути, JSX(TSX) — це прорив. Ще колись таким проривом для мене виявився MobX, і як що б не зустріч зі Svelte, я, мабуть досі писав би на React + MobX.

Перше знайомство

Це сталося у 2021 році. То був невеличкий проект по перенесенню лендінгу з jQuery на Svelte. Відразу приємно здивували інтерактивні tutorials, які зроблені на кшталт уроків Codecademy, не кажучи вже про самі доки. Все досить лаконічно і прозоро. Поріг входу вважається набагато меншим від попередників, особливо, як що є досвід з будь-яким з них. Навіть при невеликому досвіді з React досить швидко звикаєш до свелтівського jsx-синтаксису. Відміни є, але їх небагато. Ось, наприклад, вивід списку:

// React:
<ul>
  {items.map((item, i) => 
    <li key={item.id}>{i}</li>
  )}
</ul>



// Svelte:
<ul>
  {#each items as item, i (item.id)}
    <li>{i}</li>
  {/each}
</ul>

Хтось запитає, що такого є в Svelte, чого немає в React? Насправді багато чого, але як що не вдаватися в подробиці, перераховуючи усе, я б відповів коротко: анімації і стор. Так, повноцінний стор, який за своїми можливостями ні чим не гірший від Redux або MobX. А от за своєю зручністю і простотою використання стор Svelte обганяє їх на декілька років вперед. Ті, хто працював з Redux, знають, чого варте тільки його підключення до проекту. Скажімо так — писанини багато, особливо як що ми використовуємо middleware.

Ось приклад створення нового стору на Svelte:

// ../stores/count-store.js
import { writable } from 'svelte/store';

export const count = writable(0);

Його використання в компоненті:

<script>
  import { count } from '../stores/count-store';
  count.set(1);
  console.log($count) // logs '1'
  // or
  $count = 2;
  console.log($count) // logs '2'
</script>

А це приклад простого стору із документації:

import { writable } from 'svelte/store';

const count = writable(0);

count.subscribe(value => {
	console.log(value);
}); // logs '0'

count.set(1); // logs '1'

count.update(n => n + 1); // logs '2'

Вже після першого дня роботи зі стором Svelte, не важко було порівняти це з попереднім досвідом.

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

Як я вже казав, Svelte приховує дуже багато приємних дрібниць, таких як вбудовані анімації, підтримка TypeScript, збирач Vite, SSR, і ще багато чого цікавого. Окрему увагу хотілося б звернути на онлайн-редактор REPL, зроблений на кшталт codesandbox, де ви можете запустити і перевірити будь-який свій код на Svelte.

Також хотілося б сказати пару слів про SvelteKit. SvelteKit — це фреймворк. Фреймворк на базі фреймворка? Так, але не так, тому що Svelte позиціонує себе як компілятор коду. Так, вам не почулося. Тут уся справа у компіляції вашого коду. У той час як традиційні фреймворки, такі як React і Vue, виконують основну частину своєї роботи в браузері, Svelte переносить цю роботу на етап компіляції, який відбувається при створенні програми. Замість використання таких методів як порівняння віртуальних DOM, Svelte пише код, який хірургічно оновлює DOM при зміні стану вашої програми.

Післямова

Прикро, що Svelte іще не набув тієї популярності, яка б розширила ринок праці для розробників, які прагнуть йти уперед і використовувати найсучасніші інструменти розробки. Але навіть попри це, пропрацювавши зі Svelte понад два роки, можу сказати, що мені б дуже не хотілося б повертатися до знарядь кам’яного віку. За останні роки ця технологія неодноразово змінювалась на краще, процес популяризації поступово відбувається і спільнота Svelte з кожним днем дедалі зростає, тож я впевнений, що майбутнє фронтенду саме за Svelte.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нормальный такой рассадник любителей пожрать легаси говно. Как там Next 13 поживает? Уже production ready? Или еще нет?

{#each items as item, i (item.id)}
  • {i}
  • {/each}

    Відчуваю, що цю бібліотеку писали пхпшники.

    Этот фреймворк не для прод решения. Поиграться, попробовать ради интереса можно, но на прод категорически нет. Он очень хайповался на различных ресурсах, но потом вы с трудом найдете фронтендщика на поддержку свелте, т.к. на популярные типа ангуляра и реакта найти намного проще человека. Плюс куча готовых компонентов, вылизанных и обкатанных годами. Что есть под свелте — так практически ничего, только куча кишащих багами сырого тулинга, в которых вы потом будее копаться за счёт своего рабочего времени на таску. Вы будете эти же самые компоненты писать с 0, очень наврядли инвесторы обрадуются значительным расходам на переписывание готовых решений ради хайпа.Заканчивается это как обычно, выпиливанием редкосортного гуано, и использованием решений, обкатанных и вылизанных годами. Вспомните хайп на nosql и node.js, как php, java, mysql и т.д. спускались в унитаз и катающиеся по офису хипстеры на гироскутерах с пеной со рта настаивали, что весь проект теперь должен быть на ноде с монгодб, а заканчивалось мучительными проблемами с тоннами коллбеков и всеми сопутстсвующими проблемами sql vs nosql

    я писав на svelte рік. навіть написав плагін для еслінта підтримки кастомних правил для свелт (github.com/...​las/eslint-plugin-svelte3).

    Свелт підходить тільки для маленьких пет прожектів, де немає стабільності, купа багів в тулінгу, або сирий тулінг, і де купа магії, яку все-одно треба розбирати на атоми щоб не було багів. Ком’юніті близька до відсутнього, опенсорц тулів дуже мало, треба багато велосипедів робити. Пропрацювавши так довго на свелт, мені просто хочеться самому написати рендерер до реакту на веб компоненти і забути про свелт як страшний сон.

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

    этот фреймворк активно пиарился хайповался на различных ресурсах, но так и не взлетел. реакт, ангуляр или реже вью + тайпскрипт этого хватает для любого сложного фронта, остальные костыльные фреймворки не нужны или чисто покрутить на пет-проектах. Ценность фреймворка не в размерах и в компонентах и расширяемости.400 кб экономии места могут вылиться месяцами на разработку, допиливание и тестирование компонентов, а если перевести на зарплату и темпы развития продукта, то будут вообще дикие цифры. Даже если взять розетку, у нее фронт на ангуляре и все с СЕО хорошо, и грузится быстро

    ...а если важна экономия на размере бандла и прочий light-*, то например есть React совместимые Preact и Inferno.

    Использовал когда-то Riot.js — он вообще может обходиться без предварительной сборки, при этом компактный.

    Рази три перечитав цей пост, але так до кінця і не зрозумів, що такого у Svelte.

    Якщо ви дивитесь на фронтенд фреймворки як на шаблонізатори, то раджу подивитись на vue + pug + sass/stylus + suit. Тут мав би бути приклад коду, але з ним в мене форма відповіді зависає, тож погугліть десь приклади.

    Вбудований стор — це круто, але ваш приклад коду нічого окрім вбудованого стору та найпростіших операцій не показує. Я б подивися на те, як із ним працювати, коли у вас запити до сервера йдуть через його АБІ або Граф з купою полів, а потім все це ще й обробляти якось, додавати коефіцієнти з іншого запиту тощо.

    Стосовно купи прихованих дрібниць: а що, якщо вони вам не потрібні, вони вимикаються через конфіги чи ні? Наприклад, бізнес передбачає перекидання навантаження на клієнта та не має на меті індексації пошуковими роботами.

    Я так розумію, що SvelteKit — це щось на кшталт Next, Vita та CRA в порівнянні з React? Так?

    i.imgur.com/V7qG1H9.png

    Может кто обьяснить что происходит справа?
    Мне тут подсказали что это label:
    Но нет ни continue $ ни break $
    В чем смысл?

    це цукор який робить 2 way data binding для кложури, або змінної.

    пс піду проблююсь

    Як не крути, JSX(TSX) — це прорив.

    Не зовсім зрозумів, у чому тут прорив?
    JSP у Java ще з 1998 року дозволяла змішувати HTML, JavaScript та Java код у JSP-сторінках. Спочатку здалося, що це круто та додає Java динамічності.
    А за підсумком це призвело до того, що JSP-сторінки перетворилися на такий шмат спагетті-коду, що розібратися в них стало дуже складно.
    А все тому, що є MVC патерн і не варто змішувати логіку, уявлення і модель.

    Я не мега спеціаліст по фронту, але перепробувавши всі топові фреймворки в проді (крім Svelte), можу сказати що найкраще в плані читабельності/простоти/зрозумілості — це Vue 3 (script setup + composition API).
    Це звісно ж моя дуже суб’єктивна оцінка + в кривих руках все буде погано.

    Маск колись дуже доречну фразу сказав.
    Або робіть технологію в 100 раз краще, або йдіть нахрін.

    Ви бачите тут щось в 100 раз краще ?

    // React:
    
      {items.map((item, i) => 
        <li key={item.id}>{i}</li>
      )}
    
    // Svelte:
      {#each items as item, i (item.id)}
        <li>{i}</li>
      {/each}
    

    І я ні. Двері там.

    Ідея Svelte у маленькому бандлі, а не у якомусь більш зручному синтаксисі. Тому це саме та ситуація де вибирають інструмент під задачу.

    Чесно, не розумію цієї ідеї. Бандл СИЛЬНО меншим не буде, JS є JS. А через якесь зменшення на долю відсотків перевчатися на тупо нову технологію... Не дарма з фронтендерів насміхаються. Розвиток й різноманітність це звичайно круто, але імхо іноді цього прям занадто.

    Бо потім при пошуку роботи дивишся на вакансії, а там Senior Svelte/React/Vue/Angular Developer. І от ти наче і Senior, але при цьому ти ще і людина, яка має життя поза зоопарком, тож всіх нюансів кожного з ліб/фреймворків не знаєш, а інтерв’юверу по***, йому важливо щоб ти знав кожен хук в реакті.

    У тому то і річ що у разі Svelte бандл буде набагато менший.
    Простий приклад. Одна і та ж сторінка (вже з броттлі)
    — з angular — 585 kb
    — з svelte — 111 kb
    Різниця суттєва, як на мене.
    І це досить навантажене місце усілякими віджетами та іншими функціональностями. У простішому випадку буде ще менше.

    Перевчатися зовсім непотрібно. Все що треба це бути frontend інженером, а не framework name розробником.

    Без наїзду, але ви ще зрівняйте JS з C++ по швидкості. Svelte це альтернатива React, або навіть скоріше Vue, але точно не Angular. І там вже різниця по цифрах мінімальна. А якщо ще й правильно все зробити, то взагалі не важливо який фреймворк, швидко й «легко» буде навіть з Angular. А гнатись за зайвими 100кб економії — ви що, Амазон? Чи Гугл? Вам ті 0.2s принесуть тільки збитки на час розробки. Пак іконок більше займає, краще його оптимізуйте.

    Перевчатися зовсім непотрібно

    Тенденції такі, що рік-другий попрацюєш на чомусь одному, і геть втратиш пульс по другому. У мене три роки досвіду React, але три роки тому, тому зараз я інтерв’ю на одне з 80% вакансій на фронтенд (Senior React Developer) просто не пройду без підготовки. Бо наче ж JS всюди JS, але кожен хук знай, кожен lifecycle і його нюанс знай, кожну стору знай, кожен роутер знай, і тд і тп. А при цьому компаній, де потрібен саме першокласний інженер, з якого про фреймворк взагалі нічого запитувати не будуть, я можу порахувати на пальцях однієї руки, а саме головне — я не такий крутий, як і 95% інших розробників.

    Svelte, це альтернатива будь-якому фреймворку з великої трійки.
    Ні з Реактом, а ні з Ангуларом швидко й легко не буде. Що перший, що інший тягнуть за собою здоровенний бандл, який качає, парсить, а потім ще виконує браузер. Все це впливає на метрики PageSpeed Insights, а ті вже на SEO.

    Щодо паку іконок. Пак іконок не треба парсити, та виконувати. Він не має етапу ініціалізації. Тому пак іконок не можна порівнювати із Javascript.

    Другий абзац, я не зрозумів. Ви працювали 3 роки, та не цікавилися тим що відбувається в галузі?

    Я не казав про вакансії де шукають першокласного інженера. Просто якщо розумієш основні концепти, то можна хоч трохи цікавитись тим що відбувається довкола й бути в темі. Я от на Реакті не пишу, але прекрасно знаю про хуки, контексти, реконцеляцію та таке інше.

    Все це впливає на метрики PageSpeed Insights

    Якби інші фреймворки апріорі завжди мали погані оцінки, вони б довго не проіснували :) Але навіть якщо так, і Svelte справді кращий на декілька балів — імхо, це точно не привід йти його вчити. Але кожен робить що хоче.

    Тому пак іконок не можна порівнювати із Javascript.

    А чому ні? Я казав про розміри, що краще зайнятися оптимізацією завантаження іконок для економії розміру. Щодо ініціалізації та парсингу, ви так кажете, ніби велика трійка тягне по декілька МБ коду. Суть в тому, що якщо Vue/React тягнуть по 40КБ, а Svelte 4KБ (тобто по факту ці КБ просто розкидані по коду), то ці 35КБ різниці не зіграють, бо далі вступають ваші 300КБ коду, 200КБ стилів, 100КБ хтмл, і чорт зна скільки всього іншого (і саме над цим треба паритись). Далі, ось вам порівняння перфомансу (виберіть vue, react & svelte only), і я не бачу жодної причини чому я повинен обрати Svelte. В деяких цифрах Svelte виграє, але судячи по бенчмарку, virtual scroll для таблиці вирішить цю проблему, тож знову ми впираємось в деталь реалізації, а не технологію.

    Другий абзац, я не зрозумів. Ви працювали 3 роки, та не цікавилися тим що відбувається в галузі?

    1. Коли я працюю, то я працюю, а коли я відпочиваю, то не зачитуюсь речами з роботи. Я не ентузіаст. Звичайно деякими речами я цікавлюся, і прекрасно знаю що таке хуки, контексти й реконцеляція (знову термін, на який я би сказав хз, а по факту банальщина). Але на співбесіді мені це не допомогло, бо типовий Senior React Developer повинен обов’язково знати як саме називаються DOM евенти в React, бо це ж бляга капець як важливо (звичайно ні). Тому так і виходить, що фундамент знаєш, і знаєш прекрасно (бо у Vue хуки це також нова реальність, хоч благо і є опція залишатись на options api), але Senior Framework Developer ти точно не будеш, якщо окрім свого фуллтайму не будеш робити пет-проекти на всих фреймворках (що перетікає в пункт два).
    2. Чисто особливість самого мене — навіть якщо я за щось поцікавився, розібрався й зрозумів, і наче запам’ятав, але потім не використовував хочаб з пару місяців, я це геть забуваю. Типу прям зовсім. Тож концепти я знаю, а їх назви і подавно ні. Це як працювати за принципами SOLID, але взагалі дупля не давати що таке SOLID (мій кейс).

    Якби інші фреймворки апріорі завжди мали погані оцінки, вони б довго не проіснували

    Вони їх і мають. В них інша задача. А ні, SSR, а ні різні оптимізації, на які до речі ви витратите багато часу проблему не рішать.

    і Svelte справді кращий на декілька балів

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

    йти його вчити

    Для досвідченого розробника там майже нема чого вчити

    ніби велика трійка тягне по декілька МБ коду

    Не завжди прям МБ, але тягне прям багато. Треба постійно оптимізувати, щоб не було такого.

    То, що той React, просто маленька бібліотека, це просто маркетинг. Думаю ви прекрасно уявляєте скільки потім ще пакетів треба встановити для реалізації фіч.

    порівняння перфомансу
    virtual scroll

    То усьо перфоманс у рантаймі, воно дуже опосередковане відношення має до PageSpeed Insights.

    прекрасно знаю що таке хуки, контексти й реконцеляція

    То що ви це знаєте, то очевидно, я і не мав іншого на увазі.

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

    Як що ви уважно прочитаєте те, що написано перед цим прикладом коду, то зрозумієте, що це приклад не про зручність, а про те, що синтаксис JSX не дуже відрізняється.

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

    Коли я починав, нічого подібного не було, тому я після першого ж проекту написав свій і досі його використовую. Але на скільки мені відомо, є такі непагані штуки як svelteui, headlessui та pico

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

    Повністю підтримую. Бутстрап для vue/react досі гівно на 50% (по відгукам знайомих), а його пиляють вже з 5 років. Не говорю вже про інші. Тільки Tailwind наче ок, але це ж просто CSS, без JS компонентів.

    Так це просто не Svelte кейс.

    Якщо там якась монструозна таблиця, то там напевно й CRM система якась. З таким велика трійка прекрасно впорається.

    Так це просто не Svelte кейс.

    Ну то есть, когда на проекте понадобится продвинутый грид (это происходит сразу в 99.99 % случаев), я буду стоять как идиот отчитываться за ранее продавленное мною решение использовать свелте на проекте. И теперь, видите ли, команда будет писать каличную таблицу с нуля в течении 3 месяцев, а потом окажется что оно все плывет под мобильными устройствами.

    Ні.
    Якщо вашому проєкту буде потрібна SEO індексація і там не буде достатньо просто vanilla js, то ви можете написати це на Svelte.

    А CRM де гріди й усе таке, будете писати на React/Angular/Vue.

    Я от за це кажу.

    Таки це було б варто згадувати одразу, як у подібних статтях, так і на сайті самого Svelte.

    Svelte compiles your code to tiny, framework-less vanilla JS — your app starts fast and stays fast.

    Текст з головної сторінки.

    як у подібних статтях

    Думаю він просто не розібрався. В нього ж і REPL свелтівський зроблений на кшталт codesandbox, хоча база там від stackblitz.

    Я мав на увазі загальний однаковий сенс таких сервісів як codesandbox, jsfiddle, codepen і т.і.

    Просунутий грід тна Svelte пишеться за день-два однією людиною. Це майже те саме, що написати на чистому js, але набагато швидше і зручніше.

    mui.com/x/react-data-grid
    Если за полгода в одиночку напишешь такого же качества, то будешь гением.

    . Це майже те саме, що написати на чистому js

    Ты хоть элементарно представляешь объем работы впихнутый в datatables.net ?

    Деланье свистоплясных гридов аля DevExpress/ExtJs — это мовитон уже.

    Не, вообще впихивание их на страницу. Ну мне так кажется.

    Вот такое типа лепить :)
    i0.wp.com/...​.png?resize=750,456&ssl=1

    То что на скрине, отдает скорее десктопом эры вижуал бейсика. В какой-то степени я понимаю, о чем ты. Сейчас заходишь например в историю заказов пиццы, а там даже оно таблицу не оформлено, тупо нельзя даже отсортировать по дате заказа — нужно листать пагинатор. Но у меня например на проекте с огромным доменом, что не экран так здоровая таблица с по 50 колонок с кучей функциональности, фильтраций, подтаблицами итд. И я даже не могу представить как это организовать по другому.

    Нє ну це від того, що обʼєм інформації великий, а місця мало. Як ще таке впихнути на один екран.

    Не бачу тут нічого складного, серйозно. З іншого боку зараз є непагані рішення вузької спеціалізації, наприклад github.com/...​ee/master/packages/svelte. Зазвичай в мене на проектах тких плагінів не більше п’яти. Тобто працювати можна.

    count.subscribe(value => {
    console.log(value);
    });

    Не бреши нам ангуларщик

    мені б дуже не хотілося б повертатися до знарядь кам’яного віку

    Мені теж, працюй плз на своєму свєтле — мені більше грошей на реакті дістанеться.

    Був нормальний синтаксис з нативного джаваскрипта (.map()) яку замінили інородним сміттям
    {#each items as item, i (item.id)}
    яке навіть парсер доу не схавав, каменярі -_-

    DOU використовує для підсвітки коду у статтях highlightjs.org у якого відсутня підтримка JSX та Svelte highlightjs.org/static/demo

    У мене в очах теж немає підтримки тієї писанини, а сподіваюсь що ніколи не буде :)

    сініор реакт девелопер, ага

    Чесно, як людина яка працює тільки з JS, тільки повтикавши з хвилину я зрозумів що означає «i (item.id)». Може це десь з інших мов взято, але це ж гівно підхід так робити. Без прикладу з коду react я б напевно в прицнипі і не зрозумів.

    Svelte — нова дійсність

    Ліл. А що хайп на нього не пройшов 1-2 роки тому?

    це не про хайп. Скоріше про його відсутність)

    Або майбутнє фронтенду на Yew

    Підписатись на коментарі