[radicalbyte]

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.

[lakomen]

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.

[radicalbyte]

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

[evilduck]

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?

[radicalbyte]

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.

[evilduck]

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.

[radicalbyte]

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