SPA(single page app)에서 webpack을 사용하는 이유
나는야 Front-end를 지향하는 Back-end 수강생!
위코드에서는 무조건 백엔드에 집중하기로 해서, 최대한 프론트에 관심을 끄려고 노력중이다.
현재 내가 만져본 프론트엔드 관련 기술은 HTML, CSS, Jquery.. ajax... 또 뭐가있지..
약간의 jQuery 라이브러리들..?
속상하게 jQuery는 죽어가는 언어다.. 안쓰는 기술이다.. 라고 많이들 하는데 😢
내 애증의 jQuery인걸.. 지인들 일하는 모습 보면 아직 jQuery 쓰는 회사 많던데ㅜㅜㅜ
암튼 각설하고, jQuery를 많이 쓰지 않는다고 하면
난 vanilla javascript는 잘 모르니까 프론트 지식이 거의 전무하다는 소리나 다름없다
🤯🤯🤯
암튼 그래서, 본론은
말로만 들어보던 SPA, SPA.....
React를 사용하면서 본격적으로 SPA 형식의 프론트엔드 개발이 이루어지는 것 같다.
아직 React를 잘 모르니까.. 이런 글을 쓰는 것도 웃기지만
이게 너무 궁금하다.
- 도대체 왜 Html 파일, 그에 해당하는 js 파일이 존재하는 기존의 방식에서 SPA로 흐름이 바뀐걸까?
- Html 파일이 여러개면 최종 프로젝트 소스의 용량이 더 커지나..?
- js파일만 많아지는 것도 비슷할 것 같은데..?
그 이유 🙌🏻
2000년대 초반의 웹페이지는 각 페이지마다 새로운 html을 요청해서 화면을 다시 그리는 방식이었다. 자바스크립트는 DOM을 조작하는 간단한 역할만 했었기 때문에 html의 script태그에 넣는 것으로도 충분했다.
(지난 세션에서 들었던 2세대 웹 개발..!)
ajax가 유행했을 때는 자바스크립트의 비중이 조금 더 커졌지만 그래 봐야 페이지당 자바스크립트 파일 몇 개면 충분했다고 한다. SPA(single page app)는 하나의 html에 수십, 수백 개의 자바스크립트 파일을 포함하기 때문에 더 이상 기존 방식을 고수할 수 없는 현실.
<html>
<head>
<link rel="stylesheet" type="text/css" href="javascript_file_1.js">
<link rel="stylesheet" type="text/css" href="javascript_file_2.js">
...
<link rel="stylesheet" type="text/css" href="javascript_file_999.js">
</head>
...
</html>기억나니.. .과거의 하람아..
화면 만들 때 기능별로 추가되던 그 수많은 include.. link....
도대체 내 눈에 보이지 않는데 동작하는 그 함수를 찾기 위해서 모든 연결된 js, html 파일 다 까보던 과거의 너...
(전자정부프레임워크 구려)
계속 늘어나는 javascript 파일, 그 파일들이 선언되는 순서, 전역변수 중복 여부..
위험요소가 너무 많이 존재하는 개발 방식..!
아무튼 그래서 왜 SPA를 사용하는가 하면
브라우저에 얽매이지 말자.
예전부터 자바스크립트를 브라우저 밖에서 사용할 수 있게 하려는 노력이 있었다. 대표적인 표준 위원회는 CommonJS, AMD가 있다. 이들이 자바스크립트를 범용적으로 사용하기 위해서 하는 대부분의 일은 모듈 시스템을 정의하는 일이었다. 그리하여 nodejs 같은 프레임워크가 등장할 수 있었고 자바스크립트가 서버에서 돌아가는 세상이 되었다.
SPA개발은 webpack과 함께
webpack은 CommonJS와 AMD 스펙 모두를 지원한다. webpack을 사용하면 여러 개의 자바스크립트 파일을 하나의 파일(원한다면 여러 개)로 컴파일할 수 있다. 그리하여 SPA개발 시 html에는 컴파일된 하나의 자바스크립트 파일만 포함시키면 된다. 고마운 점은 ES6 표준으로 작성되지 않은 라이브러리도 알아서 잘 처리해준다는 점이다. 따라서 필요한 라이브러리를 npm으로 설치 후 필요한 부분에 import만 하면 바로 사용할 수 있다.
webpack의 장점 1: 파일 분할 기능
수백 개의 자바스크립트 파일을 하나의 파일로 컴파일하는 건 좋은 생각이 아니다. 이렇게 하면 사용자가 첫 페이지를 보기 위해 몇 초를 기다려야 할 수도 있다. webpack에는 다양한 파일 분할 기능이 있다.
- vendor코드만 따로 분리해서 하나의 파일로 만들 수 있다. vendor코드는 자주 변경되지 않기 때문에 사용자의 브라우저에 캐싱 후 오랫동안 재사용될 수 있다. 이 방법만 사용해도 사용자 경험을 상당 부분 끌어올릴 수 있다. 하지만 첫 방문자의 경우에는 의미가 없다.
- require.ensure 구문을 사용해서 파일 분할을 지정할 수 있다. 이 방법은 require.ensure 구문을 실행할 때 필요한 파일을 on-demand로 다운로드한다(webpack이 알아서 해준다-_-b). 따라서 첫 방문자의 경우에도 전체 코드를 다운로드할 필요가 없기 때문에 반응 속도가 빠르다. 첫 페이지 로딩은 빠르지만 이후 필요한 부분의 파일을 다운로드해야 하기 때문에 분할된 코드의 크기가 너무 크지 않도록 주의해야 한다. react에서는 route별로 파일을 만드는 방법이 많이 사용된다.
webpack에서는 컴파일된 파일의 이름에 hash값을 붙이는 기능이 많이 사용된다. 해당 파일이 변경된 경우에만 hash값이 변경된다. 따라서 변경되지 않은 파일은 사용자의 브라우저에 캐싱된 파일이 재활용된다.webpack의 장점 2: 다양한 loader를 사용할 수 있다.
대부분의 loader는 파일을 입력으로 받아서 자바스크립트 파일을 출력해준다. loader를 사용하면 webpack이 컴파일을 하기 전에 원하는 파일에 대해서 전처리를 할 수 있다. jsx라는 react 고유의 문법으로 작성된 파일을 자바스크립트 파일로 변환할 때 많이 쓰인다. 그 외에도 babel-loader를 이용해서 ES6, ES7과 같은 최신 자바스크립트 문법을 사용할 수도 있다.
여러 개의 loader를 체인 형식으로 묶을 수도 있다. 예를 들어 babel-loader와 eslint-loader를 묶어서 먼저 eslint로 정적 분석을 하고 성공하면 babel-loader가 jsx파일을 자바스크립트 파일로 변환하게 할 수 있다.
또 다른 대표적인 예는 style-loader와 css-loader를 같이 쓰는 경우이다. css를 사용할 때 어려운 점 중의 하나가 클래스 이름을 겹치지 않게 정의하는 것이다. css-loader는 import 하는 모듈의 id값을 클래스 이름에 자동으로 붙여주는 기능을 갖고 있다. 따라서 단순히 클래스 이름을 ‘button’으로 정의하더라도 이름이 겹칠까 봐 걱정할 필요가 없어진다. style-loader는 css-loader가 출력하는 css정보를 받아서 style태그로 만들고 그것을 DOM에 붙여준다.// a.css :local .button { background-color: red; } // b.css :local .button { background-color: blue; } // app1.jsx import styles from 'a.css' ... <button className=styles.button>click me</button> ... // app2.jsx import styles from 'b.css' ... <button className=styles.button>click me</button> 👉🏻 app1의 버튼은 빨간색이 되고, app2의 버튼은 파란색이 된다.
내가 참고한 블로그의 원문에서는 javascript 표준의 빠른 변화, 풍부한 개발 환경에 대해 많은 생각이 든다고 적혀있다.
공부에 게으른 개발자로서, 하루가 다르게 변하고있는 프론트엔드의 풍부한 생태계가 무섭기도 하지만
그래도 너무 매력있는걸...
얼른 위코드 과정 잘 마치고 프론트 공부하고 싶어서 두근두근하다
다 할수있다..! 다 배웠다..!
(배워야 할 입장이지만 ㅎㅅㅎ)
