React 에서도 Component 를 사용하고, 당연히 Svelte 에서도 Component 를 사용한다.  
프론트엔드 프레임워크에서 가장 기본적으로 볼 수 있기 때문에 포스팅을 먼저 진행해본다.  
내가 React를 Deep 하게 해보진 않아서 모르는 걸 수도 있는데, component 를 만들고 가져다 쓴다고 하더라도 스타일이 적용되지는 않더라,  
또한 html 코드 자체를 rendering 해야 하는 경우도 있는데 이때는 **@html**이 필요하다.  

```svelte

<script>
    import Nested from "./Nested.svelte";
    let string = `this string contains some <strong>HTML!!!</strong>`;
</script>

<style>
    p {
        color: purple;
        font-family: 'Comic Sans MS', cursive;
        font-size: 2em;
    }
</style>

<p>This is a paragraph</p>
<Nested />
<p>{@html string}</p>
```

```

<p>This is another paragraph.</p>
```

<img src="aaa" />


이렇게 되면 내 생각에는 p 로 들어가기 때문에 스타일이 같이 적용될거라 생각했는데, Nested.svelte 에서 넘어온것은 먹히지 않더라  
또한 내포되는 component 는 대문자로 표기해야하는 규칙이 있다.  
주의할 것은, Svelte 는 {@html .. 안의 식을 검사하지 않기때문에, 이 기능을 사용할 경우 신뢰할 수 없는 원본의 HTML을 수동으로 escape 하는 것이 중요하다, 그렇지 않으면 사용자가 XSS 공격에 노출될 위험이 있습니다.

Nested Components


Svelte 에서 event 다루는 방법을 간단하게 알아보고 modifier 에 대해서도 알아보도록 한다.

```
<script>
function handleClick() {
  alert('clicked')
}
</script>

<button on:click={handleClick}>
  Click me
</button>
```

위의 코드는 버튼 클릭 시 마다 alert 창이 뜨게 된다.

그런데, 이를 한 번만 하고 싶은 경우가 있을 텐데, 보통은 변수로 따로 길게 처리를 진행해주어야 하는데 svelte 에서는 간단하게 처리가 가능하다.

```
<button on:click|once={handleClick}>
    Click me
</button>
```

once 를 추가하면서 딱 한번만 실행이 가능해진다, 참 여러군데 처리가 가능해보인다.

다른 modifier 에 대해서도 알아보자

-   **preventDefault**  
    핸들러 처리 전에 event.preventDefault() 를 실행해준다
-   **stopPropagation**  
    event.stopPropagation()을 호출하여 이벤트가 다음 요소에 도달하지 못하게 합니다.
-   **passive**  
    터치/휠 event 에서 스크롤 성능을 개선해준다 (Svelte 가 안전하기 추가할 수 있는 위치에 자동으로 추가 해준다)
-   **nonpassive**  
    passive 의 반대
-   **capture**  
    [버블 단계](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events#event_bubbling_and_capture) 대신 캡처 단계에서 처리기를 작동시킵니다.
-   **once**
-   **self**  
    event.target이 element 자체인 경우에만 핸들러를 트리거

Svelte 에서 event 다루는 방법을 간단하게 알아보고 modifier 에 대해서도 알아보도록 한다.

Svelte 에서 Event 그리고 modifier

Svelte Tutorial 을 하나 씩 진행 중에 있는데, Keyed each blocks 라는 부분이 있고 해당 튜토리얼에 대해 포스팅을 하고자 한다.

Svelte 에서 each 는 {#each 로 시작한다.

```
 
<script>
    import Thing from './Thing.svelte';

    let things = [
        { id: 1, color: 'darkblue' },
        { id: 2, color: 'indigo' },
        { id: 3, color: 'deeppink' },
        { id: 4, color: 'salmon' },
        { id: 5, color: 'gold' }
    ];

    function handleClick() {
        things = things.slice(1);
    }
</script>

<button on:click={handleClick}>
    Remove first thing
</button>

{#each things as thing}
    <Thing current={thing.color}/>
{/each}
```

```
<script>
    // `current` is updated whenever the prop value changes...
    export let current;

    // ...but `initial` is fixed upon initialisation
    const initial = current;
</script>

<p>
    <span style="background-color: {initial}">initial</span>
    <span style="background-color: {current}">current</span>
</p>

<style>
    span {
        display: inline-block;
        padding: 0.2em 0.5em;
        margin: 0 0.2em 0.2em 0;
        width: 4em;
        text-align: center;
        border-radius: 0.2em;
        color: white;
    }
</style>
```

이렇게 된 경우 첫 화면은 아래와 같이 구성이 된다.

![R1280x0-2](https://github.com/shinYeongHyeon/dev-blog/assets/74130738/4f32a548-bad1-4811-b28d-0caaacde7044)

여기서 버튼을 클릭하면 맨 첫번째 칸이 모두 지워질 것이라 예상했다, 그러나 결과는 달랐다.

![R1280x0-3](https://github.com/shinYeongHyeon/dev-blog/assets/74130738/e266bd8b-e497-4203-b26d-42d33ee56a23)

결과는 위와 같이 initial 은 노랑색이 사라졌고 current 는 dark blue 가 사라졌다. current 만이 우리가 원하는 방식으로 동작한 것이다. 그렇다면 initial 은 왜 이렇게 동작이 되었을까?

바로 component 가 이미 초기화가 돼있어서 그런 것인데, 이 때 컴포넌트가 변화하지 않는다고 생각하면 새로 생성하지 않는 것처럼 보인다.

Thing.svelte 에서 **const initial = current** 구문이 초기화 시에만 current 로 들어가있고, 그것은 순서대로 되어있기 때문이다. 그렇다면 우리의 의도대로 동작하게 하려면 어떻게 해야할까 ?

아이디를 심어주면 된다.

바로 each 부분에 **_#each things as thing (thing.id)_** 혹은 _**#each things as thing (thing)**_ 이렇게 작성을 해주면 component 생성시에 해당 아이디로 세팅이 되어서 해당 아이디 (키) 를 찾아서 DOM 을 변경 하는 것 같다.

혹은 조금 trick을 써서 Thing.svelte 에서 [이전 포스팅](https://shinyeonghyeon.co.kr/posts/SvelteStatement)에서 배운 $: 를 활용하여 _**$: initial = currnet;**_ 로 해주어도 해당 예제에서는 똑같이 동작은 한다.

Svelte 에서의 Keyed Each blocks


```
<script>
let count = 0;

function handleClick() {
  count += 1;
}
</script>

<button on:click={handleClick}>
  Clicked {count} {count === 1 ? 'time' : 'times'}
</button>
```

버튼을 클릭 시 마다 count 가 증가하고 그게 버튼에 반영돼 변하는 코드이다.

해당 개념은 React 던 Svelte 건 조금이라도 해보면 익숙할 것이다. 여기에서 더 나아가 count 가 변화할때마다 다른 변수가 변화하게 할 수 있다

```
<script>
let count = 0;
$: doubled = count * 2;
    
function handleClick() {
  count += 1;
}
</script>

<button on:click={handleClick}>
Clicked {count} {count === 1 ? 'time' : 'times'}
</button>
<p>{count} doubled is {doubled}</p>
```

**$:** 를 활용하면 ([신기하게도 JS에 유효한 문법이라고 한다](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label)) count 가 변경될때마다 double 도 변경되고 이에 따라 맨 아랫줄 p 도 변경이 된다. 더 나아가 뭉쳐있기도 가능하고 조건도 달 수 있다.

```
<script>
    let count = 0;
    $: doubled = count * 2;
    $: console.log(`1: the count is ${count}`);
    $: {
        console.log(`2: the count is ${count}`);
        alert(`I SAID THE COUNT IS ${count}`);
    }
    $: if (count >= 10) {
        alert(`count is dangerously high!`);
        count = 9;
    }

    function handleClick() {
        count++;
    }
</script>

<button on:click={handleClick}>
    Clicked {count} {count === 1 ? 'time' : 'times'}
</button>
<p>{count} doubled is {doubled}</p>
```

이렇게 되면 버튼이 클릭시마다 버튼이변경되고 아래 p도 변경이 되고 Console에 2개가 찍히게 되고, alert창도 뜨게 된다. 계속해서 누르다가 count 가 10이되면 "count is dangerously high!" alert창이 뜨게 되고 count 가 9로 조정되며 다시 doubled 와 콘솔 2개 "I SAID ..." alert 창이 뜨게 되는 굉장한 Reactive 한 액션이 이뤄진다 !

### Array

Svelte 의 Reactivity 는 할당(assignment)에 의해서만 이뤄지기 때문에 push / splice 같은 것에는 동작하지 않는다. 바로 아래 코드 같은 것들에는 반응하지 않는 다는 것이다.

```
<script>
let numbers = [1, 2, 3, 4];

function addNumber() {
  numbers.push(numbers.length + 1);
}

$: sum = numbers.reduce((t, n) => t + n, 0);
</script>

<p>{numbers.join(' + ')} = {sum}</p>

<button on:click={addNumber}>
  Add a number
</button>
```

addNumber() 가 동작은하지만 이것으로 Trigger 되진 않는다, 이를 해결하기 위해서는 다시 numbers 에 할당해주어야한다. 아래와 같이...

```
function addNumber() {
  numbers = [...numbers, numbers.length + 1];
}
```


$: 그리고 Statement


## **Truly reactive**

Svelte 에 대해서 알아보도록 하기 위해 [공식 문서](https://svelte.dev/blog/svelte-3-rethinking-reactivity)를 번역해보도록 했다. (잘할 수 있을런지 모르겠다.. 오역은 따끔하게 알려주세요)

> After several months of being just days away, we are over the moon to announce the stable release of Svelte 3. This is a huge release representing hundreds of hours of work by many people in the Svelte community, including invaluable feedback from beta testers who have helped shape the design every step of the way.  
> We think you're going to love it.

우리는 Svelte 3의 Stable Release 를 발표할 것이다. 이 Release 는 Svelte 커뮤니티의 많은 사람들이 수백 시간 동안 작업한 것을 나타내는 대규모 릴리스로, 모든 단계에서 디자인을 구체화하는 데 도움을 준 베타 테스터의 귀중한 피드백을 포함합니다.  
우리는 당신이 좋아할 거라고 생각해요.

## **What is Svelte? (Svelte 가 뭐죠?)**

> Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like [virtual DOM diffing](https://den-shin.tistory.com/21) that eat into your frame budget and tax the garbage collector.  
>   
> Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.The first version of Svelte was all about [testing a hypothesis](https://svelte.dev/blog/frameworks-without-the-framework) — that a purpose-built compiler could generate rock-solid code that delivered a great user experience. The second was a small upgrade that tidied things up a bit.Version 3 is a significant overhaul. Our focus for the last five or six months has been on delivering an outstanding developer experience. It's now possible to write components with [significantly less boilerplate](https://den-shin.tistory.com/10?category=964374) than you'll find elsewhere. Try the brand new tutorial and see what we mean — if you're familiar with other frameworks we think you'll be pleasantly surprised.To make that possible we first needed to rethink the concept at the heart of modern UI frameworks: reactivity.

Svelte는 Reactor Vue와 같은 Component 프레임워크이지만 중요한 차이가 있습니다. 기존 프레임워크에서는 선언적 state-driven 코드를 작성할 수 있지만, 단점이 있습니다. 브라우저는 이러한 선언적 구조를 DOM 작업으로 변환하기 위해 추가 작업을 수행해야 합니다. [가상 DOM 분산](https://www.shinyeonghyeon.xyz/posts/VirtualDomIsOverhead)과 같은 기술을 사용하여 프레임 예산으로 전환하고 가비지 수집기에 세금을 부과합니다.  
대신 Svelte는 빌드 시 실행되어 Component 를 DOM을 직접적으로 업데이트하는 매우 효율적인 필수 코드로 변환합니다. 그 결과 우수한 성능 특성을 갖춘 야심찬 애플리케이션을 작성할 수 있습니다.    
(빌드타임에 어느 부분이 변경될지 파악하기 때문에 변경된 위치를 정확하게 아는 것)

Svelte의 첫 버전은 특별한 목적을 가진 컴파일러가 훌륭한 사용자 경험을 제공하는 견고한 코드를 생성할 수 있다는 가설을 시험하는 것에 관한 것이었다. 두 번째는 상황을 약간 정리하는 작은 업그레이드였다.  
버전 3은 중요한 개편이다. 지난 5~6개월 동안 당사의 초점은 뛰어난 개발자 경험을 제공하는 것이었습니다. 이제 다른 곳에서 볼 수 있는 것보다 [훨씬 적은 수의 코드](https://www.shinyeonghyeon.xyz/posts/LessCode)로 구성 요소를 작성할 수 있습니다. 새로운 튜토리얼을 사용해보고 우리가 의미하는 바를 확인해 보십시오. 다른 프레임워크에 익숙하다면 깜짝 놀랄 것입니다.  
이를 가능하게 하기 위해서는 먼저 현대 UI 프레임워크의 핵심인 리액티브(reactivity)에 대한 개념을 재고해야 했습니다.  

[영상 보러 가기](https://www.youtube.com/embed/AdNJ3fydeao)

## **Moving reactivity into the language (반응형을 언어로)**

> In old Svelte, you would tell the computer that some state had changed by calling the this.set method:

예전 Svelte에선, 이것을 불러서 어떤 state가 바뀌었다고 컴퓨터에 말하곤 했다. set method

```
const { count } = this.get();
this.set({
  count: count + 1
});
```

> That would cause the component to react. Speaking of which, this.set is almost identical to the this.setState method used in classical (pre-hooks) React:

그러면 component 가 반응할 수 있습니다. 말 나온 김에 this.set은 Class React (사전 후크)에 사용되는 this.setState method와 거의 동일합니다.

```
const { count } = this.state;
this.setState({
  count: count + 1
});
```

> There are some important technical differences (as I explain in the video above, React is not reactive) but conceptually it's the same thing.  
>   
> That all changed with the advent of [hooks](https://reactjs.org/docs/hooks-intro.html), which handle state in a very different fashion. Many frameworks started experimenting with their own implementations of hooks, but we quickly concluded it wasn't a direction we wanted to go in. Hooks have some intriguing properties, but they also involve some unnatural code and create unnecessary work for the garbage collector. For a framework that's used in [embedded devices](https://mobile.twitter.com/sveltejs/status/1088500539640418304) as well as animation-heavy interactives, that's no good.So we took a step back and asked ourselves what kind of API would work for us... and realised that the best API is no API at all. We can just use the language. Updating some count value — and all the things that depend on it — should be as simple as this:

몇 가지 중요한 기술적 차이점이 있습니다 (위의 비디오에서 설명했듯이 React는 반응적이지 않습니다). 하지만 개념적으로는 동일합니다.  
매우 다른 방식으로 state를 다루는 훅의 출현으로 많은 것이 바뀌었다. 많은 프레임워크가 자체적인 hook 구현으로 실험을 시작했지만, 우리는 빠르게 이것이 우리가 원하는 방향이 아니라는 결론을 내렸습니다. hook은 흥미로운 속성을 가지고 있지만, 그것들은 또한 부자연스러운 코드를 포함하고 가비지 수집기를 위한 불필요한 작업을 만든다. 애니메이션이 많은 상호작용뿐만 아니라 임베디드 장치에 사용되는 프레임워크는 좋지 않습니다.  
그래서 우리는 한 걸음 물러서서 우리에게 어떤 종류의 API가 좋을지 자문했습니다. 최고의 API가 전혀 없다는 것을 깨달았습니다. 우린 그냥 이 언어를 사용할 수 있어. 일부 카운트 값과 이에 의존하는 모든 항목을 업데이트하는 작업은 다음과 같이 간단해야 합니다.

```
count += 1;
```

> Since we're a compiler, we can do that by instrumenting assignments behind the scenes:

컴파일러이기 때문에 백그라운드에서 할당을 계산하여 이러한 작업을 수행할 수 있습니다.

```
count += 1; $$invalidate('count', count);
```

> Importantly, we can do all this without the overhead and complexity of using proxies or accessors. It's just a variable.

중요한 것은, 프록시나 접근자를 사용하는 데 따른 오버헤드와 복잡성 없이 이 모든 것을 수행할 수 있다는 것입니다. 단지 변수일 뿐입니다.

## **New look (새로운 것)**

> Your components aren't the only thing that's getting a facelift. Svelte itself has a completely new look and feel, thanks to the amazing design work of [Achim Vedam](https://vedam.de/) who created our new logo and website, which has moved from [svelte.technology](https://svelte.technology/) to [svelte.dev](https://svelte.dev/).  
>   
> We've also changed our tagline, from 'The magical disappearing UI framework' to 'Cybernetically enhanced web apps'. Svelte has many aspects — outstanding performance, small bundles, accessibility, built-in style encapsulation, declarative transitions, ease of use, the fact that it's a compiler, etc — that focusing on any one of them feels like an injustice to the others. 'Cybernetically enhanced' is designed to instead evoke Svelte's overarching philosophy that our tools should work as intelligent extensions of ourselves — hopefully with a retro, William Gibson-esque twist.

component 만이 아닙니다. Svelte 자체가 완전히 새로운 모습과 느낌을 갖게 된 것은  Svelte.technology 에서 Svelte.dev 로 옮겨온 우리의 새로운 로고와 웹사이트를 만든 Achim Vedam 의 놀라운 디자인 덕분이다.  
또한 태그라인을 '마법적으로 사라지는 UI 프레임워크'에서 '사이버넷적으로 강화된 웹 앱'으로 변경했습니다. Svelte는 뛰어난 성능, 작은 번들, 접근성, 내장된 스타일 캡슐화, 선언적 전환, 사용 편의성, 컴파일러라는 사실 등 여러 측면을 가지고 있습니다. 이 중 하나에만 집중하는 것은 다른 것들에게 불공평하게 느껴집니다. '사이버네틱적으로 향상된'은 대신 우리의 도구가 우리 자신의 지능적인 확장으로 작동해야 한다는 Svelte의 지배적인 철학을 환기시키기 위해 고안되었다 - 바라건대 복고풍인 윌리엄 깁슨-에스크의 트위스트와 함께.  

## **Upgrading from version 2 (Versioin 2에서의 업그레이드)**

> If you're an existing Svelte 2 user, I'm afraid there is going to be some manual upgrading involved. In the coming days we'll release a migration guide and an updated version of [svelte-upgrade](https://github.com/sveltejs/svelte-upgrade) which will do the best it can to automate the process, but this is a significant change and not everything can be handled automatically.  
>   
> We don't take this lightly: hopefully once you've experienced Svelte 3 you'll understand why we felt it was necessary to break with the past.

만약 아직 Svelte2 사용자라면 수동 업그레이드가 필요합니다. 향후 며칠간 프로세스를 자동화하는데 최선을 다하는 마이그레이션 가이드와 최신 버전의 [Svelte-Upgarde](https://github.com/sveltejs/svelte-upgrade)를 출시할 예정입니다. 이는 중요한 변경사항이나 모든 것을 자동으로 처리 할 수 있는 것은 아닙니다.  
우리는 이것을 가볍게 여기지 않는다: 일단 여러분이 Svelte 3를 경험하고 나면 여러분은 우리가 왜 과거와 단절하는 것이 필요하다고 느꼈는지 이해할 수 있을 것이다.

## **Still to come (아직 멀었습니다)**

> As grueling as this release has been, we're nowhere near finished. We have a ton of ideas for generating smarter, more compact code, and a long feature wish-list. [Sapper](https://sapper.svelte.dev/), our Next.js-style app framework, is still in the middle of being updated to use Svelte 3. The [Svelte Native](https://svelte-native.technology/) community project, which allows you to write Android and iOS apps in Svelte, is making solid progress but deserves more complete support from core. We don't yet have the bounty of editor extensions, syntax highlighters, component kits, devtools and so on that other frameworks have, and we should fix that. We really want to add first-class TypeScript support.But in the meantime we think Svelte 3 is the best way to build web apps yet. Take an hour to go through the [tutorial](https://svelte.dev/tutorial) and we hope to convince you of the same. Either way, we'd love to see you in our [Discord chatroom](https://svelte.dev/chat) and on [GitHub](https://github.com/sveltejs/svelte) — everyone is welcome, especially you.

이번 Release가 힘들었던 만큼, 우리는 거의 끝나갈 것 같지가 않다. 우리는 더 스마트하고, 더 컴팩트한 코드와, 긴 feature 위시리스트를 만들 수 있는 수많은 아이디어를 가지고 있다. Next.js 스타일의 앱 프레임워크인 [Sapper](https://sapper.svelte.dev/)는 Svelte 3을 사용하도록 업데이트되고 있다. Svelte에서 안드로이드와 iOS 앱을 쓸 수 있는 [Svelte Native](https://svelte-native.technology/) 커뮤니티 프로젝트가 탄탄하게 진행되고 있고, 핵심의 더 완벽한 지원을 받을 만하다. 우리는 다른 프레임워크가 가지고 있는 편집기 확장, 구문 강조 표시기, 컴포넌트 키트, 개발 도구 등의 혜택을 아직 받지 못했으며, 우리는 그것을 수정해야 한다. 우리는 정말로 최고의 TypeScript 지원을 추가하고 싶습니다.

하지만 그 동안 우리는 Svelte 3가 웹 앱을 구축하는 가장 좋은 방법이라고 생각합니다. 튜토리얼을 진행하는 데 한 시간이 걸리며, 우리도 당신에게 같은 것을 납득시키기를 바랍니다. Discord 와 깃허브에서 뵙고 싶습니다. 모든 분들, 특히 여러분을 환영합니다.

Svelte 공식문석 번역 : Truly reactive

(번역/의역) 진짜 반응형


Svelte 에 대해서 알아보도록 하기 위해 [공식 문서](https://svelte.dev/blog/virtual-dom-is-pure-overhead)를 번역해보도록 했다. (잘할 수 있을런지 모르겠다.. 오역은 따끔하게 알려주세요)

## **No virtual DOM**

> Let's retire the 'virtual DOM is fast' myth once and for all

'가상 DOM은 빠르다'라는 오해를 완전히 없애자.

> If you've used JavaScript frameworks in the last few years, you've probably heard the phrase 'the virtual DOM is fast', often said to mean that it's faster than the realDOM. It's a surprisingly resilient meme — for example people have asked how Svelte can be fast when it doesn't use a virtual DOM.  
>   
> It's time to take a closer look.  

자바스크립트 프레임워크를 지난 몇 년간 이용해왔다면, 아마 '가상 DOM 은 빠르다' 라고 익히 들어 왔을 테고, 이는 실제 DOM 보다는 빠르다는 의미이다. 이건 놀랍게도 탄력적인 밈입니다. 예를 들어, Svelte 가 가상 DOM 을 사용하지 않을 때 얼마나 빠를 수 있는 지 물었습니다.

자세히 살펴 볼 시간입니다.

## **What is the virtual DOM? (가상 DOM 이란?)**

> In many frameworks, you build an app by creating render() functions, like this simple [React](https://reactjs.org/) component:

많은 프레임워크에서 render() 함수를 이용해 앱을 만들 겁니다, 바로 이 간단한 React component 처럼요.

```
function HelloMessage(props) {
  return (
    <div className="greeting">
      Hello {props.name}
    </div>
  );
}
```

> You can do the same thing without JSX...

JSX 없이 똑같은 것은 이렇게 하죠.

```
function HelloMessage(props) {
  return React.createElement(
    'div',
    { className: 'greeting' },
    'Hello ',
    props.name
  );
}
```

> ...but the result is the same — an object representing how the page should now look. That object is the virtual DOM. Every time your app's state updates (for example when the name prop changes), you create a new one. The framework's job is to reconcile the new one against the old one, to figure out what changes are necessary and apply them to the real DOM.

페이지가 어떻게 보일지 나타내는 이 Object는 같습니다. 이 Object 는 Virtual DOM 이죠. 앱의 state가 업데이트 될 때마다 (예 : 이름 소품이 변경 될 때) 새 항목을 만듭니다. 프레임 워크의 역할은 새로운 것을 이전 버전과 비교하여 필요한 변경 사항을 파악하고 실제 DOM에 적용하는 것입니다

## **How did the mem start? (이 밈은 어떻게 시작됐는지?)**

> Misunderstood claims about virtual DOM performance date back to the launch of React. In [Rethinking Best Practices](https://www.youtube.com/watch?v=x7cQ3mrcKaY), a seminal 2013 talk by former React core team member Pete Hunt, we learned the following:  
> This is actually extremely fast, primarily because most DOM operations tend to be slow.  
> There's been a lot of performance work on the DOM, but most DOM operations tend to drop frames.  

가상 DOM 성능에 대한 오해는 React 출시로 거슬러 올라갑니다. Rethinking Best Practices의 전 React 핵심 팀원 Pete Hunt의 2013 년 대담에서 우리는 알았죠.

    _대부분의 DOM 작업이 느린 경향이 있기 때문에. 이것(가상돔)은 매우 빠릅니다._

    _DOM에 대한 많은 성능 작업이 있었지만 대부분의 DOM 작업은 프레임을 삭제하는 경향이 있습니다_

[##_Image|kage@cKtHB2/btqVcro8IxM/4DgaMUKibO9ovMTlxEL1OK/img.jpg|CDM|1.3|{"originWidth":1600,"originHeight":885,"style":"alignCenter","mobileStyle":"widthContent","width":513,"height":null,"caption":"Rethinking Best Practices at JSConfEU 2013","filename":"rethinking-best-practices.jpg"}_##]

> But hang on a minute! The virtual DOM operations are in addition to the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no-one actually does:

잠깐만요, 가상 DOM 작업은 실제 DOM 최종작업에 추가 됩니다. 더 빠를 수있는 유일한 방법은 효율성이 떨어지는 프레임 워크와 비교하거나 (2013 년에 돌아볼 것이 많았습니다!), 아무것도 실제로하지 않는 일을하는 것입니다. :

```
onEveryStateChange(() => {
  document.body.innerHTML = renderMyApp();
});
```

> Pete clarifies soon after...  
>   
>     React is not magic. Just like you can drop into assembler with C and beat the C compiler, you can drop into raw DOM operations and DOM API calls and beat React if you wanted to. However, using C or Java or JavaScript is an order of magnitude performance improvement because you don't have to worry...about the specifics of the platform. With React you can build applications without even thinking about performance and the default state is fast.  
>   
> ...but that's not the part that stuck.  

Pete는 곧 명확히 ...

    리액트는 마법이 아닙니다. C와 함께 어셈블러로 들어가서 C 컴파일러를 이길 수 있는 것처럼, 원시 DOM 작업 및 DOM API 호출로 이동하여 React를 누르고 싶을 때 React를 실행할 수 있습니다. 그러나 플랫폼의 세부 사항에 대해 걱정할 필요가 없으므로 C 또는 Java 또는 JavaScript를 사용하는 것이 성능 향상의 한 단계입니다. React를 사용하면 성능에 대한 생각도 없이 애플리케이션을 구축할 수 있으며 기본 상태는 빠릅니다.

그러나 이 부분이 고착화된건 아니죠.

## **So... is the virtual DOM slow? (그래서,, 가상 DOM은 느린가?)**

> Not exactly. It's more like 'the virtual DOM is usually fast enough', but with certain caveats.  
>   
> The original promise of React was that you could re-render your entire app on every single state change without worrying about performance. In practice, I don't think that's turned out to be accurate. If it was, there'd be no need for optimisations like _shouldComponentUpdate_ (which is a way of telling React when it can safely skip a component).  
>   
> Even with shouldComponentUpdate, updating your entire app's virtual DOM in one go is a lot of work. A while back, the React team introduced something called React Fiber which allows the update to be broken into smaller chunks. This means (among other things) that updates don't block the main thread for long periods of time, though it doesn't reduce the total amount of work or the time an update takes.  

꼭 그렇진 않아요. 이는 '가상 DOM은 일반적으로 충분히 빠릅니다'에 가깝지만, 특정 주의 사항을 따릅니다.

React는 원래 성능에 대한 걱정 없이 state 변경 시마다 전체 앱을 다시 렌더링할 수 있다는 것이었습니다. 실제로는 그게 정확하지 않은 것 같아요. 그렇다면 구성 요소를 안전하게 건너뛸 수 있을 때 React에게 알리는 방법인 _shouldComponentUpdate_ 와 같은 최적화 작업은 필요하지 않을 것입니다.

shouldComponentUpdate를 해야 하는 경우에도 전체 앱의 가상 DOM을 한 번에 업데이트하는 것은 많은 작업입니다. 얼마 전, 리액트 팀은 업데이트를 더 작은 덩어리로 나눌 수 있는 React Fiber라는 것을 소개했습니다. 즉, 업데이트 시 전체 작업량이나 업데이트 소요 시간은 줄지 않지만 업데이트 시 주 스레드가 장기간 차단되지는 않죠.

## **Where does the overhead come from? (overhead는 어디에서 오는가)**

> Most obviously, [diffing isn't free](https://twitter.com/pcwalton/status/1015694528857047040). You can't apply changes to the real DOM without first comparing the new virtual DOM with the previous snapshot. To take the earlier HelloMessage example, suppose the name prop changed from 'world' to 'everybody'.

가장 분명한 것은, 재조정 것은 공짜가 아닙니다. 먼저 새 가상 DOM을 이전 스냅샷과 비교하지 않고는 실제 DOM에 변경 사항을 적용할 수 없습니다. 이전의 Hello Message 예를 들어, 'world'에서 '모든 사람'으로 이름 속성이 변경되었다고 가정해 보십시오.

> Both snapshots contain a single element. In both cases it's a <div>, which means we can keep the same DOM node  
> 2\. We enumerate all the attributes on the old <div> and the new one to see if any need to be changed, added or removed. In both      cases we have a single attribute — a className with a value of "greeting"  
> 3\. Descending into the element, we see that the text has changed, so we'll need to update the real DOM

1.  두 스냅샷 모두 단일 엘리먼트를 포함합니다. 두 경우 모두 <div>입니다. 즉, 동일한 DOM 노드를 유지할 수 있습니다.
2.  변경, 추가 또는 제거가 필요한지 확인하기 위해 이전 <div>와 새 <div>의 모든 속성을 열거합니다. 두 경우 모두 "greeting" className이 있습니다.
3.  요소를 확인하면 텍스트가 변경되었음을 알 수 있으므로 실제 DOM을 업데이트해야 합니다.

> Of these three steps, only the third has value in this case, since — as is the case in the vast majority of updates — the basic structure of the app is unchanged. It would be much more efficient if we could skip straight to step 3:

대부분의 업데이트에서와 같이 앱의 기본 구조는 변경되지 않으므로 이 세 단계 중 세 번째 단계만 이 경우에 가치가 있습니다. 3단계로 바로 건너뛸 수 있다면 훨씬 효율적일 것입니다.

```
if (changed.name) {
  text.data = name;
}
```

> (This is almost exactly the update code that Svelte generates. Unlike traditional UI frameworks, Svelte is a compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time.)

이 코드는 스벨트가 생성하는 업데이트 코드와 거의 동일합니다. 기존 UI 프레임워크와 달리 Svelte는 런타임에 작업을 대기하지 않고 빌드 시 앱의 상황이 어떻게 변할 수 있는지 알고 있는 컴파일러입니다.)

## **It's not just the diffing though (어려운 것은 아니다)**

> The diffing algorithms used by React and other virtual DOM frameworks are fast. Arguably, the greater overhead is in the components themselves. You wouldn't write code like this...  

React와 다른 가상 DOM 프레임워크에서 사용되는 분산 알고리즘은 빠릅니다. 의심할 여지 없이, 더 큰 오버헤드는 component 자체에 있습니다. 이런 식으로 코드를 쓰면 안 됩니다...

```
function StrawManComponent(props) {
  const value = expensivelyCalculateValue(props.foo);

  return (
    <p>the value is {value}</p>
  );
}
```

> ...because you'd be carelessly recalculating value on every update, regardless of whether props.foo had changed. But it's extremely common to do unnecessary computation and allocation in ways that seem much more benign:

value에 대한 모든 업데이트를 속성(props)에 관계없이 신중하게 재계산할 수 있기 때문입니다. foo는 변했다. 그러나 불필요한 계산과 할당을 훨씬 더 온화해 보이는 방식으로 수행하는 것이 매우 일반적입니다.

```
function MoreRealisticComponent(props) {
  const [selected, setSelected] = useState(null);

  return (
    <div>
      <p>Selected {selected ? selected.name : 'nothing'}</p>

      <ul>
        {props.items.map(item =>
          <li>
            <button onClick={() => setSelected(item)}>
              {item.name}
            </button>
          </li>
        )}
      </ul>
    </div>
  );
}
```

> Here, we're generating a new array of virtual <li> elements — each with their own inline event handler — on every state change, regardless of whether props.items has changed. Unless you're unhealthily obsessed with performance, you're not going to optimise  
> that. There's no point. It's plenty fast enough. But you know what would be even faster? Not doing that.  
>   
> The danger of defaulting to doing unnecessary work, even if that work is trivial, is that your app will eventually succumb to 'death by a thousand cuts' with no clear bottleneck to aim at once it's time to optimise.
> 
> Svelte is explicitly designed to prevent you from ending up in that situation.

여기서는 속성/아이템의 변경 여부에 관계없이 모든 상태 변경 시 가상 <li> element의 새로운 배열(각각 인라인 이벤트 핸들러 포함)을 생성합니다. 성능에 집착하지 않는 한 성능을 최적화하지 못할 것입니다. 의미가 없어요. 충분히 빨라요. 하지만 뭐가 더 빠를지 아시나요? 그렇게는 안 됩니다.

작업이 사소한 것일지라도 불필요한 작업을 수행하는 것으로 디폴트할 경우 앱이 최적화해야 할 때 단번에 목표로 삼을 분명한 병목 현상 없이 결국 '능지처참 당하는 고통'에 직면하게 됩니다.

스벨트는 당신이 그런 상황에 빠지는 것을 막기 위해 명시적으로 설계되었다.

## **Why do frameworks use the virtual DOM then? (그러면 프레임워크가 가상 DOM을 사용하는 이유는 무엇입니까?)**

> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.  
>   
> But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.  

가상 DOM은 기능이 아닙니다. 이는 목적을 위한 수단이며, 선언적이고 state-driven UI 개발입니다. Virtual DOM은 state 전환에 대해 생각하지 않고도 애플리케이션을 구축할 수 있으며 일반적으로 성능이 충분하기 때문에 유용합니다. 즉, 버그 코드가 줄어들고, 지루한 작업 대신 창의적인 작업에 더 많은 시간이 소비됩니다.

하지만 가상 DOM을 사용하지 않고도 유사한 프로그래밍 모델을 얻을 수 있다는 것이 밝혀졌습니다. 바로 여기에서 Svelte가 등장합니다.

Svelte 공식문석 번역 : No virtual DOM

(번역/의역) 가상 DOM 자체가 오버헤드


Svelte 에 대해서 알아보도록 하기 위해 공식 문서를 번역해보도록 했다.  
(잘할 수 있을런지 모르겠다.. 오역은 따끔하게 알려주세요)

## Write less code

> All code is buggy. It stands to reason, therefore, that the more code you have to write the buggier your apps will be.
> Writing more code also takes more time, leaving less time for other things like optimisation, nice-to-have features, or being outdoors instead of hunched over a laptop.
> 
> In fact it's widely acknowledged that project development time and bug countgrow quadratically, not linearly, with the size of a codebase. That tracks with our intuitions: a ten-line pull request will get a level of scrutiny rarely applied to a 100-line one. And once a given module becomes too big to fit on a single screen, the cognitive effort required to understand it increases significantly. We compensate by refactoring and adding comments — activities that almost always result in morecode. It's a vicious cycle.
> 
> Yet while we obsess — rightly! — over performance numbers, bundle size and anything else we can measure, we rarely pay attention to the amount of code we're writing.

모든 코드는 버그가 있습니다. 따라서 코드가 많아 진다는 것은 더 큰 버그를 지닌 앱을 만드는 것이죠. 그리고 그건 더 많은 시간이 든다는 것이고 이렇게 되면 최적화, 좋은 기능/구조 등 다른것에 쏟을 시간이 줄어든다는 것을 의미하죠.  
  
실제로 프로젝트 개발 시간과 버그의 수는 코드베이스의 크기에 따라 선형이 아닌 2차원적으로 증가한다는 사실은 널리 알려져 있습니다. 그것은 우리의 직관에 따라 추적됩니다. 10줄의 풀리퀘스트는 100줄의 풀리퀘스트에 비할바가 안되는 조사수준를 받게됩니다 (훨씬 시간이 적게 든다는 의미). 그리고 주어진 모듈이 하나의 화면에 들어가기에 너무 커지면 그것을 이해하는 데 들어가는 노력이 크게 증가합니다. 리팩토링 및 주석 추가가 이따르구요.  
그렇기 때문에 항상 더 많은 코드를 생성하는 활동입니다. 악순환이죠.  
  
맞아요, 우리가 코드에 집착하는 동안 성능지표나 번들 사이즈 및 우리가 측정할 수 다른 것들에 주의를 기울이지 못합니다.  
코드를 작성하는 거에 비해서...  

## Readability is important (가독성은 중요합니다)

> I'm certainly not claiming that we should use clever tricks to scrunch our code into the most compact form possible at the expense of readability. Nor am I claiming that reducing lines of code is necessarily a worthwhile goal, since it encourages turning readable code like this...

나는 우리가 가독성을 희생하면서까지 최대한 간결한 형태로 코드를 작성하기 위해 트릭을 사용해야한다고 주장하지 않아요.  
나는 코드 줄을 줄이는 것이 반드시 가치있는 목표라고 주장하지 않습니다.  

```typescript
for (let i = 0; i <= 100; i += 1) {
  if (i % 2 === 0) {
    console.log(`${i} is even`);
  }
}
```

> ...into something much harder to parse:

상기의 것을 더 어려운 형태로 바꾸면 :
``` typescript
for (let i = 0; i <= 100; i += 1) if (i % 2 === 0) console.log(`${i} is even`);
``` 

> stead, I'm claiming that we should favour languages and patterns that allow us to naturally write less code.

대신 자연스럽게 적은 코드를 작성할 수있는 언어와 패턴을 선호해야한다고 주장합니다.

## Yes, I'm talking about Svelte (네, Svelte 요)

> Reducing the amount of code you have to write is an explicit goal of Svelte. To illustrate, let's look at a very simple component implemented in React, Vue and Svelte. First, the Svelte version:

작성해야하는 코드의 양을 줄이는 것이 Svelte 의 명백한 목표입니다.  
설명을 위해 React, Vue 및 Svelte에서 구현 된 매우 간단한 구성 요소를 살펴 보겠습니다.  

**첫째, Svelte 버전**
```svelte
<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>
```

> How would we build this in React? It would probably look something like this:

**둘째, React 버전**
```react
import React, { useState } from '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>
  );
};
```

> Here's an equivalent component in Vue:

**셋째, Vue 버전**
```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>
```

> In other words, it takes 442 characters in React, and 263 characters in Vue, to achieve something that takes 145 characters in Svelte. The React version is literally three times larger!
> 
> It's unusual for the difference to be quite so obvious — in my experience, a React component is typically around 40% larger than its Svelte equivalent. Let's look at the features of Svelte's design that enable you to express ideas more concisely:

React 에선 442 자, Vue 에서는 263자인 반면에 Svelte 에선 145 자. React 가 약 3배나 커요!  
이렇게 차이가 명확히 드러나는 것은 드문일이긴 합니다. 경험상 React 가 보통 40% 정도 많죠.  
그럼 간결하게 표현 가능한 Svelte 의 디자인 특징을 살펴보겠습니다.  

## Top-level elements (최상위 요소)

> In Svelte, a component can have as many top-level elements as you like. In React and Vue, a component must have a single top-level element — in React's case, trying to return two top-level elements from a component function would result in syntactically invalid code. (You can use a fragment — <> — instead of a <div>, but it's the same basic idea, and still results in an extra level of indentation).
> 
> In Vue, your markup must be wrapped in a <template> element, which I'd argue is redundant.

Svelte에서 컴포넌트는 원하는만큼의 최상위 요소를 가질 수 있습니다. React와 Vue에서 컴포넌트는 오직 하나의 최상위 요소를 가져야합니다. React의 경우 컴포넌트 함수에서 두 개의 최상위 요소를 반환하려고하면 문법적으로 오류가 납니다. (<div> 대신 <> 을 사용할 수 있지만 기본 컨셉은 동일하며 여전히 추가 수준의 들여 쓰기가 발생합니다.)
 
Vue에서 마크업은 <template> 요소로 래핑되어야합니다. 중복이죠.

## Bindings (바인딩)

> In React, we have to respond to input events ourselves:

리액트에서, 우리는 input event에 이렇게 반응합니다.

```react
function handleChangeA(event) {
  setA(+event.target.value);
}
```

> This isn't just boring plumbing that takes up extra space on the screen, it's also extra surface area for bugs. Conceptually, the value of the input is bound to the value of a and vice versa, but that relationship isn't cleanly expressed — instead we have two tightly-coupled but physically separate chunks of code (the event handler and the value={a} prop). Not only that, but we have to remember to coerce the string value with the + operator, otherwise 2 + 2 will equal 22instead of 4.

이건 그저 화면의 추가 공간을 차지하는 지루한 곳일 뿐아니라 버그를 위한 추가 요소이기도 합니다. 개념적으로 입력의 값은 A 에 바인딩되고 그 반대의 경우도 마찬가지지만 그 관계가 명확히 표현되진 않습니다. 대신 우리는 밀접히 결합된 쓰레기 코드를 가질 뿐이죠. 뿐만 아니라 + 연산자가 문자열 값을 강제변환하는 것을 기억해줘야 합니다, 안그러면 2 + 2 가 4대신 22가 될테니.

Svelte 와 마찬가지로 Vue 는 v-model 속성으로 바인딩을 합니다. 그러나 v-model.number 를 사용해야 한다는 것을 유의해야합니다.

## State (스테이트)

> In Svelte, you update local component state with an assignment operator:

Svelte 에서는 할당 연산자를 사용하여 state 를 업데이트 합니다.

```svelte
let count = 0;

function increment() {
  count += 1;
}
```

반면에 React 는 useState hook 을 사용하죠.
```react
const [count, setCount] = useState(0);

function increment() {
  setCount(count + 1);
}
```

> This is much noisier — it expresses the exact same concept but with over 60% more characters. As you're reading the code, you have to do that much more work to understand the author's intent.

훨씬 귀찮죠, 정확히 동일한 개념을 나타냄에도 60% 이상의 코드를 쳐야합니다. 코드를 이해하기 위해 더 많은 비용이 든다는 거죠.  

반면 Vue 에서는 state에 해당하는 속성이 있는 Object literal를 반환하는 기본 export 를 지니고 있습니다. 도움을 주는 함수 및 하위 컴포넌트를 단순히 가져와 템플릿에 사용이 불가합니다, 대신 기본 export 에 올바른 부분에 첨부하여 등록해야 하죠.  

## Death to boilerplate (상용구는 죽었다)

> These are just some of the ways that Svelte helps you build user interfaces with a minimum of fuss. There are plenty of others — for example, reactive declarations essentially do the work of React's useMemo, useCallback and useEffect without the boilerplate (or indeed the garbage collection overhead of creating inline functions and arrays on each state change).
> 
> How? By choosing a different set of constraints. Because Svelte is a compiler, we're not bound to the peculiarities of JavaScript: we can design a component authoring experience, rather than having to fit it around the semantics of the language. Paradoxically, this results in more idiomatic code — for example using variables naturally rather than via proxies or hooks — while delivering significantly more performant apps.

이는 Svelte가 최소의 번거로움으로 사용자 인터페이스를 구축하는 데 도움이되는 몇 가지 방법입니다.  
예를 들어 reactive declarations은 기본적으로 상용구없이 React의 useMemo, useCallback 및 useEffect 작업을 수행합니다 (또는 각 state 변경시 인라인 함수 및 배열을 만드는 garbage collection overhead 없이).  
  
어떻게 그러냐구요? 다른 제약 조건을 선택하기 때문이죠. Svelte 는 컴파일러이기 때문에, Javscript의 특성에 얽매이지 않습니다. 언어의 의미에 중점을 두기 보다는 컴포넌트 저작 경험을 디자인 할 수 있습니다. 역설적이게도 이는 예를 들어, 프록시나 Hook을 통하지 않고 자연스럽게 변수를 사용하는 것과 같은 관용적 코드를 생성하는 동시에 훨씬 더 성능이 뛰어난 앱을 제공하죠.

Svelte 공식문석 번역 : Write less Code

Nested Components

SVELTE_공식문서_돌아보기

Svelte 에서 Event 그리고 modifier

Svelte 에서의 Keyed Each blocks

$: 그리고 Statement

Nested Components

(번역/의역) 진짜 반응형

(번역/의역) 가상 DOM 자체가 오버헤드

(번역/의역) 더 적은 코드로