리액트 바깥의 프론트엔드

신의 (포트원)

React가 등장하기까지

React의 멋집, 그리고 잃어버린 것들

FE 앱을 구성하기 위한 다양한 선택지들

react 바깥의 FE 생태계

가장 적절한 도구 찾기

React가 등장하기까지

어떻게 최초 화면을 그릴지

어떻게 사용자 입력을 응답

상태변화의 화면 업데이트

전통적 MPA

갱신 시, 서버에 화면을 다시 요청

구현중심의 UX

jquey,Ajax

JS코드로 작성

코드 복잡도 감당 힘듬

등등

초기 JS프레임워크들

js로 SPA 만들어보려는 시도

MVC, MVVM등의 패턴 도입 및 입력 구성의 복잡도 낮추기 위해 노력함

아쉬운 점

MVC와 양방향 바인딩으로는 높은 복잡도의 프로덕션 앱을 감당 어려움

HTML 기반 커스텀 템플릿 구문 자유도 한계

라이브러리 구현 방식 특성상 성능 한계

React의 멋짐

최초로 화면을 그리는 로직과 입력 화면 갱신 로직을 단일 인터페이스로 작성 가능

UI를 선언적 인터페이스로 작성하면 실제 UI를 변경하는 일은 React가 알아서 해주면 VDOM덕에 꽤 괜찮은 성능을 보여줌

React로 오며 잃어버린 것들

js 번들 크기 및 요구 성능 증가

필요 이상으로 무거워짐

번거롭고 복잡해진 DOM 조작

바닐라 JS 시절 사용한 라이브러리들이 무거워지기 시작함

SSR 시 JS 서버 강제

서버에서 화면을 그리기 위해선 JS 서버가 필요해짐.
서버를 두 개 쓰는건 인프라 코스트에 쓸모?

리액트는 아주 유용한 프레임워크이지만, 모두의 요구사항에 대한 최적의 도구인가?

모든 것은 트레이드오프이고, 각자의 요구사항에 따라 적절한 도구를 선택해야 한다.

FE 앱 구성을 위한 선택지들

최초 화면

사용자 입력 반응 상태 업데이트

상태 변화에 따른 화면 업데이트

어떻게 최초 화면을 그릴지?

서버에서 서버 코드/템플릿으로 그리기

서버 자원등을 자유롭게 활용할 수 있음

번들 사이즈 제약으로부터 자유로움

브라우저가 HTML을 전달받는 즉시 화면을 그릴 수 있기 때문에, 첫 화면이 빠르게 그려짐

화면 그리려면 서버를 거쳐야 함

서버에서 HTM에 이미 데이터가 존재해도 전송해야하고 페이지 크기 증시킴

페이지 상태 유지하는 것 까다로움

클라이언트 동적 동작을 구현하려면 서버에서 화면을 그리는 코드를 클라이언트용으로 구현

서버 관리 필요성으로 인프라적 부담 증가

서버에서 빈 껍데기만 그리고 클라이언트에서 클라이언트 코드로 그리기

브라우저 자원들을 자유롭게 활용

CDN 등으로 정적 파일을 서빙 가능 - 서버측 세팅 단순

화면을 다시 그리는 것이 빠르고 단순

실행해야될 코드 양 많아져 인터넷 환경 및 디바이스 성능 영향도가 커짐

클라이언트 코드 실행이 불가능한 환경에서 사용이 불가능함

첫 화면을 그리는데 코드 실행이 필요하기에 약간 시간이 걸릴 수 있음

서버와 클라이언트 간에 공유 가능한 코드로 그리기

브라우저가 HTML을 전달받는 즉시 화면을 그릴 수 있기 떄문에

코드양 증가 → 성능 영향도 커짐

인프라적 부담 증가

코드를 서버/클라 공유 가능하도록 작성

페이지 동적 동작을 위한 하이드레이션 과정이 필요 → 시간이 걸릴 수 있음

어떻게 최초 화면을 그릴지?

대안적 접근들

일부는 서버에서만 그리고 , 일부는 공유 가능한 코드로 그림

공유 가능한 코드로 그리면서도 하이드레이션의 필요성을 없앰

어떻게 사용자 입력에 반응하여 상태를 업데이트할지?

양방향 바인딩: 상태가 변하면 UI 값 변하고 UI 값이 변하면 상태가 변하는 것

이벤트 핸들링을 사용하는 경우, 양방향 바인딩의 경우 한눈에 알아보기 어려워지는 문제가 발생.

어떻게 상태 변화에 따라 화면을 업데이트할지?

컴포턴트 단위로 상태 변화 추적하기

상태가 업데이트 될 때마다 화면을 렌더링하기에 비효율적일 수 있음

Fine-grained Reactivity

개별 상태 단위로 상태 변화 추적.
꼭 필요한 만큼만 일을 하는 특성인데 코드가 비 습관적으로 동작하는 것 같음.

리액트 바깥의 프론트엔드 생태계

컴파일 타임

런타임

SPA 계열 프레임워크

템플릿 구문에 기반하여 쉽게 익힐 수 있음
반응형 프리미티브의 활용으로 성능 향상

스벨트

상태 흐름 분석 업데이트 로직 최적화, 성능 향상
직관적임.

솔리드

JSX 사용하여 React 유사.
컴파일 타임 트랜스폼의 조합으로 최적의 업데이트 로직 구성

SPA 중심 풀스택 메타프레임워크들

Nuxt

SvelteKit

서버 중심 메타 프레임워크
데이터 로딩 및 라우터 체계와 프로그레시브 향상 등 특화 기능 제공

SolidStart

Next.js에 비기는 최신 기능을 다수 제공

MPA 스타일의 프론트엔드 프레임워크들

아스트로

정적 콘텐츠 위주

마르코

ebay를 위해 만듦
최상의 로딩 퍼포먼스 기대.

MPA 기반 서버 중심 프레임워크들

htmx

고전적 템플릿 엔진 기반으로 서버 스택 유연

라라벨 LiveWire

PHP의 라라벨로 그린 웹페이지에 클라이언트 동작을 추가하기 위한 프레임워크

Turbo

레일즈등의 프레임워크와 함께 사용하면 서버 위주로 손쉽게 화면을 그려나갈 수 있음.

WASM 기반 프론트엔드 프레임워크들

Dioxus

서버 중심의 컴포넌트 렌더링 기능

렙토스

솔리드의 러스트 버전

플러터

크로스 클라이언트 고성능 컴포넌트 제작 가능

미처 다루지 못한 것들

Lit

Vike

Analog

Yew

지속으로 생태계를 알아보려는 노력이 중요할 것 같다.

가장 적절한 도구 찾기

근거에 기반하여 도구 고르기

빠른 FCP와 LCP 확보하기 위해, SSR/SSG 지원 프레임워크

저품질 인터넷 고객 등

고려한 요구사항

성능 지표의 개선이 비즈니스적으로 중요

콘텐츠는 대체로 정적이나, 빠른 배포가 가능해야 함

UI는 대체로 정적이나, 일부 동적인 컴포넌트가 필요

솔리드 스타트, 아일랜드 라우터

UX 희생 없이 모든 요구사항 처리함.

Astro

MDX 콘텐츠 관리

페이지가 매우 가벼움

동적인 UI 구현이 어려움

[결제창]

결제 버튼 클릭 후 최대한 빨리 로딩될 수 있어야 함

상대적으로 동적인 UI

SolidStart

스트리밍 SSR이 필요하여 구성

관리자 콘솔

FCP, SEO 중요도가 떨어져 인프라 비용 및 코드 복잡도 최소화

정리

리액트와 SPA 시대가 찾아오면서 FE 앱 황금기

리액트와 SPA가 정답인가? 다양한 대안적 도구들이 생태계 속에 존재

패러다임 속에서 한 발짝 뒤로 물러서서, 제품의 특성을 고려한 최적의 기술적 선택이