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 $StateProvider?
Angular UI's $StateProvider
angularjs;state;internet;routing