On presentational Javascript

[Nik Coughlin]

I think this is the best argument for using Mac IE5.5 that I've come
across. Had I a Mac I would get my hands on it pronto

What am I saying! I have an old iMac G3 which I strongly suspect will be
capable of running IE5.5

Also a Mac Classic II, which I suspect may not be

 

[dorayme]

What am I saying! I have an old iMac G3 which I strongly suspect will be
capable of running IE5.5

O yes... IE5 was out for System 9 (and probably 8.5... I forget). MS
made a last gasp of making a version to run on OSX before dropping it.
The G3 was generally used for less than OS X.

(btw. I think last release was 5.2.3)

Also a Mac Classic II, which I suspect may not be

I would have to think about what *was* available back then, I was still
only faxing - not interneting - on my SE30, the Mac Classic era
roughly...

 

[Sherm Pendley]

O yes... IE5 was out for System 9 (and probably 8.5... I forget).

Dunno about MacOS 8.5, but I *do* remember running it on 8.6.

sherm--

 

[dorayme]

Dunno about MacOS 8.5, but I *do* remember running it on 8.6.

That is most likely what I did too. I went from 6 to 8.6 almost in one
leap, curiously missing 7 (in spite of having it with much literature
and floppies).

Come to think about it, there might have been an ability for IE5 (5.1.6
or 5.1.7?) to run on back to very early 8. Anyway...

 

[David Mark]

See, you're bundling them all together.  I felt exactly the same way about

As well they should be.

JavaScript libraries until I started looking further into jQuery.  So, you

You sound exactly like one of those breathless bloggers that promote
the user of this junk to "solve" Javascript.

can actually assume that for the most part I agree with you regarding the
other libraries.  But all the arguments I've been reading against it just
sound like people who don't know anything about it.  I've looked through the
source, not in detail, but enough to feel good about it.

Then you are utterly incompetent to write about Javascript, let alone
write it. Please stop doing both things until you get a handle on it.

Core jQuery is 17KB gzipped - a single medium sized medium quality photo is
bigger than that

GZIP sizes are the favorites of library proponents as they make
something large sound like something small. Hint: not every agent
accepts GZIP.

Have had no problems with core jQuery, admittedly I haven't used a lot of

LOL. You have a big problem with it if it is on a public server.

the plugins.  Of course, it's not bug-free, no piece of non-trivial software
is, including the code that you or I or anyone else writes.  But the project

But it is fairly trivial (and buggy as hell.)

is mature and they have a reputation for fixing bugs quickly.

OMFG. Where have you been?! Not in the Javascript group, that is for
sure.

It uses object detection, and internally the sort of thing it uses it for is
stuff like providing an abstracted event model that works across IE and
browsers that support the standard event model, that sort of thing.

No, it mostly relies on browser sniffing for such things. You can
take it to the bank.

To reduce size.  Given that it's GPL licensed, why would they want to
obfuscate it?

They do it so it sounds like it is less code than it is. Make no
mistake, it is a full 80K-90K of (very bad) Javascript and guaranteed
to blow up virtually any user agent, save for IE, FF, Opera or Safari
(in their default configurations of course.) I heard somebody mention
that some of it worked in Chrome, which *proves* browser sniffing is
viable (don't ask me), but of course Chrome spoofs Safari (and as it
diverges from its Safari roots...)

The jQuery minimized release isn't tokenized, just comments and whitespace
removed - taking the core from 98KB down to 54KB.  Gzipping on the server
reduces this down to 17KB.

There we go with the GZIP sales pitch again. Any way you slice that
script it sucks. End of story. I don't care if it is -1K.

You can develop against the non-minimized version with proper whitespace and
comments and then deploy the minimized version on release.

That might be the most idiotic programming advice I have ever heard.
Sure, develop and debug against one script and then release a
different one. And this is the sort of things you will hear in that
jQuery support group (the blind leading the blind.)

I always have in the past.  The thing is, using jQuery, I can generally do
the same thing in a fraction of the time.  My time is too important to hand

It is easy to save time by taking shortcuts.

craft every little thing, and I don't find any of your objections compelling
enough to think that it's worth spending a day or more writing something I
could do in a couple of hours with jQuery just to avoid having to include a
"mammoth" 17KB of gzipped JavaScript.

You don't seem to comprehend that it is also about quality. That 17K
(!) of script is excluding people from your site(s). And what are you
going to do when it breaks? Quick! Get me John Resig! LOL.

Have you looked at it at all?  You realise that the core is just a framework

You had better believe it.

that let's you, as you say, roll your own, just in a more efficient manner?

What is this "roll your own" stuff? Hint: you didn't need to query
the DOM by CSS selector in the first place. I never do.

What you're advocating is like using Java but ignoring its class
libraries... that's all jQuery is, a framework.  There are lots of

Would you use class libraries that were written by Java neophytes and
full of mistakes?

additional plugins for it, sure, but they're mostly third party.  You don't
have to use them, and indeed, I generally don't.

Those things are beyond jQuery in terms of incompetence. They are
written by the jQuery "crack babies."

The most useful thing for me is that it lets you select and manipulate the
DOM using CSS3 selectors*, which is extremely powerful.  For example, zebra
striping all tables on the page:

Dear Christ, you don't need CSS3 selector queries to "zebra stripe" a
table. As a matter of fact, you don't need script to do that at all.

$("table tr:nth-child(even)").addClass("striped");

Now we see the incompetence inherent in the system.

How many lines of JavaScript would that normally take**?

How about 0? And how many unneeded function calls does the above
normally take, with re-flows in between as you are fiddling with the
classes. That miserable $ function is outrageously inefficient on its
own (and looks like a variable to noobs) and the whole library hinges
on it.

If you're writing a lot of JavaScript then suddenly you find that it doesn't
take many cases like this to make bigger savings than the 17KB you're giving
up.

Even if that were true (which it isn't), it wouldn't have any
bearing. And enough with the 17K already. It's *not* 17K.

[snip]

 

[David Mark]

You can safely infer that if it works in FF it works in all of the Gecko

Christ on a crutch. Are you still here?

browsers seeing as how they all use the same JavaScript engine.  Same can be

Please stop giving out advice on Javascript. Steer questions like
this to comp.lang.javascript.

inferred about Webkit browsers from the fact that Safari is supported... I
Again.

see by running the test suite that this is the case for Chrome too, despite

Guess what? That is just by coincidence. Chrome spoofs Safari, so
jQuery thinks it is Safari.

it using a different JavaScript engine to the other Webkit browsers and not

But jQuery thinks it is Safari. See the problem.

being in the supported list.  Chrome fails 1 test of 1270 in the jQuery test
suite, and this is a known bug in Chrome where it doesn't escape >
characters when inserting text nodes.

So what? A test suite for a browser sniffing script is pretty
useless. What are you going to do when it fails? Add another sniff?
That's what they do.

Given that the market share for IE versions less than 6 is somewhere under
1% (even allowing for how unreliable browser share figures are), and that
So?

the market share for other browsers not using one of the rendering engines
mentioned above is well under 1% (same caveat), I think it's safe to say

It is most assuredly not safe to say.

"almost all browsers".  ~98% is not what I call a "small subset".

Sure, why not throw 2% of the client's leads out the window at the
design stage because you can't be bothered to learn browser
scripting. Why not?

Hardly by mistake, given my point above.

It is known as working by coincidence. And you have no point.

Indeed. And this, pasted directly from the JQuery code, should make you
very very scared:

Why?  What's wrong with it?  It's as close as you can get without object
detection, and see my note below about the code base.

<quote>
// Figure out what browser is being used
jQuery.browser = {
version: (userAgent.match( /.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/ ) || [])[1],
safari: /webkit/.test( userAgent ),
opera: /opera/.test( userAgent ),
msie: /msie/.test( userAgent ) && !/opera/.test( userAgent ),
mozilla: /mozilla/.test( userAgent ) && !/(compatible|webkit)/.test(
userAgent )
};
</quote>

Do I see your beloved MAC IE5.5 in there?

Bugger Mac IE5.5

For once we agree.

If you audit the code further you'll see that the browser detection stuff is
only used where it's really needed - everything that can be done with object

You need to "audit" the code further. And browser sniffing is *never*
needed. If you have questions about this, post them in
comp.lang.javascript.

detection *is* done with object detection.

Not by a long shot.

 

[dorayme]

If you have questions about this, post them in
comp.lang.javascript.

What a gentle, polite ambassador for that group you are! Who can resist
rushing there now after seeing your needless spiteful rave?

 

[Bergamot]

Guess what? That is just by coincidence. Chrome spoofs Safari, so
jQuery thinks it is Safari.

What about Konqueror?

 

[David Mark]

There should be no problem with what Nik's suggesting unless the

Yes there is. A big one.

minimizer is too aggressive and breaks things, in which case you need to

And you would know this about jQuery's chosen "minifier" how?

fix the minimizer. It's no different in principle to compiling a C
program. Worth testing against the minimized one before releasing just

That is exactly what the other poster was trying to avoid!

[snip]

 

[David Mark]

What a gentle, polite ambassador for that group you are! Who can resist
rushing there now after seeing your needless spiteful rave?

It is a newsgroup. I am pointing you to it as the best place to ask
questions about a particular subject.

 

[David Mark]

What about Konqueror?

AFAIK, it spoofs Safari as well, so it is also "detected" incorrectly
(with all of the same ramifications.)

[snip]

 

[Bergamot]

AFAIK, it spoofs Safari as well

I've never known Konqueror to identify itself as "Webkit".
It's "KHTML" by default, e.g.
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)

 

[David Mark]

I've never known Konqueror to identify itself as "Webkit".
It's "KHTML" by default, e.g.
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)

Not sure. Doesn't really matter though. The string is worthless as
nothing useful can be inferred from it. Some scripts will likely
treat it as a Gecko variety. (!) Just goes to show how futile browser
sniffing is.

 

[David Mark]

[...]
You can develop against the non-minimized version with proper whitespace and
comments and then deploy the minimized version on release.
That might be the most idiotic programming advice I have ever heard.
Sure, develop and debug against one script and then release a
different one.  And this is the sort of things you will hear in that
jQuery support group (the blind leading the blind.)
There should be no problem with what Nik's suggesting unless the

Yes there is.  A big one.

And you would know this about jQuery's chosen "minifier" how?

He doesn't have to use jQuery's minifier. Any minifier will do.

True enough, but that wasn't the suggestion I objected to.

No, he was talking about "developing against" the unminified version.
That's so you can step into it and read it so you know what it's doing.

Thus avoiding "developing against" the "minified" version and
substituting the smaller one at the last second. That is crazy.

But you should always test against the version you actually release,
just to be sure.

Of course.

If you don't trust minifiers, which are trivial and easy to get right,
what software do you trust?

The YUI compressor is great. Just make sure your code passes JSLint
first.