Live data from Hacker News

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

astro.build

71–80 of 256 posts

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

#71

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…

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?

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

#72
post #20

I'm looking at 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…

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 fl…

So they have moved all the previously frontend stuff to backend and output Hot-wired / Liveview / Livewire instead?

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

#74

I'm looking at 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…

The core concept and main difference is described here I think: https://docs.astro.build/en/concepts/islands There is also this page comparing it with other tools: https://docs.astro.build/en/comparing-astro-vs-other-tools

Comparison with alternative solutions is the first thing I look for in the docs. Great that they have it!

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

#75

Earlier quoted context omitted.

Hugo ( https://gohugo.io ) maybe? I tried it for a small static site about internal documentation, and I'm very glad I did. The hardest part was reading the documentation, the installation, content generation and rebuilds were painless.

The hardest part of Hugo for me was creating my theme from scratch (docs are eh on this but I found some good 3rd party tutorials) but after that it's been an absolute breeze. After spending a little time understanding Go templating it is really beautiful

Half way through customizing a Hugo theme, I suddenly realized that I don't need a theme at all. Hugo can be used themelessly, where you just write templates specifically for your site. Everything was so much easier from there.

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

#76

> 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 a…

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.

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

#77

Earlier quoted context omitted.

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.

> Use any SSG not written in javascript and you'll be fine. Commonly stated but not actually true. For example: https://github.com/getzola/zola/blob/master/Cargo.lock https://github.com/gohugoio/hugo (scroll to the bottom of the README)

You don't need these deps to install it, just to compile it.

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

#78

Earlier quoted context omitted.

It uses it to know what JS is needed for the client. If it sees that means that no-JS is needed. But if it sees it knows to build + bundle the Counter component and attach its JS to the page.

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

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.

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

#79

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…

I like to use tup with jinja.

https://gittup.org/tup/

https://github.com/kolypto/j2cli

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

#80
post #47

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.

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... . [1] https://docs.npmjs.com/cli/v8/commands/npm-init

> As long as you have npm installed it'll work.

Exactly proving my original point.

Post reply on HN