A collection of articles by AngularJS veterans, sometimes even core committers, that explain in detail what's wrong with Angular 1.x, how Angular 2 isn't the future, and why you should avoid the entire thing at all costs unless you want to spend the next few years in hell.
Reason for this: I'm getting tired of having to explain to everyone, chief of which all the indiscriminate Google Kool-Aid™ drinkers, why I have never believed in Angular, why I think it'll publicly fail pretty soon now (a couple years), and why it's a dead end IMO. This gist serves as a quick target I can point people to in order not to have to parrot / compile the core of the articles below everytime. Their compounded reading pretty much captures 99% of my view on the topic.
This page is accessible through http://bit.ly/angular-just-say-no and http://bit.ly/angularjustsayno, btw.
- I won't be using Angular for my next project...and neither should you. • Robert Greylin, Feb 2015
- The reason AngularJS will fail • George Butiri, Mar 2014 – Apr 2015
- Introducing Aurelia • Rob Eisenberg, Jan 26 2015
- Why you should not use Angular • Egor Koshelko, Jan 2 2015
- The problem with Angular • PPK, Jan-Mar 2015
- AngularJS: the bad bits • Mircea Moise, Sep 13 2014
- You have ruined JavaScript • Rob Ashton, Apr 23 2014
I was kind of waiting for the "why not SSR" argument. Did not disappoint. Going to apologize for the book on tape up front.
re: aspnetcore mvc, why not MVC?
Angular is an MV* as well, but that's beside the point. The server-side MVC architecture tends to be bloated an expensive in actual large applications; performance solutions always inevitably devolve "moar caching" when your issue turns out to be 'markup takes too long to compute' and you fail your SLA/SLC in load testing.
At the end of the day, you're using your own hardware to generate markup on the server, and that's just cost you don't have to take on, in addtion to redundant bandwidth expenses (before even talking about the absence of minification). I've seen too many companies with MVC apps, million dollar/year redis clusters that could be replaced with a small API, a JWT token and a few dozen lines of front end code, all to enable this particular golden hammer. All the commodity labour cost-compensation in the world won't solve that.
re: auth is better on the server, so say we all?
You're dealing with a token one way or the other. In a well-designed front end, you'll get the same role validation and policy that you get with aspnet (route guards, etc). The token -> claims blood-brain barrier is pretty much the same as it's always been, there's no inherent superiority there for a server scenario.
aside: if you ever find yourself saying, "BUT JWT HAS VISIBLE CLAIMS, IT'S NOT SECURE!!!," I might suggest that you're probably putting the wrong data into claims to begin with. Bonus: the token body can be an encrypted string, which gets some people back to their comfort zone but does not invalidate the first statement.
re: vanillajs blended with SSR (aka, the 2005 pattern)
Hot, fresh(,) sports opinion: Ime, this approach seems to always rapidly turn into spaghetti code, completely leave modern optimizations (chunking, lazy loading, budgets, etc) on the cutting room floor, or both. Some would say this is just sensible YAGNI; some are also probably skeptical about the efficacy of seatbelts, profilactics and other such hipster tech.
I've never seen this pattern implemented in a way that thoughtfully coordinated DOM updates to avoid layout thrashing and unncessary work on the browser. Rather, it almost always results in large interactive data features blowing right past the 100ms update window and being a generally terrible user experience. This pattern usually dovetails with the "render and scrape" anti-pattern where a well-known or contextualized queryable grabs some json data that was rendered to the markup and the js code then binds to it.
Agree to disagree though. At least we both think dotnet core is awesome :)
disclaimer: our org angular on the front end, scale-to-zero aspnetcore api on the backend, on linux, and have been for years, as well as some micronaut graphql lately. We're what I consider to be a "large" application, with 100+ top-level routed features. We even handle SEO fine without SSR.