4 ms·

I agree with you in principle that if apps don't meet 1, 2, 4 & 5 they shouldn't see light of day but I think your points are largely spurious or handled by any

I agree with you in principle that if apps don't meet 1, 2, 4 & 5 they shouldn't see light of day but I think your points are largely spurious or handled by any semi-competent dev. 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point. 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app. 4. is totally false as screen-readers support JavaScript. 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps.

copsarebastards 12y ago
> 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point. I'm not sure what it would even mean for this to not be broken in a one-page app. If you're displaying more than one conceptually grouped set of content on one page, you're breaking the web's concept of a page: a page is one conceptually grouped set of content. JS MVC frameworks allow you to back and forward between "pages" within a page using the hashed href trick, but they can't keep your scroll location without rendering the page to determine layout, unless there's some magic I'm not aware of. > 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app. I love when people tell me that nobody does what I do all the time. And it's not just me: a lot of people save pages for later reading, especially in academia. > 4. is totally false as screen-readers support JavaScript. Yes, screen readers support JavaScript, but JavaScript rarely supports screen readers. It's clear you've never actually attempted to browse the web using a screen reader. > 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps. JavaScript security is a fucking joke. I'm not sure what you think authentication does when your JavaScript is running in the same namespace as all the other JavaScript in a page and malicious code needs simply to tell authenticated code what to do to spoof an identity. A server can do nothing to provide security when the requests from a browser are coming from an authenticated user (but are actually made by malicious JavaScript in the page). Plenty of apps include advertisements from arbitrary sources, hence loading content from a server that isn't yours.

copsarebastards 12y ago

> 1 & 2 are a basic feature of JS MVC frameworks. I get that some people still probably mess this up, but there's no excuse to do so at this point. I'm not sure what it would even mean for this to not be broken in a one-page app. If you're displaying more than one conceptually grouped set of content on one page, you're breaking the web's concept of a page: a page is one conceptually grouped set of content. JS MVC frameworks allow you to back and forward between "pages" within a page using the hashed href trick, but they can't keep your scroll location without rendering the page to determine layout, unless there's some magic I'm not aware of. > 3. Irrelevant/FUD? No normal user 'saves' web-pages, unless it's something like a receipt, which any sane dev would make a separate html page and not part of the app. I love when people tell me that nobody does what I do all the time. And it's not just me: a lot of people save pages for later reading, especially in academia. > 4. is totally false as screen-readers support JavaScript. Yes, screen readers support JavaScript, but JavaScript rarely supports screen readers. It's clear you've never actually attempted to browse the web using a screen reader. > 5. is false/strawman as any half-sane SPA developer still authenticates using a regular back-end framework and I've no idea what 'If you app loads content from a server that isn't yours' has to do with single-page apps. JavaScript security is a fucking joke. I'm not sure what you think authentication does when your JavaScript is running in the same namespace as all the other JavaScript in a page and malicious code needs simply to tell authenticated code what to do to spoof an identity. A server can do nothing to provide security when the requests from a browser are coming from an authenticated user (but are actually made by malicious JavaScript in the page). Plenty of apps include advertisements from arbitrary sources, hence loading content from a server that isn't yours.