Prev: ECMA-262-3 in detail. Chapter 4. Scope chain.
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-03-22)
From: David Mark on 21 Mar 2010 17:22
As I've said before, if you find yourself leaning towards a design that
modifies the location hash because you think that an app can't be
"modern" or "robust" or "fast" without such hack-ery, think again.
There's always a better design (and often it involves leveraging what
the browser does best, which is _browsing_).

I ran across this recently:-

http://stackoverflow.com/questions/1078501/keeping-history-of-hash-anchor-changes-in-javascript

It is a microcosm for everything that has gone wrong with "Web 2.0"
(quotes indicate that term is used to describe so many things it is
meaningless). These ridiculous "history managers" and "back button
fixers" (see Dojo and YUI) are self-imposed doom and gloom. Doesn't
work in IE < 8 (or IE8 compatibility views of course), also fails in
less-than-ancient Opera versions. Standardizing this nonsense with a
hash change event must have felt like validation for a clearly backwards
approach to Web application authoring, but it's just more folly. You
can't force users to upgrade their browsers to accommodate incompetent
designs (and some couldn't do it if they wanted to).
From: Peter Michaux on 21 Mar 2010 17:48
On Mar 21, 3:22 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> As I've said before, if you find yourself leaning towards a design that
> modifies the location hash because you think that an app can't be
> "modern" or "robust" or "fast" without such hack-ery, think again.
> There's always a better design (and often it involves leveraging what
> the browser does best, which is _browsing_).

Browsers are not just used to navigate around a collection of linked
documents anymore. Browsers are used as an application platform. Use
as an application platform is increasing, not decreasing.

Setting location.hash is a fine idea and I appreciate applications
like Gmail and Yahoo! Maps that use the technique. I hope to see more
web applications doing it and steadily improving browser support for
it.

- - -

You are also neglecting issues related to working in a difficult
development environment/team. Some folks might be willing to implement
your alternative design but others won't be. At that point the client-
side programmer may use hash setting as a compromise.

Peter
From: Peter Michaux on 21 Mar 2010 21:53
On Mar 21, 5:05 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> Peter Michaux wrote:
> > On Mar 21, 4:09 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> >> Peter Michaux wrote:
> >>> On Mar 21, 3:22 pm, David Mark <dmark.cins...(a)gmail.com> wrote:

> I don't really see why you would need any extreme horsepower or
> bandwidth to read and write email from a Web document (or documents).
> But then, if Google wrote it... :) Why does everyone want to use
> Google as an example. It's such a self-defeating proposition.

People like using Google's apps as examples because people like using
Google's apps. I like using fully featured GMail more than a static
1997 webmail client.


> > For others they do
> > provide a stripped down client.
>
> Of course they do. They couldn't write a non-behemoth, so they ended up
> writing a whole extra application. And, as is well-documented, they
> have enough trouble maintaining one.

A lot of people do not have any trouble using GMail. I never have a
problem.

Apparently "There are several hundred thousands lines of javascript in
Gmail". I always think "several" means at least 4. That boggles my
mind. GCC is written in C and has a bit over a million lines of code.
To think that the GMail client, written in such a high-level language
like JavaScript, is getting even close to the size of GCC makes me
think something is wrong. Still, I like using GMail so I don't worry
too much.


> >>> Use
> >>> as an application platform is increasing, not decreasing.
> >> Yes, until something more appropriate replaces Web browsing as the
> >> application platform of choice (the Apple iPhone apps are a step in that
> >> direction, which is why Apple doesn't even bother with a MobileMe
> >> website). ;)
>
> > I would take Web apps in Safari over iPhone apps any day both from a
> > user and developer perspective.
>
> I don't follow. Are you comparing desktop Safari to mobile Webkit?
> That's apples and grapes.

I like using web apps with Safari on my iPhone than using iPhone apps
on my iPhone and not just by a little bit. I like the web apps a lot
more.


> > Not really. These days, just set the location hash and poll it.
>
> That doesn't work in IE < 8 (or IE8's various compatibility modes),

I haven't be experiencing any problems with IE < 8.


> Speaking of that bunch, get a load of this all-in-one-page wonder:-
>
> http://www.dojofoundation.org/
>
> This is what I'm talking about. All of those eyes (and hands) and where
> are the brains? :)

I agree that an information-based site like that, which would be
desirable to have indexed well by search engines, should not be done
with hash navigation. That is a really bad idea.

I think what they were going for was to show off dojo through their
own site.


> You said it. New browsers? Many users don't know what a browser is,
> let alone that there are new ones.

In some cases it doesn't matter much if users with new browsers and
users with old browsers have the same experience. The important part
is they all have a good experience.


> You can't force the general public
> to update browsers and that fact should be considered from the start of
> any design slated for the Web.

For the general web. A lot of applications are behind login and
benefit more by using fancy features than being accessible to all.
That is a business call.


> > Hitting the back button might mean going back a genuine
> > page.
>
> Having dealt with a project that did this recently, I can tell you it
> may do all sorts of bizarre things. Going back to a "genuine page" is
> the least of the worries. The fact is, the history gets all out of
> sync,

Under what circumstances? I'm not experiencing any problems in my
tests.

Peter

From: Jorge on 23 Mar 2010 06:05
On Mar 23, 9:55 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> (...)
> Just the simple act of setting the hash and reading it back is extremely
> problematic.  Some of the issues were described (and bizarre workarounds
> proposed) in the cited StackOverflow exchange.  All of those people
> complaining that the end result didn't seem to work in IE6/7 were not
> just whistling Dixie.  I can confirm that there are major issues in
> those browsers with relation to setting the hash with script.  If you
> set the hash and then can't read it back reliably (which I can
> definitely confirm), it pretty much sinks the whole endeavor.  I sure as
> hell wouldn't inject an IFrame (as seen in ill-advised junk like YUI and
> Dojo) or mess with Opera's navigation mode (also in YUI IIRC) to try to
> make such an obvious non-starter start.  ;)

I think that none of the many long-standing bugs in IEs are merely
accidents due to incompetence. Rather the opposite, I firmly believe
that most of them are bricks on the road clever and intentionally left
there -service pack after service pack- by M$ in order to handicap the
web and its potential, which M$ has always seen as a threat for their
OS business.

There's no need to be a genius in order to see that if the web ever
succeeded as an application delivery channel it would have been the
end for the proprietary Windows®™ API lock-in. That's why it's been
into M$ plans for the last so many years to lock and f*ck the browsers
API as much as possible in as obscure -and not too evident- as
possible ways.

You, Cornford, and so many others not only in this group but in the
whole web panorama are good living examples of M$'s intended effect,
whenever you advocate ditching a clever idea due to a certain IE
(in)compatibility.

This is exactly the same reason why there's no <canvas> in IEs: they
don't want the browsers API to provide such an essential
functionality. Think about it: there's no way but the <canvas> to draw
arbitrary pixels on-screen.

So in order to get out of this trap in which we've been for so long, I
think that the way forward for the web should not care the slightest
about working around any of the many of IE's misbehaviours. Instead,
think about killing IE forever. It deserves it.
--
Jorge.
From: Richard Cornford on 23 Mar 2010 08:26
On Mar 23, 10:05 am, Jorge wrote:
<snip>
> So in order to get out of this trap in which we've been for so
> long, I think that the way forward for the web should not care
> the slightest about working around any of the many of IE's
> misbehaviours. Instead, think about killing IE forever. It
> deserves it.

Dreaming of killing IE is futile. That action is not within your
power, or that of any web developers (individually or collectively).
The world will change (probably in unpredictable ways) but a
responsible web developer will learn to cope with the way things are
now rather then how they wish things to be.

For years there were people maintaining that only IE mattered; that it
was the de facto standard, the only really capable browser and that
there was no point in the extra work necessary to accommodate the
statistically insignificant number of user's of alternative browsers.
Those people were wrong when they said that, and proved wrong by the
passage of time. But arguing today that nobody should bother to
support IE is just repeating that mistake with a different subject. It
is arrogant to take such a position, and even more arrogant to think
that it might change anything.

Richard.
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: ECMA-262-3 in detail. Chapter 4. Scope chain.
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-03-22)