Krąży wiele żartów po sieci, że prawie codziennie powstaje nowy framework JS. Mamy już święta trójce współczesnego frontendu; Reacta, Angular i Vue oraz wiele wiele innych.
Do grona najlepszych ma zamiar dołączyć Svelte.js jednak w przeciwieństwie do Reacta, svelte.js nie używa techniki podmiany prawdziwego DOM z tym wirtualnym a metody kompilacji możliwych zmian w aplikacji o wstrzykiwaniu go bezpośrednio do kodu strony podczas budowy aplikacji.
Twórcy svelte.js przekonują, że używanie metody wirtualnego DOMu jest nie efektywne oraz wręcz nie potrzebne.
Więc ... czy wirtualny DOM jest wolny?
„Wirtualny DOM jest zwykle wystarczająco szybki”, ale z pewnymi zastrzeżeniami.
Tradycyjne frameworki umożliwiają pisanie deklaratywnego kodu sterowanego stanem, ale istnieje kara: przeglądarka musi wykonać dodatkową pracę, aby przekonwertować te deklaratywne struktury na operacje DOM, wykorzystując tzw Virtual DOM
Oryginalną obietnicą React'a było to, że mogłeś ponownie wy-renderować całą aplikację przy każdej zmianie stanu bez obawy o wydajność. Gdyby tak jednak było, nie byłoby potrzeby takich optymalizacji, jak shouldComponentUpdate albo pureComponent. Nawet w przypadku shouldComponentUpdate aktualizowanie wirtualnego DOM całej aplikacji za jednym razem to dużo pracy. Jakiś czas temu zespół React'owy wprowadził React Fibre, które pozwala podzielić aktualizację na mniejsze części. Oznacza to (między innymi), że aktualizacje nie blokują głównego wątku (main thread) przez długi czas, chociaż nie zmniejsza to całkowitej ilości pracy ani czasu potrzebnego na aktualizację prawdziwego DOMu
Zamiast tego Svelte działa podczas kompilacji, przekształcając komponenty w wysoce wydajny kod imperatywny, który chirurgicznie aktualizuje DOM. W rezultacie możesz pisać ambitne aplikacje o doskonałych parametrach wydajnościowych.
Cybernetyczne appki webowe ?
Svelte.js używa własnego typu plików ".svelte", który przyjmuje 3 bloki kodu (style, code, html markdown, przykład poniżej). Svetle w swej ideologii chcę aby programista pisał jak najmniej kodu, gdyż to zwiększa jego czytelność, nadzór i późniejsze rewizję, zamieszczam poniżej ten sam komponent w React'cie, Vue oraz Svelte.
Svetle
<style>
p {
color: red;
}
</style>
<script>
let a = 1;
let b = 2;
</script>
<input type="number" bind:value={a}>
<input type="number" bind:value={b}>
<p>{a} + {b} = {a + b}</p>
React
export default () => {
const [a, setA] = useState(1);
const [b, setB] = useState(2);
function handleChangeA(event) {
setA(+event.target.value);
}
function handleChangeB(event) {
setB(+event.target.value);
}
return (
<div>
<input type="number" value={a} onChange={handleChangeA}/>
<input type="number" value={b} onChange={handleChangeB}/>
<p>{a} + {b} = {a + b}</p>
</div>
);
};
Vue
<template>
<div>
<input type="number" v-model.number="a">
<input type="number" v-model.number="b">
<p>{{a}} + {{b}} = {{a + b}}</p>
</div>
</template>
<script>
export default {
data: function() {
return {
a: 1,
b: 2
};
}
};
</script>
Jak widać kod "Reactowy" jest prawie 3 dłuższy. Dodatkowo według oficjalnej dokumentacji svelte, możemy zapomnieć o manualnej optymalizacji komponentów za pomocą takich funckji jak useMemo, useEffect, useCallback. Svelte ma wbudowane wszystkie rozwiązania w swój compiler.
Svelte jako compiler , który następnie pakuje swoje pliki do czystego vanilla JS, html i css, ma dość bogate wbudowane API, od bindingów danych, animacje i przejścia między komponentami, moduły odpowiadające głównym reactowym bibliotekom takim jak wbudowany store (reactowy redux lub context api jak kto woli), head (react helmet) oraz wiele innych. Sprawdź więcej na oficjalnej dokumentacji svelte w języku angielskim .
Podsumowanie
Svelte obecnie (01.11.2019) jest w swojej wersji 3.0, ale wydaje mi się, że jeszcze przed nim długa droga rozwijania samego "compilera", społeczności oraz koncepcji nie używania wirtualnego DOM'u. W testach prezentowanych przez jednego z twórcą Rich Harris, svelte pokonuje wszystkie dostępne frameworki JS zarówno pod względem rozmiaru paczki jak i samej szybkości działania aplikacji , co może się okazać kluczową sprawą podczas budowania i projektowania aplikacji na urządzenia IoT (internet of things). Na teraz nadaję się raczej do budowania prostych aplikacji i stron statycznych, niż pełno flagowych aplikacji webowych.