Comment by oinksoft | Hacker News Reader

Comment by oinksoft | Hacker News Reader

I've been using Angular on-and-off in professional settings since 2012. Angular is a framework obsessed with testability that treats usability as an afterthought. That said I've found Angular to be more than flexible enough to meet the needs of your typical CRUD apps, and generally enjoy working with it.

One thing I agree with the author about is the importance of expertise for a successful Angular project. Some specialized knowledge is needed to get a decent fit and finish, and the results can be horrible without that.

Strongly discouraging globals goes a long way towards improving code written by inexperienced engineers, but Angular's provider system is still not clearly documented with practical examples, which makes those engineers more likely to shove everything into the unavoidable Angular constructs (controllers, directives, $scope).

The middling quality and small availability of third-party Angular libraries is a problem. I believe that greater awareness/better tooling for ngDoc would be a tremendous help there. Best practices are not well-presented anywhere in the Angular world, particularly for designing reusable Angular libraries.

The other big problem is the project source code which I find poorly organized and documented. If you want to get into the guts of Angular for debugging purposes, good luck!

You say:

> That said I've found Angular to be more than flexible enough to meet the needs of your typical CRUD apps

The OP says:

> Are there any use cases where Angular shines?

> * Building form-based "CRUD apps".

So I guess you and the OP pretty much agree.

The author and I don't agree, except that Angular is not suitable for high-performance frontends (like games). The author suggests that Angular is only suitable for prototyping and that simply using the framework is technical debt. I particularly disagree with this statement: "Accept the fact that you will suffer in the future. The lowered expectations will help you stay happy sometimes."

It seems like the author is simply unhappy to be working in a framework not of his own design: "Create a metaframework based on angular, tailored SPECIFICALLY for your project needs and your team experience!" That's the one thing you shouldn't do if you want to reuse code between projects.

It's also one thing you shouldn't do in general. IMHO, adding too many abstractions on top of already abstracted concepts is just asking for a maintenance nightmare once the original team leaves.

(some abstraction is fine, but a metaframework on top of a framework is just going too far.)

> The author and I don't agree, except that Angular is not suitable for high-performance frontends (like games).

Would you really use DOM/virtual DOM templates to make a game? it makes little sense. I dont believe any "MV*" framework is suitable for games,even if the game is DOM based.

In a game,what you want is to make sure that at time T,the screen reflects the state of the game.Since you are manually pooling all states with a timer in order to render the game on screen,there is no need for databinding.

Actually that is the point :) The virtual DOM is equivalent to how you do write games. Declarative to imperative. React took its cues from how games are written. The renderer in react targets the DOM. React is a renderer.

The OP said he thought it would probably be great for a typical CRUD app.

From you wrote, you implied that maybe you mostly make only typical CRUD apps, when you write that's where you've found Angular to be more than flexible enough?

So that could explain your different experiences/analyses? You both actually agree it's good for typical CRUD apps?

Reply on news.ycombinator.com