5 ms·

> 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

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

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.