Hacker News Reader

Comment by Alir3z4 | Hacker News Reader

It's like either use Angular or end up building an Angular when you choose a smaller/lightweight framework. At least so many times it's true in my case.

Angular gives so much out of the box without making your double think it, well it's an opinionated toolset for sure.

However, any other frontend framework I've used and know, makes you to build all those stuff form scratch or get them by adding more and more dependencies to your project.

Great release and can't wait to try the performance optimization and build enhancements.

Looking forward to see esbuild gets more and more involved in their toolchain.

View on HN

This is exactly my experience. I also recently heard a story (from a close friend) of a rewrite to React where a good few months were spent on questions like which routing (or whatever) library to use, all things provided by Angular out of the box.

JSX mixing presentation and business logic also looks weird for someone who lived at a time when not doing MVC in PHP was a blasphemy and would not get you a respectable job.

Admittedly AngularJS was horrible but nowadays Angular offers me everything I need while I watch other people moving to Nextjs or whatever latest buzz frameworks for features Angular provides (like server side rendering).

Months choosing routing?

If so then they have bigger problems.

It's life. It's one thing to call people amateurs from a sofa and an other to find yourself in 20 person team arguing about things.

The easy solution to arguments is having less things to argue about, similarly how Go solved formatting wars by an official format, Angular solves those fights by providing a default implementation.

It's not life, it's your typical bike-shedding. React is being used on much larger teams all the time without spending months on arguing whether react-router is the right choice. I don't think I have ever spent more than ten minutes on choosing which library concoction works best for a given project.

In less dysfunctional organizations you go with whatever the technical lead specified.

> It's not life, it's your typical bike-shedding

It's typical because it's life and it happens often.

> In less dysfunctional organizations

Dysfunction is the norm.

I am arguing for opinionated tools in general, I'm not saying you can't make it without them.

Similarly I advise against lottery while not doubting you won at it.

How is the angular internationalization and automated testing story? Last time I looked at it (v3 or v4, I think), it was still half baked, especially in comparison with AngularJS.

I imagine it's settled by now?

The i18n has apparently progressed (can't speak to it, though; we're still using ngx-translate, without which Angular life would have gone to Hard Mode) but the testing (and also debugging runtime errors) story is still the utter trash fire that it's always been.

"Unit" or "component" testing works, but there is tons of boilerplate required in real-world situations, which will often only become obvious after you try to run your tests, so it is tedious to write.

Protractor (the previous Angular-sanctioned E2E test framework) really died with AngularJS, so it's been a pretty unworkable and high-maintenance mess this whole time, and they only just now finally came to terms with this and killed it. (Also didn't replace it.)

P.S.:

From grievous and traumatic personal experience: Don't use Cypress. Use Playwright[1]. Cypress was great in 2017 of you were coming from Selenium/Protractor. But Playwright in 2021 is to Cypress what Cypress was to Selenium in 2017.

[1] https://playwright.dev

The provided i18n library is really good, but it lacks tooling around it (like proper extraction of keys, meanings, descriptions, etc..).

Unit testing works flawlessly out of the box with Karma and live reloading, E2E needs a bit of setup, especially if you want to go with Cypress instead of Protractor.

For most use cases its ready to use and for everything else there will almost always be some articles on how to achieve it (i.e. E2E with Cypress).

> The provided i18n library is really good, but it lacks tooling around it (like proper extraction of keys, meanings, descriptions, etc..).

Ah, damn, so it hasn't progressed much, if I'm not mistaken. They should really invest in that. I wonder how Google uses it internally, in this case.

Reply on news.ycombinator.com