4 ms·

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

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.

username__ 12y ago
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.)
aikah 12y ago
> 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.
- kuni-toko-tachi 12y ago
  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.
jrochkind1 12y ago
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?

username__ 12y ago

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

aikah 12y ago

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

kuni-toko-tachi 12y ago
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.

jrochkind1 12y ago

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?