This question already has an answer here:
I was thinking of using Angular UI, and specifically its
$StateProvider, which makes it easy to create nested views, in my next application. Until now, I have been using vanilla Angular's
ngInclude directive with a URL as a variable passed in from some controller. This is easy enough, but, as you can imagine, it can get pretty complex, and the
uiView directive promises to make it simple.
One thing I keep coming back to as a reason not to use
$StateProvider is the "state" part. The Internet is supposed to be "stateless", yet this is an entire routing system built on providing "states" to your site. It feels wrong. I know we have things like cookies and sessions that provide a kind of pseudo-statefulness, but these were kind of needed and they aren't a full system like
$StateProvider. Also, state may not necessarily be a bad thing for the Internet. I tend to think it is, but I can see why some programmers might want it.
On the other hand, the states provided by
$StateProvider don't seem like the kind of states the Internet isn't meant to have. When I think of "statefulness" in terms of the Internet, I think of initial state, not inherent state. If you do some action on a website, and then GET a resource again through the same path (URI), then the resource you get should be the same resource, though it might be changed or deleted.
$StateProvider does not seem to violate this principle because you're GETting the same resource each time you go to the same path (in general).
To reiterate: I am NOT asking about whether cookies and sessions are good or bad, or whether a stateful Internet is good or bad. Therefore, the answers to this question, while helpful, do not entirely satisfy me. I am asking whether Angular UI's
$StateProvider creates state on the Internet, in particular the kind of state that web programmers seem to hate.
So, should I be worried about making the Internet stateful when using Angular UI's