저는 최근 Astro를 사용하여 원래 WordPress, Go, Rails 및 Hugo로 구축된 사이드 프로젝트를 다시 빌드하기 시작했습니다. Astro를 선택한 이유는 언어 서버 지원이 좋은 React와 유사한 DX가 있고 무료 계층이 넉넉한 서버리스 호스팅 플랫폼(Cloudflare, AWS Lambda 등)과 호환되기 때문입니다.
저는 Astro를 사용하기 시작했을 당시에는 Astro에 대해 잘 몰랐습니다. 이제 여러 사이트를 마이그레이션했으므로 프레임워크 사용을 고려 중인 다른 사람들을 위해 프레임워크에 대해 내가 좋아하는 것과 싫어하는 것을 공유하고 싶었습니다.
기본적으로 Astro는 필요할 때 동적 서버 렌더링 페이지를 생성할 수 있는 기능을 갖춘 정적 사이트 생성기입니다. Astro는 상호작용이 제한된 블로그나 소규모 마케팅 사이트에 매우 적합합니다. 프레임워크는 React.js 오버헤드 없이 Next.js의 DX 대부분을 제공합니다.
솔직히 말하자면, 전통적인 서버 렌더링 템플릿 언어에서는 좋은 언어 서버 지원과 코드 형식이 심각하게 부족합니다. Go 템플릿, Jinja, ERB 및 EJS는 React/Vue/Svelte와 비교할 때 툴링 측면에서 고통스럽게 뒤쳐져 있습니다. 대부분의 서버 렌더링 템플릿 언어에는 어떤 변수가 범위에 있는지, 해당 유형이 무엇인지 알 수 있는 방법이 없습니다.
Astro를 사용하면 이러한 모든 기능이 VS Code 확장 하나로 가능합니다.
Astro 템플릿 내에서 빌드 시 또는 서버의 요청에 응답할 때 실행되는 "코드 펜스" 내부의 템플릿 상단에 데이터를 설정합니다. 실제로는 다음과 같습니다.
---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";
const posts: { id, title }[] = await getPosts();
---
<Layout pageTitle="Posts">
<h1>Posts</h1>
{post.length > 0 ? (
<ul>
{posts.map((post) => (
<li>
<a href={`/posts/${post.id}`}>
{post.title}
</a>
</li>
)}
</ul>
) : null}
</Layout>
템플릿의 모든 데이터는 템플릿 위의 "코드 펜스"에 로드되므로 언어 서버는 범위 내에 정의된 모든 개체의 속성에 대해 자동 완성 기능을 제공할 수 있습니다. 존재하지 않는 변수를 사용하려고 할 때도 표시됩니다.
Go 템플릿, Jinja, EJS와 같은 전통적인 템플릿 언어에 대한 가장 큰 불만 중 하나는 자식을 허용할 수 있는 "구성 요소"가 없다는 것입니다. 대부분의 웹사이트에는 일종의 제한된 너비의 "컨테이너" UI 요소가 있어서 콘텐츠가 초광각 모니터에서 화면 끝까지 날아가지 않도록 합니다.
요소가 있는 경우 일반적으로 정상적으로 작동합니다. 그러나 Tailwind와 같은 유틸리티 CSS 프레임워크를 사용하는 경우 모든 단일 페이지 템플릿에 다음 코드를 추가할 수 있습니다.<div > <p>When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable. </p> <p>Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot /> tag. A long string of utility classes could be extracted into a reusable Astro component:<br> <pre class="brush:php;toolbar:false"><div > <p>The Astro component could then be consumed from another Astro file.<br> </p> <pre class="brush:php;toolbar:false">--- import Container from "../components/Container.astro"; --- <Container> <h1>Hello, world!</h1> </Container>
Astro 파일은 단일 슬롯으로 제한되지 않고 여러 개를 가질 수 있습니다.
Astro 구성 요소에서 제가 가장 좋아하는 기능은 코드 펜스 내에서 소품을 수용할 수 있다는 것입니다. 예는 다음과 같습니다.
---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";
const posts: { id, title }[] = await getPosts();
---
<Layout pageTitle="Posts">
<h1>Posts</h1>
{post.length > 0 ? (
<ul>
{posts.map((post) => (
<li>
<a href={`/posts/${post.id}`}>
{post.title}
</a>
</li>
)}
</ul>
) : null}
</Layout>
그러면 구성요소는 다른 파일 내에서 사용될 때 props를 허용할 수 있습니다.
<div > <p>When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable. </p> <p>Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot /> tag. A long string of utility classes could be extracted into a reusable Astro component:<br> <pre class="brush:php;toolbar:false"><div > <p>The Astro component could then be consumed from another Astro file.<br> </p> <pre class="brush:php;toolbar:false">--- import Container from "../components/Container.astro"; --- <Container> <h1>Hello, world!</h1> </Container>
저는 이전에 Vite를 사용하여 자체 서버측 통합을 구축한 적이 있습니다. 온라인에서 빠르게 무언가를 얻으려고 한다면 이는 스스로 구축하는 것을 피하고 싶은 일종의 필수 기능입니다. Astro에는 내장되어 있습니다.
Astro 페이지나 구성 요소에 사용자 정의 스크립트를 추가하려면 페이지에 스크립트 태그를 놓으면 됩니다.
---
type Props = { pageTitle: string; pageDescription: string };
const { pageTitle, pageDescription } = Astro.props;
---
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>{pageTitle}</title>
<meta name="description" content={pageDescription} />
</head>
<body>
<slot />
</body>
</html>
Astro는 사이트 구축 프로세스의 일부로 TS 및 JS 파일을 자동으로 컴파일합니다. Astro 구성 요소 내의 스크립트 태그 내부에 node_modules에서 가져오기를 사용하는 스크립트를 작성할 수도 있으며, Astro는 빌드 시간 동안 이를 컴파일하고 자체 파일로 추출합니다.
--- import Layout from "../layouts/Layout.astro"; --- <Layout pageTitle="Tyler's Blog" pageDescription="I don't really post on here." > <h1>Tyler's blog</h1> <p>Sorry, there's no content yet...</p> </Layout>
CSS 또는 Scss 스타일을 코드 펜스 내에서 가져와서 Astro 파일에 포함할 수 있습니다.
<div> <h1>This is my page</h1> <script src="../assets/script.ts"></script> </div>
Astro는 Astro 파일의 스타일 태그를 사용하여 범위가 지정된 스타일을 수행하는 기능도 제공합니다. 이 기능은 Vue 사용자에게 익숙할 수 있습니다.
다음 Astro 파일이 제공됩니다:
<script>
// This will also compile down to a JavaScript file at build time.
import axios, { type AxiosRequestConfig, type AxiosResponse } from "axios";
const response = await axios
.get<AxiosRequestConfig, AxiosResponse<{foo: string}>>("/some-endpoint");
console.log(response.data.foo);
</script>
쉽죠?
액션은 백엔드 기능을 실행하는 유형에 안전한 방법을 제공합니다. 유효성 검사를 제공하고 JSON과 양식 데이터를 모두 처리할 수 있습니다. 이는 Astro의 킬러 기능 중 하나입니다. 이 모든 기능은 Next.js 앱에서 맞춤형 방식으로 직접 연결해야 합니다. 예제에 깔끔하게 들어갈 수 있는 것보다 약간 더 많은 코드가 필요하지만 사용하기에는 매우 우아합니다. 액션 문서 페이지를 읽어 보시기 바랍니다.
React가 "충분히 빠르다"고 말하는 트위터 개발자는 끝없이 많습니다. 그렇지 않은 경우가 많습니다.
작은 프로젝트에 Rasbperry Pi 4s를 사용하는데, React의 런타임 비용을 느끼할 수 있습니다. 저렴한 Android 휴대폰에서도 마찬가지일 것이라고 확신합니다. 단, 이 경우 JS 오버헤드로 인해 배터리도 소모됩니다.
내 사이트에 필요한 유일한 상호 작용이 탐색 메뉴를 전환하는 것이라면 직접 연결하는 편이 낫습니다. 필요할 때 기꺼이 React에 접근하겠지만 너무 많은 프로젝트에서는 실제로 필요하지 않습니다.
제가 Astro에 대해 싫어하는 점은 프레임워크에만 국한된 것이 아닙니다. 이는 JavaScript 생태계의 다른 도구에서 빌린 아이디어입니다.
Astro는 파일 기반 라우팅을 사용하기 때문에 Astro 프로젝트의 파일 중 절반은 index.(astro|js|ts) 또는 [id].(astro|js|ts)라는 이름을 갖게 됩니다. 파일 기반 라우팅은 Next.js가 구현한 후 프런트엔드 세계를 폭풍으로 휩쓸었던 불쾌한 패턴이며 많은 단점이 있습니다.
인정합니다: 파일 기반 라우팅은 10페이지 미만의 사이트를 만들 때 매우 좋습니다. 그러나 사이트가 성장함에 따라 마찰이 가중되고, 그 기능을 통해 얻을 수 있는 이점보다 기능과 더 많은 싸움을 벌이게 됩니다.
JavaScript 생태계에서 Remix는 모든 경로를 단일 디렉터리로 평면화하고 사용자가 수동 경로 구성을 통해 파일 기반 라우팅을 완전히 옵트아웃할 수 있는 파일 기반 라우팅 버전을 제공한다는 점에서 차별화됩니다.
파일 기반 라우팅은 Astro의 가장 큰 불만이지만 벗어나기 어려운 기능입니다. 이는 Next.js, Nuxt.js, SvelteKit 등에서 구현됩니다. 더 이상한 점은 이러한 프레임워크가 애플리케이션의 다른 부분에 대한 파일 이름에 대해 거의 의견이 없다는 것입니다. Ruby on Rails와 달리 대부분의 JavaScript 프레임워크는 라우팅을 제외하고 제외 파일 이름과 프로젝트 구조에 있어 상당한 자유도를 제공합니다. 이는 특별한 경우이며, 특별한 경우는 소프트웨어에 복잡성을 더합니다.
제가 정말 좋아하는 JavaScript 언어 기능은 단일 파일에서 여러 변수, 함수 및 클래스를 정의하는 기능입니다. 이를 통해 언어 수준의 제약으로 인해 관련 기능을 다른 파일에 조기에 추출할 필요 없이 쉽게 같은 위치에 배치할 수 있습니다.
Vue의 단일 파일 구성 요소와 마찬가지로 Astro 파일을 사용하면 파일당 하나의 구성 요소를 정의할 수 있습니다. 지루한 일이지만 Astro가 해결 방법을 제공합니다.
Astro는 클라이언트 측 JavaScript를 로드하지 않고도 사전 렌더링된 React, Vue, Svelte, Solid 및 Preact 구성 요소를 템플릿에 직접 포함할 수 있습니다. Preact JSX는 React JSX보다 HTML에 훨씬 더 가깝기 때문에 Preact 구성 요소는 Astro와 합리적으로 잘 결합됩니다. 하지만 동일한 프로젝트에서 Astro 및 Preact 구성 요소를 모두 관리하는 것이 어색해지며, Preact 구성 요소를 사용하기 시작하면 대부분의 UI가 Astro 파일에서 Preact로 이동됩니다.
Next.js, Nuxt 또는 SvelteKit의 열렬한 사용자이고 프레임워크에 만족한다면 Astro에서 많은 것을 얻지 못할 수도 있습니다. 그러나 Next.js와 같은 DX를 유지하면서 사용자에게 JavaScript의 부담을 덜 주고 싶다면 Astro가 적합할 수 있습니다.
Astro는 콘텐츠 중심 웹사이트에 맞춰져 있으며 기본적으로 마크다운 지원을 제공합니다. 콘텐츠에 중점을 두기 때문에 WordPress 또는 Hugo 사이트를 대체할 수 있는 이상적인 개발자 블로그 플랫폼입니다. 그러나 Actions와 같은 기능을 통해 단순한 콘텐츠 사이트 이상의 기능을 수행할 수 있습니다.
파일 기반 라우팅을 매우 싫어함에도 불구하고 Astro를 채택할 때 가장 우려되는 점은 사이트를 다시 구축해야 하는 변경 사항이 발생할 수 있다는 점입니다. JavaScript 도구는 다른 언어 생태계에서 볼 수 있는 도구보다 획기적인 변화에 훨씬 더 공격적입니다. 나는 Astro를 처음 접했기 때문에 하나의 주요 버전에서 다음 주요 버전으로 얼마나 많은 변경이 있었는지 모릅니다. 이러한 우려에도 불구하고 저는 Astro의 최고 수준의 DX를 활용하고 저렴하게 사이트를 호스팅할 수 있도록 다른 플랫폼에서 내 사이트 중 5~6개를 Astro로 이전할 계획입니다.
위 내용은 아스트로의 첫인상: 좋았던 점과 싫었던 점의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
