I'm looking at <a href="https://docs.astro.build/en/concepts/why-astro/" rel="nofollow">https://docs.astro.build/en/concepts/why-astro/</a> and I still can't tell what's interesting and unique about this as compared to other options in this space.<p>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.<p>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.
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.<p>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).<p>[Edit]: Ah, I see in the 1.0 they have built-in image optimization :) I'll have to try that out.
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.<p>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.<p>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.
After having tried and given up on so, so many SSG frameworks, I'm loving Astro. In particular:<p>- Templates are plain HTML/Javascript, instead of some other templating language (e.g. Jekyll/Liquid)<p>- Typescript out of the box<p>- SCSS out of the box<p>- Easy remote builds on Netlify<p>- Scoped stylesheets<p>- No overcomplicated build process/customization (e.g. Webpack)<p>- Supports Markdown, YAML, JSON, all the things<p>- It builds really quickly<p>And all of that is with virtually no additional configuration. It's great.<p>Also a big bonus: the team is super friendly and very responsive!
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.<p>[0] <a href="https://koptional.com" rel="nofollow">https://koptional.com</a>
Really interesting stuff especially for existing jam stack websites, but oh god<p>> This vision of a better web is why Netlify is bullish on Astro<p>can't this horrible stock market and crypto bro lingo stay in the casino bubble.
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<p><pre><code> import { createApp } from 'vue'
import { Quasar } from 'quasar'
app = createApp()
app.use(Quasar)
</code></pre>
But since astro abstracts away the root Vue application, I don't see how this is possible anymore.<p>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.
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.<p>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.
It always annoys me when I read something like:<p><pre><code> To try Astro on your local machine, run npm create astro@latest in any terminal.
</code></pre>
because it doesn't make it clear to me what to do before this command will actually do anything. No, running this command will <i>not work</i> in any terminal.
I used a static site generator for all of these benefits in the past, but the rebuilding process is a total nightmare.<p>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?
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.<p>And of course any framework where SolidJS can shine so bright is going to be the top of my list.<p>Congratulations on an amazing release.
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:<p>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"?<p>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?
> What People are Saying<p>> 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.<p>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.<p>But the above quote is... weird?<p>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?
Could this not be a complete replacement for Next, Nuxt, SvelteKit, ... ?<p><a href="https://docs.astro.build/en/comparing-astro-vs-other-tools/" rel="nofollow">https://docs.astro.build/en/comparing-astro-vs-other-tools/</a><p>"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)."<p>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.<p>Did somebody has some real life examples, that could explain the difference?<p>Or why it could be better to stay with XXX and not use Astro.<p>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?
Here's the link to their "Astro vs. X" page. <a href="https://docs.astro.build/en/comparing-astro-vs-other-tools/" rel="nofollow">https://docs.astro.build/en/comparing-astro-vs-other-tools/</a><p>They compare Astro to Docusaurus, Elder.js, Eleventy, Gatsby, Hugo, Jekyll, SvelteKit, Next.js, Nuxt, Remix, VuePress, and Zola.<p>(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!)<p><a href="https://docs.astro.build/en/concepts/why-astro/" rel="nofollow">https://docs.astro.build/en/concepts/why-astro/</a>
TBH if it comes with some decent starter templates it's a massives step up from what the python world offers.<p>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.<p>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.?
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.<p>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.<p>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?<p>Surely I'm missing something that already exists?
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.<p>The ability to totally not send any JS at all apart from what you manually add such as framework specific components is really something.
> If your project falls into the second “application” camp, Astro might not be the right choice for your project…<p>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.
There are a lot of open source projects similar to astro.
Here is a comparison of the popularity and product iteration trend of them. <a href="https://ossinsight.io/collections/static-site-generator" rel="nofollow">https://ossinsight.io/collections/static-site-generator</a>
You can see that astro's popularity is on the rise. I think it's worth keeping an eye on.
> 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.<p>So we're back to multi-page websites now? K.<p>I'm still writing my html and CSS by hand.
How does Astro compare to QWIK <a href="https://qwik.builder.io/docs/overview" rel="nofollow">https://qwik.builder.io/docs/overview</a> ? Has anyone tried using both? It seems like they're both attempting to address the hydration problem from different angles
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.<p>Might try this out at some point.
Excited to see where this goes. For me it fills the niche of simple md -> html with lots of room to expand.<p>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.
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.
We've built multiple websites with Astro.js, including customer facing ones such as bustinger.com, and love it.<p>Simple to use, blazing fast results. JSX. Use another framework you like inside it (e.g. React, svelte).
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.
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?
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!
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.)
congrats team on 1.0!!! huge milestone!<p>inevitable question that always can use answering - what can you share about Astro's company business plan/business model at this time?
Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update?<p>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.<p>As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run.<p>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?