Comment by eKIK | Hacker News Reader

Comment by eKIK | Hacker News Reader

Parent Full thread

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....

> 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.

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 :)

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.

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.

Reply on news.ycombinator.com