10 년마다 JavaScript에서 보호 기능이 변경됩니다. 나는 우리가 자바 스크립트 의 제 3의 시대 로 간주 될 수있는 가속화 된 변화의 기간을 막 시작했다고 생각한다 .

지금까지의 이야기 🔗

1997 년부터 2007 년까지 JS의 첫 번째 나이 는 강타로 시작하여 m 소리로 끝났습니다. 여러분은 모두 Brendan Eich의 이야기를 알고있을 것입니다. Flash / Actionscript와 같은 폐쇄 된 생태계와의 강력한 경쟁 속에서 ES4 노력이 어떻게 왜곡되었는지는 잘 알려져 있지 않습니다. JS의 주요 이야기는 주요 저자 인 Brendan Eich와 Allen Wirfs-Brock의 JavaScript : The First 20 Years에서 더 잘 알 수 있습니다.

2009 년부터 2019 년까지 JS의 두 번째 나이는 2009 년 의 annus mirabilis 에서 시작하여 npm, Node.js 및 ES5가 탄생했습니다. Doug Crockford가 우리에게 좋은 부분을 보여 주면서 사용자는 JS 빌드 도구 및 라이브러리를 구축 하고 데스크톱 및 새로운 스마트 폰으로 JS의 범위를 확장했습니다. 2019 년에는 Facebook의 Hermes 와 같은 전화기 와 Svelte 3 과 같은 컴파일러의 첫 번째 프론트 엔드 프레임 워크 에서 JS를위한 특수 런타임이 등장했습니다 .

세번째 시대 🔗

2020 년은 새로운 시대의 시작과 같은 느낌입니다. 1 세가 언어를 개발하는 것과 2 세가 사용자가 언어를 탐색하고 확장하는 것에 관한 것이라면, 3 세는 레거시 가정을 지우고 툴링 계층을 붕괴시키는 것입니다.

참고 : 전에 축소 레이어 논문을 발표했습니다!

해결되는 주요 레거시 가정은 일련의 타협으로 발전한 CommonJS에 대한 JS 에코 시스템의 의존성입니다. 그 대체품 인 ES Modules는 한동안 기다려 왔지만 기존 툴링은 느리지 만 "충분히"뛰어 나기 때문에 진정으로 도약 할 모멘텀이 부족했습니다. 프론트 엔드에는 최신 브라우저가이를 소량 처리 할 수있는 기능을 갖추고 있지만 중요한 세부 사항은 아직 해결되지 않았습니다 . 새앙 토끼 / 스노우 팩의 프로젝트는 ES 모듈 밖으로 흥분으로 사라질 수있는 외관을 제공함으로써 미래를 가속화하기 위해 배치됩니다. 최종 보너스로서, IE11은 올해부터 시작하여 2029 년 에 끝날 때까지 느린 행진을 시작할 것 입니다.

또 다른 가정은 JavaScript 도구가 JavaScript로 작성되어야한다는 것입니다. 핫 패스에서 타입 안전 및 10x-100x 성능 속도 의 가능성은 무시하기에는 너무 큽니다. "JS의 JS를위한"이상은 TypeScript가 JavaScript를 거의 완전히 인수함으로써 없어졌고 이제 Deno와 Relay는 사람들이 Rust를 배우고 핵심 JS 도구에 기여할 수 있음을 입증하고 있습니다. Brandon Dail 은이 변환이 2023 년까지 완료 될 것으로 예상 합니다. 접근성이 성능을 능가하는 대부분의 주변 툴링에 대해 JavaScript 및 TypeScript를 계속 작성합니다. " 기능적 코어, 명령형 쉘 " 에 대해 생각하던 곳에서 이제 " 시스템 코어, 스크립팅 쉘 "로 이동하고 있습니다.

참고- 이것은 논쟁의 여지 가 있으며 Python의 PyPy는 이것이 확실한 결론이 아니라는 것을 나타냅니다 .

레이어는 흥미로운 방식으로 무너지고 있습니다. Deno는 완전히 새로운 런타임을 작성하는 급진적 인 접근 방식을 취하여 테스트, 서식 지정, 보푸라기 및 하나의 바이너리로 묶기, TypeScript 말하기 및 표준 lib 포함과 같은 작업을 수행하는 일반적인 도구 모음을 접습니다 . 로마는 다른 압정을 취해 Node.js 위에있는 모든 레이어를 무너 뜨립니다 (내가 아는 한 너무 가까이 있지는 않습니다).

10 년 전에 존재하지 않았고 지금은 삶의 사실은 퍼블릭 클라우드 (AWS, Azure, GCP 등)입니다. 자바 스크립트는 클라우드와 흥미로운 관계를 맺고 있습니다. 클라우드 플랫폼 개발자는 10 피트 폴로 JS를 건드리지 않지만 JS는 가장 큰 소비자입니다. AWS Lambda가 먼저 JS와 함께 시작되었습니다. 또한 IDE와 클라우드 사이에서 계층을 축소하고 그 사이에서 성가신 랩톱을 제거하는 명확한 이동이 있습니다. Glitch, Repl.it, Codesandbox, GitHub Codespaces , Stackblitz 등은 JS를 활용하여이 공간을 탐색하는 모든 Cloud Distros 입니다.

프론트 엔드 프레임 워크에서도 진행중인 활동은 흥미 롭습니다. Svelte 는 애니메이션에서 상태 관리에 이르는 모든 것을 컴파일러로 축소했습니다 . React는 메타 프레임 워크 와 클라이언트-서버 통합을 탐색 하고 있습니다. 그리고 Vue는 Vite라는 "unbundler"dev 서버 프로젝트를 진행하고 있습니다.

요약 : Third Age JS 도구는

• 더 빠른
• ESM 우선
• 접힌 레이어 (한 가지 일을 잘하는 것보다 많은 일을 잘하는 것)
• Typesafe-er (핵심에 강력한 형식의 언어로 구축되고 구성이 0 인 사용자 코드에서 TS 지원)
• 보안 성 (종속성 공격 또는 느슨한 권한)
• 폴리 글롯
• Neo-Isomorphic (대부분은 아니지만 대부분의 경우 JS가 빌드 타임 또는 서버 측에서 클라이언트에 도달하기 전에 먼저 실행되어야 함을 인식)

이 모든 작업의 ​​결과는 더 나은 개발자 경험 (빠른 빌드, 업계 표준 툴링) 및 사용자 경험 (더 작은 번들, 더 빠른 기능 전달)입니다. 사이트 스크립팅 토이 언어에서 전체 애플리케이션 플랫폼에 이르기까지 JavaScript의 최종 변형입니다.

자바 스크립트의 죽음? 🔗

경우 게리 베르나르의 예측이 성립 , 세 번째 시대는 자바 스크립트의 마지막 (자신의 타임 라인 2035까지 JS를 제공) 할 수있다. 브랜든 아이 히 (Brendan Eich)조차도 "JS와 WASM에 항상 배팅하라"는 그의 유명한 말을 피봇했다. 그는 원래 JS가 "범용 가상 머신" 이라고 생각 했지만 WASM이 이제 그 아이디어의 궁극적 인 성취 라고 한 번 말했습니다 .

원문 : https://www.swyx.io/writing/js-third-age/

v-for을 사용하다보면 생각보다 요놈이 문제 많은 녀석이라는걸 느낄 때가 있다.

그런데 국내나 해외나 이 v-for에 대해서 제대로 적어놓은 녀석이 별로 없는거 같다.

그냥 불편해도 사용하는건지...

사용시 주의를 요하는 녀석인데 그 이유에 대해서 논해보도록 하자.

코딩을 하다보면 v-for은 안쓸래야 안쓸 수가 없다.

굉장히 좋은녀석이지만 몇가지 문제점이 존재한다.

일단. v-for은 해당 데이터의 길이가 0이면 그리지 않는다.

그래서 굳이 v-if를 달 필요가 없다는건 장점이다.

하지만 문제는 길이가 가변할 경우이다.

대부분 v-for의 문제는 가변하는 길이에서 오는 것이다.

v-for에서 데이터를 처리하는 방식은 아래와 같다.(완벽하게 같지는 않고 얼추 맞음)

1. data의 길이가 0(혹은 초기화)에서 n의 길이가 되었을 경우 n개의 컴포넌트를 만들고 dom으로 바꾼다.

2. 1번 이후 당연히 컴포넌트는 새로 만들어졌으므로(dom으로 인스턴스화 됬으므로) created와 mounted 이벤트가 발생

3. data의 길이가 n개에서 m개로 증가 되었다.(m은 n보다 크다)

4. 3번 이후 컴포넌트가 추가되었지만 기존의 dom자체를 파기하지는 않고 적절히 순서를 유지한다.(새 데이터가 앞일지 뒤일지 중간일지 모르므로)

5. 데이터가 당연히 추가되야하므로 m-n개 만큼 추가로 dom을 생성한다 당연히 추가로 생성된 컴포넌트는 created와 mounted가 발생한다. 

여기서 눈여겨 볼것은 데이터가 추가되었을 때 기존의 dom을 파기하지 않는다는것, 이말은 기존의 컴포넌트를 파기하지 않는다는 말과 동의어다.

그렇기 때문에 데이터가 늘어나서 추가로 돔이 생겨도 기존의 dom이 파기되지는 않았으므로 이벤트는 발생하지 않는다.

싹 재 렌더링을 하지 않기 때문에 당연히 성능이 상승하게 된다.

여기서 문제점이 발생하는 경우가 많다.

이 때 발생하는 문제점

일단 이 문제점 보다 이번에는 key에 초점을 맞춰보도록 하자.

이 때까지 위의 이야기는 다 key의 역활을 말하기 위해서 한것이다.

4번에 dom자체를 파기하지 않고 적절한 순서를 유지하는것은 바로 key때문에 가능하다.

데이터가 다시 업데이트 될 때 가상돔과 돔의 key를 비교한다.

key가 지정되어있다면 이 key를 통해서 특정 녀석을 "재 렌더링 할지"정하게 된다.

key가 없다고 반드시 재 랜더링을 하는것은 아닌거 같다.(필자의 테스트결과)

하지만 key가 겹치게된다면 매우 높은 확률로 재 렌더링을 한다는 것이다.

※아 그리고 key가 없으면 인덱스를 그냥 key로 넣는다는 주장이 있다. 주장인데 신빙성은 있는 듯.

이는 몇가지 테스트를 통하여 확인하였다.

테스트 조건은 아래와 같다.

데이터 앞에 신 데이터 끼워넣기

1. 크기와 색, 위치는 렌덤인 div에 숫자를 넣는다. 갯수는 1만개이다.

2. 3초후에 1만개의 div를 추가적으로 기존 데이터의 앞에 추가한다.(즉 배열은 2만개가 되고 앞의 1만개는 신데이터, 과거 1만개는 구데이터)

3. 그 후 과거 1만개가 생성된 직후에서 새로 1만개가 생성된 직후의 시간차이를 계산한다.

4. 3개의 대조군을 만드는데 하나는 key가 없는 녀석, 하나는 key가 있지만 중복이 발생하는 녀석, 하나는 key가 있고 유니크한 녀석이다.

이렇개 개발자 도구 켜서 총 걸리는 시간을 확인하겠다는 뜻이다.

그럼 실험 결과를 공개하겠다. 단위는 초이다.

key가 없는 경우 => 3.92 3.81 3.92 3.94 4.10

key가 있지만 유니크하지 않음 => 3.68 3.77 3.63 3.66 3.72

key가 있고 유니크함 => 3.55 3.47 3.58 3.58 3.36

평균을 내보면

key(없음) = 3.93

key(중복) = 3.69

key(유니크) = 3.5

키가 없는것 보다는 중복되더라도 있는게 빨랐고 중복된것보단 유니크한게 빨랐다.

하지만 여기서 함정이 있는데 위의 경우에는 데이터의 순서가 유지가 됬기 때문에 중복이 되어도 재 렌더링이 거의(혹은 전혀)일어나지 않는다.

아마 vue에서 과거데이터와의 대조를 통하여 key가 없어도 어느정도 캐싱효과를 보장해주는것 같다.

일반적인 경우에는 중복된다면 없는게 더 나은데 그 이유는 아래를 보면 알 수 있다.

실험 방식을 약간 바꿔보자.

과거 데이터와 신 데이터를 교차로 섞기

1. 크기와 색, 위치는 렌덤인 div에 숫자를 넣는다. 갯수는 1만개이다.

2. 3초후에 1만개의 div를 추가적으로 기존 데이터와 셔플하듯이 사이에 교차로 추가한다.(즉 배열은 2만개가 되고 앞의 1만개는 신데이터, 과거 1만개는 구데이터)

3. 그 후 과거 1만개가 생성된 직후에서 새로 1만개가 생성된 직후의 시간차이를 계산한다.

4. 3개의 대조군을 만드는데 하나는 key가 없는 녀석, 하나는 key가 있지만 중복이 발생하는 녀석, 하나는 key가 있고 유니크한 녀석이다.

이 경우 어떻게 될까?

놀랍게도 결과는 이상하게 전개된다.

key가 없는 경우 => 3.99 4.00 3.88 4.01 4.04

key가 있지만 유니크하지 않음 => 5.7 5.53 5.10 5.23 5.29

key가 있고 유니크함 => 3.60 3.58 3.63 3.56 3.63

평균을 내보면

key(없음) = 3.98

key(중복) = 5.37

key(유니크) = 3.6

오히려 키가 중복될 때 성능이 눈에 띄게 하락하는 것을 확인할 수 있다.

그 이유는 제랜더링이 눈에 띄게 많이 일어나는데 이는 아래의 그림을 보면 알 수 있다.

사진속 마우스 커서가 새로 고침을 누른 시점에서 확인하라!

key가 없는 경우이다.

key가 있고 중복되지 않는 경우이다.

key가 있는데 중복되는 경우이다.

뭔가 차이가 느껴지는가?

위의 둘은 기존 컴포넌트(돔)이 사라지지 않고 추가만 됬지만 key중복이 있는 경우 몇개는 없어지고 재 렌더링이 된다.

일종의 캐싱 효과를 못 받는걸로 해석된다.

애당초 key가 중복된다는 것은 일종의 버그이다. "특정 상황에서 key가 있을 때 없을 때"의 성능이 다르긴하지만

그걸 논하는건 무의미하며 정의된 스펙이 아니다. 따라서 그냥 key는 유니크하게 만들어야한다.

결론

 

1. key는 성능에 영향을 확실하게 미친다.

2. key가 없는 경우 데이터가 삽입 정도와 정렬정도에 따라서 캐싱효과를 보고 못보고가 결정된다.

3. key가 중복되는데 캐싱을 못볼경우 그냥 재 렌더링 해버리는데 그 사이드 이펙트가 클 수도 있다.

4. key를 쓸꺼면 아예 중복안되게 key를 만들고 안 쓸거면 그냥 쓰지 않는게 낫다.

결론 중의 결론

 

그냥 key쓰세요. 아 그리고 무조건 유니크하게

key가 없을 때는 사실 필자가 테스트할 땐 제 랜더링이 일어난 적이 없는데 더 뚜렷하게 아시는 분이 알려주시면 감사하겠다.

출처: https://kamang-it.tistory.com/entry/WebPerformanceVue-vfor%EA%B3%BC-key-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%84%B1%EB%8A%A5%EC%82%AC%EC%9D%B4%EC%9D%98-%EA%B4%80%EA%B3%84

github에 레포지터리를 생성하지 않고 시작한 경우입니다.

레포에는 아무 파일이 존재하지 않아야합니다.

1. github에 새로운 저장소(레포지터리)를 만듭니다.

2. 터미널을 열어줍니다.

3. 자신이 git에 올리고 싶은 root 폴더로 이동합니다.

4. 해당 폴더의 깃을 초기화 하여 줍니다.

$ git init

5. commit을 합니다.

$ git add .

$ git commit -m "First Commit"

6. remote repository를 등록합니다.

※ 깃헙 레포 url은 웹에서 해당 레포를 들어가시면 확인이 가능합니다.

$ git remote add origin [ github repo URL ]

$ git push -u origin master

Vue.js의 라이프 사이클은 크게 Creation, Mounting, Updating, Destruction 으로 나눌 수 있다.

1. Creation : 컴포넌트 초기화 단계

Creation 단계에서 실행되는 훅(hook)들이 라이프사이클 중에서 가장 처음 실행된다. 이 단계는 컴포넌트가 돔에 추가되기 전이다. 서버 렌더링에서도 지원되는 훅이다.

따라서 클라이언트 단과 서버단 렌더링 모두에서 처리해야할일이 있다면 이단계에서 하면된다. 아직 컴포넌트가 돔에 추가되기 전이기 때문에 돔에 접근하거나 this.$el를 사용할 수 없다.

이 단계에서는 beforeCreate 훅과 Created 훅이 있다.

beforeCreate

모든 훅 중에 가장 먼저 실행되는 훅이다. 아직 data와 events(vm.$on, vm.$once, vm.$off, vm.$emit)가 세팅되지 않은 시점이므로 접근하려고 하면 에러를 뿜어낼 것이다.

<script>
  export default {
    data () {
      return {
        title: ''
      }
    },

    beforeCreate () {
      //can't use Data(this.title ...), events(vm.$on, vm.$once, vm.$off, vm.$emit)
    }
  }
</script>

created

created 훅에서는 이제 data와 events가 활성화되어 접근할 수 있다. 여전히 템플릿과 가상돔은 마운트 및 렌더링되지 않은 상태이다.

<script>
  export default {
    data () {
      return {
        title: ''
      }
    },
    computed: {
      titleComputed() {
        console.log('I change when this.property changes.')
        return this.property
      }
    },
    created () {
      //can use Data(this.title, this.titleComputed ...), events(vm.$on, vm.$once, vm.$off, vm.$emit)
      //don't use $el
    }
  }
</script>

2. Mounting : 돔(DOM) 삽입 단계

Mounting 단계는 초기 렌더링 직전에 컴포넌트에 직접 접근할 수 있다. 서버렌더링에서는 지원하지 않는다.

초기 랜더링 직전에 돔을 변경하고자 한다면 이 단계를 활용할 수 있다. 그러나 컴포넌트 초기에 세팅되어야할 데이터 페치는 created 단계를 사용하는것이 낫다.

beforeMount

beforeMount 훅은 템플릿과 렌더 함수들이 컴파일된 후에 첫 렌더링이 일어나기 직전에 실행된다. 대부분의 경우에 사용하지 않는 것이 좋다. 그리고 서버사이드 렌더링시에는 호출되지 않는다.

<script>
export default {
  beforeMount() {
    console.log(`this.$el doesn't exist yet, but it will soon!`)
  }
}
</script>

mounted

mounted 훅에서는 컴포넌트, 템플릿, 렌더링된 돔에 접근할 수 있다. 모든 하위 컴포넌트가 마운트된 상태를 보장하지는 않는다. 서버렌더링에서는 호출되지 않는다.

<script>
export default {
  mounted() {
    console.log(this.$el.textContent) // can use $el
    this.$nextTick(function () {
      // 모든 화면이 렌더링된 후 실행합니다.
    })
  }
}
</script>

mounted 훅에서 유의할 점은, 부모와 자식 관계의 컴포넌트에서 우리가 생각한 순서로 mounted가 발생하지 않는다는 점이다. 즉 부모의 mounted훅이 자식의 mounted훅보다 먼저 실행되지 않는다. 오히려 그 반대이다.

Parent/child initialisation workflow

위 그림처럼 Created훅은 부모->자식의 순서로 실행되지만 mounted는 그렇지 않다는 것을 알 수 있다. 다른 식으로 말하면 부모는 mounted훅을 실행하기 전에 자식의 mounted훅이 끝나기를 기다린다. (참고 Vue Parent and Child lifecycle hooks)

3. Updating : Diff 및 재 렌더링 단계

컴포넌트에서 사용되는 반응형 속성들이 변경되거나 어떤 이유로 재 렌더링이 발생되면 실행된다. 디버깅이나 프로파일링 등을 위해 컴포넌트 재 렌더링 시점을 알고 싶을때 사용하면 된다. 조심스럽지만, 꽤 유용하게 활용될 수 있는 단계이다. 서버렌더링에서는 호출되지 않는다.

beforeUpdate

이 훅은 컴포넌트의 데이터가 변하여 업데이트 사이클이 시작될때 실행된다. 정확히는 돔이 재 렌더링되고 패치되기 직전에 실행된다. 재 렌더링 전의 새 상태의 데이터를 얻을 수 있고 더 많은 변경이 가능하다. 이 변경으로 이한 재 렌더링은 트리거되지 않는다.

updated

이 훅은 컴포넌트의 데이터가 변하여 재 렌더링이 일어나 후에 실행된다. 돔이 업데이트 완료된 상태이므로 돔 종속적인 연산을 할 수 있다. 그러나 여기서 상태를 변경하면 무한루프에 빠질 수 있다. 모든 자식 컴포넌트의 재 렌더링 상태를 보장하지는 않는다.

<script>
export default {
  updated() {
    this.$nextTick(function () {
      // 모든 화면이 렌더링된 후 실행합니다.
    })
  }
}
</script>

4. Destruction : 해체 단계

beforeDestroy

이 훅은 해체(뷰 인스턴스 제거)되기 직전에 호출된다. 컴포넌트는 원래 모습과 모든 기능들을 그대로 가지고 있다. 이벤트 리스너를 제거하거나 reactive subscription을 제거하고자 한다면 이 훅이 제격이다. 서버 렌더링시 호출되지 않는다.

destroyed

이 훅은 해체(뷰 인스턴스 제거)된 후에 호출된다. Vue 인스턴스의 모든 디렉티브가 바인딩 해제 되고 모든 이벤트 리스너가 제거되며 모든 하위 Vue 인스턴스도 삭제된다. 서버 렌더링시 호출되지 않는다.

그 밖에

activated와 deactivated가 있다. 각각 keep-alive 컴포넌트가 활성화 될 때와 비활성화 될 때 호출된다.

출처: https://medium.com/witinweb/vue-js-%EB%9D%BC%EC%9D%B4%ED%94%84%EC%82%AC%EC%9D%B4%ED%81%B4-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-7780cdd97dd4