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

[Nick Sabalausky]

"BCS" <none at anon.com> wrote in message 
news:a6268ff14f568ccd8dfcc495764 at 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.