Hacker News Reader

Comment by CharlesW | Hacker News Reader

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 I find that confusing since content-focused sites are a popular use case for web frameworks that are also suitable for more complex apps.

View on HN

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.

Their homepage https://astro.build has a nice summary of its approach and benefits.

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

I wish. AFAIK it's just classic server-side rendering with full-page navigation. Mind you, that's the optimal solution in many cases. But a full-stack JavaScript web framework with something like Phoenix's channels and LiveView built in would be a killer combination.

Isn't that what Hotwire and StimulusJS is?

I just started working on something like this. It's a VDOM implemented in Ruby and it streams updates to the browser via Server-Sent Events which are then applied by a tiny bit of JavaScript.

A basic counter component would look something like this:

    initial_state do |props|
      { count: 0 }
    end

    handler(:increment) do |e|
      update do |count:|
        { count: count + 1 }
      end
    end

    render do
      <div>
        <p>Count: {state[:count]}</p>
        <button on-click={handler(:increment)}>Increment</button>
      </div>
    end

There are some things I'm used to in the JavaScript world that I'm trying to introduce here. I got hot reloading which is pretty cool. And CSS modules... and static typing with Sorbet.

Events are handled on the server, so there's no need for an API... You could just talk to your database directly in your onsubmit-handler. I think that might be the largest benefit from using something like this.

If the app is deployed in a region close to you, you won't barely notice the latency.

Check out https://liveviewjs.com

Not getting it tbh. Why would you go nuclear and develop a React or Vue app and then not actually use it on the browser side? For content-oriented websites there are much simpler workflows based on SGML and other classic markup processing and content management practices. I mean the point of "content-oriented" and web sites in general really is that an expert in the field, rather than a web developer, can achieve useful results as an author.

Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.

Nothing about the developer experience of React seems better than any old HTML template language (and hardly better even than plain HTML), if you're not doing any interactivity and are just going to render once and spit out the HTML.

Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.

Yes. JSX is nice for escaping by default but encourages total spaghetti coding hiding app logic in the templates and various footguns like non-standard attributes className and breaking id. Running it on the server side mitigates the React performance hit somewhat but the selling point is interactivity.

What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte.

I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html ?

Think of JSX as a macro, rather than "regular" templating, which is typically string substitution.

For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.

You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).

Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.

The thing is, if you know JS, then a conditional is JSX is the same as in JS. Contrast that with every new templating language under the sun which might have its own way of doing conditionals and loops and control flow. That to me is much more annoying.

But you’re aware JSX is just plain old PHP files, code intermingled with HTML? It’s the exact same thing, and it breeds the exact same bad behaviour.

Separation of concerns is different from separation of languages.

PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.

Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.

JSX doesn't separate languages, you're mixing HTML with TypeScript. You can absolutely do database queries in your template. What is keeping you from doing `fetch('https://side-effect.ts').then(() => doSomethingHorrible())` in your template? Or invoking an `alert()`?

You can do those things, but you're not going to capture the effect that you want. Renders happen frequently, and the render process will complete before your `fetch` resolves. As for alert, the alert will pop up immediately before the render is applied to the DOM- and will likely pop up many times more than you thought it would, assuming you're popping it up based on some state variable.

In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.

Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.

Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.

This is a dubious claim, since JSX is limited to expressions. If you ask people for “a conditional in JS”, they’ll very probably go for `if (…) { … } else { … }` first, not `… ? … : …` (if you can even rewrite it as a ternary). Same deal with loops: you’re limited to expressions, so you can’t use the normal way of writing a loop (and this regularly leads to mild contortions as you deal with iterables of diverse types). Therefore I’d tend to (qualifiedly) describe JSX as doing its own thing too.

Plenty of people are taught that ternary operators are evil and should never be used.

Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.

That doesn't make either of those things true.

As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.

How so? Any expression is valid within JSX- ternaries, function calls, binary and unary operators are all valid. If you know JavaScript, you already know all of the control mechanisms that are valid.

I have used React. I'm a huge fan and I also prefer it over its most common "competitors" like Vue and Svelte.

But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.

It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).

Which looks nicer? Eta vs JSX

   <%~ includeFile('./navbar', { pages: [
     'home',
     'about',
     'users'
   ] }) %>

   <navbar pages={['home', 'about', 'users']} />

> would just be JavaScript functions that take props and return some JSX

They can also be async functions that process data independently. Whereas templates are commonly just passed in data from the controller.

https://github.com/dsego/ssr-playground/#jsx-partials

JSX is much easier to maintain than pretty much every other templating language.

If you are building a growing design system with any degree of complexity, React is one of the best tools available.

> Nothing about the developer experience of React seems better than any old HTML template language

Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.

You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.

TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).

Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.

I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.

So what do you use for shell scripting?

I like using Nim or Rust, or TypeScript, depends on the script. If it's just a few lines, sure I'll write it in bash, but if it gets a little larger, I convert it into a real programming language.

Rust as a replacement for a bash script?

My bash scripts are often edited, I could not imagine using a compiled language where I would have to store the source as a separate file from the executable, then compile it each time.

I'd love to know your more specific use cases, if you don't mind. I'm always happy to learn something new. Could you share some Rust that most people would script in Bash as an example? What's your build and deploy (to ~/.local/bin I presume) strategy?

> where I would have to store the source as a separate file from the executable, then compile it each time

> What's your build and deploy (to ~/.local/bin I presume) strategy?

You can run scripts as you would with bash, you don't have to manually build and run the executable. For example, `cargo run (inside the script source folder)` and `sh script.sh` do basically the same thing, end user wise. `nim compile --run script.nim` is similar in that the language compiler will automatically compile and run it together.

> Could you share some Rust that most people would script in Bash as an example?

I was creating dotfiles the other day and I didn't want to use some dotfile manager program as I had some specific steps I wanted to follow, so I started it as a bash script. Well, it got kind of annoying so I made it into a Rust script with some nice features like interactive prompts, text coloring, etc with libraries like `clap`. You can do this in bash of course, but the Rust version was more ergonomic. When I need to run the script, I just did `cargo run` and it worked great.

I see, but then your scripts are not nice compact commands.

For instance, my most-used bash script takes a file as input and opens either VIM or Emacs depending on whether the file is a .md or .org (simplified example). I run it like so:

  $ n foo.org

I can edit ~/.local/bin/n and update the file, and use it immediately. I actually have my whole ~/.local/bin in version control. Having to type out e.g.

  $ nim compile --run n foo.org

...would make the whole experience far less fluent. I probably would never use it.

I'm asking because I'd love to rewrite this script in e.g. Rust, but I don't see any good way to deploy it to ~/.local/bin/n.

Just alias the command in your .bashrc? e.g. `alias n="nim compile --run n"`. I'm not sure what the issue is with longer commands because the benefits of writing in a strongly statically typed language definitely outweigh a few extra characters to type, which you don't even need to do with aliases.

For what it's worth, you need only type "nim r n". If "n.nim" is marked executable and begins with "#!/usr/bin/nim r" then you also need only type "n.nim".

For nim, you could use something like nimcr (https://nimble.directory/pkg/nimcr). You put a shebang in your script `#!/usr/bin/env nimcr` and then call it like a normal script.

eg:

  $ code script.nim


  #!/usr/bin/env nimcr
  echo "hello world"


  $ ./script.nim
  hello world

edit:

There's also the possibility of using nimscript, using nim e. It works similarly but you'd change the shebang line to something like

  #!/usr/bin/env nim e --hints:off

Actually another way to do nimscript is to make a config.nims file with tasks in it. eg:

In config.nims:

  switch("hints", "off")
  task hello, "say hello world":
    echo "hello world"

In bash:

  $ nim hello
  hello world

But TypeScript doesn’t have ADTs which you stated was a hard requirement. It has some other features that can achieve similar things though, so maybe that’s good enough?

Discriminated unions aren't quite as nice, but they're pretty close.

Kinda nitpicky. Sure ADTs are a pattern in Typescript rather than a first-class entity, but they're an extremely well-supported pattern, exhaustiveness checking and all.

    type ADT = 
        | { case : 'a', a : Number }
        | { case : 'b', b : string }

    function f (c : ADT) {
        switch(c.case) {
            case 'a' : return c.a
            case 'b' : return Number.parseInt(c.b)

            // case 'c' : return 0 // compile error

            // case 'b' : return c.a // also compile error
        }
    }

For sure. I'm a big fan of type safety in larger codebases with reasonably stable domains. But when a project's small or new enough to be relatively volatile, the overhead just isn't worth it for me.

because it's nice to know whether that `post` variable contains a property `createdAt` or `published` At without leaving the template. Arguing "I don't use it why should you" is unproductive.

Agreed, you get all the benefits of type inference even in a template. It's a pain to debug template variables that don't exist, I've written enough Handlebars to know.

There are "templating languages" such as SGML for generating type-checked markup ie. respecting the regular content model and lexical types expressed in DTDs and other markup declarations. This results in injection-free, HTML-aware templating ie. templating engines can properly quote/escape content in attributes, CDATA sections, etc. and can enforce content model rules (that eg lists consist of nothing but list items, that script elements aren't placed where forbidden as would be required in user content such as comments provided by your web site visitors, etc.) Much more powerful than programming language types, and needed in CMSs.

and what's your experience writing other markup languages that you base this statement on? I can definitely agree it is nicer for a data intensive sites, and with effort can be made somewhat equivalent in most document heavy sites, but there are definitely some scenarios I've encountered where the match of technology to use case was disastrously not in React's favor.

Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts.

I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required.

I can say that because I have built big solutions in both stacks, though.

I've used many, Handlebars, Pug, Vue's, Svelte's, Zola's, many. They're all somewhat similar in that they try to recreate loops and conditionals, all without strong type support unlike in JSX. I've never used SGML though, another commenter told me that it is more powerful.

You get the speed of SSR but can sprinkle interactivity into the app using the same SPA style frameworks via isolated “islands”.

It might be all you know.

I'm not a web dev by trade but I have a website for a hobby project. I had taught myself React thinking I might make an app. (I never did.)

So now I want to maintain this thing on the side with not much effort using what I already know. And that keeps those skills fresh, which is great.

I'm very interested in Astro.

Component-based UI frameworks and ecosystem has made building frontends much nicer, especially when you need some optional interactivity since you're already writing in JS.

Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.

In that case, it'd be interesting to see the benefits of Astro vs something like Gatsby

Frameworks like Gatsby didnt have any special support for interactive islands. You can choose to have:

a. A completely static site with no frontend javascript and no client side hydration, or

b. client hydration in which case all the components needed in the page will need to be loaded in the client.

If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort.

Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.

I suppose it's just a different templating engine (plus some optional features for the client side). Probably as a front-end developer people are more familiar with that compared to Jinja for example? Though I think if the target is static web sites then it's simply overkill.

> using a technology you may already be fluent in.

I think this is the only selling point, given the "content-focused". It's not different than just writing HTML and vanilla js for some interactivity.

While Astro has a lot of impressive features I found that it was the "developer experience" (god I hate that term) that was superior compared to everything I've tried before.

With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues.

Publii was cool, but trying to shoehorn everything into fitting in the "Blog" model never quite worked out for me. Also being forced to work in a new IDE wasn't to my liking either.

Here are some of the things I love about Astro:

- The docs are great. You can read through them all really quickly. I tend to prefer systems that are simple to grok, and Astro is just that.

- The lightweight Astro components (https://docs.astro.build/en/core-concepts/astro-components/) were great for me, because they delivered on being able to create reusable pieces of code very easily (without having to touch React).

- Being able to generate part of your site from markdown and part of it from precisely crafted HTML is a great way to be able to handle both repetitive and unique content.

- The Astro themes (https://astro.build/themes/) are a great way to start. Find something that's somewhat similar to what you want to build and study how they did it.

This is obviously very subjective, but for me Astro was the first SSG that I really enjoy using, and that I didn't feel like I had to fight against.

> "developer experience" (god I hate that term)

Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience).

Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, it's hardly the only offender) is servers and services, and the users (other engineers) consuming those outputs can have a nice time. The DX of using Chef, though, can be ughh....

it is subjective and overused - perfect storm for industry jargon that takes up a lot of space without saying anything more than "this thing sparks joy"

It’s no more subjective than “user experience”, which is a term thrown around far more often than “developer experience”, without complaint (and of course, the DX of Astro-using devs is UX for the Astro creators)

It might be overused, that’s an opinion, I don’t agree.

100% agree with you that there's a lot of improvements to be done for a lot of the software we developers use on a daily basis. It's the term DX / Developer Experience in itself I dislike strongly. My sibling poster @swyx did a great job explaing my main gripe with using abbreviations like this.

I also hadn't had any coffee in way too long, so I have to admit I was a bit grumpy at the time of writing the comment :)

> Honestly we need more DX improvements in this industry.

Nope, we need to roll back everything that happened in the last ~10 years. We at the very least need to stop sticking JS and the web stack everywhere. Use the right tool for the job, NOT pick up a shiny tool and try to do literally everything with it. NOT stumble upon solution and start looking for problems to it. Finally realize that software engineering is actual engineering that, like other forms of engineering, has a sizable impact on other people's lives. Unlike in other forms of engineering, the cost of a mistake might feel diminutive enough, but people do suffer trying to use modern software products. I wish I was joking.

Have you used Next.js much? Next was the first (and so far, only) SSG I enjoyed using in the JS world. Just wondering if you have any comparisons. Markdown generation in Next was also a breeze.

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!

For me it's the pre-rendering. I've used Next.js, Nuxt.js, Remix etc and they all server-render great. But for deploying SPAs to file-hosting (S3 + Cloud Front or Firebase Hosting) without a server runtime, you end up with empty HTML on request which is worse for SEO, social previews etc. There are solutions to pre-rendering for these stacks but they're more focused on deploying to Vercel or Netlify functions, or having a post-build script which opens the site in Puppeteer and saves the HTML into your build file! With Astro, all this is out of the box immediately. Try putting together an Astro site and look in your build directory; you'll see even for React components the HTML is already there

I can just do a `nuxt generate` and put it on CF+S3 as well, right? how is that any different to what Astro does?

Looks the same to me after a quick read as someone who has never used an SSG BEFORE

Yeah you can, but there's more configuration involved. The default `nuxt generate` output is an HTML page that just has a loading element and a bunch of JavaScript tags*. On my Astro apps all of components that don't explicitly have a "client" attribute are prerendered

* unless something changed since my last Nuxt project

That's what I find confusing in Astro's self-presentation: they talk a lot about MPA vs SPA and how nicely they blend, making it abundantly clear that by MPA, they mean server-rendered. But then there's all the talk about static file hosting and I think the project even started as a static site generator ("dev-machine rendered")? It would be super awesome if they tackled what might be called "three level partial hydration" (build time, server side, client side).

Might even sneak in a fourth level, "server side, but cached until marked dirty". For when you are set up for static rendering, but want to reduce backend load for rarely changing stuff. I'd expect that it would be quite powerful to have that capability inside the engine that handles rendering, on component level if necessary,and not just on some internal microservice boundary (where I think it's quite common?).

Responding to myself: documentation clearly seems to come from two different areas, one when everything was either client side or build time and another after astro introduced server side dynamism.

Apparently there has been quite a watershed moment, with the announcement merely a few months ago: https://astro.build/blog/experimental-server-side-rendering/

If you look at the project structure it uses that might help make it more clear the capabilities: https://docs.astro.build/en/core-concepts/project-structure/ Content-focused seems to highlight that you can just dump markdown files into it and spit out rendered pages, very much like content focused static site generators (hugo, jekyll, etc.). But in addition to that static content it has all kinds of hooks and capabilities to add dynamic components or even pages, kind of like more modern web application platforms like next.js.

The winning point over other frameworks is the implementation of island architectures (streaming ssr static content + only load required js to run dynamic components) https://www.patterns.dev/posts/islands-architecture/

This gives some more examples of what Astro offers https://twitter.com/matthewcp/status/1557103499724333057?t=8...

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.

I feel you, tbh as someone who has NextJS as my main tools, it's hard enough to choose Remix or Redwood as a starter project, when I needed backend it's either Django or Spring boot from time to time.

Not really sure when to play around with these new frameworks if it's not giving me enough reason to switch, especially since they're not adopted in big tech companies it makes it harder to justify the usage when I want to build somethjing

That page is almost like the product is shrouded in secrecy of some sort.

I feel that this is what I was looking for https://docs.astro.build/en/concepts/why-astro/

I think it makes the tradeoffs that are ideal for content-oriented sites rather than web apps.

> Next.js uses React to render your website. Astro is more flexible: you are free to build UI with any popular component library (React, Preact, Vue, Svelte, Solid and others) or Astro’s HTML-like component syntax which is similar to HTML + JSX.

> Both Next.js and Astro are frameworks for building websites. Next.js does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).

https://docs.astro.build/en/comparing-astro-vs-other-tools/#...

Also Astro sites can be hosted on CloudFront or any another static CDN. Next you’re kind of tied to Vercel no?

You can upload the Next.js build to anything you like. netlify, S3 bucket, Apache or Nginx server running on solar powered bare metal.

If you need backend api functions - https://github.com/serverless-nextjs/serverless-next.js/ AWS Lambda etc. Probably slightly more work I grant you.

I tried this and the output HTML seemed pretty awful, but perhaps I was doing it wrong.

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.

forgive my ignorance but these front end based, non server rendering frameworks, how are they getting indexed by Google?

Reply on news.ycombinator.com