글쓰는 개발자

특히나 요즘엔, 이상하리만큼 알고있던 지식들의 뿌리를 뒤흔드는 일이 종종 생기는 것 같다. 가령 예를들어 일전에 썼던 [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로 했는지 리뷰하며 수정을 요청드릴 정도로 정신머리가 있지는 았았다. ...물론, 급할수록 돌아가랬다고 변명이다. 개발자로써 직무유기랄까...

1. awesome-devblog 최근에 개발관련 기술 포스팅을 검색하다보면 유독 Velog에 포스팅된 것들이 많이 나오길래, 스마트폰 기변병마냥 블로그를 한 번 더 갈아타야할때인가 싶어서 이래저래 살펴보다가... 결국 내가 쓰는 글 스타일에는 티스토리가 적격인 것 같아서 스테이하게됐다. 그리고 그렇게 리서치하는 과정에서 awesome-devblog 라는 서비스를 알게됐는데... 위와 같은 형태로 구독받을 이메일만 입력하면 매일 오전 10시에 기술 블로거들이 전날 포스팅한 내용이 리스트 형식으로 메일로 도착하게 된다. 저렇게 메일로 받은 포스팅을 클릭해서 들어가면 해당 포스팅이 나오는 형식이다. 어릴때 등교하려고 집 문을 열면, 현관앞에 놓여진 조간신문같은 느낌인건데 기대해던 것보다 괜찮아서 점심식사후나..

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에서 데이터를 바라보는 관점, 혹은 다루는 차이에 대해서 작성을 하려고 했습니다. 저는 보통 기술 포스팅을 할 때면, 눈을 감고도 입에서 술술 나올만큼 완전히 체화된 지식을 바탕으로 포스팅하려하는 편입니다. 그러다보니, 아직 ..

문제점 개발중인 Vue.js 기반의 프로젝트에서, 배포를 위해 빌드를 하던중에 배포된 상태의 용량을 최대한 줄이기 위해서 import된 npm 패키지들을 분석하던 도중에, 컴포넌트 쪽 패키지가 생각보다 너무 크길래 줄이려고 시도하다가 난 이슈다. 확인결과 해당 컴포넌트 패키지를 import 하는 대상이, minify & uglify가 적용되지 않은 js를 사용하고 있었기에 minify & uglify 된 파일을 import 하는 형태로 바꿨는데...콘솔이 에러메시지로 가득차버렸다. did you register the component correctly? For recursive components, make sure to provide the "name" option. 사실, 이 에러는...Vue 파일..

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

어,음…저번 포스팅때 이번편부터 본격적으로 Vue 파일들에 대해 파헤쳐보겠다고 했던 거 같은데, 생각해보니 라우터와 관련해서 못 다한 이야기가 있어서 이렇게 또 라우터를 주제로 작성하게 됐습니다. 그냥 나중에 좀 더 상세한 내용을 담는 포스팅에서 쓸까하다가, 그냥 나온김에 쓰자 싶어서요. (제 성격이 방학숙제조차도 미뤄놓으면 되게 찜찜해하는 타입이라 그렇습니다) 그래서 이번편은 #04_2편 입니다. 1. vue-router는 사실 2개야. 우선, Vue에서 라우터 기능을 사용하기 위해서 우리는 하나의 npm 패키지를 설치해줘야 합니다. 대략 vue-router 라는 이름을 가진 npm 패키지구요, Vue.js를 활용하신다면 필수적으로 사용할 수 밖에 없는 라이브러리입니다. 근데 여기서 중요한 점은 포스팅..