지난번에 포트폴리오 관련 강의를 마무리하고 자바스크립트에 더욱 흥미가 생겨서 드림코딩에서 프로젝트101강의를 들었다.
아직 자린이기 떄문에 최대한 수업을 열심히 들었고 노마드코더의 크롬앱 코딩에서 배워서 알게 된 기능들이나 지식들은 선 강의 후코딩이 아니라 선코딩 후강의로 진행했다.
우선 이번강의에서 알게 된 내용중 중요하다, 새로웠다 생각한 내용들은 총 세가지고 아래와 같다.
1. New addeventlistener
1 - resize
2 - mousemove
2. API(Application Programming Interfaces)
3. DOM(Document Object Model)
우선 새로 알게된 addeventlistener 중에 resize 와 mousemove가 있었고 간단하게 설명하자면 전자는 웹의 window크기를 resize할떄 생기는 event이고 mousemove는 window내에서 작성자가 설정한 범위내 ex) document, element ... 마우스를 움직일떄 마다 발생한다.
저번에 사용했던 scroll event와 마찬가지로 조금만 움직여도 상당히 많은 event가 발생한다.
그렇기 때문에 성능이 좋은 코딩을 할 필요가 있다.
우선 처음으로 사용했던 방법은 Java Script에서 elment.style.left, elment.style.top을 이용하여 실제 페이지내에서의 마우스가 어딨는지 pagex나 clientx와 같이 값을 받아온다음 그 안에 left와 top에서 그만큼의 픽셀을 주어서 움직이게 하는 방법이었다.
여기서 중요한점은 받아온값에 px을 string으로 꼭 줘야한다는점이다!!
이 방법으로 해도 구현이 되었으나 앞서 말했던 좋은 코딩이 필요하다고 했었는데 이 방법은 좋지 못한 코딩 방법에 속한다.
왜 그런가는 밑에 DOM 부분에서 자세하게 설명할 예정이다
특히 내가 중요하게 생각했던 event는 mousemove이고 내가 개인적으로 생각하기에 혹시나 어떤 웹사이트에서 사용자들의 mousemove의 events를 모아서 데이터 분석한다면 하나의 지침이 될 수도 있다고 생각했기 때문이다.
자 이제 DOM을 설명하려면 API에 관한 설명이 먼저 나와야하고 간단하게 말하면 API의 주체는 다양 할 수 있다.
내가 웹을 작성해야한다면 window가 주체이고, 모바일앱을 개발해야 한다면 안드로이드나 애플os가 주체가 될것이고, 내가 NAVER나 YOUTUBE에서 제공된 로그인과 같은 API를 사용한다면 주체는 NAVER나 YOUTUBE이다.
여기서 나는 웹을 현재 개발하고 있으므로 window에서 제공하는 API에 대해서 알 필요가 있는데 수많은 API들중 DOM이라는 API가 있다.
위에서 적은 DOM(Document Object Model)을 직역하면 문서 대상 모델이고 우리가 HTML을 작성하게 되면 그것을 css에서도 읽어야 하고 javascript에서도 읽어와 css를 입히고, javascript에서 동적인 동작을 입히고 하는데 HTML을 읽어내기 위해서 javascript를 예로들면 node로 변환한다.
이 node는 EventTarget을 상속하고 document와 element는 node를 상속한다.
상속한다는 말을 간단하게 이해하면 속한다고 볼 수 있고 EventTarget이 최상의 상속자기 떄문에 모든 node들은 Event가 발생한다고 할 수 있고 그 밑에 document와 element들은 node를 상속하기 떄문에 이것들 또한 모두 Event가 발생한다고 볼 수 있다.
이제 이런것들을 css에서는 cssom이라고 하여 css버전의 dom을 만들어낸다.
이제 dom과 cssom을 종합하여 rendertree를 만들게 되는데 여기서 rendertree는 css에서 display none과 같은 특성을 가진다면 제외 시킨다.
여기서 헷갈리는게 그럼 화면에서 보여지지 않는다면 rendertree에 포함되지 않는가? 이고 이에 대한 답은 no이다.
간단하게 예로들면 css의 요소중에 opacity:0을 설정하면 사용자 눈에 보이지 않는다.
하지만 이것 투명도를 0으로 줄이는것이지 삭제 시키는것도 아닐뿐더러 mouse-event를 지우지 않으면 클릭되어지기도 한다.
즉 문서내에서 완전히 사라진것이 rendertree에 포함되지 않는다고 할 수 있다.
이제 앞서 말했던 좋은 코딩의 조건이 설명이 가능해지고 있다.
브라우저에서 URL을 입력하게 되면 아래와 같은 순서로 이루어진다.
requests/response > loading > scripting > rendering > layout > painting
앞의 4가지는 말그대로 서버에 요청보내고 응답받은후 loading하고 node로 변환하는 절차이고 이 과정을 construction 뒤에는 실제로 화면을 구상하는 과정이고 이 과정을 operation이라 한다, construction과 operation이 늦어지면 사용자의 화면에 적용되는 기간이 늘어나고 이는 불쾌한 경험을 하게 된다.
이러한 불쾌한 경험을 줄이기 위해선 위의 과정을 줄이는 좋은코딩의 과정이 필요하게 되고 좋은코딩이란 위의 과정의 시간을 줄이는것이다.
그럼 시간을 줄이려면 어떤게 중요한가하면 operation이다.
operation에 관해서 설명을 덧붙이자면 layout > paint > composition의 과정을 거치게되고 가장큰게 layout이다.
layout이란 어떤 element는 어디 있는지 블로그에서의 layout가 괕이 위치를 정하는거고 paint는 z-index로 예로들자면 어떤 element가 같은 z-index내에 있다면 그 element들을 같이 묶어주는 과정이고, composition은 이렇게 정해진것을 이동하는 과정이다.
블로그로 예로들자면 우리가 블로그를 수정해야 되는데 어떤글을 어디에 배치하는지와 같이 레이아웃을 바꿔야 하는 수준이면 블로그를 새로 써야 하는 과정일것이고 레이아웃을 수정하고 글자폰트와 색깔 같은것도 바뀔 수 있고 심지어 내용도 바뀔 수 있고 이는 상당히 귀찮은 작업이다.
이러한 과정이 layout과정이고 layout은 정해져있지만 layout내에서 다른 부가작업들은 앞서 layout을 바꾸는 수준보다는 덜 귀찮을것이고 이는 painting에 해당한다.
마지막으로 이러한 작성된 블로그들을 어느 카테고리에 배치할지와 같이 비교적 간단한 작업들은 composition에 해당한다.
비유가 적절했는지 모르겠으나 최종적으로 과정의 크기를 비교하면 layout > paint > composition 이다.
그래서 좋은 코딩이란 최대한 할 수 있는 범위내에서 가장 적은 크기로 해야하고 내가 위에서 했던 left로 예를들자면 이는 위에 3가지가 모두 적용되는 기능이고 이를 앞서 100픽셀만 움직여도 100가지 event가 발생하는 로직에서 이러한 경우가 생기면 상당히 불쾌한 경험을 제공할 확률이 높다.
그래서 이 부분을 composition만 사용하여 바꿀 수 있었고 그 대표적인게 transform에 translate이고 이를 통해 위에서 만들었던 앱을 수정했다.
이러한것을 배우면서 좋은코딩이 필수라고 생각을 헀고 ellie님의 말을 첨언하자면 실제로 큰 회사에서는 이러한 성능을 담당하는 부서가 있을정도로 중요하다고 했다.
CSS Triggers
@PROPERTY_DESCRIPTION@ B G W E Change from default B G W E Subsequent updates
csstriggers.com
이 사이트는 위에서 말햇던 css의 기능들이 layout > paint > composition중 어떤것을 사용해서 적용하는지 설명이 되있으니 참고하면 좋을것 같다.