5 ms·

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 us

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.

spriggan3 10y ago
> 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.
- abritinthebay 10y ago
  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.
  - bobajeff 10y ago
    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.
    - nomel 10y ago
      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.
    - abritinthebay 10y ago
      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?
    - abritinthebay 10y ago
      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?
  - spinlock 10y ago
    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.
    - abritinthebay 10y ago
      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
      - spinlock 10y ago
        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?
- robinson7d 10y ago
  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.
3pt14159 10y ago
The only time I need cookies is during OAuth requests because you need the token there. That's the only place I use them.
deleted 10y ago
[deleted]

spriggan3 10y ago

> 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.

abritinthebay 10y ago
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.
- bobajeff 10y ago
  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.
  - nomel 10y ago
    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.
  - abritinthebay 10y ago
    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?
  - abritinthebay 10y ago
    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?
- spinlock 10y ago
  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.
  - abritinthebay 10y ago
    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
    - spinlock 10y ago
      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?
robinson7d 10y ago
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.

3pt14159 10y ago

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

deleted 10y ago

[deleted]