[OT Web 2.0] Do you think free ad's might help advance D?

[BCS]

Hello Nick,

> "BCS" <none at anon.com> wrote in message
> news:a6268ff14f1d8ccd880e8e83886 at news.digitalmars.com...
> 
>> Hello Nick,
>> 
>> Using JS alows many thing to be done without reloading the page. This
>> is a plus as far as I care. Making it work with JS *and* without is
>> harder than either by its self.
>> 
> Only slightly harder. Unless you try to go completely overboard with
> JS, but that would be a bad thing anyway.
> 

Maybe I should have said "Making it work implemented in terms of JS *and* 
not is harder than either by its self." But then your point may still be 
valid

>> Given the choice between a high functionality version and/or a lower
>> version, the worst choice is to do only the low version.
>> 
> 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.

>> First, I don't think your nuts,
>> 
> Well that just goes to show how nuts you are! (J/K ;) )
> 

The entire CS department figured that one out years ago.

>> 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.
 
> 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 :)>
 
-- 
... <IXOYE><