프론트엔드 101 - 10+년차 프론트엔드 엔지니어 친구에게 들었던 기초 내용 정리

Frontend 101 

 

예전에 들었던 내용을 간단하게 메모했습니다.
추후에 공부하며 좀 더 살을 붙여볼게요!

빠른 메모라 글투가 짧게 끊어지는 점 양해 부탁드립니다.

---

Overview 

 
프론트엔드 개발? 
 
web 
 
client는 Browser(Chrome, FF, Edge, Safari, Whale) 를 통해 웹에 접근 

client (user’s device / user agent / host device ) 
 
 
- 
Support Language : HTML, CSS, JS, WebAssembly(WASM) 
브라우저가 지원하는 언어에는 한계가 , 4개까지 (*****) 
png 같은 파일은 언어가 아니라 Binary 
 

e.g. 
https://www.naver.com 에 접속한다고 하면 
naver.com은 도메인 
해당 도메인이 저장된 DNS 에 들어가서 IP를 찾아 
 
Request 
브라우저 ———> 서버 - 호스팅 서버 (백엔드를 돌리는 서버,). <——> Database 
<——— 
Response (보통은 HTML을 받아요) 
 
response를 받는 대부분의 포맷은 HTML 
HTML을 어떻게 만드느냐가 현재까지의 웹의 발전 방식 
 
- 
정적 파일이 아니기 때문에 데이터가 있겠지. 서버와 DB가 통신 
 
 
- 
과거에는(약 2012년쯤에) 서버가 html을 생성하여 클라이언트 전달. : Server-side Rendering (SSR) 
대표적인 게 ASP, PHP, JSP 
요즘에는 이 언어들이 상대적으로 안 쓰임. 서버사이드 렌더링을 잘 안쓰기 때문에 
 
현재는(요즘은 다 여기) 클라이언트가 API를 통해 데이터를 받아서 HTML을 생성 : Client-side Rendering (CSR) 
대표적으로 AJAX 
 
FE개발자가 알아야되는 범위가 되게 모호해. 
Backend For Frontend (서버가 api만 하고, fe가 서버사이드렌더링까지 다 하는 것)이 요즘의 패러다임 
 
 
 
— 
 
도메인에 대해 더 깊이 있게 얘기해본다면 
 
naver.com/search 
호스트도메인 / Path 
 
과거에는 서버에서 root(/)로 리퀘스트를 하면 혹은 root search(/search)로 오면 어떤 처리를 하는지를 지정해줬어야 했다. : 라우팅 (routing) 
 
브라우저에서 index.html을 가지고 있고 
JS에서 Path 별로 api 호출을 다르게 : Single Page Application, SPA (JS에서 처리해줘) (양날의 검. 요새는 이것만 쓰지 않고 섞어 씀) 
ㄴ> / => API 
ㄴ> /search => search API 
——> 문제점 : 라우팅 수 확대, 번들 사이즈 커짐 (자바스크립트 파일 사이즈) : 초기 로딩이 느려짐 
 
서버사이드와 클라이언트사이드의 가장 큰 차이는 

1. 새로고침(CSR, Client-side Rendering 에서 필요없다) 
2. 필요한 데이터만 가져올 수 있다. 

 
 
- 
 
SPA (Single Page Application) 
SSG (Static Side generation) - 사이트를 미리 static으로 다 생성해서 서버에 올리는, 
SSR (Server Side rendering) 
 
위 3가지를 섞어서 씀. 
 
 
— 
 

Paradigm 패러다임 

FE에는 크게 두 가지 영역 
1. UI (HTML, CSS) 
2. Presentation (React, Angular, Vue.js, Svelte—View Model(VM, HTML, CSS를 다 아우름)) 
— 모델과 프레젠테이션이 실제로는 명확하게 나눠지지 않는다는 것.(이 어려운 부분) 
> Model (Redux, MobX,,,,, Recoil, Context API) 
> Data (Fetch API, AJAX) 
Business Logic (모델과 프레젠테이션이 섞여 음) 
 
 
어떻게 state가 바뀌면서 re-render를 막을 것인가 현대 FE의 중요한 쟁점. 
너무 커졌기 때문에. 
강결합이 되기 쉬워서. 모델을 나누려고 하는 노력이 커짐.(Recoil, Context API) 
데이터 파이프라인이 복잡해짐 . 렌더를 다시한다는 건 리소스가 낭비된다는 뜻이기 때문에. 
그래서 클라이언트 프로그래밍이 어렵다고. 
 
— 
 
우리가 제일 많이 쓰게 될 언어는 바로 Javascript 
JS는 브라우저 상에서 동작한다. 기본적으로 서버에서 리퀘스트를 받아서 받아오는 건데. 
JS파일을 어떻게 관리하느냐가 되게 중요해짐. (= (모든게 다 마무리가 된)번들 파일) 
 
 

JS의 역사 

10일만에 만들어진 언어. 모카 
쓰레기같은 언어 ^^… 였음. 
2015년까지 버전업이 4번. 
2009년에 node.js 런타임(브라우저가 아닌 공간)에서 돌리는 최초의 js 
js로 만든 패키지가 나옴. 
2015년에 대대적인 변화가 생김 : 인터페이스 개선 
이때부터 ES 2015 + 라고 지칭함. 공식버전은 ECMA Srcipt 6 (ES6) 매년 업데이트 되어왔음. 
TC39라는 표준화기구가 이 업데이트를 담당함. 
 
2010년에 ajax를 처음으로 사용한 웹 어플리케이션 : 지메일 gmail 
 
js가 할 일이 기존에 1만큼 했다면 지금은 100만큼. 
 
ES2015의 가장 큰 고민거리 : 하위 호환성 - Babel (구형 브라우저가 인식할 수 있게끔. Pre-processor) 
 
양이 엄청 길어짐. 그래서 모듈 시스템이 나옴. 
모듈 시스템의 문제 : 브라우저가 지원을 못함 (지금은 함) -> 그래서 모듈 시스템을 지원하기 위해 나온 패키지가 Webpack (Parcel, Rollup 등, 웹팩이 제일 좋음) 
 
그 외 npm(node.js에서 쓰는) 
 
현재 자바스크립트 개발을 하려면 Babel, Webpack, and npm 
때문에 Scaffolding이 복잡해짐 (초기 세팅) 
 
 
— 
 
reactjs.org/

React – A JavaScript library for building user interfaces

babeljs.io/

Babel · The compiler for next generation JavaScript

 
— 

자바스크립트 프로토타입 

 
객체 A (name, age, sex, getter, setter) 
객체 B (name, age, sex, getter, setter) 
 
필드가 3가지고 메서드가 여러가지라고 했을 때, 
객체가 앞으로 계속 만들어진다고 했을 때, 필드 하나당 getter, setter가 한쌍씩 생기니까 주루룩, 메모리가 낭비가 됨. 
 
JS에서 객체의 마지막 필드에 proto 라는 게 있음. proto는 조상격에 속하는 객체. 
개별 객체들이 각각 다르게 가져야하는 값이 있는 필드의 경우 조상격객체에 없어도 됨. 
그래서 getter,setter를 조상격에 넣음. 객체에서 getter, setter 가 없을 경우 프로토로 찾아감. 
proto chain 이 많이 발생할 경우 느려짐. 깊어질 수록. 
 
HTML Element가 있을 때, 
e.g. 
div element의 공통형질들을 html element가 가지고 있음. 
markup language 의 공통형질들이 element. 그 밑에 node -> event target - > object 
(DOM = 프로토타입을 가장 잘 쓰는 모델.) 
 
 
 
 
javascript.info/

The Modern JavaScript Tutorial

 

---

읽어주셔서 감사합니다.