Skip to main content


Integrations directory:, integrations guide:

VSCode official extension:



Rebuilt my (next.js) blog using @astrodotbuild out of curiosity...holy shit the difference in bundle size. Home route: 138kb → 7.6kb "All posts": 570kb → 100kb (85kb was images)

Astro is an Multi-Page Application framework, not a Single-Page Application framework - see docs

TODO check:

TODO mirar:

Front matter

The front matter is optional, you don't need to add the --- section. You can always add it later when you need it.

Everything in the component front matter never runs in the browser.

A .astro file's front matter is written in JavaScript. source

You can use all modern JavaScript logical operators, expressions and functions in either section of your .astro file (front matter and HTML), but when inside the HTML template section of an Astro component, curly braces are necessary. source

.astro components and template syntax

The built-in component language.

An Astro component can be an entire page, a layout or a UI component.

Astro components will automatically create a new page on your site when you put the .astro file within src/pages/.

Any valid snippet of HTML is already a valid Astro component. Any HTML file is valid Astro language. source

Has CSS scoping by default, meaning that it only affects the elements in its own file. see docs

Anything in the /public folder will always be included on the final build and can be referenced from inside components.

Astro's templating syntax is similar to JSX syntax. If you’re ever wondering how to use your script in your HTML, then searching for how it is done in JSX is probably a good starting point! source. Docs:

You can import a React, Vue, Svelte or any of the supported frameworks all in a single Astro component and it would just work! source


  • <!-- HTML comment syntax is valid in .astro files -->
  • {/* JS comment syntax is also valid */}

Client-side JavaScript

The JavaScript in a component's front matter and HTML templates is executed at build time to create static HTML for your site, and then the code is "thrown away", whereas the JavaScript in a <script> tag is sent to the browser and runs client-side, adding interactivity on user actions like refreshing a page or toggling an input. source

You can add a <script> at any .astro file:

<html lang="en">
<h1>Page title</h1>
document.querySelector('.hamburger')?.addEventListener('click', () => {

Or even import a script file inside a <script> tag:

<html lang="en">
<h1>Page title</h1>
import '../scripts/menu.js'

define:vars directive

const textColor = 'blue'
<html lang="en">
<style define:vars="{{ textColor }}">
.text {
color: var(--textColor);
<p class="text">Hola</p>

.md markdown files

The front matter uses YAML (instead of JavaScript like in .astro files).

A .md file inside the /pages directory will generate a page.

Markdown layouts

You can add a special layout: ../../layouts/MarkdownPostLayout.astro property to the front matter of a markdown file. Then you can access the markdown file front matter properties in the MarkdownPostLayout.astro layout file with const { frontmatter } = Astro.props - see docs.

Content Collections

Type-safety for Markdown and MDX content.

Sample code that uses content collections:

Use astro sync to manually update the .astro directory. Note that astro dev and astro build update it automatically.

export const collections = {
// collectionName: collection
newsletter: newsletterCollection,

The render function gives you 3 things: const { Content, remarkPluginFrontmatter, headings } = await post.render()


pages/tags.astro and pages/tags/index.astro both generate the route /tags, see

Dynamic page routes with [xyz].astro and getStaticPaths

If a page uses dynamic params in the filename, the component will need to export a getStaticPaths function.

getStaticPaths returns an array of page routes, and all of the pages at those routes will use the same HTML template defined in the [xyz].astro file.

getStaticPaths should always return a list of objects containing params (the name of a page route generated dynamically) and optionally any props (data that you want to pass to those pages).

  • If you need information to construct the page routes, write it inside getStaticPaths, eg with Astro.glob().
  • To receive information in the HTML template of a page route, write it outside getStaticPaths, eg with Astro.params and Astro.props.



Create a project: npm create astro@latest

Create a project using a starter template or GitHub repository:

npm create astro@latest -- --template <example-name>
# Eg to use the 'Empty' run:
npm create astro@latest -- --template minimal

npm create astro@latest -- --template <github-username>/<github-repo>
npm create astro@latest -- --template <github-username>/<github-repo>#<branch>

Add an integration (eg Preact): npx astro add preact. See the Integrations guide.

Upgrade astro:

npm install astro@latest

npm i -E astro@latest && \
npm i -D -E prettier@latest prettier-plugin-astro@latest


Prettier plugin:

Adds support for formatting .astro files outside of the editor (e.g. CLI) or inside editors that don’t support our editor tooling. If you’re using the Astro VS Code Extension or the Astro language server within another editor, code formatting with Prettier is included. source


npm i -D -E prettier prettier-plugin-astro

As explained in, to use the plugin on VSCode you need to install the Prettier extension and then add "prettier.documentSelectors": ["**/*.astro"] to settings.json.

On WebStorm, on Preferences → Languages & Frameworks → JavaScript → Prettier include 'astro' and 'mjs' too, eg: {**/*,*}.{js,ts,jsx,tsx,mjs,vue,astro,css,json,md,yml,yaml}.

Get VSCode, eslint & prettier working with Astro -

## TypeScript support



TypeScript is configured using tsconfig.json. Even if you don’t write TypeScript code, this file is important so that tools like Astro and VS Code know how to understand your project.

If you do intend to write TypeScript code, using Astro’s strict or strictest config is recommended.

stricttest.json is the most strict config.


astro start and astro build commands will transpile the code with esbuild, but will not run any type checking. To check TypeScript errors add a script in package.json source:

"check": "astro check && tsc --noEmit"

Templates, starters and example repos

Official example projects: Each of these templates is meant to show a common pattern or use case.

Official examples: Use npm create astro@latest -- --template <example-name> to create a new project using the example.


Starter templates on GitHub:

You can create a new project based on a GitHub repository’s main branch with npm create astro@latest -- --template <github-username>/<github-repo> (see docs).


Islands architecture


  • Rendering pages using an islands architecture results in the heavier dynamic portions of the page being initialized not just progressively, but separately. This means individual regions of the page become interactive without anything else on the page needing to be loaded first.
  • In an "islands" model, server rendering is not a bolt-on optimization aimed at improving SEO or UX. Instead, it is a fundamental part of how pages are delivered.
  • Sections of that HTML may be missing their client-side interactivity, but the document should at least contain the most essential content.
  • A "buy now" button that directly relates to revenue should be easily prioritized over a site feedback survey button that relates to information gathering.
  • Decompose the app into independently deliverable widgets.

Persistent islands -

client: directive

Controls how UI Framework components are hydrated on the page.

  • <ReactComponent /> → Sends HTML and CSS to the browser. Will be a static element.
  • <ReactComponent client:load /> → Sends HTML, CSS and JavaScript to the browser. This is an hydrated component. Will have interactivity.

If we hydrate a (eg) React component with client: we load the whole React framework! See this article:


You can add interactivity with <script> tags too - see example and docs

client: directive on UI framework components vs <script> tags on Astro components

Both allow you to add interactive UI elements. Differences:

client: directive on UI framework components:

  • Is required on UI framework components to create interactive elements. (If not present they are static.)
  • Allows you to reuse code in other UI frameworks.

<script> tag on Astro components:

  • Allows to add interactivity without any JavaScript framework.



tells Astro to leave the <script> or <style> tag as-is in the final output HTML. The contents will not be processed, optimized, or bundled.

meta tags




New (assets)


Assets (Experimental) -

Image service API:

View Transitions


Netlify hosting

  • Build command: astro build
  • Publish directory: dist

Quickstart template:

(Nice) How to integrate commonly used features within Netlify for Astro:

Blog posts:

How to deploy an Astro site:

Netlify SSR

SSR is required only if you want to have dynamic features -like shopping cart, login/logout etc.- or build pages on demand rather than building the whole site upfront.

SSR adapter: