jquery question on slideUp fadeIn and show

[Matt Kruse]

The fact that developers are blindly telling their bosses that Safari
2, Konqueror, X, Y or Z are not used anymore, and that they'll be just
fine using the lib-of-the-moment does not automatically validates that
as the best alternative.

Agreed, but it also doesn't invalidate the option.

Personally, if I had a solution available to me that would not work in
Safari2 or Konqueror, it wouldn't matter to me at all. Others may have
different requirements, which is fine.

I'm sure that a great share of those using jQuery could improve their
reach - and therefore, their profit - with a small investment.

For some, certainly. For others, probably not.

It just depends on the situation. Which is why I would never blindly
recommend using jQuery (or Dojo, or Prototype, or YUI, or anything)
nor would I ever blindly recommend against it. It always depends.

Matt Kruse

 

[Garrett Smith]

Yahoo's doing fine as an overall entity,

Yahoo is failing miserably.

though yes... losing market

share in search (which is browser-neutral). They made $400mil last year
on revenues of $7B+. I'm fairly certain the decision to ignore certain
browsers wasn't made on a whim.

In a large company, decisions often take longer to make and mistakes
take even longer to rectify.

Google most-famously doesn't bother supporting Opera.

Google's front-end code has significant problems with both internal
(source code) and external quality (the UX).

Try creating a

Google doc spreadsheet with Opera and see what happens, or see the
latest GMail interface. Won't happen. The horror! Yet they manage to do
ok.

So what? Yahoo managed OK before Google.

You seem to be of the opinion that code quality does not matter.

Your opinion on the significance of code quality does not rank that highly.

Given an open and focused mind, one can learn plenty of interesting
things to learn about here.

 

[Matt Kruse]

So, you're suggesting some user downloads a new niche browser and finds
the sites they visit don't work as expected -- they're going to visit
other sites rather than ditch this new browser? Good luck with that.

Perhaps. Different things drive the market.

More people are browsing the web using mobile devices now, and they
will probably continue to do so even if the experience sucks. But they
just might change from one site to another if one doesn't work nicely
with their phone and another does. Eventually, this market may be
enough that it starts demanding the web support it. And at that point,
it will.

This may be the kind of environment shift that challenges the use of
scripts like jQuery, et al. And it may just grow to be enough to
either force a drop in jQuery use or force jQuery to change to
something more compatible. If this happens, I'm confident that there
will be other options that step up and become available. When and if
that becomes a concern for developers, they'll adapt.

That's the way it's always worked so far. How many people used
horrible MM_* functions for a long time? It fit their needs for a
time, then better options became practical, and people moved on. The
same will surely happen to jQuery, Dojo, Prototype, YUI, etc. It's
just a matter of when and what drives it.

Matt Kruse

 

[S.T.]

Perhaps. Different things drive the market.

More people are browsing the web using mobile devices now, and they
will probably continue to do so even if the experience sucks. But they
just might change from one site to another if one doesn't work nicely
with their phone and another does. Eventually, this market may be
enough that it starts demanding the web support it. And at that point,
it will.

Mobile *could* alter the landscape. To date the impact of mobile I've
seen has been trivial, albeit a small sample size (my sites). Aside from
minimal traffic, the referrers make it pretty clear most mobile users
are surfing for reference and research -- not so much transactions. I'm
all for letting reference-seekers access our site, but no way I'll be
retooling a site for this traffic at the possible expense of my
transaction-likely traffic (whether that means 'dumbing-down' a page, or
slowing down overall development).

When mobile browsing does become more commercially relevant I suspect
we'll see more mobile versions of websites rather than single websites
trying to accommodate both. That'll be my approach, at least. Nearly all
the content is databased already -- just need to output it in a manner
geared towards mobile devices, and have an economic motive to spend the
resources to do so. I suspect client-side scripting will be used
sparingly on mobile websites for a long time to come as well.

This may be the kind of environment shift that challenges the use of
scripts like jQuery, et al. And it may just grow to be enough to
either force a drop in jQuery use or force jQuery to change to
something more compatible. If this happens, I'm confident that there
will be other options that step up and become available. When and if
that becomes a concern for developers, they'll adapt.

Fair point. I think we're seeing some of that effect already. The JQuery
team announced v1.4 will include a build that caters to iPhone, Android,
Palm Pre and Fennec devices. I'm sure the other libraries have similar
goals (or have already done so). Perhaps some new library, wide of small
in scope, will emerge that serves this market best.

That's the way it's always worked so far. How many people used
horrible MM_* functions for a long time? It fit their needs for a
time, then better options became practical, and people moved on. The
same will surely happen to jQuery, Dojo, Prototype, YUI, etc. It's
just a matter of when and what drives it.

I'd agree all the present libraries will eventually fade. However they
will fade because a new option comes along that provides greater utility
-- they won't disappear because the development community concludes they
must support 99.99% of all users as a basis for their business model.

Maybe better libraries evolve. Maybe browsers add more built-in
functionality that removes library's current advantages. However the
most vocal in this newsgroup keep pushing the mantra it's best to do all
scripting from scratch, and presumably cater towards and test versus an
absurd number of browsers and OS's. That will never happen on a
wide-scale in the present state of Javascript. No fiscal reason to do so.

 

[S.T.]

In what sense could the relationship - maximum browser support ==
maximum potential users/customers - not apply?

The same reason I can't go to a restaurant down the street and get a
copy of the menu in German, Italian, Chinese, Russian or French.

I can get the menu in English -- that's expected. Where I live there is
a significant population with Spanish as their first or only language,
and many restaurants will offer a Spanish version of their menu as a
result. I'd guess perhaps 30%-40% offer both languages.

There is also a healthy population of diverse immigrants and plenty of
international tourists to the area at any given time. Yet no such luck
for menus in any of their native tongues.

Could a restaurant reproduce their menus in a wide range of languages?
Sure they could.

Would any customers use these menus? Sure, now and then.

Would it cost much to have the menus translated? Not really. $15-$20
per translation via a Craigslist post. Hell, they could probably use an
online translation service and have a modestly useful translation done
for nothing more than the cost of time and a few sheets of paper.

Would a wide range of translated menus expand their potential customer
base? Yes, in theory. Couldn't hurt in any case.

Is there enough economic incentive to spend the time and/or resources to
offer these translations? Nope, there is not. Resources are finite and
utilized where they'll provide the greatest benefit. Trying to reach
every potential customer is not such a case.



The rest of your post looks pretty in-depth. I'll try and get through it
at a late point.

 

[David Mark]

[snip]

Maybe better libraries evolve. Maybe browsers add more built-in
functionality that removes library's current advantages. However the
most vocal in this newsgroup keep pushing the mantra it's best to do all
scripting from scratch,

Nobody, but nobody in this group has ever advocated such a thing.

and presumably cater towards and test versus an
absurd number of browsers and OS's. That will never happen on a
wide-scale in the present state of Javascript. No fiscal reason to do so.

I still don't know what you are talking about. Is this some excuse to
use jQuery? With that script, it's not about backward of forward
compatibility, but current bugs in major browsers (and constant
rewrites to combat them). And what does it do when it blows up in
environments unknown (and presumably untested) anyway? Nobody really
knows and there's no way for the calling script to tell. Fair bet it
will leave the document in an unusable state. In that case, you'd
have been better off staying home on the JS front.

 

[Matt Kruse]

Nobody, but nobody in this group has ever advocated such a thing.

Don't be obtuse. This point is repeated often: Write your own code,
build your own library of functions, and reuse them.

Since there has never been a library or set of code that is
recommended here as a starting point for most common tasks (despite
Peter's attempt), it is only reasonable to conclude that no such code
exists, and the preferred approach is to write code from scratch.

I still don't know what you are talking about.  Is this some excuse to
use jQuery?  With that script, it's not about backward of forward
compatibility, but current bugs in major browsers (and constant
rewrites to combat them).  

If the functionality you use doesn't trigger those bugs, then it's a
moot point.

And what does it do when it blows up in
environments unknown (and presumably untested) anyway?  Nobody really
knows and there's no way for the calling script to tell.  

If your environment is known to be supported, or if the number of
unsupported users is below your threshold of concern, then if it blows
up you wouldn't really care, would you? One of those two situations is
a prerequisite for using jQuery, IMO.

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

Don't be obtuse. This point is repeated often: Write your own code,
build your own library of functions, and reuse them.

Since there has never been a library or set of code that is
recommended here as a starting point for most common tasks (despite
Peter's attempt), it is only reasonable to conclude that no such code
exists, and the preferred approach is to write code from scratch.

No, the preferred approach is to make an informed assessment of the quality
of existing snippets of code, copy-pasting them where allowed, rewriting
them where necessary, instead of including a 50K blob without knowing what
one (and it) is really doing.

You have been told this several times, in fact ad nauseam, before.
Repeating this nonsensical argument of yours over and over again does
not make it any more valid or helpful; it just shows your ongoing
short-sightedness, and the dangerous degree of dependency that you have
developed to the tool(s) that you once decided to use (when you were
uninformed enough not to see an alternative), and that you are continuing to
use despite their obvious (and ad nauseam pointed out) shortcomings (jQuery
& friends).

IOW: You are deliberately advocating junk code/coding and hope nobody will
notice that (despite sufficient evidence to the contrary in the past).
Go away.

If the functionality you use doesn't trigger those bugs, then it's a
moot point.

But it *does* trigger the bugs; does attr() ring a bell?


PointedEars

 

[Eric Bednarz]

You seem concerned about how many browsers a site supports.

It may be foolish to think that you can just code according to rules and
have it work, but it is at least as foolish to think that you can safely
code for some specific browsers; all you can do is test that it works in
a very limited amount of installations/configurations of your end.

Commercial sites are concerned about... well.. commercial
interests. They care about user reach, not browser reach.

Ah. I remember *the* big 3-letter transport corporation over here
looking for developers who could make their booking system work in IE
5.0 about one and a half year ago.

Yahoo probably spells it out best:
http://www.yuiblog.com/blog/2009/07/02/gbs-update-20090702/

All this spells out is that the amount of browser scripting
generalization is inversely proportional to its compatibility.

(I remember how excited Resig was about this A-grade stuff coming from a
big player in his first book. Almost like mom saying that it is okay to
watch porn on the internets.

 

[Matt Kruse]

No, the preferred approach is to make an informed assessment of the quality
of existing snippets of code, copy-pasting them where allowed

Which existing snippets of code do you feel are worthy of being copied
and used? If this strategy is to be used, surely you have a set of
public-domain code snippets that a developer should start with, no?

, rewriting
them where necessary, instead of including a 50K blob without knowing what
one (and it) is really doing.

I sometimes use jQuery, rewriting it when necessary. It seems like I
am in fact using your strategy. You just disagree with the specifics.

But it *does* trigger the bugs; does attr() ring a bell?

Of course attr() has some problems.
In some cases.
Avoid those cases.

Matt Kruse

 

[David Mark]

Which existing snippets of code do you feel are worthy of being copied
and used? If this strategy is to be used, surely you have a set of
public-domain code snippets that a developer should start with, no?

No, you are just angling for some public domain treasure trove of JS
that doesn't exist. Why don't you start with your own? If your
answer is that you don't have any...

I sometimes use jQuery, rewriting it when necessary. It seems like I
am in fact using your strategy. You just disagree with the specifics.

No, that's the worst of both worlds.

Of course attr() has some problems.

Odd it is used in almost every example out there. I still don't think
it simplifies setting properties.

In some cases.
Avoid those cases.

Which cases and how is that of course? For jQuery, the cases are
different from one browser (or jQuery) version to the next.

 

[Matt Kruse]

No, you are just angling for some public domain treasure trove of JS
that doesn't exist.  Why don't you start with your own?  If your
answer is that you don't have any...

The argument goes like this:

a) If I don't use a library, don't I have to write everything from
scratch?
b) No, of course not! Start with existing quality code, and modify and
build on it.
a) Which code should I start with?
b) You're just angling for a treasure trove of js!!!!!!

I, myself, personally, am not looking for anything.

But thinking as someone who is trying to follow the strategy that Mr.
Lahn recommends, then I would want to know where to find this code to
copy from that he says exists somewhere. Because that's the basis of
his strategy, after all. Without it, the developer must write
everything from scratch, and of course no one here recommends that,
right?

If no obvious example of code that should be copied exists, then I
call bullshit on the whole argument.

And if the code is too hard to find, or if "you should already know
where it is" then I call bullshit again, because someone looking for
code to start with surely is not going to scour the web looking for
the code that the experts say is copy-worthy. They are going to start
with a library that has a huge following and appears to be the most
commonly-accepted solution. And they will arrive at jQuery!

The point - unless you can show that your strategy of building a
library of code based on finding and modifying quality snippets is
feasible, then what good is it?

Odd it is used in almost every example out there.  I still don't think
it simplifies setting properties.  

Nor do I, obviously. It is an entirely useless method, and it is
unfortunate that it's used internally.

[...]

Matt Kruse

 

[RobG]

The market is fairly rational.

Getting off-topic here, but that statement is completely wrong. If
"markets" were rational, we wouldn't have had the global financial
crisis. They are demonstrably *not* rational[1]. If markets were
rational, you could predict with almost complete certainty how they
will behave, the fact that no-one has yet done that is a pretty clear
indication that they aren't.

And even if they were, it doesn't prove anything about development
tool choices.

If it was more profitable to cater to a
lowest common denominator surfer the practice would be MUCH more
prevalent than is currently the case.

The point is that by simply selecting popular library X *because* it's
popluar, a reasonable number of potential visitors are
disenfranchised. It doesn't necessarily cost anything to support them.

For example, the BuiltWith site that you referenced earlier has a home
page with a single input field and a button. By choosing to implement
it using javascript rather than a simple form, they are imposing a
requirement that visitors have a browser supported by jQuery 1.2.6 and
stuff built with it.

No doubt in the near future someone will days "hey, version 1.3.2 is
out, we'd better upgrade". And since there are some significant
changes between the two, it will take another round of development and
testing, more time and money, and support even fewer browsers than it
did before.

For what? To support something that should have used an extremely
simple form that nearly any browser since Netscape 1.0 could have
used.


1. The Myth Of the Rational Market
<URL: http://www.time.com/time/magazine/article/0,9171,1904153,00.html
Rational Market Theory Takes Another Beating
<URL: http://mooreslore.corante.com/archives/2004/12/02/rational_market_theory_takes_another_beating.php>


Just Google "rational market", nearly all the hits are why it
*isn't* rational.

 

[Gregor Kofler]

S.T. meinte:

The market penetration of JQuery alone is huge:
http://trends.builtwith.com/javascript/JQuery

Huh, impressive what they can analyze today. Apart from that: Those
figures are of course utter bullshit, but there are obviously enough
dimwits out there who buy into such "statistics".

Gregor