Posted by Curtis on 03/11/07 09:09

On Sun, 25 Feb 2007 05:49:49 -0800, Jerry Stuckle =

<jstucklex@attglobal.net> wrote:

> Curtis wrote:
>> Jerry Stuckle wrote:
>>> Erwin Moller wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>>> Erwin Moller wrote:
>>>>>> Jerry Stuckle wrote:
>>>>>>
>>>>>> <snip>
>>>>>>>> In defense for JavaScript: My *personal experience* is that a l=
ot =

>>>>>>>> of my
>>>>>>>> customers prefer the sexy behaviour a site gets with javascript=
=

>>>>>>>> above
>>>>>>>> better compatibility (=3D JS disabled).
>>>>>>>> Also: It takes a lot more developmenttime in realworld situatio=
n =

>>>>>>>> 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 - bu=
t =

>>>>>>> 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 checke=
d
>>>>>> 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.
>>>>
>>>> My bad.
>>>> That happens when Dutch guys think they mastered english enough. ;-=
)
>>>>
>>>
>>> Understandable. But you wouldn't want to hear my try at Dutch! :-)
>>>
>>>>
>>>>>>>> I simple say at the homepage/entrancepage that JS must be enabl=
ed =

>>>>>>>> to
>>>>>>>> use the site.
>>>>>>>> Of course, a website that handles both situations right is bett=
er =

>>>>>>>> than
>>>>>>>> one that demands JS.
>>>>>>>>
>>>>>>> And therein lies the problem. How many people leave after seein=
g =

>>>>>>> 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 base=
d =

>>>>>> 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?
>>>>
>>>> To be honest, I am unsure.
>>>> Last numbers I saw (w3schools) says 6% is JS challenged.
>>>> But I admid I have no clue how reliable that numbers are.
>>>>
>>>
>>> Me, neither. And it depends a lot on the target audience.
>>>
>>>> By the way: I cannot reach www.thecounter.com anymore. They used to=
=

>>>> serve good statistics if memory serves me well. Does anybody know =

>>>> what happened with them? Paying clients only?
>>>>
>>>
>>> I can still get it here.
>>>
>>>
>>>> Still, from a (business) clients point of view 6% missed customers =
=

>>>> can or cannot be acceptable (pricewise).
>>>> Very roughly speaking: I think the price for sites I build rises by=
=

>>>> 10-20% on most projects I work on to make them work in both =

>>>> situations.
>>>> Mostly because of double work.
>>>>
>>>
>>> Yes, it is more work. But things like validation (as you pointed ou=
t =

>>> earlier) can be done on the client side - but must be done on the =

>>> server end, also. And yes, 10-20% is about right, in my experience.=

>>>
>>>>
>>>>>>>> An example (a thing I am working on right now):
>>>>>>>> I need a geograpical map of some area with lots of regions in i=
t.
>>>>>>>> The user clicks on one region and I must select the neighbourin=
g
>>>>>>>> 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 enduserexperien=
ce.
>>>>>>>> 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 layo=
ut =

>>>>>> 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 misjudgin=
g =

>>>>>> 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 t=
he =

>>>>> 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.
>>>>
>>>> True.
>>>> But after one click JS wins performancewise.
>>>> Slower to build the first time, faster after one click.
>>>>
>>>>> So a good compromise in this case would be to have JS load the cop=
ies
>>>>> 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.
>>>>
>>>> True.
>>>> I am merely trying to get the point across that I have to make the =
=

>>>> routines in HTML/JS AND in PHP serverside.
>>>> More work, higher bill.
>>>>
>>>
>>> Yep, and fewer lost potential customers.
>>>
>>>>>>>> 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 ar=
e
>>>>> 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.
>>>>
>>>> Just curious, roughly speaking, how much more work do you guess you=
=

>>>> need to make your app work nicely with and without JS? (I estimated=
=

>>>> that in my case around 10-20%)
>>>>
>>>
>>> About the same here. It depends a lot on the site.
>>>
>>>>
>>>>>> 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/thinki=
ng =

>>>>>> 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, als=
o
>>>>> (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 d=
o
>>>>> flash at all - too "graphically challenged" :-). But I have someo=
ne =

>>>>> 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 ne=
ed =

>>>>> it.
>>>>
>>>> True.
>>>> I also seldom use Java clientside these days. (I used to love it, b=
ut =

>>>> since Javascript became more powerfull, and I could develop a lot =

>>>> fatser in JS...)
>>>>
>>>
>>> I still do some server side Java - it's nice if you get it on a fast=
=

>>> server. But Java can be a resource hog, and many clients it would r=
un =

>>> unacceptably slow, especially when you're targeting consumers (who a=
re =

>>> more likely to be speed and/or memory constrained).
>>>
>>>>
>>>>> In an "ideal world" you could require JS/Flash/Java and anything e=
lse
>>>>> 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.
>>>>
>>>> Yes, that is the question.
>>>> And the answer depends on the type of customer indeed.
>>>> I do a lot of start-ups (people who just start their business and =

>>>> need online help), and lots of them are very pennywise, but =

>>>> poundfoolish. In case their business runs smoothly, they DO have th=
e =

>>>> money to upgrade/fix annoying stuff on their site. :-)
>>>>
>>>
>>> Yes, I see that, also. But that's where I explain to them how they =
=

>>> can lose customers because of it. If the have any brains at all, th=
ey =

>>> think about that.
>>>
>>>>
>>>>> It's a trade-off, and details will be different for each site. Bu=
t =

>>>>> for
>>>>> my customers the extra up front cost would be recovered by just a =
few
>>>>> sales.
>>>>>
>>>>
>>>> You don't charge them enough Jerry! ;-)
>>>>
>>>
>>> Sure I do :-)
>>>
>>> But most of them aren't selling $5 Rolex Replicas, either. :-) =

>>> They're doing something a little higher end, where their markup coul=
d =

>>> be from $10-100 per order. Even at $10 it doesn't take long to reco=
up =

>>> a couple of hundred dollars.
>>>
>>>>> 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 wit=
h
>>>>> 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 "enhanc=
es =

>>>>> the
>>>>> experience".
>>>>
>>>> Yes, that's the right way to do it: replace the content of some div=
=

>>>> or something like that. No discussion there. :-)
>>>>
>>>> Happy coding.
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>
>>>
>> I don't run my own business, and have been coding mainly for the sak=
e =

>> of learning/enjoyment. So, there are probably perspectives I just can=
't =

>> conceive of right now.
>> I was just curious why one couldn't eliminate the extra work of maki=
ng =

>> a more accessible site through the practice of organizing code and =

>> making it as modular as possible. It would seem like you could reduce=
=

>> the overhead of a lot of tasks this way. I have become fluent in =

>> JavaScript over the years, and I find it works best when you start th=
e =

>> app design without any JS, and build up from there, each layer =

>> gracefully degrading to the previous, when necessary. This is what I =
=

>> think of when Jerry mentioned using JS to "enhance" apps, not make ap=
ps =

>> dependent upon it. JS, I feel is a great way to reduce server load fo=
r =

>> things like validating data on the client side (of course, always =

>> ensuring that data is validated server side). But all this can be =

>> organized so reusing and building new things is relatively painless.
>> Like I said though, I haven't been in a position like Erwin's, so I =
=

>> couldn't speak of that situation. I would imagine though, as long as =
=

>> your clients are happy, referring others, and/or returning, then you =
=

>> must be doing something right. :)
>> -- Curtis, http://dyersweb.com
>
> Curtis,
>
> Yes, you can do that - but it still requires additional effort, which =
=

> adds time and cost to the project - Just like doing a database-driven =
=

> PHP page takes more time and effort than a static HTML page.
>
> Every time you add a new bell/whistle you're talking about more work, =
=

> and there are only so many billable hours. Now, if you want to give =

> your time away...
>

Wow, I dropped off the radar for quite a while.

Well, on my free time, I still enjoy coding, and have made my own web de=
v =

"standard library," if you will. It's not perfect, but it does help me =

reduce the time in making sure JS degrades gracefully, as well as =

simplifying many things server side.

-- =

Curtis, http://dyersweb.com

[Back to original message]