글쓰는 개발자

특히나 요즘엔, 이상하리만큼 알고있던 지식들의 뿌리를 뒤흔드는 일이 종종 생기는 것 같다. 가령 예를들어 일전에 썼던 [CSS] opacity는 reflow가 발생 안 한다구요...? 포스팅과 같은 일 말이다. 이번 포스팅도 그와 비슷한 맥락에서 출발한다. Vue는 MVVM 패턴과 관련이 없다, 라는 명제에 대한 증명을 위해서. 0. 이 명제의 출발점 시작은 언제나 사소하다. Vue.js 공식 Doc에 나와있는 한 문장으로부터 출발한다. Vue.js와 MVVM패턴은 관련이 없고, 그저 부분적으로 영감을 받았을 뿐, 이라는 이 문장. 오피셜 사이트에 그렇다는데...뭐, 더 할 말이 있겠는가. 1. 그렇다면 왜 나는 Vue.js가 MVVM이라고 생각해왔는가. 자, 그럼 나는 왜 Vue.js는 MVVM 패턴이..

이 포스팅은 사실 [javascript] var가 let보다 빠르다...? 포스팅을 쓰던 중에, 부가설명이 필요해서 var과 let, const에 대한 내용을 별첨으로 정리하던 내용인데... 이게 또 쓰다보니 제법 길어져서 별도 포스팅으로 발행하게 되었습니다. 0. javascript에서 변수를 선언하기 아이들이 마음껏 뛰어놀 수 있는 놀이터처럼, 컴퓨터로 동작하는 모든 시스템은 메모리라는 놀이터에서 뛰어놀게 된다. 이 놀이터에서 뛰어놀기 위한 값들은 메모리의 한 켠에 적재되고, 적재된 값을 가리키는 변수 혹은 상수를 활용해서 개발자들은 시스템을 구축하게 된다. Javascript도 당연히 변수를 정의하는 키워드가 존재한다. ES6(2015)가 공시된 2015년 이전에는 var이라는 하나의 키워드만 존재..

0. var가 let보다 빠르다고들 한다. 모 프로젝트로부터 헬퍼 요청이 있어서 2주 정도 단기로 투입됐을 때, 코드를 분석하며 의아했던 점 중에 하나는 대부분의 변수가 var로 선언되어있다는 것이었다. 코드를 살펴봤을 때, let을 두고 var를 사용할 이유가 없어보였기에 해당 로직을 개발하신 분께 여쭤봤더니 아래와 같은 답변을 들을 수 있었다. "var가 let보다 빨라요" 사실 당시엔 그런가보다, 하고 넘겼다. 왜 var가 let보다 빠르다는건지에 대한 설명이 부족했지만, 오픈직전의 프로젝트에 헬퍼로 투입된 입장에서 이미 동작하고 있는 로직의 변수선언을 왜 var로 했는지 리뷰하며 수정을 요청드릴 정도로 정신머리가 있지는 았았다. ...물론, 급할수록 돌아가랬다고 변명이다. 개발자로써 직무유기랄까...

0. 왜 이 포스팅을 쓰게되었는지에 대하여. 이 포스팅은 계획에 없던 포스팅이다. 사실 CSS Triggers에 대한 포스팅은 저번 포스팅으로 끝내려고 했었다. 근데 왜 또, 포스팅을 작성하고 있냐...면, 사실 내가 숱한 기술 블로그 포스팅들을 보면서 답답했던 부분이, 왜 이론은 엄청 방대하고 자세하게 설명들을 하면서 쉽고 직관적이며 이해하기 쉬운 예제는 잘 안 넣어두시는 걸까, 였었다. 그래서 예시가 있으면 이해가 더 쉬울 것 같은 포스팅에는 그때그때 예시를 될 수 있으면 넣으려고 하는데...그래서 저번 포스팅이었던 [CSS] CSS Triggers 에서도 역시나, CSS Triggers에 대한 쉬운 예제 코드를 넣으려 했었다. 근데 아뿔싸, 예상치 못 한 현상을 봐버린거다. CSS Trigger 그..

0. Rendering Pipeline 브라우져는, HTML을 어떻게 해석해서 우리의 눈에 버튼과 텍스트 필드와 아이콘과 테이블과, 지금 읽고 있는 이 글을 보여주게될까? 보통 이에 대한 설명을 단순하게는 'HTML을 해석해서 보여준다'라고들하지만, 순차적인 단계의 입장에서보면 대략 아래와 같은 절차를 거치게된다. 위 그림은 크로미움에서 사용하는 Blink의 렌더링 엔진에서 제공하는 그림이다. 브라우져 별로 사용하는 렌더링 엔진은 다 다르지만, 대부분 위와같은 프로세스에서 크게 벗어나지 않는다. * 브라우저별 Rendering Engine Blink : 크롬, 신형 Edge Gecko : 파이어폭스 WebKit : 사파리 Trident : IE EdgeHTML : 구형 Edge 1. 화면의 요소는 언제든..

기억도 나지않는 어느 날엔가, 누군가 내게 제목과 같은 질문을 했다. "Javascript의 Class도 호이스팅이 되나요?" 그리고 내가 답했다. "네, Class도 당연히 호이스팅 됩니다." 그러자 질문자가 되물었다. "하지만 아래와 같은 코드는 에러를 뱉는걸요?" var foo = new Foo(1, 2); //ReferenceError class Foo { constructor(x, y) { this.x = x; this.y = y; } } "네, 에러를 뱉겠죠. Foo class의 선언보다 사용이 앞섰으니까요." 0. 누구에게나 처음은 있다. 위의 일화가 본 포스팅을 작성하게 된 이유다. 아마도 Javascript를 시작하는 길목에서 처음 호이스팅이라는 개념을 이해할 때면, 우리는 아래와 같은 ..

이 포스팅은 미완입니다. 써놓은 포스팅임에도 불구하고 미완이라니, 그럼 굳이 왜 써놓는거지? 싶은 생각을 하실 수도 있는데... 사실 앞선 포스팅(Javascript의 불변성)에서 설레발치듯 '밑밥'이라는 표현을 써서 이렇게 빈 포스팅을 남겨두게 되었습니다(밑밥을 깔아뒀더니 순서상 다른 주제로 포스팅하기가 뭔가 애매해져서...이렇게 영역부터 차지해두려고 합니다) 그래도 미완이지만 포스팅을 하는김에 또 썰을 풀어보자면, 이번 포스팅에서 다루고싶었던 주제는 React.js와 Vue.js에서 데이터를 바라보는 관점, 혹은 다루는 차이에 대해서 작성을 하려고 했습니다. 저는 보통 기술 포스팅을 할 때면, 눈을 감고도 입에서 술술 나올만큼 완전히 체화된 지식을 바탕으로 포스팅하려하는 편입니다. 그러다보니, 아직 ..

이 포스팅은 사실, 하고싶은 다음 포스팅을 위한 밑밥이라고 보시면 됩니다. 오랜만에 포스팅해보고 싶은 이야깃거리가 생겼는데, 거기서 불변성의 개념까지 설명하기엔 너무 주제를 벗어나는 느낌이기도하고 불변성(Immutability)이라는 개념 자체도 충분히 하나의 포스팅거리로 삼을법한 주제이기 때문에, 이 포스팅을 작성하게 되었습니다. 0. 변수인데 불변한다는게 무슨 말이야? 처음 불변성이라는 용어를 Javascript를 공부하며 들었을때, 머릿속에 들었던 첫 번째 물음. 우리는 개발을 하고 코드를 작성하며 수많은 변수를 사용한다. 변수라는 건 엄연히 변경이 가능한 수를 뜻하고, 변하지 않는 수라면 그건 상수라고 칭하면 될 텐데 굳이 불변성이라는 용어로 정의하면서까지 설명을 해놓는 이유가 뭘까. 1. 포인터..

한줄요약. !important >>> inline >>> id선택자 >>> class명 >>> HTML 태그명 >>> DOM구조의 상위 상속 위에 요약한 것과 같이 아래 정리된 번호를 기준으로 낮은 번호가 우선순위가 높습니다. 즉, 1번과 2번이 동일한 Element를 가리키면서 CSS를 정의한다면, 1번 내용이 적용됩니다. 1. !important 가장 높은 우선순위입니다. 해당 키워드는 정의되는 CSS의 요소 값 뒤에 위치하게 됩니다. h3태그에 대해서 아래와 같은 CSS요소가 정의되어있다면 h3태그의 색상이 빨갛게 나오게 됩니다. .title-box{color: red !important;} .title-box{color: blue;} 타이틀 CSS는 일반적으로 후정의사항이 우선순위가 높게 책정됩니..

안녕하세요, 오랜만에 Vue.js 관련 포스팅을 합니다. 와...벌써 2021년 4월이라니...Vue.js 관련 마지막 포스팅이 작년 11월이네요. ([Vue.js_#04_2] 라우터(vue-router) vol.2) 무려 4개월이 넘는 시간동안 포스팅을 하지 않다니... 바쁘다는 건 늘 핑계라고 생각하는 성격상 입이 열개라도 할 말이 없습니다......만! 그래도 열 한 번째 입이라도 강물에 둥둥떠서 살아보고자 이 포스팅을 쓰게 되었습니다. 사실, 티스토리에서 못 다한 Vue 가이드 포스팅을 Github Page에서 완성해버렸답니다? 에헷>_