18 ms·

Astro 1.0 – a web framework for building fast, content-focused websites

452 points by danielskogly 4y ago

stoicjumbotron 4y ago
Really excited for this release!
jackconsidine 4y ago
I've used Astro my company's landing page for the past year or so [0]. We write blog posts in Notion and port them right to the site and the experience has been fantastic. There are a few understanding quirks with regard to using React etc within Astro (it's SSR'd unless you add the "client" attribute, and counter-intuitively the Component Lifecycle doesn't run the same). For client landing pages, we'll use Astro too- occasionally they'll want a CMS to write their own blog posts without a Git / commit pipeline. In those cases, Netlify CMS plugs in seamlessly and has a generous free tier. [0] https://koptional.com https://koptional.com
- foofoobar 4y ago
  Netlify recently changed their pricing structure, so if you are using Netlify CMS (or just Netlify Identity) with a private repo, every contributor to the repository (committer) will be charged as full pro seat. This can get really expensive if you have a few users working with the CMS (and thus committing content to the repository). We will move a few pages from Netlify now because of this change.
  - eins1234 4y ago
    Also, found out the hard way that "Enterprise" pricing (i.e. call us and we'll charge you an opaque amount based on whatever we think you can afford pricing) starts at 7 users. Vercel is not much better at 10 users, and they hide it deep within their pricing table behind a tooltip so you're not likely to realize this until it's too late. Cloudflare Pages doesn't charge per user but limits concurrent builds which can get really painful. I honestly can't find a good option in this space anymore... What happened?
    - zoover2020 4y ago
      +1, looking for answers too.
    - pbowyer 4y ago
      > I honestly can't find a good option in this space anymore... What happened? They took lots of VC money, got crazy valuations and picked up a few enterprise customers as the JamStack trend grew - and now have to try to generate a return.
      - tomnipotent 4y ago
        > and now have to try to generate a return Otherwise called running a business.
        acoard 4y ago
        You missed the point. Many businesses only need revenue (or EBITDA) to exceed expenses and you're profitable. Once you take VC money, you must exceed profitability and provide a return on VC money. Not all businesses must make a return on outside investment because they did not take outside investment.
        deleted 4y ago
        [deleted]
    - tomnipotent 4y ago
      Assuming that 7-10 users are FTE, the company is already spending more than $1M on salary and related costs. I imagine the annual Enterprise pricing for Vercel for that numbers of users would hover around 1/4 of an FTE's salary, which is reasonable considering the value provided.
      - eins1234 4y ago
        The increase in value provided by these services is very much linear w.r.t. number of users. The 10x+ leap in cost with enterprise pricing is not at all justified by additional value provided. I don't mind paying a fair, pre-disclosed price for services that provide value. I do mind opaque enterprise sales tactics that try to take full percentage points off my available runway for no discernable increase in value when I try to add one more user. Doubly so when they go to such lengths to cover it up as Vercel is currently doing.
  - andrethegiant 4y ago
    That pricing change only impacts private repos owned by organizations — you can still have private repos on a personal account and not be charged.
  - swyx 4y ago
    netlify pricing changes for those who want the source https://www.netlify.com/blog/announcing-changes-to-netlify-plans/ https://www.netlify.com/blog/announcing-changes-to-netlify-p... and for private orgs https://www.netlify.com/pricing/private-org-repo-faq/ https://www.netlify.com/pricing/private-org-repo-faq/
- bdn_ 4y ago
  Interesting, how does the process of going from Notion to Astro work? Are you just exporting Markdown files, or is there an API integration in use?
  - jackconsidine 4y ago
    Sorry for the late reply- we use the API! We had done so manually for a long time
swyx 4y ago
congrats team on 1.0!!! huge milestone! inevitable question that always can use answering - what can you share about Astro's company business plan/business model at this time?
lloydatkinson 4y ago
It’s a really great tool I’ve been using since last year. I had previously attempted using Nuxt but that’s a real mess and I never actually got to writing anything. Now I’m using Astro and I’ve got a few articles and it’s a really pleasant developer experience. A lot of static site generators I have found needed more time configuring and writing code for leaving less time in the day for posts etc. I haven’t found this with Astro. The ability to totally not send any JS at all apart from what you manually add such as framework specific components is really something.
Annatar 4y ago
- 91edec 4y ago
  Are you really complaining that people are trying to innovate and create new things? You are not forced to use it.
  - Annatar 4y ago
    How is inventing yet another complicated machinery to churn out some HTML and JavaScript innovation?
- dang 4y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - Annatar 4y ago
    It's not a shallow dismissal, it's the scourge of our industry; I can't wait to retire so that I would never have to look at it again. Give it a rest with virtue signalling.
    - dang 4y ago
      X being a scourge does not make every X-comment deep. On the contrary, comments about scourges are often shallow and lame. Edit: I just took a look at your recent comment history, and ouch—that makes it painfully clear that you don't want to use HN as intended. I've therefore banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
      - Annatar 4y ago
cube2222 4y ago
This look very cool overall! Could you please explain the tradeoffs vs tools like Hugo and Docusaurus?
- brycewray 4y ago
  https://docs.astro.build/en/comparing-astro-vs-other-tools/ https://docs.astro.build/en/comparing-astro-vs-other-tools/
CharlesW 4y ago
I'm looking at https://docs.astro.build/en/concepts/why-astro/ https://docs.astro.build/en/concepts/why-astro/ and I still can't tell what's interesting and unique about this as compared to other options in this space. I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation. It seems like Astro's creators believe "content-focused" is a differentiator, but I find that confusing since content-focused sites are a popular use case for web frameworks that are also suitable for more complex apps.
- azangru 4y ago
  As far as I can tell, Astro is zero-js on the client by default, while both Next and Remix are very much the opposite. Plus, both Next and Remix are tightly coupled with React, whereas Astro is trying to be more agnostic in that regard.
- dirheist 4y ago
  The one thing I like about Astro is the component island UI. With react you would need to re-render the entire UI on a UI change while in Astro you can signify which portions of your website are static and which dynamically should re-render upon data fetching or whatever. It's just a faster way to build UI's that don't need the full complexity of a SPA and also don't need to come bundled with the entirety of react from what I've seen and used it for.
- GrahamL 4y ago
  It's interesting their blog post doesn't mention some of the benefits. Neither does the doc page you linked—at least it doesn't do it succinctly. Essentially Astro lets you build sites using a JS framework like React or Vue without requiring that framework to be loaded on the frontend. By default, components are just HTML content. Super nice for building very fast static sites using a technology you may already be fluent in. You can still add interactivity to components if you'd like—just tag components that require interactivity and Astro will bundle the requisite JS for the client.
  - reilly3000 4y ago
scastiel 4y ago
Very nice! I was thinking about migrating my blog which has been running with Eleventy for the past few years. It might be the perfect opportunity :)
- azangru 4y ago
  What do you find missing in Eleventy?
  - scastiel 4y ago
    To be honest, I miss React :)
    - lloydatkinson 4y ago
      You will definitely like Astro then! I wrote an article on using (P)react and Astro if you're interested! https://www.lloydatkinson.net/posts/2022/writing-a-fuzzy-search-component-with-preact-and-fuse-for-astro/ https://www.lloydatkinson.net/posts/2022/writing-a-fuzzy-sea...
akmittal 4y ago
Can anyone explain if it's replacement of Next/remix to build complex sites or more like a SSG?
- azangru 4y ago
  I believe the most complex use case they are targeting is an ecommerce site. Definitely not something as client-side-heavy as, say, Excalidraw, etc.
- pier25 4y ago
  It started as SSG only but they added SSR so yeah they're now in the same space as Next, Remix, SvelteKit, etc. In fact Solid's creator has said Astro is probably the best way to do SSR with it.
ryansolid 4y ago
So excited for this. SSR with Astro is a gamechanger which opens up its usage to so many different avenues. Great strides with framework interop too. Named Slots really closing the gaps. And of course any framework where SolidJS can shine so bright is going to be the top of my list. Congratulations on an amazing release.
gavinray 4y ago
Serious question: Why does Astro need a custom file format? The format looks identical to MDX
- swyx 4y ago
  it -is- MDX https://www.brycewray.com/posts/2022/07/astro-move-to-mdx/ https://www.brycewray.com/posts/2022/07/astro-move-to-mdx/
  - gavinray 4y ago
    Then it's just for vanity, lol?
  - brycewray 4y ago
    No, `.astro` is more than that. What I wrote about was their emphasizing MDX rather than generic Markdown.
- MatthewPhillips 4y ago
  It uses it to know what JS is needed for the client. If it sees <Section /> that means that no-JS is needed. But if it sees <Counter client:load /> it knows to build + bundle the Counter component and attach its JS to the page.
  - gavinray 4y ago
    That's just a property on an element tag, you can access "client:load" under the ".properties" key of the element Open your browser devtools, pick a random tag on the page, add "client:load" to it, and then "console.log(yourEl.properties)" I dunno why you need an entire custom filetype for behavior and semantics that are MDX with a few extra preprocessor rules
    - MatthewPhillips 4y ago
      The reason why you don't know is that you've decided in advance that it's not actually needed. .astro is not actually like MDX at all. MDX extends Markdown, Astro does not, it extends HTML. MDX is a variant of JSX, Astro is not, it supports things that JSX does not like void elements. Astro supports text inside of script and style tags, JSX does not. If you think you can rebuild Astro with "a few extra preprocessor rules", then by all means go for it. But you're going to fail.
mwcampbell 4y ago
> If your project falls into the second “application” camp, Astro might not be the right choice for your project… Plenty of applications in the second category (logged-in admin dashboards, to-do lists, etc.) have been developed using server-first frameworks, and some of us still prefer to develop web applications that way. Is Astro missing any key features for dynamic server-first applications, e.g. form submission and validation support? If not, I think the Astro developers might be selling Astro and MPAs short.
- deleted 4y ago
  [deleted]
- eyelidlessness 4y ago
  I agree some of their examples aren’t great, but I think what they’re saying is that Astro’s benefits become less relevant for apps which are highly interactive in the client. You can certainly use Astro to build those, but in many cases you may be just as well served (if not better) by using a more established tool oriented toward whichever client framework/libraries you choose (eg Next.js or Nuxt or SvelteKit etc). That said, there’s quite a lot of space between that extreme and the mostly-static “web site” extreme, and I agree Astro would be a better fit than they let on, for a large chunk of that space. My suspicion is that this is intentional, to keep their current focus and explicit use-case commitments narrower. And I wouldn’t expect it to remain that narrow in the future.
pembrook 4y ago
Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? Inevitably, when a new "hot" SSG comes on the scene, I try it, and then go back to compare it to the old "hot" SSG from 2 years ago. Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times. As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run. And like all SSGs, I see no mention of sane SEO defaults on the homepage. Let me guess--with Astro I'm going to have to set all of this up myself?
- jutanium 4y ago
  Astro is that tool. It can output a server that can react immediately every time you do an update.
- bluehedgehog29 4y ago
  Not sure if you've heard of Publii?[0] It's a static blog generator type thing, bit of a different concept to the framework posted. I've tried it a few times casually and it seems ok for non-devs to get something simple up and running. Bit of dev work can update templates etc The SEO defaults aren't perfect but they're easy enough to change in the software. [0] https://getpublii.com https://getpublii.com
- MatthewPhillips 4y ago
  Here's a good SEO component: https://www.npmjs.com/package/simple-astro-seo https://www.npmjs.com/package/simple-astro-seo
- malfist 4y ago
  Have you checked out Hugo? It's builds are pretty fast, and it has a watch function for rapid dev work. Not sure how you'd get away from a build on updates though, it is called a static site __generator_. If you want to skip the build entirely, just write .html files and call it a day.
- game-of-throws 4y ago
  Use any SSG not written in javascript and you'll be fine. Hugo, Zola, Jekyll, etc. Though if I was starting from scratch I might avoid Jekyll just because of the Ruby dependency.
fareesh 4y ago
I used a static site generator for all of these benefits in the past, but the rebuilding process is a total nightmare. The site has about 20 categories, and each category has about 100 images. Every time the team adds a new image or category, the deployment/building task clones the repo and then the build process generates all the optimally sized images again and then re-uploads multiple gigabytes to the host. Is there a way around this type of problem with static site generators?
- butz 4y ago
  Offload image optimization to separate service?
- naet 4y ago
  You might need ISR (incremental static regeneration). IIRC there are a couple standard SSG frameworks that support something like it. Usually only worth investing in if you are operating at a large enough content scale though.
- fwip 4y ago
  A makefile
oxff 4y ago
Why does it feel like there are million solutions and wheel reinventions like this. Why can't they converge on 1-2 solutions?
- jaywalk 4y ago
  https://xkcd.com/927/ https://xkcd.com/927/
itcrowd 4y ago
It always annoys me when I read something like: To try Astro on your local machine, run npm create astro@latest in any terminal. because it doesn't make it clear to me what to do before this command will actually do anything. No, running this command will not work in any terminal.
- ksbrooksjr 4y ago
  As long as you have npm installed it'll work. Npm create is an alias for the npm init command [1], which will look for a package with the prefix 'create-', install it, and run its bin file. It looks like this is the file that ends up being run: https://github.com/withastro/astro/blob/main/packages/create-astro/create-astro.mjs https://github.com/withastro/astro/blob/main/packages/create.... [1] https://docs.npmjs.com/cli/v8/commands/npm-init https://docs.npmjs.com/cli/v8/commands/npm-init
  - itcrowd 4y ago
    > As long as you have npm installed it'll work. Exactly proving my original point.
    - brabel 4y ago
      If you don't have npm installed, just stay as far as you can from this :D Seriously, JS static website generators are the worst... use something written in any compiled language so you just download and run a single binary, no messing around with npm and millions of dependencies. Take your pick here: https://jamstack.org/generators/ https://jamstack.org/generators/
      - bdlowery 4y ago
        PHP is pretty great. No NPM needed
        progx 4y ago
        PECL? PEAR? Composer? ...
rcarr 4y ago
Been using this the last week to convert an 11ty website and really enjoying it so far. Very cool to just be able to use whatever JS framework you want for a component and just drop it in.
jlarky2012 4y ago
Congrats guys. Astro+SolidJS is the future :)
recroad 4y ago
Provide and migration path from Wordpress and I'm in!
oneplane 4y ago
Sometimes all the frameworks that re-invent MVC (but in a detached fashion) and tout "server side rendering" just feel like we've come full circle where we're just serving a static view cache that was generated from models and data using a controller. The big difference here (as with other JavaScript-based renderers) is of course the "use one tool/language for everything" aspect which to me is a bit of a 'meh'-benefit. At this point, while all the renderers get better and simpler, we're still in a situation where complexity or writing code hasn't really gone away, it just shifted around to new places. Perhaps at some point we get to the HTML + WebComponents stage again (kinda like MDX and React mixing), and classic Apache Server-Side Includes become the new hot thing again.
- quickthrower2 4y ago
  I think edge computing and CDNs might be what is making this all more interesting. It is not just where you render (Server vs. Client), it is where you render (Dallas vs. Rio). If you can get your app to re render small sections and have the framework figure out that these sections are static and can chuck them in a CDN (or they are not and need an edge server, or a central server) then you can get lots of optimizations that way. That said, for most side projects and commercial projects the complexity may not be worth it. It probably makes the most difference to very high traffic sites where money is lost for each millisecond delay in giving you the page (or the ads). And in this sense it may be premature optimization. I like using Next.js, but I often wonder if it is "too much" and adds complexity I wouldn't have otherwise. An old fashioned rails app, and some caching / CDN done in front of it as a separate concern is probably more than enough performance for most people.
  - est 4y ago
    > I think edge computing and CDNs might be what is making this all more interesting You know what's old-fashioned way of doing this? Buy multiple VPS around the world and deploy website files using a script.
    - quickthrower2 4y ago
thwrowaway 4y ago
It provides themes; as does Next.js/Versel, mui, etc. Are seasoned developers usually forking from these provided designs? What value do you guys ascribe to provided themes?
ijustwanttovote 4y ago
If you are trying to "flip" websites, SSG isn't the way to go. I created websites with my own SSG using Javascript, Eleventy, Nuxt, Next. But when I create a website now, I got to stick with Wordpress because they are easier to sell and non tech people can use it.
- mateomorris 4y ago
  Check out Primo. Still in Alpha but very promising for that use-case.
shodan757 4y ago
Not to be "that guy", but could you please put the language in the title when posting stuff like this? We all have our language preferences, and I'd rather not have to go digging just to figure out if a project is relevant to me.
- SamBam 4y ago
  It says it's a "web framework" in the title. That generally means it's going to have some kind of templating system, plus html, css, JavaScript, and probably support for other things like markdown and json. Which of these did you want in the title? Or if you mean what was astro itself written in, I think this post is aimed at users of the system, not potential contributors. Personally I dislike it when when a post says something like "Hugo, a static site generator (Golang)" because it incorrectly implies you need to write Go in order to develop with it.
  - yoyohello13 4y ago
    When I see "web framework" I think Phoenix, Django, Spring, etc. Which do all require you to write in the associated language. If you said "Static Site Generator" then yes that doesn't imply you need write in a specific language.
jsdevtom 4y ago
We've built multiple websites with Astro.js, including customer facing ones such as bustinger.com, and love it. Simple to use, blazing fast results. JSX. Use another framework you like inside it (e.g. React, svelte).
j-pb 4y ago
Really interesting stuff especially for existing jam stack websites, but oh god > This vision of a better web is why Netlify is bullish on Astro can't this horrible stock market and crypto bro lingo stay in the casino bubble.
gherkinnn 4y ago
Excited to see where this goes. For me it fills the niche of simple md -> html with lots of room to expand. I like working with TS, JSX is fab, and I never enjoyed Hugo or Jekyl. Next.js is nice but too much for this case. Gatsby is not nice and doesn’t do much. Astro sounds just about right.
dfabulich 4y ago
Here's the link to their "Astro vs. X" page. https://docs.astro.build/en/comparing-astro-vs-other-tools/ https://docs.astro.build/en/comparing-astro-vs-other-tools/ They compare Astro to Docusaurus, Elder.js, Eleventy, Gatsby, Hugo, Jekyll, SvelteKit, Next.js, Nuxt, Remix, VuePress, and Zola. (For some reason, this page doesn't appear linked anywhere from their documentation's table of contents, and isn't even linked from the "Why Astro?" page. It's almost like they're trying to hide it or something!) https://docs.astro.build/en/concepts/why-astro/ https://docs.astro.build/en/concepts/why-astro/
- UlisesAC4 4y ago
  I didn't really like that comparison as one big page. It is not complete at all. As an avid user of Gatsbyjs I can say that people don't see that the graphql usage in that tool is the medium not the end for the sake of having graphql.
robertakarobin 4y ago
After having tried and given up on so, so many SSG frameworks, I'm loving Astro. In particular: - Templates are plain HTML/Javascript, instead of some other templating language (e.g. Jekyll/Liquid) - Typescript out of the box - SCSS out of the box - Easy remote builds on Netlify - Scoped stylesheets - No overcomplicated build process/customization (e.g. Webpack) - Supports Markdown, YAML, JSON, all the things - It builds really quickly And all of that is with virtually no additional configuration. It's great. Also a big bonus: the team is super friendly and very responsive!
- vosper 4y ago
  Also out of the box: - Tailwind support - Optional choice of UI framework (React, SolidJS, Svelte etc...) - Partial hydration. Generates _actual HTML_ on the server-side rather than JS blobs (which is what some other frameworks call SSR). It really does work nicely. It's very fast, minimal config required.
  - sbarre 4y ago
    As someone who started building web pages in the 90s, the "islands architecture" (generating HTML server-side) of Astro and others makes me laugh because it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago. We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML. There's nothing wrong with this coming back around, it worked quite well! It's just amusing how some things come full circle and are now considered innovative again. I'm sure there are advancements under the hood of course.
    - tomnipotent 4y ago
      And before Ajax you could use a hidden iframe and update the parent page with some JS.
    - vosper 4y ago
      Sure, and I was also around when XMLHttpRequest was new and innovative. And development then was awful compared to where webdev is today - I've been in the industry that entire time. And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that load after the full HTML renders. You could use that to fetch static HTML, or you could use it to provide an interactive client-side experience that only operates on a portion of the page, up to whatever complexity you like. And if the user has JS disabled the rest of the site still renders correctly.
knowsuchagency 4y ago
How does Astro compare to QWIK https://qwik.builder.io/docs/overview https://qwik.builder.io/docs/overview ? Has anyone tried using both? It seems like they're both attempting to address the hydration problem from different angles
- eyelidlessness 4y ago
  I haven’t done any serious work with either, but I’ve been following both closely (and have contributed a bit to Astro early on). So this isn’t the hands-on response you specifically asked for, and may not contain new information to you. I’m posting anyway in case it adds context for others. Qwik City[1] is probably more directly analogous to Astro, Qwik being more analogous to Astro’s integrated renderers. But that highlights one of the key differences. Astro’s compiler mostly focuses on server rendering of static content (.astro templates, MDX) and bundling client resources along with the logic necessary to hydrate islands. Astro defers to those renderers (and in some cases their own compilers) for any further optimization of the client bundle. Qwik’s compiler optimizes the component code directly, serializing state into the HTML it renders server-side, for the client bundle to resume from that state. Its output is conceptually similar to Phoenix LiveView (which was mentioned in another sub-thread). Both are compelling approaches. I think Qwik’s will probably (eventually) have an optimization advantage because that’s a core focus of the client library. Astro will likely have an adoption advantage because it’s client-library-agnostic. Another framework in the space often gets passed over: Marko[2], which has been doing partial hydration for years at eBay. Marko is probably more similar in approach to Qwik (and as I understand it, getting more similar as they’re going resumable too), but like Astro has its own templating language which enables its compiler optimizations. Also worth watching SolidJS[3] (whose creator has also worked on Marko), which is tracking partial hydration/resumability on its roadmap. I’m not sure what their approach will look like but there’s quite a lot of insight both in the issue and the creator’s tweets/replies on the topic. Personally I think there’s a gap between all of these approaches which could leverage type-level analysis to go much further. But that isn’t really feasible when types being available or accurate isn’t a safe assumption. 1: https://qwik.builder.io/qwikcity/overview https://qwik.builder.io/qwikcity/overview 2: https://markojs.com/ https://markojs.com/ 3: https://www.solidjs.com/ https://www.solidjs.com/
biztos 4y ago
> What People are Saying > Astro works with the tools you already love, but this requires a lot of effort to get right. Luckily, Astro is supported by some amazing partners across the industry who support our vision for a faster web. Fast/easy content-focused websites are a subject dear to my heart but far from my day-jobs, so I'm always happy to hear about people making the thing I never quite finish making. But the above quote is... weird? The first thing "people" are saying about Astro is it's a pain in the butt, however "luckily" you can spend money on companies to make it less so?
- necovek 4y ago
  They are saying it's hard to develop a tool like Astro, but they've got support from a number of companies so that's why they are succeeding. Not very clear, agreed.
avivo 4y ago
I'm curious if Astro supports git-backed visual editing? I can't seem to find that, but it would rather useful if so! (ala tinacms.io , stackbit, etc.)
deleted 4y ago
[deleted]
xpe 4y ago
Publishing with a SSG is so complex (and for many good reasons, as other comments mention). When anything gets this this complex, I pine for an end to end optimization targeting simplicity. And I don't think the static site generator is the driving force for complexity here. The web ecosystem really seems nuts when you step back. When it comes to publishing on the web, I would really like to see something simpler gain traction. Browsers are both amazing and amazingly complicated. I would like to see the 80/20 rule applied to see what comes after HTML -- maybe a reboot for 2023? Surely I'm missing something that already exists?
- mateomorris 4y ago
  That same thinking is what led me to build [Primo](https://github.com/primodotso/primo https://github.com/primodotso/primo) - a SSG in a desktop/server CMS. It’s the only thing me or anyone I know who’s uses it uses to build normal websites anymore bc it’s so much faster to get a site up and easier to write code/content.
  - bdlowery 4y ago
    Looks cool, but I think you missed a big opportunity to charge money for this.
    - mateomorris 4y ago
      thanks :D
trinovantes 4y ago
One thing that's not too clear to me is if it's possible to use existing UI libraries. For example, to install Vue's Quasar component library I need to run import { createApp } from 'vue' import { Quasar } from 'quasar' app = createApp() app.use(Quasar) But since astro abstracts away the root Vue application, I don't see how this is possible anymore. Astro might make sense for a blog where you don't need a full blown component library but for any other web application, I'm skeptical of its capabilities.
daemond 4y ago
There are a lot of open source projects similar to astro. Here is a comparison of the popularity and product iteration trend of them. https://ossinsight.io/collections/static-site-generator https://ossinsight.io/collections/static-site-generator You can see that astro's popularity is on the rise. I think it's worth keeping an eye on.
zbird 4y ago
> Astro was a catalyst that caused developers to ask, ‘Do we really need to ship all that JavaScript?’ The reintroduction of multi-page apps (MPAs) in a modern context is a huge opportunity for developers in the Jamstack ecosystem to make the web better for users. So we're back to multi-page websites now? K. I'm still writing my html and CSS by hand.
wiradikusuma 4y ago
Content-focused websites -- so it's like Hugo, Jekyll and other static site generators? (the HTMLs are precompiled so we can host just the files)
hestefisk 4y ago
It looks a bit like serverside Blazor components but with JS as the backend instead of C#?
fullofdev 4y ago
Currently using Hugo for my static site generator that required blog-like. Otherwise write pure HTML will do it. Congrats for the Astro team though reaching v1!
5350-uiop-1130 4y ago
another day, another js framework
WuxiFingerHold 4y ago
I'm developing in-house business apps, so I'm probably a bit ignorant regarding the new trend of all these SSR/hybrid/transitional frameworks. But I'm curious: Is the difference in page loading speed really that significant? SolidJS or Svelte apps with lazy component loading are already pretty fast - Ryan Carnatio has shown some benchmarks on his Youtube streams where the differences are in the ballpark of around 50-500 ms IIRC. Is it a mobile client thing? Or more like "We are Amazon and every 0.1 seconds waiting for the page some xyz customers leave and therefore costs as quite some money"? I mean, those frameworks are really complex. Is it worth it if you already use a fast and small SPA framework like SolidJS or Svelte?
- 8n4vidtmkvmk 4y ago
  500ms for a single page load? that's significant. even 50 is pretty significant. we should be targeting 400 or less, total to render the page
garfieldnate 4y ago
I used Astro recently to rebuild my personal website/portfolio, and I really enjoyed it. I'm not a frontend dev and I quickly get overwhelmed by all of the choices and the breakneck speed that the web ecosystem changes at. Astro was exactly what I needed. It's optimized for spending most of your time writing content in markdown, but it gives you complete freedom to seamlessly add web code of any complexity you like. MDX is just markdown plus custom components, and Astro lets you drop in stuff from React, Vue or Angular, so you're not restricted to whatever components you can find for the single framework that you choose at the beginning of your project. Everything possible is made static. I found it to be pretty intuitive and I don't feel boxed in by it. This is how I want to make (frontend-only) websites in the future. My biggest issues using it (admittedly in the beta state) were 1) wrong line numbers printed for errors due to extensive rewriting and transpilation without source mappings and 2) no built-in image optimization (there is a third-party tool that works well enough, but for a content-first framework this doesn't seem good enough to me). [Edit]: Ah, I see in the 1.0 they have built-in image optimization :) I'll have to try that out.
- jdthedisciple 4y ago
  Hey, mind sharing your website? I'd like to check it out.
  - garfieldnate 4y ago
    I've added it to my profile. It's nothing fancy, mind you, but I think it gets the job done.
    - jdthedisciple 4y ago
      Cool, thanks. Looks good
- gishse 4y ago
  I looked at your site and its source code. The site is snappy and code straightforward. I would love to tinker with Astro when time allows.
lukewiwa 4y ago
I've been searching for something like this. JSX templates but compiles completely down to static html. Closest I found was `lume` from the deno ecosystem. It's mostly fine but you can be a little hamstrung in what js libraries are compatible. Might try this out at some point.
erikthiart 4y ago
What makes thins better than say PHP + Tailwinds?
progx 4y ago
Could this not be a complete replacement for Next, Nuxt, SvelteKit, ... ? https://docs.astro.build/en/comparing-astro-vs-other-tools/ https://docs.astro.build/en/comparing-astro-vs-other-tools/ "Both XXX and Astro are frameworks for building websites. XXX does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites)." This explanation is used for every XXX framework, but i can't really see why. With components you can show high dynamic data, so for me there is no difference if i use XXX or Astro. Did somebody has some real life examples, that could explain the difference? Or why it could be better to stay with XXX and not use Astro. Currently we want to switch our svelte project to SvelteKit, git rid of our custom fiddle (router, etc.). But when i see Astro now, i think about what speak against using Astro? But at the moment it seems that it has many additional benefits?
nprateem 4y ago
TBH if it comes with some decent starter templates it's a massives step up from what the python world offers. I've been looking to make a simple website recently - landing page, user sign up, taking payments, then access to a simple react one-pager. It's all doable but with django you just have to do everything, even if you start with the cookicutter. I just want something where I can pick from a good base template, then get started, not spend days plugging all the parts together. If this helps with that I'll check it out. What would you use for the user data? Firebase, etc.?
- wahnfrieden 4y ago
  Django-tailwind + flowbite blocks
  - nprateem 4y ago
    Thanks, those blocks are exactly what I'm looking for.
    - wahnfrieden 4y ago
      Cheers

452 points by danielskogly 4y ago

Really excited for this release!

I've used Astro my company's landing page for the past year or so [0]. We write blog posts in Notion and port them right to the site and the experience has been fantastic. There are a few understanding quirks with regard to using React etc within Astro (it's SSR'd unless you add the "client" attribute, and counter-intuitively the Component Lifecycle doesn't run the same). For client landing pages, we'll use Astro too- occasionally they'll want a CMS to write their own blog posts without a Git / commit pipeline. In those cases, Netlify CMS plugs in seamlessly and has a generous free tier. [0] https://koptional.com https://koptional.com

foofoobar 4y ago
Netlify recently changed their pricing structure, so if you are using Netlify CMS (or just Netlify Identity) with a private repo, every contributor to the repository (committer) will be charged as full pro seat. This can get really expensive if you have a few users working with the CMS (and thus committing content to the repository). We will move a few pages from Netlify now because of this change.
- eins1234 4y ago
  Also, found out the hard way that "Enterprise" pricing (i.e. call us and we'll charge you an opaque amount based on whatever we think you can afford pricing) starts at 7 users. Vercel is not much better at 10 users, and they hide it deep within their pricing table behind a tooltip so you're not likely to realize this until it's too late. Cloudflare Pages doesn't charge per user but limits concurrent builds which can get really painful. I honestly can't find a good option in this space anymore... What happened?
  - zoover2020 4y ago
    +1, looking for answers too.
  - pbowyer 4y ago
    > I honestly can't find a good option in this space anymore... What happened? They took lots of VC money, got crazy valuations and picked up a few enterprise customers as the JamStack trend grew - and now have to try to generate a return.
    - tomnipotent 4y ago
      > and now have to try to generate a return Otherwise called running a business.
      - acoard 4y ago
        You missed the point. Many businesses only need revenue (or EBITDA) to exceed expenses and you're profitable. Once you take VC money, you must exceed profitability and provide a return on VC money. Not all businesses must make a return on outside investment because they did not take outside investment.
        deleted 4y ago
        [deleted]
  - tomnipotent 4y ago
    Assuming that 7-10 users are FTE, the company is already spending more than $1M on salary and related costs. I imagine the annual Enterprise pricing for Vercel for that numbers of users would hover around 1/4 of an FTE's salary, which is reasonable considering the value provided.
    - eins1234 4y ago
      The increase in value provided by these services is very much linear w.r.t. number of users. The 10x+ leap in cost with enterprise pricing is not at all justified by additional value provided. I don't mind paying a fair, pre-disclosed price for services that provide value. I do mind opaque enterprise sales tactics that try to take full percentage points off my available runway for no discernable increase in value when I try to add one more user. Doubly so when they go to such lengths to cover it up as Vercel is currently doing.
- andrethegiant 4y ago
  That pricing change only impacts private repos owned by organizations — you can still have private repos on a personal account and not be charged.
- swyx 4y ago
  netlify pricing changes for those who want the source https://www.netlify.com/blog/announcing-changes-to-netlify-plans/ https://www.netlify.com/blog/announcing-changes-to-netlify-p... and for private orgs https://www.netlify.com/pricing/private-org-repo-faq/ https://www.netlify.com/pricing/private-org-repo-faq/
bdn_ 4y ago
Interesting, how does the process of going from Notion to Astro work? Are you just exporting Markdown files, or is there an API integration in use?
- jackconsidine 4y ago
  Sorry for the late reply- we use the API! We had done so manually for a long time

swyx 4y ago

congrats team on 1.0!!! huge milestone! inevitable question that always can use answering - what can you share about Astro's company business plan/business model at this time?

lloydatkinson 4y ago

It’s a really great tool I’ve been using since last year. I had previously attempted using Nuxt but that’s a real mess and I never actually got to writing anything. Now I’m using Astro and I’ve got a few articles and it’s a really pleasant developer experience. A lot of static site generators I have found needed more time configuring and writing code for leaving less time in the day for posts etc. I haven’t found this with Astro. The ability to totally not send any JS at all apart from what you manually add such as framework specific components is really something.

Annatar 4y ago

91edec 4y ago
Are you really complaining that people are trying to innovate and create new things? You are not forced to use it.
- Annatar 4y ago
  How is inventing yet another complicated machinery to churn out some HTML and JavaScript innovation?
dang 4y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- Annatar 4y ago
  It's not a shallow dismissal, it's the scourge of our industry; I can't wait to retire so that I would never have to look at it again. Give it a rest with virtue signalling.
  - dang 4y ago
    X being a scourge does not make every X-comment deep. On the contrary, comments about scourges are often shallow and lame. Edit: I just took a look at your recent comment history, and ouch—that makes it painfully clear that you don't want to use HN as intended. I've therefore banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
    - Annatar 4y ago

cube2222 4y ago

This look very cool overall! Could you please explain the tradeoffs vs tools like Hugo and Docusaurus?

brycewray 4y ago
https://docs.astro.build/en/comparing-astro-vs-other-tools/ https://docs.astro.build/en/comparing-astro-vs-other-tools/

CharlesW 4y ago

I'm looking at https://docs.astro.build/en/concepts/why-astro/ https://docs.astro.build/en/concepts/why-astro/ and I still can't tell what's interesting and unique about this as compared to other options in this space. I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation. It seems like Astro's creators believe "content-focused" is a differentiator, but I find that confusing since content-focused sites are a popular use case for web frameworks that are also suitable for more complex apps.

azangru 4y ago
As far as I can tell, Astro is zero-js on the client by default, while both Next and Remix are very much the opposite. Plus, both Next and Remix are tightly coupled with React, whereas Astro is trying to be more agnostic in that regard.
dirheist 4y ago
The one thing I like about Astro is the component island UI. With react you would need to re-render the entire UI on a UI change while in Astro you can signify which portions of your website are static and which dynamically should re-render upon data fetching or whatever. It's just a faster way to build UI's that don't need the full complexity of a SPA and also don't need to come bundled with the entirety of react from what I've seen and used it for.
GrahamL 4y ago
It's interesting their blog post doesn't mention some of the benefits. Neither does the doc page you linked—at least it doesn't do it succinctly. Essentially Astro lets you build sites using a JS framework like React or Vue without requiring that framework to be loaded on the frontend. By default, components are just HTML content. Super nice for building very fast static sites using a technology you may already be fluent in. You can still add interactivity to components if you'd like—just tag components that require interactivity and Astro will bundle the requisite JS for the client.
- reilly3000 4y ago

scastiel 4y ago

Very nice! I was thinking about migrating my blog which has been running with Eleventy for the past few years. It might be the perfect opportunity :)

azangru 4y ago
What do you find missing in Eleventy?
- scastiel 4y ago
  To be honest, I miss React :)
  - lloydatkinson 4y ago
    You will definitely like Astro then! I wrote an article on using (P)react and Astro if you're interested! https://www.lloydatkinson.net/posts/2022/writing-a-fuzzy-search-component-with-preact-and-fuse-for-astro/ https://www.lloydatkinson.net/posts/2022/writing-a-fuzzy-sea...

akmittal 4y ago

Can anyone explain if it's replacement of Next/remix to build complex sites or more like a SSG?

azangru 4y ago
I believe the most complex use case they are targeting is an ecommerce site. Definitely not something as client-side-heavy as, say, Excalidraw, etc.
pier25 4y ago
It started as SSG only but they added SSR so yeah they're now in the same space as Next, Remix, SvelteKit, etc. In fact Solid's creator has said Astro is probably the best way to do SSR with it.

ryansolid 4y ago

So excited for this. SSR with Astro is a gamechanger which opens up its usage to so many different avenues. Great strides with framework interop too. Named Slots really closing the gaps. And of course any framework where SolidJS can shine so bright is going to be the top of my list. Congratulations on an amazing release.

gavinray 4y ago

Serious question: Why does Astro need a custom file format? The format looks identical to MDX

swyx 4y ago
it -is- MDX https://www.brycewray.com/posts/2022/07/astro-move-to-mdx/ https://www.brycewray.com/posts/2022/07/astro-move-to-mdx/
- gavinray 4y ago
  Then it's just for vanity, lol?
- brycewray 4y ago
  No, `.astro` is more than that. What I wrote about was their emphasizing MDX rather than generic Markdown.
MatthewPhillips 4y ago
It uses it to know what JS is needed for the client. If it sees <Section /> that means that no-JS is needed. But if it sees <Counter client:load /> it knows to build + bundle the Counter component and attach its JS to the page.
- gavinray 4y ago
  That's just a property on an element tag, you can access "client:load" under the ".properties" key of the element Open your browser devtools, pick a random tag on the page, add "client:load" to it, and then "console.log(yourEl.properties)" I dunno why you need an entire custom filetype for behavior and semantics that are MDX with a few extra preprocessor rules
  - MatthewPhillips 4y ago
    The reason why you don't know is that you've decided in advance that it's not actually needed. .astro is not actually like MDX at all. MDX extends Markdown, Astro does not, it extends HTML. MDX is a variant of JSX, Astro is not, it supports things that JSX does not like void elements. Astro supports text inside of script and style tags, JSX does not. If you think you can rebuild Astro with "a few extra preprocessor rules", then by all means go for it. But you're going to fail.

mwcampbell 4y ago

> If your project falls into the second “application” camp, Astro might not be the right choice for your project… Plenty of applications in the second category (logged-in admin dashboards, to-do lists, etc.) have been developed using server-first frameworks, and some of us still prefer to develop web applications that way. Is Astro missing any key features for dynamic server-first applications, e.g. form submission and validation support? If not, I think the Astro developers might be selling Astro and MPAs short.

deleted 4y ago
[deleted]
eyelidlessness 4y ago
I agree some of their examples aren’t great, but I think what they’re saying is that Astro’s benefits become less relevant for apps which are highly interactive in the client. You can certainly use Astro to build those, but in many cases you may be just as well served (if not better) by using a more established tool oriented toward whichever client framework/libraries you choose (eg Next.js or Nuxt or SvelteKit etc). That said, there’s quite a lot of space between that extreme and the mostly-static “web site” extreme, and I agree Astro would be a better fit than they let on, for a large chunk of that space. My suspicion is that this is intentional, to keep their current focus and explicit use-case commitments narrower. And I wouldn’t expect it to remain that narrow in the future.

pembrook 4y ago

Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? Inevitably, when a new "hot" SSG comes on the scene, I try it, and then go back to compare it to the old "hot" SSG from 2 years ago. Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times. As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run. And like all SSGs, I see no mention of sane SEO defaults on the homepage. Let me guess--with Astro I'm going to have to set all of this up myself?

jutanium 4y ago
Astro is that tool. It can output a server that can react immediately every time you do an update.
bluehedgehog29 4y ago
Not sure if you've heard of Publii?[0] It's a static blog generator type thing, bit of a different concept to the framework posted. I've tried it a few times casually and it seems ok for non-devs to get something simple up and running. Bit of dev work can update templates etc The SEO defaults aren't perfect but they're easy enough to change in the software. [0] https://getpublii.com https://getpublii.com
MatthewPhillips 4y ago
Here's a good SEO component: https://www.npmjs.com/package/simple-astro-seo https://www.npmjs.com/package/simple-astro-seo
malfist 4y ago
Have you checked out Hugo? It's builds are pretty fast, and it has a watch function for rapid dev work. Not sure how you'd get away from a build on updates though, it is called a static site __generator_. If you want to skip the build entirely, just write .html files and call it a day.
game-of-throws 4y ago
Use any SSG not written in javascript and you'll be fine. Hugo, Zola, Jekyll, etc. Though if I was starting from scratch I might avoid Jekyll just because of the Ruby dependency.

fareesh 4y ago

I used a static site generator for all of these benefits in the past, but the rebuilding process is a total nightmare. The site has about 20 categories, and each category has about 100 images. Every time the team adds a new image or category, the deployment/building task clones the repo and then the build process generates all the optimally sized images again and then re-uploads multiple gigabytes to the host. Is there a way around this type of problem with static site generators?

butz 4y ago
Offload image optimization to separate service?
naet 4y ago
You might need ISR (incremental static regeneration). IIRC there are a couple standard SSG frameworks that support something like it. Usually only worth investing in if you are operating at a large enough content scale though.
fwip 4y ago
A makefile

oxff 4y ago

Why does it feel like there are million solutions and wheel reinventions like this. Why can't they converge on 1-2 solutions?

jaywalk 4y ago
https://xkcd.com/927/ https://xkcd.com/927/

itcrowd 4y ago

It always annoys me when I read something like: To try Astro on your local machine, run npm create astro@latest in any terminal. because it doesn't make it clear to me what to do before this command will actually do anything. No, running this command will not work in any terminal.

ksbrooksjr 4y ago
As long as you have npm installed it'll work. Npm create is an alias for the npm init command [1], which will look for a package with the prefix 'create-', install it, and run its bin file. It looks like this is the file that ends up being run: https://github.com/withastro/astro/blob/main/packages/create-astro/create-astro.mjs https://github.com/withastro/astro/blob/main/packages/create.... [1] https://docs.npmjs.com/cli/v8/commands/npm-init https://docs.npmjs.com/cli/v8/commands/npm-init
- itcrowd 4y ago
  > As long as you have npm installed it'll work. Exactly proving my original point.
  - brabel 4y ago
    If you don't have npm installed, just stay as far as you can from this :D Seriously, JS static website generators are the worst... use something written in any compiled language so you just download and run a single binary, no messing around with npm and millions of dependencies. Take your pick here: https://jamstack.org/generators/ https://jamstack.org/generators/
    - bdlowery 4y ago
      PHP is pretty great. No NPM needed
      - progx 4y ago
        PECL? PEAR? Composer? ...

rcarr 4y ago

Been using this the last week to convert an 11ty website and really enjoying it so far. Very cool to just be able to use whatever JS framework you want for a component and just drop it in.

jlarky2012 4y ago

Congrats guys. Astro+SolidJS is the future :)

recroad 4y ago

Provide and migration path from Wordpress and I'm in!

oneplane 4y ago

Sometimes all the frameworks that re-invent MVC (but in a detached fashion) and tout "server side rendering" just feel like we've come full circle where we're just serving a static view cache that was generated from models and data using a controller. The big difference here (as with other JavaScript-based renderers) is of course the "use one tool/language for everything" aspect which to me is a bit of a 'meh'-benefit. At this point, while all the renderers get better and simpler, we're still in a situation where complexity or writing code hasn't really gone away, it just shifted around to new places. Perhaps at some point we get to the HTML + WebComponents stage again (kinda like MDX and React mixing), and classic Apache Server-Side Includes become the new hot thing again.

quickthrower2 4y ago
I think edge computing and CDNs might be what is making this all more interesting. It is not just where you render (Server vs. Client), it is where you render (Dallas vs. Rio). If you can get your app to re render small sections and have the framework figure out that these sections are static and can chuck them in a CDN (or they are not and need an edge server, or a central server) then you can get lots of optimizations that way. That said, for most side projects and commercial projects the complexity may not be worth it. It probably makes the most difference to very high traffic sites where money is lost for each millisecond delay in giving you the page (or the ads). And in this sense it may be premature optimization. I like using Next.js, but I often wonder if it is "too much" and adds complexity I wouldn't have otherwise. An old fashioned rails app, and some caching / CDN done in front of it as a separate concern is probably more than enough performance for most people.
- est 4y ago
  > I think edge computing and CDNs might be what is making this all more interesting You know what's old-fashioned way of doing this? Buy multiple VPS around the world and deploy website files using a script.
  - quickthrower2 4y ago

thwrowaway 4y ago

It provides themes; as does Next.js/Versel, mui, etc. Are seasoned developers usually forking from these provided designs? What value do you guys ascribe to provided themes?

ijustwanttovote 4y ago

If you are trying to "flip" websites, SSG isn't the way to go. I created websites with my own SSG using Javascript, Eleventy, Nuxt, Next. But when I create a website now, I got to stick with Wordpress because they are easier to sell and non tech people can use it.

mateomorris 4y ago
Check out Primo. Still in Alpha but very promising for that use-case.

shodan757 4y ago

Not to be "that guy", but could you please put the language in the title when posting stuff like this? We all have our language preferences, and I'd rather not have to go digging just to figure out if a project is relevant to me.

SamBam 4y ago
It says it's a "web framework" in the title. That generally means it's going to have some kind of templating system, plus html, css, JavaScript, and probably support for other things like markdown and json. Which of these did you want in the title? Or if you mean what was astro itself written in, I think this post is aimed at users of the system, not potential contributors. Personally I dislike it when when a post says something like "Hugo, a static site generator (Golang)" because it incorrectly implies you need to write Go in order to develop with it.
- yoyohello13 4y ago
  When I see "web framework" I think Phoenix, Django, Spring, etc. Which do all require you to write in the associated language. If you said "Static Site Generator" then yes that doesn't imply you need write in a specific language.

jsdevtom 4y ago

We've built multiple websites with Astro.js, including customer facing ones such as bustinger.com, and love it. Simple to use, blazing fast results. JSX. Use another framework you like inside it (e.g. React, svelte).

j-pb 4y ago

Really interesting stuff especially for existing jam stack websites, but oh god > This vision of a better web is why Netlify is bullish on Astro can't this horrible stock market and crypto bro lingo stay in the casino bubble.

gherkinnn 4y ago

Excited to see where this goes. For me it fills the niche of simple md -> html with lots of room to expand. I like working with TS, JSX is fab, and I never enjoyed Hugo or Jekyl. Next.js is nice but too much for this case. Gatsby is not nice and doesn’t do much. Astro sounds just about right.

dfabulich 4y ago

Here's the link to their "Astro vs. X" page. https://docs.astro.build/en/comparing-astro-vs-other-tools/ https://docs.astro.build/en/comparing-astro-vs-other-tools/ They compare Astro to Docusaurus, Elder.js, Eleventy, Gatsby, Hugo, Jekyll, SvelteKit, Next.js, Nuxt, Remix, VuePress, and Zola. (For some reason, this page doesn't appear linked anywhere from their documentation's table of contents, and isn't even linked from the "Why Astro?" page. It's almost like they're trying to hide it or something!) https://docs.astro.build/en/concepts/why-astro/ https://docs.astro.build/en/concepts/why-astro/

UlisesAC4 4y ago
I didn't really like that comparison as one big page. It is not complete at all. As an avid user of Gatsbyjs I can say that people don't see that the graphql usage in that tool is the medium not the end for the sake of having graphql.

robertakarobin 4y ago

After having tried and given up on so, so many SSG frameworks, I'm loving Astro. In particular: - Templates are plain HTML/Javascript, instead of some other templating language (e.g. Jekyll/Liquid) - Typescript out of the box - SCSS out of the box - Easy remote builds on Netlify - Scoped stylesheets - No overcomplicated build process/customization (e.g. Webpack) - Supports Markdown, YAML, JSON, all the things - It builds really quickly And all of that is with virtually no additional configuration. It's great. Also a big bonus: the team is super friendly and very responsive!

vosper 4y ago
Also out of the box: - Tailwind support - Optional choice of UI framework (React, SolidJS, Svelte etc...) - Partial hydration. Generates _actual HTML_ on the server-side rather than JS blobs (which is what some other frameworks call SSR). It really does work nicely. It's very fast, minimal config required.
- sbarre 4y ago
  As someone who started building web pages in the 90s, the "islands architecture" (generating HTML server-side) of Astro and others makes me laugh because it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago. We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML. There's nothing wrong with this coming back around, it worked quite well! It's just amusing how some things come full circle and are now considered innovative again. I'm sure there are advancements under the hood of course.
  - tomnipotent 4y ago
    And before Ajax you could use a hidden iframe and update the parent page with some JS.
  - vosper 4y ago
    Sure, and I was also around when XMLHttpRequest was new and innovative. And development then was awful compared to where webdev is today - I've been in the industry that entire time. And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that load after the full HTML renders. You could use that to fetch static HTML, or you could use it to provide an interactive client-side experience that only operates on a portion of the page, up to whatever complexity you like. And if the user has JS disabled the rest of the site still renders correctly.

knowsuchagency 4y ago

How does Astro compare to QWIK https://qwik.builder.io/docs/overview https://qwik.builder.io/docs/overview ? Has anyone tried using both? It seems like they're both attempting to address the hydration problem from different angles

eyelidlessness 4y ago
I haven’t done any serious work with either, but I’ve been following both closely (and have contributed a bit to Astro early on). So this isn’t the hands-on response you specifically asked for, and may not contain new information to you. I’m posting anyway in case it adds context for others. Qwik City[1] is probably more directly analogous to Astro, Qwik being more analogous to Astro’s integrated renderers. But that highlights one of the key differences. Astro’s compiler mostly focuses on server rendering of static content (.astro templates, MDX) and bundling client resources along with the logic necessary to hydrate islands. Astro defers to those renderers (and in some cases their own compilers) for any further optimization of the client bundle. Qwik’s compiler optimizes the component code directly, serializing state into the HTML it renders server-side, for the client bundle to resume from that state. Its output is conceptually similar to Phoenix LiveView (which was mentioned in another sub-thread). Both are compelling approaches. I think Qwik’s will probably (eventually) have an optimization advantage because that’s a core focus of the client library. Astro will likely have an adoption advantage because it’s client-library-agnostic. Another framework in the space often gets passed over: Marko[2], which has been doing partial hydration for years at eBay. Marko is probably more similar in approach to Qwik (and as I understand it, getting more similar as they’re going resumable too), but like Astro has its own templating language which enables its compiler optimizations. Also worth watching SolidJS[3] (whose creator has also worked on Marko), which is tracking partial hydration/resumability on its roadmap. I’m not sure what their approach will look like but there’s quite a lot of insight both in the issue and the creator’s tweets/replies on the topic. Personally I think there’s a gap between all of these approaches which could leverage type-level analysis to go much further. But that isn’t really feasible when types being available or accurate isn’t a safe assumption. 1: https://qwik.builder.io/qwikcity/overview https://qwik.builder.io/qwikcity/overview 2: https://markojs.com/ https://markojs.com/ 3: https://www.solidjs.com/ https://www.solidjs.com/

biztos 4y ago

> What People are Saying > Astro works with the tools you already love, but this requires a lot of effort to get right. Luckily, Astro is supported by some amazing partners across the industry who support our vision for a faster web. Fast/easy content-focused websites are a subject dear to my heart but far from my day-jobs, so I'm always happy to hear about people making the thing I never quite finish making. But the above quote is... weird? The first thing "people" are saying about Astro is it's a pain in the butt, however "luckily" you can spend money on companies to make it less so?

necovek 4y ago
They are saying it's hard to develop a tool like Astro, but they've got support from a number of companies so that's why they are succeeding. Not very clear, agreed.

avivo 4y ago

I'm curious if Astro supports git-backed visual editing? I can't seem to find that, but it would rather useful if so! (ala tinacms.io , stackbit, etc.)

deleted 4y ago

[deleted]

xpe 4y ago

Publishing with a SSG is so complex (and for many good reasons, as other comments mention). When anything gets this this complex, I pine for an end to end optimization targeting simplicity. And I don't think the static site generator is the driving force for complexity here. The web ecosystem really seems nuts when you step back. When it comes to publishing on the web, I would really like to see something simpler gain traction. Browsers are both amazing and amazingly complicated. I would like to see the 80/20 rule applied to see what comes after HTML -- maybe a reboot for 2023? Surely I'm missing something that already exists?

mateomorris 4y ago
That same thinking is what led me to build [Primo](https://github.com/primodotso/primo https://github.com/primodotso/primo) - a SSG in a desktop/server CMS. It’s the only thing me or anyone I know who’s uses it uses to build normal websites anymore bc it’s so much faster to get a site up and easier to write code/content.
- bdlowery 4y ago
  Looks cool, but I think you missed a big opportunity to charge money for this.
  - mateomorris 4y ago
    thanks :D

trinovantes 4y ago

One thing that's not too clear to me is if it's possible to use existing UI libraries. For example, to install Vue's Quasar component library I need to run import { createApp } from 'vue' import { Quasar } from 'quasar' app = createApp() app.use(Quasar) But since astro abstracts away the root Vue application, I don't see how this is possible anymore. Astro might make sense for a blog where you don't need a full blown component library but for any other web application, I'm skeptical of its capabilities.

daemond 4y ago

There are a lot of open source projects similar to astro. Here is a comparison of the popularity and product iteration trend of them. https://ossinsight.io/collections/static-site-generator https://ossinsight.io/collections/static-site-generator You can see that astro's popularity is on the rise. I think it's worth keeping an eye on.

zbird 4y ago

> Astro was a catalyst that caused developers to ask, ‘Do we really need to ship all that JavaScript?’ The reintroduction of multi-page apps (MPAs) in a modern context is a huge opportunity for developers in the Jamstack ecosystem to make the web better for users. So we're back to multi-page websites now? K. I'm still writing my html and CSS by hand.

wiradikusuma 4y ago

Content-focused websites -- so it's like Hugo, Jekyll and other static site generators? (the HTMLs are precompiled so we can host just the files)

hestefisk 4y ago

It looks a bit like serverside Blazor components but with JS as the backend instead of C#?

fullofdev 4y ago

Currently using Hugo for my static site generator that required blog-like. Otherwise write pure HTML will do it. Congrats for the Astro team though reaching v1!

5350-uiop-1130 4y ago

another day, another js framework

WuxiFingerHold 4y ago

I'm developing in-house business apps, so I'm probably a bit ignorant regarding the new trend of all these SSR/hybrid/transitional frameworks. But I'm curious: Is the difference in page loading speed really that significant? SolidJS or Svelte apps with lazy component loading are already pretty fast - Ryan Carnatio has shown some benchmarks on his Youtube streams where the differences are in the ballpark of around 50-500 ms IIRC. Is it a mobile client thing? Or more like "We are Amazon and every 0.1 seconds waiting for the page some xyz customers leave and therefore costs as quite some money"? I mean, those frameworks are really complex. Is it worth it if you already use a fast and small SPA framework like SolidJS or Svelte?

8n4vidtmkvmk 4y ago
500ms for a single page load? that's significant. even 50 is pretty significant. we should be targeting 400 or less, total to render the page

garfieldnate 4y ago

I used Astro recently to rebuild my personal website/portfolio, and I really enjoyed it. I'm not a frontend dev and I quickly get overwhelmed by all of the choices and the breakneck speed that the web ecosystem changes at. Astro was exactly what I needed. It's optimized for spending most of your time writing content in markdown, but it gives you complete freedom to seamlessly add web code of any complexity you like. MDX is just markdown plus custom components, and Astro lets you drop in stuff from React, Vue or Angular, so you're not restricted to whatever components you can find for the single framework that you choose at the beginning of your project. Everything possible is made static. I found it to be pretty intuitive and I don't feel boxed in by it. This is how I want to make (frontend-only) websites in the future. My biggest issues using it (admittedly in the beta state) were 1) wrong line numbers printed for errors due to extensive rewriting and transpilation without source mappings and 2) no built-in image optimization (there is a third-party tool that works well enough, but for a content-first framework this doesn't seem good enough to me). [Edit]: Ah, I see in the 1.0 they have built-in image optimization :) I'll have to try that out.

jdthedisciple 4y ago
Hey, mind sharing your website? I'd like to check it out.
- garfieldnate 4y ago
  I've added it to my profile. It's nothing fancy, mind you, but I think it gets the job done.
  - jdthedisciple 4y ago
    Cool, thanks. Looks good
gishse 4y ago
I looked at your site and its source code. The site is snappy and code straightforward. I would love to tinker with Astro when time allows.

lukewiwa 4y ago

I've been searching for something like this. JSX templates but compiles completely down to static html. Closest I found was `lume` from the deno ecosystem. It's mostly fine but you can be a little hamstrung in what js libraries are compatible. Might try this out at some point.

erikthiart 4y ago

What makes thins better than say PHP + Tailwinds?

progx 4y ago

Could this not be a complete replacement for Next, Nuxt, SvelteKit, ... ? https://docs.astro.build/en/comparing-astro-vs-other-tools/ https://docs.astro.build/en/comparing-astro-vs-other-tools/ "Both XXX and Astro are frameworks for building websites. XXX does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites)." This explanation is used for every XXX framework, but i can't really see why. With components you can show high dynamic data, so for me there is no difference if i use XXX or Astro. Did somebody has some real life examples, that could explain the difference? Or why it could be better to stay with XXX and not use Astro. Currently we want to switch our svelte project to SvelteKit, git rid of our custom fiddle (router, etc.). But when i see Astro now, i think about what speak against using Astro? But at the moment it seems that it has many additional benefits?

nprateem 4y ago

TBH if it comes with some decent starter templates it's a massives step up from what the python world offers. I've been looking to make a simple website recently - landing page, user sign up, taking payments, then access to a simple react one-pager. It's all doable but with django you just have to do everything, even if you start with the cookicutter. I just want something where I can pick from a good base template, then get started, not spend days plugging all the parts together. If this helps with that I'll check it out. What would you use for the user data? Firebase, etc.?

wahnfrieden 4y ago
Django-tailwind + flowbite blocks
- nprateem 4y ago
  Thanks, those blocks are exactly what I'm looking for.
  - wahnfrieden 4y ago
    Cheers