There's a simple secret to building a faster website — just ship less.
Unfortunately, modern web development has been trending in the opposite direction—towards more. More JavaScript, more features, more moving parts, and ultimately more complexity needed to keep it all running smoothly.
Today I'm excited to publicly share Astro: a new kind of static site builder that delivers lightning-fast performance with a modern developer experience. To design Astro, we borrowed the best parts of our favorite tools and then added a few innovations of our own, including:

• Bring Your Own Framework (BYOF): Build your site using React, Svelte, Vue, Preact, web components, or just plain ol' HTML + JavaScript.
• 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default.
• On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
• Fully-Featured: Astro supports TypeScript, Scoped CSS, CSS Modules, Sass, Tailwind, Markdown, MDX, and any of your favorite npm packages.
• SEO Enabled: Automatic sitemaps, RSS feeds, pagination and collections take the pain out of SEO and syndication.

This post marks the first public beta release of Astro. Missing features and bugs are still to be expected at this early stage. There are still some months to go before an official 1.0 release, but there are already several fast sites built with Astro in production today. We would love your early feedback as we move towards a v1.0 release later this year.

Note that it's currently not available for dev.

There is a lot of overlapping content from both pages, I believe we could merge them both in a way that we can have the "quick start" followed by the rest of the "installation" content.

I believe this should be done after these two PR's are completed so that no content is missed or we have double work.

• #32
• #16

To replicate:

• clone the repo at 70a4d0c
• build the repo & serve it with npx serve dist, navigate to http://127.0.0.1:5000/basic-concepts/layouts
• compare to yarn start and http://127.0.0.1:3000/basic-concepts/layouts (or https://astro-docs-preview.vercel.app/basic-concepts/layouts)

http://127.0.0.1:3000/basic-concepts/layouts:

This should look like the normal AvatarList.astro.

For some reason there's a dark color used now - I expect this is the default color for <code> blocks regardless of whether it's embedded in a <pre>

Currently, we put the MoreMenu.astro at the bottom of the page on mobile views, which means that they only rarely get seen..

Two options would be:

1. Moving the theme toggle to a fixed floating position, replicating https://fasterthanli.me's setup
2. Moving the theme toggle to the navigation menu

pt-BR is the only non-two-character language code we've used in translations (leading to /pt-br/), and it's not being recognized in utils.ts to create a non-English sidebar.

I've tried adding it to SIDEBAR in config.ts in a couple of different ways, tried playing with the regex in config.ts, but I can't get it working correctly myself. Neither pt-BR (nor pt-br) are being successfully matched in getLanguageFromURL so the Portuguese site is showing the default English sidebar.

I have it confirmed from our i18n community that the following translations are correct for Brazilian Portuguese, so this can be added into SIDEBAR in config.ts in whatever way is going to make this file, and the function happy together.

	pt-BR: [
		{ text: 'Instalação', header: true },
		{ text: 'Introdução', link: 'pt-br/getting-started' },
	],

Task -> Assignee

• Integrations ->
• Deploy Astro ->
• Data Sources / CMS ->
• State Management ->
• Styles & CSS Libraries ->
• Developer Tools ->

Under Styling & CSS Bundling it mentions

All styles are hashed according to their contents (the hashes only change if the contents do!)

This is (I presume) fine with most services. With Netlify as per [Support Guide] Making the most of Netlify’s CDN cache hashes break caching.

Perhaps your build framework is trying to be helpful. Gatsby for instance uses asset fingerprinted filenames intentionally, which breaks Netlify’s usual caching.

In order to eliminate the hashes I did find it is possible to disable this via a setting in vite.config.js as originally read here with official documentation here

export default {
  build: {
    rollupOptions: {
      output: {
        // Disable hashes for CSS files.
        assetFileNames: `assets/[name].[ext]`
        // These may also work, though haven't tested
        // entryFileNames: `assets/[name].js`,
        // chunkFileNames: `assets/[name].js`,
      }
    }
  }
}

I can confirm the assetFileNames setting is honoured in Astro (unsure about the entryFileNames and chunkFileNames as I haven't a project to test these on currently) and think it worth adding this to official documentation for those who (like me) may wish to remove hashes.

Currently, if you select light theme or dark theme in the theme toggle, it is then fixed, and there is no way to return to prefers-color-scheme without going into Inspect Element and clearing the local storage key.

I'd like to propose using https://cssdb.org/'s Theme Switcher that adds an indeterminate state to the theme toggle.

light mode:

dark mode:

"let the browser choose" mode:

https://code.visualstudio.com/Docs @aFuzzyBear suggested adding some links to the sidebar that felt like it suggested "Join our community"

Maybe we could add an invite to the Discord under the "edit on github" link? Etc....

https://docs.renovatebot.com/install-github-app/

It's probably helpful for us to stay in step w/ the latest astro so that we're running into the same questions and breaking changes anyone else might have:

If we setup @renovatebot or @dependabot to make automated update PR's, then we can have vercel build those PR's as a test to see at least whether there's any problems with it!

It would be pretty cool if we could some how make a Netflix style slider that shows off all of the example sites!

- slider, not a carousel: https://lsnrae.medium.com/if-you-must-use-a-carousel-make-it-accessible-977afd0173f4

cc the non-existent @snowpackjs/maintainers/design role xD

It sounds like a carousel is less popular, but there's another design to copy from in: https://nextjs.org/showcase

Possible showcase sites include:

• https://navillus.dev/
• https://backlight.dev
• https://divriots.com

This came up for me while working on withastro/astro#935, apparently Astro actually does have support for passing options to a renderer. We should add docs to cover this and also make sure there is test coverage for it as well

withastro/astro#935 (comment)

Currently we have a yarn lint:linkcheck:local command that can check for broken links, but we don't have any way to switch what language you're using without JS, so it only checks the English pages.

I want to write a script using the programmatic version of blc to check all translations of the docs for broken links!

Add docs for building non-HTML pages PR #2586

The feature is currently hidden behind the --experimental-static-build flag, but has some very powerful use cases for building generic files (ex: JSON or XML), and a couple useful caveats like the Astro global isn't available

I noticed across the site { is being replaced by {. But not in every instance.

E.g. 1: Collections page: const { collection } = Astro.props;

It'd be great to make a component that styles a code example and the rendered component side-by-side!

Could honestly just look like hooking up Prism and a little css grid box that renders the source on the right side 🤔 though i'm not sure how you say "create a component out of this source code that was passed to me as a prop", though maybe we do like the astro tests and pull from a code examples folder 🤔

<CodeExample src="src/examples/fetchingdata.tsx" />

This reads to me as linked to the issue in the astro repo about wanting a compiler api though!

Currently there is a button to open the sidebar on mobile, but it is not linked to showing the sidebar, and the sidebar is not visible if I manually disable the display: none; via devtools.

Currently the "Editor On Github" and table of contents are thrown away and hidden on mobile, maybe we can add them to the layout somehow on mobile?

• Maybe add the TOC to the top before the page content
• Maybe add Edit on Github to the footer, in addition to social links

When searching for define:vars using the algolia search (top right) it doesn't find this page:

https://docs.astro.build/en/guides/styling/#variables-in-scripts--styles

Or any relevant page to "define:vars". Not sure if this can be fixed?

Also note, the documentation here might be improved to explain the double {{ syntax...
Something like {myval} expands to {myval: myval}, and that is within an outer { which is a JSX expression.

The object literal property value shorthand was introduced in ES6 to make the object initialization shorter. It allows us to define an object whose keys have the same names as the variables passed-in as properties, by simply passing the variables like {myval} which is interpreted as {myval: myval}.

Hello all! I think Astro is pretty great at what it does and I even contribute a small amount each month to help support your work.

I came across the docs for deploying to github pages and found the deploy script would overwrite my main branch with the output of the dist folder. I'd like to be able to maintain my main branch as it is but to instead deploy to a separate branch named gh-pages. I ran into issues with the deploy script for this scenario and instead went with using an npm package to help: gh-pages. All I had to do was run yarn build && touch ./dist/.nojekyll && gh-pages -d dist -t true and it worked like a charm. In my settings for the repo, I just point to gh-pages as the branch I want deployed.

I thought this would be a good idea to add to the docs but maybe it's too specialized to npm land, hence the bash script you have as the first/primary way to deploy. Anyhow, I'd thought I'd at least bring up the idea and see what you all thought in case there was agreement there. Thanks for all the work on this project, I am excited to see where things go.

Links should be added to this issue for now, and Later on (when doing the renderers page) we add the third party renderers section.

The hover state colors in sidebar menu for dark theme seems to be using the same color that is being used for light theme.

Task -> Assignee

• Installation -> @aFuzzyBear
• Quickstart -> @jgil-r
• Examples -> @FredKSchott

[email protected] introduces Components in Markdown! We need to add a section about how this works in our docs.

Task -> Assignee

• Project Structure ->
• Astro Pages ->
• Astro Components ->
• Component Hydration -> @itskitto
• Layouts -> @ewatch
• Styling -> @itskitto
• Content (Markdown) -> @jgil-r
• Data Fetching ->
• Pagination ->
• Collections ->
• Build & Deploy ->
• URL Sanitization -> Tackled in "Security FAQs" of Markdown document

For example on Netlify we should add

yarn build --site $DEPLOY_PRIME_URL

for Deploy Previews and Branch Deploys in the explanation

reported by @okikio#3174 on discord https://discord.com/channels/830184174198718474/853350631389265940/864984473699221514

Maybe it would make sense to use something like tailwind focus rings to avoid it?

cc: @okikio

I only recently learned about how useful "git rebase" is, especially from the core team on this project!

It sounds like several other people who have made PRs haven't used it before, it might be nice to add a blurb to https://github.com/snowpackjs/astro/blob/main/contributing.md or https://docs.astro.build/references/contributing

Starting a new project in Astro is easy:

# create your project
mkdir new-project-directory
cd new-project-directory
npm init astro
# install your dependencies
npm install
# start the dev server and open your browser
npm start

Further reference: https://github.com/snowpackjs/astro#-guides

Hello, is this repo intended to have an MIT license?

withastro/astro#515

Astro no longer uses magic Svelte props! Whooo!

When you query an API outside of a .astro component, you need to use node-fetch, which should be documented for folks creating utility functions.

Update the example in /pages/guides/data-fetching.md to use the pokeapi like @FredKSchott suggested in #66

Especially now that we removed the "Quick Start" page and replaced all instructions with the Installation page, we should really have a custom 404 page.

This could be a fun thing for someone to build and a great project for a new contributor!

Preview:

There is an issue with arabic theme, some MarkDown go after footer and Display as LTR not sure why.

We need an

img {
 width: 100%
}

somewhere so that on mobile it doesn't blow out the screen with overflow

It seems that a lot of users that never worked with frontmatter or related technologies are trying to manipulate the DOM inside frontmatter, so we should have it detailed that DOM manipulation is not possible within frontmatter because it runs on the server, at build time, and not on the client/browser.

File is here: https://github.com/snowpackjs/astro/blob/97d5a2ba187a7e6b61d849226daf4cbd03485782/.github/workflows/format.yml

I'll make a PR for adding a yarn format command atm...

Can we add documentation that makes it easier to add extra plugins to remark? At the moment, we list the plugins used, but we don't document how to replicate the current config.

I feel like there should be more padding to the right of the theme switcher, no?

Even though nearly-everything is configurable, we recommend starting out by creating an src/ folder in your project with the following structure:

├── src/
│ ├── components/
│ └── pages/
│ └── index.astro
├── public/
└── package.json
src/components/: where your reusable components go. You can place these anywhere, but we recommend a single folder to keep them organized.
src/pages/: this is a special folder where your routing lives.

Hi, I was looking around the current documentation to understand in brief what astro really does when you build your site's using astro.

Would also like to know whether astro is a SPA (Single page application) or a pure SSG or both somehow.

As per Internet reading it looks like a SSG but as per my first project its acting as a SPA .. local routes and stuff like that. So pretty confused whether I am it right or am I missing something in my understanding.

Hi! Tried several increasingly cheekier ways of linking to my SCSS files, to no avail. Several times, in fact, because I keep forgetting this not being possible from my experiments.

Is this something that is possible? The docs consistently <link /> to CSS. Could a notice be added noting that this is not an option?

Examples:

<!-- none of these work for me -->

<link rel="stylesheet" src={Astro.resolve("@styles/heet.scss")} lang="scss" /> <!-- using my tsconfig alias -->
<link rel="stylesheet" src={Astro.resolve("../../../styles/heet.scss")} lang="scss"  /> <!-- using astro.resolve -->
<link rel="stylesheet" src={path.join(PUBLIC_SRC_DIR, 'styles/heet.scss')} lang="scss" /> <!-- using an actual absolute path -->

In all 3 cases, the actual file is resolved, and in the 2nd case I can get Astro to point to the correct, if uncompiled, SCSS file. But I was expecting it would render it for me? If this isn't supposed to happen, it'd be pretty cool if the docs would mention it.

Hi all,

I find this is a nice framework compare to react and svelte, can someone or do I submit a pull request to add astro docs link to astro repo readme.md?

or someone will do this?

Thanks.

I noticed by default in the examples/templates, the color contrast ratios come up in the accessibility portion of the Lighthouse Audit.

Primarily seems to be these 2 colors:

--theme-accent(--color-orange): #ff5d01 - against white provides ratio of 3.08

and

--theme-text-lighter(--color-gray-400): #9ca3af - against white provides ratio of 2.53

For smaller font sizes, the minimum ratio should be 4.5 to meet AA standards.
For larger font sizes, the minimum ratio should be 3.0 to meet AA standards.

It would great to provide no accessibility issues out of the box on our examples/templates.

Task -> Assignee

• Reference ->
• API Reference ->
• Configuration Reference ->

Based on https://github.com/withastro/rfcs/blob/main/active-rfcs/0000-style-unification.md we should revamp the docs where styles are discussed and steer people towards the supported methods.

Small win can be made with internally linking the deploy text on the Quick-start page to the deploy page.
I will open a PR related to this issue.