Hacker News Reader

Comment by avolcano | Hacker News Reader

It's funny, I got started with web development relatively recently (2012 or so) and immediately started working on single-page/client-side applications, so I used localStorage from the start. It seemed easy enough to make a little Ajax wrapper for all my requests to tack the authentication token on (whether as a URL param, form data, or header data).

Imagine my surprise when I later learned how cookie storage worked! There was a brief moment of "oh, I guess not having to manually append this to my requests would be nice," only to read about CSRFs and other horrors cookies enabled.

Since then, I've fixed multiple existing CSRF exploits in production (or near-production) applications, and continued to avoid cookies wherever possible.

View on HN

> Imagine my surprise when I later learned how cookie storage worked! There was a brief moment of "oh, I guess not having to manually append this to my requests would be nice," only to read about CSRFs and other horrors cookies enabled.

Cookies do not require javascript, unlike whatever solution using web apis.

Which is relevant for the ~1% of the web that doesn't use JS then (even screen readers support JS) and LOTS of sites won't even work at that point - cookies or not.

I just want to say that while a lot of people have browsers with JavaScript enabled you shouldn't use it for things that the browser does natively.

Not just for performance reasons. But because that puts the burden of maintenance of those elements on the website.

It's a lot like how you shouldn't use fixed width and margins for pages. There are a lot of assumptions developers make when building these elements that can easily change and obsolete their work.

So unless you absolutely have to don't take on that burden.

Any idea why this was put down? The concept of keeping critical functionality to "expertly maintained" libraries seems sane to me, otherwise we would all be writing our own encryption routines.

Right, I'm not disagreeing with that at all.

I'm pointing out that a knee-jerk "doesn't work with JS" is irrelevant to 99% of web users.

Be there are other considerations of course, like accessibility, UX consistency, etc (all of which ARE doable in JS if you have to) but that's not what I was responding to, was it?

I'd argue that there's a resurgence in non-JS web sites due to server-side rendering. React and Ember both support this really well at this point. So, you'll actually get a non-JS view of your SPA then progressively enhance this with JS.

I agree, I'm doing it myself.

But that still doesn't mean it's going to be seen by more than either bots or that 1%.

I'm being down voted for pointing out the actual number of users that will care about that effort directly.

HN is hilarious sometimes

I'm not using fastboot (just not worth going from rails to node in our use case) but if you have set that up, won't all of your users see a non-js website before they see your js website?

To me it seemed implied that Javascript was required for other reasons anyway, when the parent said "started working on single-page/client-side applications".

At least, that's typically part of how I parse it when people refer to a site as an SPA.

The only time I need cookies is during OAuth requests because you need the token there. That's the only place I use them.

Reply on news.ycombinator.com