Posted by Jerry Stuckle on 02/23/07 13:01

Erwin Moller wrote:
> Jerry Stuckle wrote:
>
> <snip>
>>>
>>> In defense for JavaScript: My *personal experience* is that a lot of my
>>> customers prefer the sexy behaviour a site gets with javascript above
>>> better compatibility (= JS disabled).
>>> Also: It takes a lot more developmenttime in realworld situation to make
>>> a 'double site': one for JS enabled, one for disabled. And not all want
>>> to pay for that, and settle for JS only site.
>> You don't need to have two sites. JS should enhance a page - but not be
>> required to use it.
>
> Hi Jerry,
>
> Of course you don't need 2 seperate sites.
> I know that. I I think you know I know. :-)
> That is why I wrote 'double site' between the ''.
> My point is simply that making sites work in both situations can take a lot
> more effort in some situations.
> And I am not refering to trivial checks like somebody filled in a certain
> field in a form. That is a breeze of course, and should be checked
> serverside anyway.
>

But a lot of people would take "double site" to mean two separate copies
of each page - one with JS enabled and one without.

>
>>> I simple say at the homepage/entrancepage that JS must be enabled to use
>>> the site.
>>> Of course, a website that handles both situations right is better than
>>> one that demands JS.
>>>
>> And therein lies the problem. How many people leave after seeing your
>> home page without going any further? Every one of them who run with JS
>> turned off. So obviously, since you only see those who have javascript
>> disabled, your conclusion is that most people have JS enabled.
>
> ???
> Where did I say I concluded that most people have JS enabled based on my
> visitors? You put words in my mouth/writing.
>
> I DO think that by the way, I just didn't say it. Maybe you are confusing
> posters. :-)
>

No, you didn't state it here. But it's a logical conclusion from other
comments you've made and the fact you don't push it with your customers.
But it's also an obvious conclusion to make when you never see the
non-JS users.

There isn't anything wrong with this opinion, Erwin. And for your
customer base it may be 100% correct. But do you think it might also be
based on incomplete information?

>>> An example (a thing I am working on right now):
>>> I need a geograpical map of some area with lots of regions in it.
>>> The user clicks on one region and I must select the neighbouring regions:
>>> they light up.
>>> Another selectbox defines how deep the neighbours are found (eg 0, 1, 2,
>>> etc).
>>> If I must deliver that piece without JS, I need a roundrobin to the
>>> server for each click, rebuild the map with the right regions lighted up:
>>> quite slow and it will result in a sluggish enduserexperience.
>>> This is just an example of realworld situations I do want to
>>> program/deliver without JS.
>>>
>> Yes, it requires a request to the server. but it should not be "slow"
>> and should not result in a sluggish end user experience".
>
> Not?
> Not if the map exists of 200+ images that the browser has to layout every
> time after every click?
> Of course that will be sluggish compared to Javascript switching a few
> images, and you know that just as well as I do. Or I am misjudging your
> competence completely.
>

First of all, most of those images would already be cached by the
browser and wouldn't need to be fetched from the server.

But it also means you need to send two copies of every image for the JS
version, whether or not you'll even need them (and chances are you won't
need all of them - maybe not even a large percentage of the copies).

So your first page is going to be twice as slow loading because it has
to load all of those images which probably won't be used.

So a good compromise in this case would be to have JS load the copies
and handle the image switches. And if JS isn't active, don't load the
extra copies and make the trip to the server.

That way JS is enhancing the experience, but the experience doesn't
require JS.

>
>>> One a sidenote: What is so bad about demanding JS for your site? People
>>> demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
>>> I have no problems with it. :-/
>>>
>> Because you lose customers that way. Every one who surfs with
>> javascript turned off. And you never see them go.
>
> Loose customers?
> I loose MY customers if I present them bills for fully compatible sites
> (JS/no JS, Java/No Java, Flash/no Flash, etc).
>

I'm talking about THEIR customers. I don't lose customers because I can
show them how not being compatible would lose them money. Most are
quite happy to pay for non-JS versions when they understand requiring JS
can cost them more in lost sales than the cost of implementing the solution.

> Well Jerry, as I said: I don't mind making apps 100% non-JS compatible. But
> I must raise my bill because it results in more coding/thinking and in some
> situations a lot of double work.
> Of course I prefer a site that handles both situations....
> And the situation flas/no flash.
> And the situation Java/no Java.
> Go on and do the math. My bills will grow.
>
> I think you are describing some 'ideal world' solution, while I tried to
> describe real world situations that run on tight budgets.
> I do not know how you are employed, but I run my own business and simply do
> not have the luxery to make perfect apps day-in-day-out, allthough I would
> like that.
>

No, not "ideal world". The way I work. I run my own business, also
(have for over 16 years, now). I don't make 'perfect' apps. But at the
same time I show my customers the real world. And BTW - I don't do
flash at all - too "graphically challenged" :-). But I have someone who
can do the flash if I need it. And I don't do client-side Java unless
there is a very good reason for it. Most sites obviously don't need it.

In an "ideal world" you could require JS/Flash/Java and anything else
and not lose any potential customers. In the "real world", though,
doing any of these will lose you potential customers. The only question
is which will cost you more money in the long run - the loss of
customers by requiring these technologies, or the cost of implementing
non-JS/Java/Flash version.

It's a trade-off, and details will be different for each site. But for
my customers the extra up front cost would be recovered by just a few
sales.


> And for clearity's sake: I DO agree that sites that handle JS and no-JS are
> better.
>
> Regards,
> Erwin Moller
>
>>> just my 2 cent.
>>>
>>> Regards,
>>> Erwin Moller
>>
>

Another example here. I'm working on a site with dropdowns for country
and state/province. When the country changes, the state/province
contents change (or it is disabled).

Obviously this requires javascript and there's no way to do it with
javascript disabled. So I set it up such that all entries are placed in
the state/province block. When JS is enabled, it replaces the content
with an accurate list (or disables it completely). But if JS is
disabled, the state/province block shows all entries. Either way there
needs to be further validation server side. But again, JS "enhances the
experience".

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]