"BCS" <n...@anon.com> wrote in message news:a6268ff14f568ccd8dfcc495...@news.digitalmars.com... > Hello Nick, > >> I would disagree that "JS == high-functionality and non-JS == >> low-functionality" is true in the general sense. I'm not saying that >> the reverse is necessarily true, but I think that's a false dichotomy. >> > > I see three cases: > -JS and non-JS look and feel the same to the user (do non-JS) > -JS can be tacked on the non-JS and people without scripts just loose some > non critical functionality. > -Some functionality can be done via JS or no-JS but they work in > completely different ways. (like voting: do you reload the page or not?) > > The first two cases are uninteresting and I was ignoring them. In the > third case, If you assume the devs aren't stupid, the JS version has to > have higher functionality than the non-JS one. >
Hmm, I guess we see things differently here. To me, that voting example seems a prime candidate for case #2. Make it work with a normal non-JS page request, and then toss in a JS-override that, instead of being a new page request, just sends a little message to the server which, in turn, does exactly what it nomally would, but without rendering and sending a new page. Ie, just a minor variation on what's normally done. >>> however I think the economics are against you here. From the web page >>> writers standpoint, given that most user DO allow JS, the cheapest >>> way to deliver the best user experience to the most people is to do >>> each part in whatever way is easiest to do a good job with. It >>> doesn't pay to spend hardly any time making the site better for a few >>> percent of your user base when the same time could be spent making it >>> better for the other 95+%. >>> >> One problem with that is that most sites that use exactly that logic >> end up using JS poorly and wind up with something much worse than if >> they hadn't used JS at all (Granted, SO isn't as bad in certain >> regards as other sites, but as a programmer, many of those other sites >> are a little easier for me to ignore than SO). > > Why assume they will be any more competent in static HTML than in JS? I've > based all of what I'm saying on the assumption that the devs aren't > stupid, because if they are, they can make all kinds of problems no mater > what they use. > I assume that for two reasons: 1. I've seen screwed-up static-HTML pages and I've seen screwed up JS pages. The worst of the static-HTML screwups have always seemed to be far better than then the worst of the JS screwups. 2. Static-HTML just simply provides less opportunity for serious screw-ups. It's like a butter knife vs a carving knife: If an idiot's gonna use one of them, better the butter knife. Yea, they can still cause trouble with it, but not as badly, and not as easily. >> Plus, remember about ten or so years ago when there was a lot of >> discussion in the web dev world about page-loading times, and the >> general consensus was that anything that took longer than a few >> seconds to load and render was bad from a usability standpoint? Well, >> now it's a regular occurrence for these JS sites to take much more >> time than that, and then still act sluggish once you're there, and >> that's despite increases in computational power (even for low-tech >> me), despite the fact that we've gone from mostly-dial-up to >> mostly-broadband, despite the *claims* that it's allegedly faster (it >> frequently isn't in actual practice), despite the fact that *we knew >> better* 10+ years ago. > > Up front times vs. background times <copy arguments from above :)> > Yes, but from a usability standpoint (especially for the average Joe), that distinction doesn't make one bit of difference: It's still a delay before being able to deal with the page.
