프론트엔드-개발환경

node.js는 단순히 브라우저 환경이 아닌 환경에서도 자바스크립트를 실행할 수 있게 해주는 자바스크립트 런타임이다. 하지만, 최근 프론트엔드 개발 환경에서는 Node.js를 제대로 이해하고 있지 못하면 많은 어려움을 겪게 된다.왜 최신 스펙으로 개발하려면 웹브라우저의

일명 기여자(Contributor)라고 불리는 개발자들이 다른 개발자들이 개발을 편리하게 할 수 있도록 자주 이용되는 소스코드 패턴들을 공유한 것이다.이러한 소스코드를 가져오는데는 다양한 방법이 존재한다.CDN은 Content Delivery Network의 약자이다.

자바스크립트는 node.js 전까지는 단순히 웹 브라우저에서의 동작만을 담당하여, 파일을 따로 나누더라도 <script src="경로"></script>와 같은 방식으로 그냥 HTML 파일에 추가하기 마련이었는데 ES2015부터 모듈이라는 개념이 도입되었다.

기본적으로 웹팩은 개발자가 작성한 파일들을 번들링한다. 번들링이란, 내가 작성한 모든 파일을 1개의 자바스크립트 파일로 합치는 행위를 말한다. 파일을 합칠 때는 파일을 합치는 시작점이 되는 파일이 필요하고 이러한 파일을 시작점 혹은 엔트리 포인트(Entry point)

웹팩은 파일을 전처리하기 위해 로더를 사용한다. 자바스크립트 파일이 아닌 다른 정적인 리소스를 번들링하기 위해 로더를 넣을 수 있는 것이다. Node.js를 이용하면 쉽게 로더를 작성할 수 있다.require() 구문에 loadername! 접두사를 넣어서 로더를 활성

css-loader 자바스크립트에서 css 파일을 모듈로 불러올 수 있는 기능을 제공한다. app_amd.js css-loader를 이용하면, 위와 같이 app.css를 import할 수 있다. app.css 위는 예시로 작성한 css이다. index.htm

로더가 파일 단위로 처리한다면, 플러그인은 번들된 결과물을 처리한다. 번들된 자바스크립트 난독화나 특정 테스트 추출 용도로 사용한다.플러그인은 웹팩의 척추(backbone)라고 불린다. 웹팩 자체도 내가 웹팩에서 설정하는 플러그인과 같은 방식으로 만들어졌다.플러그인은

사실 이전시간에 플러그인을 간단히 만들어보았지만, 일반적인 업무에서 플러그인을 만들 일은 잘 없다. 다만, 자주 사용하는 플러그인을 학습할 필요는 있다. 로더처럼 플러그인도 자주 사용되는 것들이 있다.웹팩에서 직접 제공하는 플러그인을 사용하거나 써드파티 라이브러리를 찾

성경 창세기전에 나오기를 당시 사람들이 바벨탑을 쌓아 그 꼭대기가 하늘에 닿게 하려고 했다. 그런데, 하나님은 사람들의 그 오만함에 분노했고 사람들이 협업하는데 꼭 필요한 소통수단인 언어를 제각각으로 만들어버렸다고 한다.히브리어로 '바벨'은 '혼돈'을 뜻한다.웹개발에서

실무에서는 바벨을 직접 사용할 일은 거의 없고 웹팩에 바벨 설정을 넣어서 사용하는 경우가 대부분이다. 보통 이것도 로더 형태로 제공하는데, babel-loader가 바벨을 불러오는 역할을 한다.babel-loader를 통해서 .js 파일을 로드해주면 된다.core-js

IE에서 동작시키려면 몇가지 요구사항이 있다.babel이 있어야 한다.@babel/core, @babel/cli, @babel/preset-envwebpack이 있어야 한다.웹팩은 5버전 기준이 가장 무난하다.polyfill이 있어야 한다.core-jscss-loade

프론트엔드에서 쓰는 CSS 역할을 하는 전처리 언어이다.SASS 공식문서.sass: sass의 코드만 사용할 때 이 확장자를 사용한다..scss: sass와 css의 코드를 둘 다 사용하고 싶을 때 이 확장자를 사용한다.이렇게 변수 등을 할당해서 사용할 수 있다.이렇게

Lint란 옷에 일어난 보풀같은 것을 말한다. 위의 사진이 바로 Lint이다. 코드도 작성하다보면 작은 보푸라기들이 있을 수 있다. 그런 것들을 없앨 수 있게 도와주는 것이 ESLint이다.위의 경우에 아마 사용자가 의도한 동작은 console.log()를 이용해 로그

ESLint는 포맷팅 및 버그 방지였다면, Prettier는 포맷팅에 집중하여 코드를 더 예쁘게 만드는 도구이다. 반면 ESLint 처럼 버그 방지와 같이 코드 품질과 관련된 기능은 하지 않는다.app.js를 다음과 같이 작성했다.여기에 prettier 명령어를 적용해

린트나 프리티어를 사용할 때 명령어로 등록하여 사용해도 되지만, 명령어로 사용하면 코드를 작성한 이후 실행을 깜빡할 때가 많기 때문에 추천하지 않는다.git으로 소스코드를 관리한다면 githook을 이용하여 lint를 통과해야만 push나 commit을 허용하는 정책을

webpack-dev-server는 웹팩을 이용한 애플리케이션을 개발하는 것을 도와주는 도구이다. 웹팩의 설정 파일에도 이를 설정하기 위한 devServer라는 설정이 있다.개발 환경에서 단순히 html을 열어서 해당 코드가 잘 돌아가나 확인하는 것이 아니라 서버와 비

Mock-up API란 실제 데이터가 아직 완성되지 않았을 때, 가짜 데이터로 화면을 구성해보는 것이다.webpack-dev-server에서 expressjs의 서버 인스턴스를 devServer.app이라는 이름으로 넣어준다. 단순히 위와 같이 작성함으로써, 가짜 AP

웹팩 개발 서버에서는 HTML이나 JS의 소스 코드를 변경했을 때, 모든 소스 코드를 다시 가져오면서 화면을 다시 그려주는 방식으로 우리에게 개발 편의성을 제공했다.그런데 SPA(Single Page Application)에서는 빈 html인 index.html과 같은

번들링한 결과물의 코드가 커지면, 브라우저에서 해당 파일을 로드하는데 너무 많은 시간을 소모할 수 있다. 결과적으로 사용자가 기다려야 할 로딩 시간이 너무 길어진다. 그렇다면 번들링한 결과를 어떻게 최적화할 수 있을지 몇가지 방법에 대해 알아보자.위와 같이 SET NO

웹사이트에 사용된 기술을 알려줍니다.어떤 웹사이트에서도 기술 스택을 알아냅니다. 회사 및 연락처 세부정보와 함께 특정 기술을 사용하는 웹사이트의 목록을 만듭니다. 시장 분석과 경쟁업체 조사, 잠재고객 발굴을 위해 우리 도구를 사용해보세요.Identify technolo