5 ms·
I fully agree with this. SPAs are for webapps, not websites. For websites, you should always use progressive enhancement - there is no reason why you couldn't
by joepie91_ 11y ago
I fully agree with this. SPAs are for webapps, not websites.
For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for.
Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.
- baddox 11y agoThe title and article are also for web apps, not web sites.
- tomjen3 11y agoMaybe not all my clients support javascript, but substantially all I care about do. I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it. Works very well.
- dorgo 11y agoI enable JS for sites I feel are valueable for me. The first impression is always without JS. If navigation-buttons dont work without JS - I just leave.
- oldmanjay 11y agoif you self-select into the group that isn't cared about, then do you expect your leaving to be cared about? i ask only because i'm puzzled as to the purpose of your reply.
- dorgo 11y agoI am too small a group to be cared about. But in my opinion only poor designed websites use JS for layout or navigation. And the way back to the search-engine is always just one mouse gesture away. JS = code written by someone with not neccessarily my best interests in mind running on my computer.
- sumedh 11y agoHonest question - What are you trying to prove by not enabling JS by default?
- bottled_poe 11y agoAside from the fact that JavaScript is often poorly written, I generally don't want untrusted code running on my computer.
- Qantourisc 11y agoI think it's a matter of prevent: links to facebook, linked-in, and god knows what other service; and possibly save some bandwith, cpu time and ram.
- aw3c2 11y agoI doubt she tries to prove anything. It is probably rather the peace of mind of not having ads stabbing in your eyes, subscribe popups appearing as you scroll, things wiggling around, images fading up in a popup instead of loading directly, protection against exploits and saving bandwidth just to name a few benefits.
- joepie91_ 11y ago> Maybe not all my clients support javascript, but substantially all I care about do. See here: http://bradfrost.com/blog/post/fuck-you/ http://bradfrost.com/blog/post/fuck-you/ > I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it. That is a reverse CAPTCHA, it works very well, and has absolutely nothing to do with Javascript. They are typically implemented using CSS.
- tomjen3 11y agoActually I think you are right that this particular one uses CSS - but I may have to upgrade to JS if the spammers get past it.
- baddox 11y ago> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the Internet.
- liviu- 11y agoI think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.
- baddox 11y agoIt does, however, require a potentially large amount of work for a SPA. Granted, server-side rendering for JavaScript libraries like Ember and React is doable now.
- joepie91_ 11y ago"Graceful fallback" is what came before progressive enhancement, and is considered obsoleted for good reason. Graceful fallbacks tend to be maintained as a separate version, and neglected over time. Progressive enhancement means taking a basic page and adding snazzy functionality to it - eg. ajaxified page loads. The latter is what you want.
- fred2133 11y agoYou should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.
- baddox 11y agoJust out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.
- mandeepj 11y agoFirst page load can be totally server side generated. Once loaded on client side, you can check using modernizer or something if your user's browser supports the features that you need for SPA if yes then you can replace server side generated HTML structure with a client side version. Now, you can proceed with all of your server and client communication via your favorite SPA framework.
- noir_lord 11y agoI didn't even use a SPA for a webapp on my main work project I wrote a lightweight base and send down the page specific stuff and that model (so in a way it's lots of little SPA's not sure if that has a name) which means I get most of the advantages with few of the downsides.