<colbgcolor=#ff5d01><colcolor=#fff> Astro | |
개발 | Fred K. Schott외 300명[1] |
종류 | 웹 프레임워크 |
출시 | 2022년 8월 10일[2] |
언어 | JavaScript, Astro |
버전 | 4.16.7 |
라이선스 | MIT 라이선스 |
링크 |
[clearfix]
1. 개요
아일랜드 아키텍처를 활용한 오픈 소스 웹 프레임워크이다.2. 상세
현재 웹 프론트엔드의 기술은 나날히 복잡해지고 있다. 이 와중 React가 등장해 웹 개발에 '컴포넌트'라는 혁명적인 개념을 들고 나왔고, 이어 Vue.js, Svelte등이 잇따르며 독창적인 컴포넌트와 상태 관리의 개념을 제시하였다.다만 각 프레임워크가 서로 호환되지 않는 문제가 발생하였고, 단순한 정적 웹사이트를 만들기 위해선 불필요하고 거추장스러운 여러 기술들이 더해지며 개발 생태계는 한층 복잡해지기 시작하였고 개츠비 등의 몇몇 시도[3]가 존재하였지만 여전히 모던한 프런트엔드 기술을 사용하면서도 간편하게 정적 웹사이트를 빌드하는 것은 어려웠다. 그러다 2021년 이 모든 문제를 해결하기 위해 만들어진 프레임워크가 바로 Astro이다.
==# 역사 #==
2021년 3월 15일 개발이 시작되었다.
2022년 4월 4일 1.0 Beta를 출시했다.
2022년 8월 10일 드디어 1.0버전이 출시되었다. SSR빌드, 이미지 최적화, MDX사용, Vite 3.0사용 등 상당한 개선이 있었다.
2.1. 2.0
2023년 1월 24일, Astro 2.0이 출시되었다.- 콘텐츠 컬렉션
- 하이브리드 렌더링
- 오류 오버레이 재설계
- HMR(Hot Module Reloading) 개선
2.2. 3.0
Astro 3.0 마이그레이션 가이드Astro 3.0 이 출시되었다. Vercel 의 큰 관심 속에 활발한 활동을 통한 빠른 버전 업으로 주목받고 있다.
- View Transitions API를 자체 지원하는 최초의 메이저 웹 프레임워크
- 공통 UI 페이지간 유지 가능
- Astro 컴포넌트들이 30~75% 빨라짐
- 이미지 최적화 기능 안정화
- Vercel 과 공식 파트너십
- JSX HMR 향상: React/Preact에 Fast Refresh 지원
- CSS Inlining 지원
이하는 3.x 버전별 업데이트 내역이다.
- Astro 3.2 : View Transitions 개선 등
- Astro 3.3 : <Picture /> 컴포넌트가 실험적으로 추가됨.
- Astro 3.4 : 부분적 페이지 추가됨. 디버깅용 개발 오버레이가 실험적으로 추가됨.
- Astro 3.5 : i18n 라우팅과 콘텐츠 컬렉션 빌드 캐시가 실험적으로 추가됨. Qwik 통합이 추가됨.
- Astro 3.6 : View Transitions 이벤트 추가됨.
2.3. 4.0
Astro 4.0 마이그레이션 가이드2023년 12월 5일 버전 4.0이 출시되었다.
- Vite 버전 5로 변경
- Astro Dev Toolbar
- 국제화(i18n) 라우팅
- 증분 콘텐츠 캐싱
- 새로운 View Transitions API
- 로깅 재설계
3. 특징
3.1. 아일랜드 아키텍처
Astro의 가장 큰 특징이자, 후술할 모든 놀라운 특징들을 뒷받침하는 기술이기도 하다.쉽게 설명하자면 웹 페이지가 하나의 거대한 사이트가 아닌, '대체 가능하며 독립적인 덩어리(component)로 분리된 하나의 거대한 바다'로, 동적인 컴포넌트들은 '바다 위에 떠 있는 섬들' 바꾸어 생각하는 패러다임이다.
이러한 아이디어를 적용하게 되면 동적인 부분을 제외한 나머지 부분(바다 영역)은 순수 HTML로 대체가 가능해지며[4], 각각의 섬(컴포넌트)들을 나중에(lazy), 또는 다양하게(polyglot) 불러올 수 있다.
따라서 서버가 전달해주는 HTML은 SPA 프레임워크를 사용할 때처럼 동적이지는 않지만, 적어도 페이지의 핵심 데이터만은 가진 상태로 전달된다. 예를 들어 뉴스 사이트를 만든다면 SPA프레임워크는 우선 라이브러리와 js전체를 로딩한 후 컨텐츠(기사)를 Ajax로 불러오는 방식이라면, 반대로 아일랜드 아키텍처는 이미 컨텐츠(기사)가 HTML에 정적으로 박힌 상태로, 브라우저가 추가적인 반응성(컴포넌트)들을 개별적으로 불러온다. 쉽게 요약하자면 SPA는 js가 데이터를 불러와 html을 렌더링해 끼워넣지만, 해당 아키텍처의 경우 반대로 html에 필요한 데이터가 이미 들어 있고, 그 상태를 출발점으로 js를 필요에 따라 불러오는 것.[5]
이때 컴포넌트가 로딩되는 방식도 특이한데, 각 컴포넌트는 완전히 독립적이고 하나의 SPA앱처럼 취급되기 때문에 서로에게 영향을 끼치지 않는다. 즉 컴포넌트 중 100% 모두 로딩되어도, 전체의 50%만 로딩되어도, 심지어 0%가 로딩되어도 일단 웹사이트 자체는 동작을 할 수 있으며, 이를 이용해 사용자가 보고 있지 않은 컴포넌트는 lazy하게 로딩하는 것이 가능해진다.[6] 또한 각 컴포넌트가 완벽히 독립적이기 때문에 서로에게 종속성을 가지지 않아 각 컴포넌트를 동시에 불러올 수 있으며 이렇게 되면 waterfall이 줄어들어 불러오는 용량이 같더라도 로딩 속도를 줄일 수 있다.
해당 패러다임은 2019년 처음 등장했으며, Preact의 개발자이기도 한 제이슨 밀러의 한 블로그 포스팅으로 인해 개념이 현재와 같이 확장되었다.
3.2. 멀티 프레임워크
가장 파격적인 특징 중 하나로 React, Vue, Svelte, SolidJS, Preact, Lit, Alpine.js, Qwik과 같은 수많은 종류의 웹 프레임워크의 컴포넌트를 지원하며, 심지어는 한 페이지에 이들 중 여럿, 심지어는 전부를 섞어서 사용할 수도 있다는 점이다.여러 프런트엔드 UI 프레임워크들이 호환되지 않는 컴포넌트로 서로 경쟁하는 가운데 이는 매우 파격적인 기술이 아닐 수 없다. 이 역시 Island architecture를 사용함으로써 얻는 장점인데, 각 컴포넌트가 서로 독립적이기 때문에 상태(state)가 겹치지 않으며, 따라서 여러 프레임워크의 컴포넌트가 한 페이지 내에서 동시에 작동할 수 있다는 것을 의미한다.
3.3. MPA
하나의 페이지를 하나의 덩어리로 두고 Ajax등을 통해 새 내용을 이동시마다 업데이트하는 SPA(Single Page Application)방식과는 다르게, 아스트로는 MPA(Multi Page Application)를 채택하였다.MPA는 렌더링과 라우팅을 서버에서 처리하기 때문에 접근성이 올라가고, 속도가 향상되지만 반대로 매 요청마다 같은 내용을 받아와야 한다는 단점이 있다. 따라서 SPA에서 볼 수 있는 Astro에서는 동적 라우팅을 처리하기 위해 파일 구조와 파일명을 사용한다.
Astro가 MPA를 선택한 구체적인 이유에 대해서는 Astro의 공식 문서를 참고하자.
플러그인으로 astro-spa라는 게 있는데 현재 미완성이긴 하지만 네비게이션, 히스토리, 캐싱, 프리페칭, 심지어 구글 애널리틱스 등을 지원한다.
3.4. SSR
1.0이후 Next.js처럼 SSR을 지원하기 시작했다. 이 말은 매 요청마다 서버에서 모든 페이지를 렌더링한 후 완성된 결과물만 배달할 수 있다는 것이다.하지만 해당 기능을 위해서는 결국 서버가 필요해지기 때문에 완벽한 SSG를 달성할 수 없다는 단점이 있다. 현재 Vercel등의 엣지 서버에 배포해 사용할 수 있다.
3.5. 콘텐츠 컬렉션
Content Collections마크다운, MDX, YAML, JSON, 이미지 등과 같은 콘텐츠들을 쉽게 관리하고 연결할 수 있게 해준다. 콘텐츠에 스키마를 정의하고 검증[7]까지 가능하다.
3.6. View Transitions
View TransitionsView Transitions API를 사용하여 DOM 전환과 애니메이션을 간단하게 정의할 수 있다.
4. 문법
기본적으로 JSX와 비슷하지만 CSS등을 처리하는 방식은 Vue.js, Svelte등을 닮았다. 좋게 말하면 기존 개발자들에게 친숙한 문법 중 좋은 것만 추려낸 간략한 컴포넌트 언어이고 나쁘게 말하자면 이도저도 아닌 끔찍한 혼종이다(...). 확장자로는.astro
를 사용한다.astro파일은 스크립트 영역과 템플릿 영역으로 구분되는데[8], 스크립트 영역은 서버에서(빌드 시) 실행되고 템플릿 영역은 (역시 빌드되어 plain HTML로 나오긴 하지만)클라이언트에서 UI로 그려지는 영역이다.
#!syntax javascript
---
// 빌드시 실행되는 코드
import Box from './Box.astro'
// 다른 프레임워크의 컴포넌트를 가져올 수도 있다.
import Image from './Image.jsx'
import Content from './Content.svelte'
// 해당 파일이 컴포넌트로 쓰일 때 전달되는 props를 가져올 수 있다.
const {
title,
content,
tags,
} = Astro.props
// 그냥 일반 JS를 사용할 수 있다.
const image = '/img/article-default-image.png'
// top level await도 쓸 수 있다!
// 그래서 그냥 fetch()를 쓰든 DB요청을 하든 자유롭게 데이터를 가져올 수 있다.
// 단, 이때 가져온 데이터는 빌드 시 단 한번만 요청되며 바뀌지 않는다.
---
<!-- JSX 컴포넌트처럼 사용할 수 있다. -->
<Box>
{image && <Image source={articleDefaultImage}>}
<h2>News: {title}</h2>
<Content content={content}>
<!-- className이 아닌 class를 사용한다. -->
<ul class="tags">
{tags.map(tag => <li>{tag}</li>)}
</ul>
</Box>
<style>
태그를 사용해 현재 컴포넌트에 스타일을 부여할 수 있다. 다만 해당 스타일은 해당 컴포넌트에게만 적용(scoped)된다.#!syntax html
<style>
/* 다른 컴포넌트의 태그에는 영향을 끼치지 않는다. */
p {
font-weight: bold
}
</style>
<p>이 문장은 두꺼운 폰트를 사용합니다</p>
또한 JSX와는 다르게 한 컴포넌트 내에 여러 형제 컴포넌트가 들어가도 래퍼 컴포넌트(
<></>
)로 감싸지 않아도 된다.[9] 이런 점에서
Vue.js나
Svelte의 영향을 상당히 받았다.5. 사용 현황 및 전망
2022년에야 1.0버전이 나왔고, 국내에선 이름조차 모르는 사람이 대다수인 프레임워크이기 때문에 현재로써 사용 전망은 매우 좋지 않다.다만 오픈 콜렉티브를 보면 그 Vercel이 해당 프로젝트를 엄청나게 후원하고 있다. (총합 1만 2천 달러, 한화로 약 1671만원) 이를 보면 버셀은 나름의 가치를 알아본 것으로 추측할 수 있다.
마이크로소프트의 디자인 시스템인 플루언트 디자인 시스템의 신규 홈페이지에 Astro가 사용되었다. Fluent 2 Design System Web Pages in Half the Time: Why Microsoft Chose Astro to Build Their Fluent 2 Design System Website | Astro
6. 여담
-
Snowpack의 개발팀에서 만든 프로젝트이다. 다만 내부적으론 snowpack이 아닌
Vite를 사용한다.
-
Fireship이 개인적으로 굉장히 좋아하는 프레임워크이기도 하다. 1.0이 출시되기도 전에 한번 영상을 찍었고 1.0이 나오자 코드리포트에서 한번 더 다뤘다.
아래 영상은 한때 심지어 Astro의 공식 사이트에 소개 동영상으로 쓰이기도 했었다.
- Astro 팀에서 starlight라는 이름의 Astro 기반의 문서화 웹프레임워크를 개발하고 있다.
- 공식 문서 한글화가 잘 되어 있는 편이다.
7. 관련 문서
[1]
Snowpack(그리고 Skypack)의 개발팀에 의해 만들어진 프로젝트이다. 초창기부터 관심을 많이 받은 프로젝트였기 때문에 얼리베타에 참여한 개발자만 해도 수백명은 족히 넘었다고.
[2]
정식 1.0.0버전 출시 기준
[3]
개츠비는 Pre-render방식의 프레임워크이다. 즉
Next.js처럼 매 요청마다 서버에서 SSR로 렌더링하는 것이 아닌 모든 페이지를 사전에(빌드시) 모조리 렌더링해두고 요청이 올때마다 이미 완성된 페이지를 전달만 하는 것. Astro와 상당히 비슷하지만 Astro는 Partial Hydration을 사용하여 부분적으로 반응성을 추가할 수 있어 개츠비에 비해 훨씬 선택지가 자유롭다.
[4]
정적 사이트에서 HTML이 차지하는 부분이 많아진다는 것은 곳 SEO(검색엔진 최적화), 로딩속도 개선, 접근성 개선 등 정적 사이트만이 이끌어낼 수 있는 장점들을 최대한으로 끌어올릴 수 있음을 의미한다.
[5]
주객전도로 보이지만 사실 원래 전통적인 SSG식 개발 방식은 이게 맞긴 하다.
[6]
이를 Partial Hydration이라고 부른다.
[7]
Zod를 사용한다.
[8]
MDX등을 써 보았다면
---
위쪽 부분을 frontmatter라고 부를 수도 있다.
[9]
다만 컴포넌트를 표현식으로 사용하는 경우 <></>
로 묶을 필요가 있다.