특히나 요즘엔, 이상하리만큼 알고있던 지식들의 뿌리를 뒤흔드는 일이 종종 생기는 것 같다. 가령 예를들어 일전에 썼던 [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로 했는지 리뷰하며 수정을 요청드릴 정도로 정신머리가 있지는 았았다. ...물론, 급할수록 돌아가랬다고 변명이다. 개발자로써 직무유기랄까...
문제점 사실 이 부분은 에러라기보단, 아래와 같이 Warning의 레벨이라서, 고치지않아도 node.js 서버의 기동이나 개발시엔 이슈 될 일이 없긴한데... 매번 서버 기동시마다 보이니까, 늘 찝찝한 건 어쩔 수 없다. 해결법 보통 node.js에서 Module not found와 같은 키워드로 시작하는 이슈는 1. 그 npm 패키지 파일이 설치되지 않았거나 2. import하고 있는 대상 파일이 없거나. 이 둘 중에 하나로 수렴하는데, 해당 Warning 메시지 같은 경우에는 2번사항이었다. 해결법부터 설명하자면 ./node_modules/moment/src/lib/locale/locales.js 파일의 코드를 아래와 같이 수정해주면 된다. try { oldLocale = globalLocale._a..
목차 1. ES11문법을 위한 babel의 최신화(Hi, Unexpected token, bye!) 2. polyfills는 Default를 가지고있다. 3. core-js 3 라고 왠만하면 명시하자. ...그리고 -1. 별첨. es6? es7? ㄴㄴ es! 1. ES11문법을 위한 babel의 최신화(Hi, Unexpected token, bye!) 문제점 현재 프로젝트에서 사용하고 있는 컴포넌트의, 새버전이 릴리즈되어 현장에 적용하려하였는데... 아래와 같은 에러 로그를 만나게 되었다. Module parse failed: Unexpected token Unexpected token 이라는 에러는 보통, Javascript 문법을 잘 못 썼거나 컴파일 단계에서 babel이 이해하지 못 하는 구분자(t..
0. 왜 이 포스팅을 쓰게되었는지에 대하여. 이 포스팅은 계획에 없던 포스팅이다. 사실 CSS Triggers에 대한 포스팅은 저번 포스팅으로 끝내려고 했었다. 근데 왜 또, 포스팅을 작성하고 있냐...면, 사실 내가 숱한 기술 블로그 포스팅들을 보면서 답답했던 부분이, 왜 이론은 엄청 방대하고 자세하게 설명들을 하면서 쉽고 직관적이며 이해하기 쉬운 예제는 잘 안 넣어두시는 걸까, 였었다. 그래서 예시가 있으면 이해가 더 쉬울 것 같은 포스팅에는 그때그때 예시를 될 수 있으면 넣으려고 하는데...그래서 저번 포스팅이었던 [CSS] CSS Triggers 에서도 역시나, CSS Triggers에 대한 쉬운 예제 코드를 넣으려 했었다. 근데 아뿔싸, 예상치 못 한 현상을 봐버린거다. CSS Trigger 그..
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에서 데이터를 바라보는 관점, 혹은 다루는 차이에 대해서 작성을 하려고 했습니다. 저는 보통 기술 포스팅을 할 때면, 눈을 감고도 입에서 술술 나올만큼 완전히 체화된 지식을 바탕으로 포스팅하려하는 편입니다. 그러다보니, 아직 ..