single page apps, URL hash setting, bookmarking, & the back button.

[David Mark]

How large is a "mammoth script"?

Typically tens of thousands of lines.

You never encounter any problems? *Never*?

Obviously that's not the case. My track record is pretty uncanny in
this area though.

No. It is true.

But the implication is defeatist.

If I test a script in a browser and see that it works there then I am
sure that script works in that browser. That is pretty clear.

Nope. You'd have to test a lot of configurations (too many for one
lifetime.)

If I don't test script in a particular browser then I don't know that
it works there. The *only* way to know for sure is to test it.

But that's not what you said.

You have avoided stating what is wrong with the *design* of the Yahoo!
Maps page with regard to setting the URL hash.

On the contrary, I've told you at least a dozen times. The whole
thing should be discarded as it is known to break recent browsers (and
there is no test.) Never mind that you don't need it for anything
anyway. Don't drink the hemlock.

Are you implying the feature testing is completely possible? When did
you become such a defeatist? ;-)

You have lost coherence at this point.

Also all scripts are not destined for the general web.

Still gone.

Some scripts
are used only on intranets and so feature testing is not necessarily
required or even desired.
Nope.


Why do you find it offensive that the URL hash is changing as you
manipulate the state of a single page web-app? (I'm not asking about
modifying the history stack.)

Because I know it reloads the page (or worse) in some (even recent)
browsers and is completely unnecessary. What more reason do you need
to avoid it?

 

[Peter Michaux]

Because I know it reloads the page (or worse) in some (even recent)
browsers and is completely unnecessary.  What more reason do you need
to avoid it?

Now we are getting to something meaty! Which browsers do you know that
reload the page (or worse) when setting the location.hash property?

Peter

 

[Roger]

I wasn't.

Odd as you replied directly to Thomas' statement about that dialog.

[snip]

 

[David Mark]

Odd as you replied directly to Thomas' statement about that dialog.

Yes, I noticed that too. The rebuttal seems automated and born of
frustration.

 

[David Mark]

Now we are getting to something meaty! Which browsers do you know that
reload the page (or worse) when setting the location.hash property?

I'd classify it as nutty. Did you not read the thread (or the umpteen
similar that preceded it?)

For example:

http://groups.google.com/group/comp.lang.javascript/msg/1a118ade7b4800f2

Getting tiresome.

 

[Peter Michaux]

I wasn't.

Odd as you replied directly to Thomas' statement about that dialog.

[snip]

I was replying about the concept of URL hash-setting. Not the
particular example PointedEars posted.

Peter

 

[Roger]

Odd as you replied directly to Thomas' statement about that dialog.

[snip]

I was replying about the concept of URL hash-setting. Not the
particular example PointedEars posted.

Well, you did not make it clear. Getting a little tired of this
thread, especially since Google Groups is now complaining about my
"posting limit."

 

[Peter Michaux]

I'd classify it as nutty.  Did you not read the thread (or the umpteen
similar that preceded it?)

For example:

http://groups.google.com/group/comp.lang.javascript/msg/1a118ade7b4800f2

Of course I knew about those older versions of Safari and Opera. I was
the one who brought them up in the first place. Kangax was very
helpful in reporting the version numbers.

Safari 2 and Opera 8.5 are not exactly recent or popular browsers on
the web. For the case of Safari 2, from what I was told by the Webkit
developers, Safari 2 has been auto-updated to Safari 3 on Mac OS 10.4.
Someone would need a very old operating system or refuse updates to
still have Safari 2 running. Anyone on OS 10.3 would have only Safari
1.x and so is probably using Firefox by now.

Don't interpret that as meaning I think those browsers don't matter at
all. I didn't write that. For some sites they might matter. For some
sites, an extremely conservative approach must be taken and even
script should be avoided all together.

On the other hand, for the target group of other sites, Safari 2 and
Opera 8.5 are ancient browsers and restricting certain script
possibilities would be more detrimental than beneficial.

It depends on the site.

Peter

 

[Roger]

Of course I knew about those older versions of Safari and Opera. I was
the one who brought them up in the first place. Kangax was very
helpful in reporting the version numbers.

Then why did you ask? This is the silliest thread I've ever been in.

Safari 2 and Opera 8.5 are not exactly recent or popular browsers on
the web.

Well, Opera 8.5 is not exactly ancient. And it doesn't matter
anyway. There are plenty of these browsers out there. And you don't
need to do what breaks them anyway.

For the case of Safari 2, from what I was told by the Webkit
developers, Safari 2 has been auto-updated to Safari 3 on Mac OS 10.4.
So?

Someone would need a very old operating system or refuse updates to
still have Safari 2 running.

You do realize that a lot of Mac (as well as PC) users don't know what
an OS is? It's particularly true of Mac users as Macs don't foul up
as often, so the OS remains in the background (where it belongs.)
Picture the Little Old Lady from Pasadena. She wants to buy from your
site, but your idiot Web designers just sent her browser into an
infinite load or crashed it or whatever. You want to keep this stuff
as simple and predictable as possible. That's how you make scripts
fly (or gracefully bail out) in virtually any environment.

Anyone on OS 10.3 would have only Safari
1.x and so is probably using Firefox by now.

What does that mean? I'm sorry, but I'm not buying into your psychic
abilities with regard to users of old Macs. That Little Old Lady has
never heard of Firefox.

Don't interpret that as meaning I think those browsers don't matter at
all. I didn't write that. For some sites they might matter. For some
sites, an extremely conservative approach must be taken and even
script should be avoided all together.

If you know what you are doing, you can have it both ways.

On the other hand, for the target group of other sites, Safari 2 and
Opera 8.5 are ancient browsers and restricting certain script
possibilities would be more detrimental than beneficial.

You have to weigh the benefits. In this case, you've got nothing to
weigh against potential disaster and user frustration/confusion. For
the last time, leave the window location alone.

It depends on the site.

That's an appropriately ambiguous note to close on (crossing my
fingers.)

 

[Peter Michaux]

Then why did you ask? This is the silliest thread I've ever been in.

To find out if David knew of any new versions that have problems.

Well, Opera 8.5 is not exactly ancient. And it doesn't matter
anyway. There are plenty of these browsers out there. And you don't
need to do what breaks them anyway.


So?

Since OS 10.3 users are stuck on Safari 1.x and OS 10.4 users have
been auto updated to Safari 3, that means only those with auto update
disabled would have Safari 2.

Safari 1.x was not a very good browser so there is a good chance those
users have moved on to other browsers.

The market share of Safari 1.x and 2.x is miniscule.

You do realize that a lot of Mac (as well as PC) users don't know what
an OS is? It's particularly true of Mac users as Macs don't foul up
as often, so the OS remains in the background (where it belongs.)
Picture the Little Old Lady from Pasadena. She wants to buy from your
site, but your idiot Web designers just sent her browser into an
infinite load or crashed it or whatever. You want to keep this stuff
as simple and predictable as possible. That's how you make scripts
fly (or gracefully bail out) in virtually any environment.


What does that mean? I'm sorry, but I'm not buying into your psychic
abilities with regard to users of old Macs. That Little Old Lady has
never heard of Firefox.

Well there is no way to bring up browser statistics in c.l.js.

If you know what you are doing, you can have it both ways.

Sometimes. Sometimes you cannot have it both ways due technical
problems (e.g. lack of feature tests) or to limited development
dollars. The server-side developers cannot always develop both a
traditional HTML template-based site, and a JSON data API. It is often
one or the other and the successful boss will pick the JSON data API
if that means more customers will be happy with the final product.

You have to weigh the benefits. In this case, you've got nothing to
weigh against potential disaster and user frustration/confusion.

Yes there is something positive: enhancing the user experience by
keeping the state of the page up-to-date in the URL so it can be
bookmarked or emailed at any time. That is a compelling advantage.

Peter

 

[Peter Michaux]

As you well know, I do that all the time. It's called progressive
enhancement. That's what feature testing is for (and it's not
warranted here, even if a practical test could be found.)

The intention of feature detection and progressive enhancement is to
add JavaScript to the page without breaking the page. I wrote that
adding JavaScript that *breaks* the page in older browsers is fine if
the net number of users actually increases. Totally different.

It demonstrates that the design is strictly multi-browser, which is
yesterday's news now (thank God.)

Regardless of hash-setting, using YUI on a particular page would make
the *implementation* of the page multi-browser. It doesn't make the
design multi-browser as a different implementation of a design could
work in more browsers.

That doesn't jibe with your theory about scripts working only where
they've been tested. How do you sleep at night?

It jibes well. I test my scripts in some browsers/configurations. I
know my scripts work in those browser/configurations. I don't know
that my scripts work elsewhere.

It's an easily demonstrable fact.

As you wrote, you sometimes encounter problems with your scripts and
so they don't always work. If you tested your scripts in those other
browsers, saw that your scripts don't work there, then you could fix
your scripts and *know* they work. You won't know without the test.
You can only guess which is a reasonable thing to do as endless
testing is not realistic. It is still guessing, however.

Peter

 

[Roger]

[snip retreads of previous posts]

As you wrote, you sometimes encounter problems with your scripts and

Now, who doesn't? Virtually every time, I'm the one that finds them
(before they hit the testers.) In other words, I don't get a lot of
returns (and I write more scripts of more than a modest size.)

so they don't always work. If you tested your scripts in those other
browsers, saw that your scripts don't work there, then you could fix
your scripts and *know* they work.

Problems are rarely a result of "other browsers." I find that if my
scripts work in FF and IE, the rest usually fall right into place.
And I'm not talking about slide shows.

You won't know without the test.

I can be pretty damned sure and that usually turns out to be good
enough.

You can only guess which is a reasonable thing to do as endless
testing is not realistic. It is still guessing, however.

I have no idea what you mean. Endless testing has no practical
application. Constant testing (e.g. after every little change in
every browser) is a waste. I test when I'm ready and in a way I feel
is appropriate (varies by project.) It's not an exact science, but
it's hardly guessing either (my nearly non-existent bounce rate speaks
to that.)

 

[Peter Michaux]

Now, who doesn't?

My point exactly. David has implied his scripts "just work" even if he
doesn't test them in a particular browser/configuration. Given the
number of bugs/browsers/configurations that have ever been in
existence, the chances are slim.

Virtually every time, I'm the one that finds them
(before they hit the testers.) In other words, I don't get a lot of
returns (and I write more scripts of more than a modest size.)

That is great. Really a page doesn't have to work in every browser/
configuration on planet earth. No lost sales or complaints is the real
objective.

Problems are rarely a result of "other browsers." I find that if my
scripts work in FF and IE, the rest usually fall right into place.

How exotic is your "the rest"? For example, are you testing early
versions of Safari, iCab, Ice Browser, etc? They have unique bugs that
testing in other browser will not reveal.

I can be pretty damned sure and that usually turns out to be good
enough.

I agree. David seems to think he knows that his scripts work in
untested browsers.

I have no idea what you mean. Endless testing has no practical
application. Constant testing (e.g. after every little change in
every browser) is a waste. I test when I'm ready and in a way I feel
is appropriate (varies by project.) It's not an exact science, but
it's hardly guessing either (my nearly non-existent bounce rate speaks
to that.)

It is guessing to say a page works in browser/configuration X if you
haven't tested it there.

Peter

 

[Roger]

My point exactly. David has implied his scripts "just work" even if he

For Christ's sake. As mentioned, I am David. This miserable thread
has exceeded my "posting limit" on Google (idiots.)

doesn't test them in a particular browser/configuration. Given the
number of bugs/browsers/configurations that have ever been in
existence, the chances are slim.

But you are generalizing about nothing. I have specific evidence.
And that attitude is the typical paranoia of the inexperienced (for
them the chances are nil, even for a "hello world" app!) Where did
you pick that up?

That is great. Really a page doesn't have to work in every browser/
configuration on planet earth. No lost sales or complaints is the real
objective.

I don't follow. The idea is that my scripts are tested in lots of
browsers and configurations I've never tried. They don't come back
from the testers.

How exotic is your "the rest"? For example, are you testing early
versions of Safari, iCab, Ice Browser, etc? They have unique bugs that
testing in other browser will not reveal.

You'd have to ask the testers on any given project. Some are more
thorough than others. And, of course, there's loads of published
script out there to test (and lots of people have done so.)

I agree. David seems to think he knows that his scripts work in
untested browsers.

I am David (see above.) And because of experience, I can predict such
things with great accuracy for past, as well as future browsers (as
has been shown repeatedly.)

It is guessing to say a page works in browser/configuration X if you
haven't tested it there.

Depends on who said it and how experienced they were at the time. You
could call it educated guessing, but even that's a stretch. Sometimes
you just know as you have experienced it before.

 

[Peter Michaux]

For Christ's sake.  As mentioned, I am David.

Oh. Hi David.

This miserable thread
has exceeded my "posting limit" on Google (idiots.)

With all your hatred of Google sites, why are you using theirs to post
to the news group? Why not use Mozilla's newsgroup reader or something
else?

Peter

 

[Roger]

Oh. Hi David.
Hi.


With all your hatred of Google sites, why are you using theirs to post

You know that isn't true. Don't use such words to describe my
opinions about incompetently designed Websites. It just makes you
look silly.

to the news group? Why not use Mozilla's newsgroup reader or something
else?

Gee, because I don't feel like setting up an NNTP account since my
miserable ISP discontinued that service. Really none of your concern
though.

 

[Peter Michaux]

You know that isn't true.

No I didn't. Your posts about the quality of Google's programming made
me think you wouldn't go anywhere near their products.

Gee, because I don't feel like setting up an NNTP account since my
miserable ISP discontinued that service.  Really none of your concern
though.

So taken as a whole you actually like Google's service better than the
alternatives? That is contrary to the impression I get from your
frequent Google-bashing posts.

Peter

 

[Roger]

No I didn't. Your posts about the quality of Google's programming made
me think you wouldn't go anywhere near their products.

Do my comments about the quality of code imply hatred to you? You
take newsgroups a bit too seriously I think.

So taken as a whole you actually like Google's service better than the
alternatives?

As mentioned, none of your concern. I'm not granting interviews at
this time.

That is contrary to the impression I get from your
frequent Google-bashing posts.

I don't write such posts. I virtually never mention them unless asked
(or when they serve as a highly visible example of a specific blunder.)

 

[David Mark]

It is common advice from successful companies of developers to write
applications that you would like to use yourself.

I missed this one. What are "successful companies of developers?"
Can I assume you mean Web developers? Anyone who takes browser
scripting advice from Web developers deserves whatever they get. Use
jQuery, dude. It rocks!

[snip]

 

[Peter Michaux]

I missed this one.  What are "successful companies of developers?"

Companies where the founders are developers.

 Anyone who takes browser
scripting advice from Web developers deserves whatever they get.

You are a web developer and you give out advice frequently. Why should
anyone listen to you?

Peter