JavaScript considered harmful

[Erno Kuusela]

In article <3dg05gdclu.fsf_-_ at ute.mems-exchange.org>,
Andrew Kuchling <akuchlin at mems-exchange.org> writes:

| aahz at panix.com (Aahz Maruch) writes:
|| I'm simply pointing out that using cookies doesn't gain site developers
|| much (if anything) and that *requiring* cookies loses users.  If that's
|| what they want, fine -- but most developers don't even *understand* this
|| yet.

| What cookies gain is simplicity.  They avoid the need to run every
| single page on a site through a script that inserts the session into
| every link.

actually no. you can embed the session id in the url as a path
element, and then use relative links.

| 	* URLs stay simple; users are not able to figure out which
| 	* part of the URL is a session ID and can be omitted.

that is indeed an advantage, but imho the disadvantages outweigh it.

| Personally, I'd implement with cookies.  Newer user agents have the
| flexibility to allow cookies for some domains and reject them for
| others (but does IE, which is the 900-pound gorilla here?), so
| sophisticated users can configure their browser appropriately, and
| unsophisticated users won't go disabling cookies anyway.

requiring users to do configuration specifically for your
site is not as user friendly. (relying on
your users' indifference or computer illiteracy may work, but
i do not consider it elegant.)

| I deem supporting both cookies and URL IDs to be impractical; 99% of
| people will be happy with the cookied version, so the URL version will
| get very little testing, and it'll add painful complexity to the Web
| server's configuration.

sure, if you do both a cookie and a url version, it will add
complexity. but if you only use url based state, they are equally
complex.

  -- erno