While I'd agree that conceptually cookies and hidden fields are similar -- they both offer ways to maintain state within the confines of a stateless protocol -- I would argue that they are, in fact, different enough for separate discussion. There are RFC's for cookies that make their use much more predictable than hidden fields. And they have features like expirations that you'd have to build into a hidden fields implementation.

I'm not arguing that any one state mechanism is better or worse. But they are different. I've used them both for different situations. The advantage of good abstractions and wrappers is that they provide a consistent state-saving API regardless of the underlying method(s) used. This may be what Selena/Eric was referring to with J2EE. To my knowledge it only hides it all under a consistent API, but still uses cookies (usually) or hidden fields as the mechanism. I always throw those "encoded in the URL" state-saving methods into the same bucket as hidden fields, but one could argue that as another, distinct method with its own distinct merits. IMO, A really good API defaults to whatever is available so that there's no real dependency. i.e., if cookies are disabled use another method. Selena/Eric's knock on CGI may be that there is no such layering there. I'd argue that for that you pick a higher level abstraction.