Hacker News Reader

Comment by dan_sbl | Hacker News Reader

Like some other commenters here who started with Bootstrap/jQuery/etc., I feel stuck in the stone ages at times. My most recent content-based site uses Hugo (https://gohugo.io/), but I'm starting to tire of the magic and gotchas I keep running into.

Can someone that has used Astro and an older static site generator framework explain the pros/cons of Astro in that context?

View on HN

Next.js is like what you'd get if you didn't want to use Angular because it's not "cool", only you took the guy in the back of the class who spent all day smoking weed, pumped him full of Ritalin then told him he'd only get his weed back if he designed a new javascript framework.

Only said dude also happened to be the son of the CEO so everyone was forced to use it and a large marketing team would be put together and bankrolled to make everyone else use it.

It's not that Angular isn't cool, it's not productive and very cumbersome. Rxjs gets in the way and ngrx has too much boilerplate. It's for large teams and companies that can afford to move slowly.

It depends on what you're doing. When I've used Angular I generated a lot of that boilerplate which reduced a lot of friction between frontend/backend.

If you can't do that then taking a simple approach (pulling in the libraries you need) makes more sense

My experience with Next.js is that it's an order of magnitude slower than Angular and makes it very easy to make massive security blunders (I have more than once found developers accidentality sending secrets to the browser).

What are you asserting that Angular is doing so special that it specifically prevents sending secrets to the browser in a way that NextJS doesn't already, or couldn't equivalently do?

Next.js combined code which runs on client and server into one thing, by default, then uses a naming convention to avoid disaster to avoid disaster.

That's a massive foot-gun.

Angular, out of the box, is focused on code which runs on the client. Yes you can do some tricks where some code is executed on the server, however the logical model stays the same: it's frontend code. So you wouldn't put tokens which you know belong in a BFF anywhere near it.

It's not just a naming convention it's part of the build/compilation step that will not bundle anything not specifically prefixed for the client, and is safe by default. You have to go out of your way to purposefully prefix an environment value with NEXT_PUBLIC_* to get it into the client bundle. I strongly doubt you've seen anyone screw this up by happenstance, maybe extreme laziness with copy and pasting but even then, the all caps naming requirement that includes "PUBLIC" is a big enough clue that I would consider it malice first.

This is also no worse than literally any SSR tool that's ever existed, going back to the CGI days.

> It's not just a naming convention it's part of the build/compilation > step that will not bundle anything not specifically prefixed for > the client, and is safe by default.

Yeah no, it isn't safe-by-default. I caught a frontend team shipping keys in the frontend code. Cause? Typo and using default templates which built-on-deploy.

Can you share a clear example? This still seems like a contrived complaint. How did someone fat finger typing that specific naming requirement prefix? Or how is leaking a value into a template like that not similarly a risk in Python or a Go backend that renders stuff on the server (like all the HTMX hype). It feels like you're saying that a fat client side SPA is the only answer to anything.

I think Astro enables component based architecture and higher interactivity than a typical static site generator. This is sometimes easier to manage complex designs, and or when working with bigger development teams.

They also have a good doc on their page

https://docs.astro.build/en/concepts/why-astro/#content-driv...

Reply on news.ycombinator.com