프레임워크 없는 프론트엔드 I

 

책의 제목부터 심상치 않음을 느꼈다.

책에게 간택당했다

아직 역사가 깊지 않은 만큼 생태계가 빠르게 변하고 있는 곳이 바로 프론트엔드 영역이다. 어떤 언어와 프레임워크, 라이브러리가 우세하다 라는 말들은 간혹 들어봤을테지만, 결국 양측의 의견을 수렴해보면, 어떤 기술적 논쟁이든 트레이드오프로 이루어져 있다는걸 알 수 있다. 이런 불확실한 상황에서도 살아남는 방법은 무엇일까 고민하던 중, 이 책이 눈에 띄었다.

책이 하고싶은 말

이 책의 목록을 살펴보도록 하자. 책은 총 8개의 챕터로 이뤄져있으며, 첫 장은 다른 책과 마찬가지로 프레임워크에 대한 이야기를 서술하고 있다.

책에서는 책 제목 그대로 프레임워크 없이 개발하는 법을 알려주기 보단, 각각 프레임워크의 특징과 전략을 설명해주며, 적절한 작업에 필요한 도구를 선택하는 방법을 알려주고 있다.

프론트엔드 개발을 한다면 꼭 신경써야하는 렌더링, 라우팅, 상태 관리 등의 내용들을 독자에게 알려줌으로써 독자들의 “코어운동”을 격려하고 있다.

프레임워크, 그리고 라이브러리

프레임워크와 라이브러리의 차이는 코드를 호출하는 지점에 있다. 프레임워크는 코드를 호출하며, 라이브러리는 코드에게 호출을 당한다. 이런 차이점을 알고 있다면, 적어도 프레임워크와 라이브러리의 차이점을 설명할 줄 아는 사람이라 할 수있다.

프레임워크에선 코드를 끼워넣을 수 있는 틀을 제공하는 반면에, 순수 js는 공개 API를 존중하는 한(?) 자주 사용하는 많은 npm패키지를 분류할 수 있다. (로컬 레파지토리에 모듈을 따로 저장하는 방식이 이래서 있구나 싶다)

앵귤러 vs 리액트

앵귤러에선 타입스크립트가 표준이라고 한다. 타입스크립트를 배워야 해당 프레임워크를 잘 다룰 수 있다는 뜻이다. 신기한건, 앵귤러는 타입스크립트를 자바스크립트로 트랜스파일한 다음, 파일내용을 한번 더 번들링해서 브라우저로 쏴준다. 그래서 성능이슈가 없다는 건 앵귤러 내부구조의 최적화가 매우 잘 되어있다는 것이다.

 

앵귤러를 설명하는 예제가 조금 헷갈리는데, 코드 내부에선 people와 peopelList의 속성인 people가 같은이름이라 안좋은 에제인 것 같다.

 

리액트도 제약 사항이 있다. 주요 제약 사항은 선언적 패러다임의 사용이다. DOM을 직접 조작하는 대신 구성 요소의 상태를 수정해야한다. 리액트에게 DOM 조작을 맡겨야한다. 선언적 패턴을 리액트의 커뮤니티에서 수용한 제약 사항이기에 어떤 관점에선 리액트를 프레임워크 방식을 갖고있는 프레임워크라고 볼 수 있다고 저자는 얘기한다.

 

여기서 나는 리액트는 왜 기존의 클래스 컴포넌트 형식을 버리고 함수형 프로그래밍으로 진화한 이유가 궁금했다: Hooks와 함수형 컴포넌트의 작성이 라이프사이클을 훨씬 간결하게 만들어주고, 컴포넌트의 가독성과 재사용성을 높여준다고 한다. 특히 Hooks를 이용하면 컴포넌트의 분리를 용이하게 할 수 있다는 커다란 장점을 취할 수 있다.

제이쿼리 ? 제2 쿼리?

제이쿼리는 프론트엔드라는 필드를 위해 기반이 되어준 매우 역사적인 자바스크립트 프레임워크다. 제2의 쿼리를 우습게 여기는 분위기가 형성됐지만, 제이쿼리는 현대 웹 개발의 초석 역할을 했다는 사실을 자각하도록 하자. (제이형 무시해서 미안해..)

 

제이쿼리가 문자의 발명이라면 앵귤러JS는 인쇄술의 발명에 견줄 수 있다고 책에선 서술한다. 리액트를 공부하면서 가장 많이 언급된 프레임워크가 바로 앵귤러JS였는데, 그 중 양방향 데이터 바인딩이라는 특성은 많이 들어봤었다. 이 특성이 웹을 빨리 구현할 수 있도록 해줬지만, 대규모 앱에는 적합하지 않아서 도태된듯 싶다.

 

(주의 : 앵귤러JS는 1을 의미하고 앵귤러는 2다, 앵귤러JS는 js를 쓰고 앵귤러 2는 타입스크립트가 주 언어다)

기술부채, 부채를 투자로

기술 부채라는 내용이 나왔는데, 이는 Ward Cunningham이 도입한 개념이다. 지저분한 솔루션을 선택할수록 단기간 빠를진 몰라도 시간이 지날 수록 기존 기능의 변경 또는 새로운 기능의 확장에 따르는 비용이 부채처럼 기하급수적으로 늘어난다는 내용이다.

(여기서 드는 생각은, 사이드,토이 프로젝트처럼, 단기간으로 사용될 코드들은 굳이 디자인에 너무 신경쓰지 않아도 좋다라는 것이다. 만약 좋은 디자인 설계의 코드를 보여주고 싶다면, 장기적인 프로젝트를 진행해서, 기술부채를 피부로 느끼며 심혈을 기울이며 코드를 짜도록 하자)

 

“최적이 아닌 방법을 선택할 때 부채가 발생하기 시작한다. 여기서 말하고 싶은 요점은 내 문제를 해결하는 데 있어 다른 사람의 코드가 최적이 될 수는 없다는 것이다.” 해당 책에서 저자는 프레임워크를 맹목적으로 따르고 반하는 것 보단, 각각의 특징을 잘 이해하여 기술부채를 기술투자로 승화하길 바라는 바램을 담았다고 생각한다.

---

꼬리말

다음 챕터에선 렌더링과 DOM 조작의 기본원리를 알려준다고 하는데, 많이 설렌다.