Absolute element offsets--exercise in futility

[Matt Kruse]

http://groups.google.com/group/jquery-en/browse_thread/thread/ee5b53d...
How can it take so much work to be so utterly incompetent?  These
people are too busy writing to stop and read anything.

I just think it shows that people using jQuery are not usually hard-
core programmers, and quite often not very familiar with javascript.
People get confused. It's allowed in life.

See, jQuery exists to fill a need that you (and many here) do not
have. That is, to provide an API that more closely matches what the
user is trying to accomplish and to implement it in the best possible
(although often not ideal) way. Setting obj.style.display="block" may
be obvious to you, but $(obj).show() is way more obvious to someone
new to scripting or who doesn't have a lot of time to invest in
getting this part correct. You already understand the problem. jQuery
is not trying to help you. Move on.

This is the point that has been and will continue to be lost on you.
jQuery solves a problem that you don't have. jQuery does not solve the
problems that you do have. Therefore, you shouldn't use jQuery. Easy!

But no matter how much it may annoy you, people want to abstract
browser scripting and not worry about the details. THAT is the problem
that jQuery is trying to solve. For someone making a page for their
child's basketball team without much experience in web development, a
library like jQuery will allow them to add some animations, maybe make
some tabs, perhaps even show pictures in a little "lightbox" that
impresses all the other parents. Good for them! They don't care about
browser compatibility, attributes, offset bodies, or browser sniffing.
All they care about is making something kind of spiffy and fun, and it
works. Were it not for libraries like jQuery, learning about the DOM
and CSS and cross-browser scripting would be out of their reach.
jQuery brings web development to the masses. That's why it's
successful.

"But look at its technical flaws!" you keep yelling to the empty
streets.

So? That is not the criteria on which it is being judged! Maybe by
you, yes. But that's why you despise it. Others don't care as much
about that (if at all) and instead are judging it on factors that you
care nothing about.

But you are still so fixated on your view of the problem that you lack
the ability to see it from another's perspective. You cannot seem to
comprehend how someone would willingly and knowingly accept a solution
that has technical faults, yet you surely do it every day as well -
just in areas that you are not a knowledgeable expert. Surely the
arrogant experts in those areas must laugh at you as well, call you
stupid, and wonder how anyone could be so ridiculous as to make the
choices that you do.

You read a thread where clearly someone is confused and needs
guidance, you re-post it to another group as an example of stupidity,
then call the people utterly incompetent. Rather than taking 1 minute
of your time to help another fellow human being out with even the
slightest bit of wisdom (since you were obviously reading the thread
anyway). See, that pretty much _defines_ an arrogant asshole. And
that's why it's so easy for so many people to just ignore you.

Matt Kruse

 

[David Mark]

I just think it shows that people using jQuery are not usually hard-
core programmers, and quite often not very familiar with javascript.
People get confused. It's allowed in life.

I think that a collection of ostensible jQuery experts put their heads
together to solve a trivial browser scripting problem with their
favorite tool and turned it into a Chinese fire drill. The solution
that was ultimately recommended was a ridiculous end-around for a
script that is obviously just getting in the way. Did you see all of
those attr calls?

So much for the large and active developer community argument. These
discussions are taking place a week *after* I spelled out their
glaring, ten years too late oversight regarding the attr method. This
is one of many examples posted recently indicating that jQuery over-
complicates and even outright prevents the simplest of operations due
to abject incompetence. If that wasn't enough, the misconceptions are
ever-shifting, so it is as I once heard another disastrous API
(Windows) described, like stapling Jello.

See, jQuery exists to fill a need that you (and many here) do not
have. That is, to provide an API that more closely matches what the
user is trying to accomplish and to implement it in the best possible
(although often not ideal) way.

Your mind's gone. We aren't talking about anything close to
idealism. We are talking outright failures, maddening misconceptions
and near-constant upgrades of a script that is now almost completely
superfluous (they lopped off too many supported browsers for their own
good.)

Setting obj.style.display="block" may
be obvious to you, but $(obj).show() is way more obvious to someone
new to scripting or who doesn't have a lot of time to invest in
getting this part correct.

Who conducted that study? Dot notation, assignment and display style
rules are pretty easy concepts to grasp. jQuery or no jQuery, anyone
scripting a Website needs those concepts, just as they need to know
the difference between attributes and properties. The jQuery example
makes obj look like a variable, also uses dot notation and throws in a
method call. There's no telling exactly what that line of code will
do without delving into the show method.

show: function(speed,callback){
if ( speed ) {
return this.animate( genFx("show", 3), speed, callback);
} else {
for ( var i = 0, l = this.length; i < l; i++ ){
var old = jQuery.data(this, "olddisplay");

this.style.display = old || "";

if ( jQuery.css(this, "display") === "none" ) {
var tagName = this.tagName, display;

if ( elemdisplay[ tagName ] ) {
display = elemdisplay[ tagName ];
} else {
var elem = jQuery("<" + tagName + " />").appendTo("body");

display = elem.css("display");
if ( display === "none" )
display = "block";

elem.remove();

elemdisplay[ tagName ] = display;
}

jQuery.data(this, "olddisplay", display);
}
}

// Set the display of the elements in a second loop
// to avoid the constant reflow
for ( var i = 0, l = this.length; i < l; i++ ){
this.style.display = jQuery.data(this, "olddisplay") || "";
}

return this;
}
},

So much for symmetry. I find the comment about reflows very
interesting. Of course, reflows are another awful side-effect of
jQuery-speak.

You already understand the problem. jQuery
is not trying to help you. Move on.

obj.style.display="block";

Read it again. Why is that a problem? Works in virtually anything.
Want to know for sure if it will?

if (typeof obj.style.display == 'string') {
...
}

Sadly, that logic could have made for a useful "show" function. As it
is, it is just one more bizarre strand of code from the latest capsule
of wasted time. As such, it is guaranteed to change over time,
changing the meaning of code foolish enough to call the jQuery show
method, rather than setting a property.

And half the jQuery people are now doing this:

jQuery(obj).show();

Concise? Easy to understand?

We've constructor that starts with a lowercase letter, a hundred
function calls (at least), one of which could have been avoided by
including the new operator and code that over-complicates and obscures
the meaning of a very basic operation.

This is the point that has been and will continue to be lost on you.

You have no point. A script that manages to get in the way of finding
an element by ID in an XHR response, setting properties of DOM nodes,
positioning in IE quirks mode, etc. and manages to fumble around with
such basic operations for *three years*, during which time browsers
changed very little, is not progress. It's not helping *anyone*.
That's why the Web is such a mess.

jQuery solves a problem that you don't have. jQuery does not solve the
problems that you do have. Therefore, you shouldn't use jQuery. Easy!

It solves no problems, the support people have no idea how to make it
solve problems and the developers are obviously asleep. Are you
really still here recommending this to... anyone? Last I recall, your
list of stipulations and exclusions was growing rapidly and you had
admitted that you used a patched version of the thing.

But no matter how much it may annoy you, people want to abstract
browser scripting and not worry about the details. THAT is the problem
that jQuery is trying to solve. For someone making a page for their
child's basketball team without much experience in web development, a
library like jQuery will allow them to add some animations, maybe make
some tabs, perhaps even show pictures in a little "lightbox" that
impresses all the other parents. Good for them! They don't care about

Unless they are blind, spastic, use mobile devices, hate Javascript,
use older browsers, use new browsers, etc., etc.

But I am willing to stipulate that such a trivial vanity page may be
the only justification for such a script. It's like using AOL's
builders to create a home page.

browser compatibility, attributes, offset bodies, or browser sniffing.

But see, those things are going to get fouled up for them anyway. The
point is that scripts that don't work result in pages that don't
function as intended. That miserable "lightbox" you propose is
impossible to do properly with jQuery as there is no mechanism for
progressive enhancement. It's a can of blunders.

All they care about is making something kind of spiffy and fun, and it
works.

That "it works" line really irritates me. Works in what for whom? I
bet some of those parents have jobs and use IE (hint.)

Were it not for libraries like jQuery, learning about the DOM
and CSS and cross-browser scripting would be out of their reach.

No, the browsers stabilized about the time Prototype and jQuery came
out. They are the wave of the past. Each build was another time
capsule, all done with mirrors (browser sniffing.) All a complete
waste of time. The resulting widespread ignorance is not a good thing
either (as evidenced here.)

jQuery brings web development to the masses. That's why it's
successful.

You sound like a TV commercial.

"But look at its technical flaws!" you keep yelling to the empty
streets.

Odd, seems a lot of people (particularly you) are listening. You feel
my influence on the browser scripting world is lacking? And, once
again, we are not talking about flaws here. Remember those Pintos
from the 70's that blew up on rear-impact collisions? That was a
technical flaw. If the car didn't drive at all, that would be
analogous to jQuery's integrity. The progress you think you see is
analogous to a projected image of a street scene viewed through the
window. Are you there yet?

So? That is not the criteria on which it is being judged! Maybe by
you, yes. But that's why you despise it. Others don't care as much

Despise it? I'd "despise" it only half as much if *you* would just
shut up about it. You do realize that in the larger scheme of things,
*you* dropped the ball on jQuery. I gave you the answers and your dog
ate them. Now, in 2009, you are back to argue the same nonsense? I
hate jQuery? I never tried to help jQuery? If you would spend half
the time fixing your favorite script as trying to convince everyone
that I am the problem, you'd have a lot more success.

about that (if at all) and instead are judging it on factors that you
care nothing about.

Misjudging it, based on misinformation.

But you are still so fixated on your view of the problem that you lack
the ability to see it from another's perspective. You cannot seem to
comprehend how someone would willingly and knowingly accept a solution
that has technical faults, yet you surely do it every day as well -

Again, these are not technical faults. These are the script tripping
over itself to make very simple operations into a nightmare.

just in areas that you are not a knowledgeable expert. Surely the
arrogant experts in those areas must laugh at you as well, call you
stupid, and wonder how anyone could be so ridiculous as to make the
choices that you do.

Where are you going with this?

You read a thread where clearly someone is confused and needs
guidance, you re-post it to another group as an example of stupidity,

Yes. I think it is a prime example of the absurdity of jQuery's two
biggest "selling points": support and documentation. It also
demonstrates that not only does jQuery confuse issues with HTML and
XHTML, but with XHR responses as well. That's quite a hat trick. All
of that flailing seems like a lot of work for something that is
supposed to make browser scripting easier. BTW, have you un-patched
and upgraded your version yet or are you still cool with the browser
sniffing? Most of those sniffs are for IE, IE8 is out and it is quite
unlike IE6/7 (which are still botched in the latest jQuery.)

then call the people utterly incompetent. Rather than taking 1 minute

They are and they are your support. The Marx Brothers could have done
a better job on that one. Are these people even vaguely familiar with
the jQuery code? If not, what makes them so confident in it? I have
asked you that before, but didn't get a very good answer. You've got
to ask if these people are vaguely familiar with XHR, HTML, the DOM,
etc. What *do* these people know other than jQuery gibberish? What
is behind the gibberish? See the problem?

of your time to help another fellow human being out with even the

OMFG. This one is in your lap. If you had paid the slightest
attention to what I said back in 2007, jQuery would have been fixed
(as much as it can be fixed) a long time ago. You dropped the ball.

And again, I am not a member of that group. You are, but you didn't
see fit to help out a fellow human being either. Better to come in
here and argue impossible points with me? How is that helping?

As usual, you are as hypocritical as you are annoying. How long are
you going to go on with this act?

slightest bit of wisdom (since you were obviously reading the thread
anyway). See, that pretty much _defines_ an arrogant asshole. And
that's why it's so easy for so many people to just ignore you.

You know, that's the second time you've called me that. I think you
should cut your losses at this point. Don't you have something better
to do anyway?

 

[Matt Kruse]

Dot notation, assignment and display style
rules are pretty easy concepts to grasp. jQuery or no jQuery, anyone
scripting a Website needs those concepts, just as they need to know
the difference between attributes and properties.

Not necessarily.

obj.style.display="block";
Read it again. Why is that a problem? Works in virtually anything.

Well, obviously the code that is there is trying to correct for
different browsers using block, table-row, etc. A single show()
function tries to hide those implementation details from the
developer, so it "just works" in whatever case they use it in.

It solves no problems

Obviously you are mistaken.

But I am willing to stipulate that such a trivial vanity page may be
the only justification for such a script.

Thank you.

It's like using AOL's
builders to create a home page.

Perhaps similar. Or FrontPage, or Dreamweaver, or Visual Basic, et al.
jQuery is entry-level javascript for the masses. And when used
appropriately, it works very well. When developers try to use it for
things beyond its capabilities (as is often the case), it fails. Just
as when you try to do a robust real-time app in VB, you will fail. But
if you want to make a quick app to gather basketball scores for your
league, VB might be quite sufficient. There is a sliding scale between
convenience and robustness.

That miserable "lightbox" you propose is
impossible to do properly with jQuery as there is no mechanism for
progressive enhancement.

Who says that's a requirement?

You sound like a TV commercial.

I'm the ShamWow! guy.

You do realize that in the larger scheme of things,
*you* dropped the ball on jQuery.

Nah, I think I have a good perspective.

I gave you the answers and your dog ate them.

Which one? I have three.

BTW, have you un-patched
and upgraded your version yet or are you still cool with the browser
sniffing?  Most of those sniffs are for IE, IE8 is out and it is quite
unlike IE6/7 (which are still botched in the latest jQuery.)

I use jQuery mostly in IE6-only environments, so IE8 doesn't concern
me. I very rarely use jQuery on any public-facing sites.

OMFG.  This one is in your lap.  If you had paid the slightest
attention to what I said back in 2007, jQuery would have been fixed
(as much as it can be fixed) a long time ago.  You dropped the ball.

You must have me confused with someone else. I am not the author or
jQuery or on its dev team or even a contributor to its bug-tracking
system. I'm just a user who occasionally voices his thoughts.

And again, I am not a member of that group.  You are, but you didn't
see fit to help out a fellow human being either.  

I don't read most of the threads in there. Didn't even notice that
one.

Better to come in
here and argue impossible points with me?  How is that helping?

Good question. I argue impossible points with you for three reasons, I
think.
1) Because I want others who are looking for information about jQuery
to hear a more balanced view between the people who praise jQuery
naively and people like you who say it's total trash. There is a
middle ground, and anyone looking for a reasonable view will hopefully
find the discussions between us and use them to arrive at their own
conclusions.
2) I always like having a knowledgeable, vocal challenger to any
beliefs I may hold. It makes me examine things and I'm usually better
off for it.
3) Because I tend to discuss things ad nauseam, especially when I feel
like someone is missing the point. It's a personality flaw. I'm
working on it. Or not.

Don't you have something better to do anyway?

Yeah, probably. My lego sculpture of John Resig is almost complete...

Matt Kruse

 

[Gregor Kofler]

Am Tue, 14 Apr 2009 08:15:21 -0700 schrieb Matt Kruse:

I use jQuery mostly in IE6-only environments, so IE8 doesn't concern me.
I very rarely use jQuery on any public-facing sites.

Er... I don't get it. You are constantly defending jQuery for being a
tool to the inexperienced web author, yet at the same time you admit,
that one has to be aware of the limitiations of the library (which I
suppose the casual web author lacks entirely) *plus* you hardly use it on
public webpages.

How does this measure up?

Gregor

 

[Timo Reitz]

BTW, have you un-patched and upgraded your version yet or are you

Er... I don't get it. You are constantly defending jQuery for being a
tool to the inexperienced web author, yet at the same time you admit,
that one has to be aware of the limitiations of the library (which I
suppose the casual web author lacks entirely) *plus* you hardly use it on
public webpages.

How does this measure up?

He tries to trick the competitors into using jQuery, so they don't pose a
threat to him.

 

[David Mark]

Am Tue, 14 Apr 2009 08:15:21 -0700 schrieb Matt Kruse:



Er... I don't get it. You are constantly defending jQuery for being a
tool to the inexperienced web author, yet at the same time you admit,
that one has to be aware of the limitiations of the library (which I
suppose the casual web author lacks entirely) *plus* you hardly use it on
public webpages.

Yeah, it was "IT approved" a week ago. Now he's down to girl scout
sites and IE6-only Intranets. Of course, jQuery doesn't work for shit
on IE6.

How does this measure up?

Apparently, it is for people confused by things like this:

el.style.display = 'block';

Of course, in many cases, that reduces to:

el.style.display = '';

So much for jQuery's "help" with table rows. As if anyone who doesn't
understand the above should be working on a Website and using a script
that turns that straightforward logic into hundreds of winding
function calls. Also, notice how none of the libraries has figured
out visibility?

Creates expandos on elements too. Everything in jQuery does. I heard
Resig mention that "no major library" would ever work without
expandos, certainly not if events are involved. You can't make this
stuff up.

Apparently it has been conceded that jQuery has no progressive
enhancement capabilities at all. I thought that was a selling point
for the "Unobtrusive Javascript" movement. (?)

 

[Matt Kruse]

Er... I don't get it. You are constantly defending jQuery for being a
tool to the inexperienced web author, yet at the same time you admit,
that one has to be aware of the limitiations of the library

Most inexperienced developers will not hit upon the limitations in the
beginning. When they do, I hope they will know enough to look beyond
jQuery and start deciding when it should and shouldn't be used. I've
been an advocate of this all along - you have to know when to "unroll"
your jQuery code and write POJS. I hate it when people want to do
everything "the jQuery way". I've always been against attaching lots
of events on $(document).ready(). I've always advised people against
blindly using plugins. The jQuery UI project is way too heavy for my
tastes. Some jQuery proponents seem to think jQuery is the best
solution for every situation, and I don't like that view at all.

jQuery provides convenience. As with _any_ tool that provides
convenience, it has limitations. Once you start hitting the
limitations, you have to start deciding if it's time to move to
another tool or method.

*plus* you hardly use it on public webpages.

Well first, I rarely create public webpages except for my own personal
use.

How does this measure up?

I really don't see where the confusion is. jQuery is a tool. It works
well within its limitations. If you are a beginner or you can accept
its limitations, then it offers convenience which may be useful to
you. That's it.

Matt Kruse

 

[Matt Kruse]

Yeah, it was "IT approved" a week ago.

There are a number of large companies that have "standardized" on
jQuery for their web sites and/or internal apps. In some cases, other
libraries may not be used. So knowing how to use it is helpful.

Of course, jQuery doesn't work for shit on IE6.

Funny, because I've used it quite a bit with IE6 without problems.

Apparently, it is for people confused by things like this:
el.style.display = 'block';
Of course, in many cases, that reduces to:
el.style.display = '';

I'm sure you know this, but if you're showing a table row that is
hidden by CSS rules by default, then setting the display to '' will
not work.
Setting it to 'block' is correct in some browsers, incorrect in
others.
If you're suggesting that all developers should know all this before
attempting to hide/show a table row, yet jQuery conveniently lets them
do it without ever learning these details, then it's easy to see why
people choose the jQuery route.

That's the _whole point_ of adding a layer over top of technology.
Even when you're using POJS, you're depending on countless layers of
technology, each with its own flaws. Surely you don't consider the
potential technical problems in the ethernet implementation or the
router you are connected to before deciding whether you should rely on
it. Users of jQuery have simply decided that the level of complexity
in writing javascript for web applications has exceeded a threshold of
discomfort, and they will accept convenience at the price of some
compatibility or robustness.

Just look at .NET. Talk about a monster. It's way more horrendous than
most things jQuery-related, IMO. Yet countless businesses depend on
it, web sites are built on it, some developers love it, and it
certainly seems like the best choice for some people. Good for them!
Or maybe we should go tell them how stupid they are and point out all
the flaws and browser-incompatibilities in the js it spits out.

Apparently it has been conceded that jQuery has no progressive
enhancement capabilities at all.  I thought that was a selling point
for the "Unobtrusive Javascript" movement. (?)

It certainly has capabilities. It's just insufficient to handle it in
a robust way. Which, I would guess, many developers don't care about
to begin with.

Matt Kruse

 

[Garrett Smith]

Most inexperienced developers will not hit upon the limitations in the
beginning.

On the other hand...

Inexperienced developers will try stuff that a more experienced
developer would know better to try.

For example, a beginner might modify Object.prototype and wonder why
jQuery adds a call to "ready" with his function as a callback and why
jQuery does the same call to jQuery.fn.one.

A more experienced developer (who is working to build a shared codebase)
would not modify Object.prototype.

A beginner might wonder why document.write does not work in "ready"
sometimes (depends on browser). A more experienced developer would
figure out what ready does right away and not use document.write there
(or anywhere).

Garrett

 

[David Mark]

There are a number of large companies that have "standardized" on
jQuery for their web sites and/or internal apps. In some cases, other
libraries may not be used. So knowing how to use it is helpful.


Funny, because I've used it quite a bit with IE6 without problems.

You are funny.

I'm sure you know this, but if you're showing a table row that is
hidden by CSS rules by default, then setting the display to '' will
not work.

"Hidden" by default? There's a recipe for disaster.

Setting it to 'block' is correct in some browsers, incorrect in
others.

Good thing most scripts never need to do this. Certainly it isn't
something a neophyte should need abstracted (and certainly not as
badly as it is abstracted in jQuery.) The first thing you tell them
is that display:none does not normally belong in a CSS file.

I'm reminded of a line in an old movie that goes something like:
"Every time you go to a good crime, there are fifty ways you can ****
it up. If you can name twenty-five of them, you're a genius (and you
ain't no genius.)"

jQuery multiplies the fifty ways by a hundred and then randomly
changes the rules from one version to the next. Think the old "show"
looks anything like the new one?

Who do you suppose will go back and swap out the entire jQuery library
when the next new browser comes out (or you discover that it doesn't
work that well with the latest releases.) Think a neophyte can debug
and test this spaghetti factory on top of whatever gibberish they
wrote? Nobody would bother. They sites just get thrown out like
disposable diapers. That is not how the Web works and certainly not
how business works.

If you're suggesting that all developers should know all this before
attempting to hide/show a table row, yet jQuery conveniently lets them
do it without ever learning these details, then it's easy to see why
people choose the jQuery route.

See above. There's nothing convenient about it. And how many
neophytes does it take to "hide/show" a table row (realize we aren't
even talking about visibility here?) Would you assign such a task to
a team of neophytes, knowing they are 100% reliant on the knowledge
and experience of other jQuery users?

That's the _whole point_ of adding a layer over top of technology.

I know about layers, thank you.

[snip more about layers]

Just look at .NET. Talk about a monster. It's way more horrendous than

I've seen it. It seems to be finally dying out.

most things jQuery-related, IMO. Yet countless businesses depend on
it, web sites are built on it, some developers love it, and it
certainly seems like the best choice for some people. Good for them!

No, to hell with them. You can't help some people. Now they want to
toss jQuery on top of .NET. Good luck with that!

Or maybe we should go tell them how stupid they are and point out all
the flaws and browser-incompatibilities in the js it spits out.

BTDT. As with any large group, some listen, some don't. Make no
mistake, .NET is history.

It certainly has capabilities. It's just insufficient to handle it in
a robust way. Which, I would guess, many developers don't care about
to begin with.

Don't care about progressive enhancement? When did something that
"enables you to build kick-ass Web applications" that "degrade
gracefully" in "all browsers" become a script exclusively for girl
scout sites? Hope none of their parents are on dial-up.

You've got a primitive culture with little or no written history,
passing down old wives' tales and superstitions. They can't (or
won't) read for comprehension, analyze problems or debug code. And
these are the developers! They barely ever ask for a jQuery version
when charged with investigating an issue. Why? They really believe
that jQuery is some sort of magical browser tamer that always works
with "all browsers." We know it changes every revision (seemingly
every other month) and the list of "supported browsers" is constantly
pruned, which indicates that it is a very bad script for a Website (at
least one that wants to last more than a couple of months!)

Coming full circle, I see you opened a ticket on the - each -
function. Good for you! Of course, the only thing that happened
since is that some native added a comment noting that Richard's
analysis was flawed and the cited thread only existed to criticize
jQuery. What was that, a month ago? No word on attr, removeAttr or
offset. I think they've used up their mulligans for the year.

Would you be willing to buy a book on this?

 

[David Mark]

On the other hand...

Inexperienced developers will try stuff that a more experienced
developer would know better to try.

For example, a beginner might modify Object.prototype and wonder why
jQuery adds a call to "ready" with his function as a callback and why
jQuery does the same call to jQuery.fn.one.

A more experienced developer (who is working to build a shared codebase)
would not modify Object.prototype.

A beginner might wonder why document.write does not work in "ready"
sometimes (depends on browser). A more experienced developer would
figure out what ready does right away and not use document.write there
(or anywhere).

God knows they wouldn't use *that* "ready" method at all. If we are
talking about neophytes, the only advice for them is to use the onload
attribute of the body. Unfortunately, that wasn't "unobtrusive"
enough for people like John Resig.

 

[Matt Kruse]

"Hidden" by default?  There's a recipe for disaster.

That's a false over-generalization. If you are trying to be super
accessible and all that, sure, don't hide things by default. But
internal webapps rarely have those types of concerns.

And how many
neophytes does it take to "hide/show" a table row (realize we aren't
even talking about visibility here?)

I think it's fairly common, actually. Click on a row to expand
"details" below it in another row.

I've seen it.  It seems to be finally dying out.

Perspective, I guess. In some areas it's growing.

BTDT.  As with any large group, some listen, some don't.  Make no
mistake, .NET is history.

Everything is history at some point. I hope .NET dies out sooner
rather than later. But that doesn't change the fact that it's built by
a huge company, has lots of devoted developers who swear by it, is the
back-bone of mission-critical webapps and web sites, and must satisfy
a need for a huge number of people, even if you think it is horrible.
Sounds a lot like jQuery (s/huge company/ninja/).

Hope none of their parents are on dial-up.

People still use dial-up?

I see you opened a ticket on the - each - function.

I don't think I did? I did make a comment on an existing ticket, and I
posted suggestions to the dev mailing list, referencing the thread
here.

Would you be willing to buy a book on this?

Sure, if by "book" you mean "pdf file" and by "buy" you mean "download
for free".

Matt Kruse

 

[Lawrence Krubner]

I remember that like it was yesterday.





Why?  Certainly I said nothing about writing everything from scratch.
I think I am starting to see where this is coming from.

David, you don't seem to understand your own argument. When a
programmer writes code, they can do one of two things:

1.) Reuse old code, that is, use a library.

2.) Write new code from scratch.

Any reuse of old code means you're using a library. It doesn't matter
if that library is informal - just some functions you wrote that you
like to reuse because you're comfortable with them - or formal and
public like jQuery or Prototype or mootools.

You've argued against libraries, which means you are in favor of
writing new code, from scratch. Anything that is a "context-specific
solution", written just for one specific solution, involves writing
new code from scratch.

 

[Lawrence Krubner]

Am Sun, 12 Apr 2009 16:36:34 -0700 schrieb Lawrence Krubner:


No, that's /the/ misconception.

According to your logic graphics designers are supposed to congratulate
me upon my decision to use one of those fancy predefined webpage
templates, because it enables me to do "professional layouts" without
having to learn the basics of design. (Who cares if colors of fonts don't
match the chosen template, or the template doesn't match the CD of the
customer.)

The standard I'd use is "How can we meet the customer's needs, at the
lowest possible cost, for a given level of quality?" That doesn't mean
that things should be low quality or low cost, but rather, that they
should be the lowest cost per whatever quality the client needs. Some
clients need very high levels of quality, and some only need very low
levels of quality.

You are critical of those pre-package templates that only cost $29.99
(or sometimes they are free), but I'd argue that, for a certain class
of customer, those ultra-cheap templates are very successful. I've
seen sites where the owners simply want to run a simple store, selling
fishing gear, and the web site is a sideline to their real business.
And these sites only generate $100 or $200 a week in sales, and
therefore do not justify great expense. But the owners of such sites
deserve to be congratulated for pulling together a working business
model. The sites may not look great, but they are sufficient, and the
business is able to attract customers. If you were to argue that the
site should be built to a higher level of quality, you'd have to prove
that the higher quality would bring in additional sales.

Some very ugly sites are extremely successful. Jason Fried has argued
that Drudge Report is one of the most successful sites on the web, and
I agree with his reasoning:

http://www.37signals.com/svn/posts/...-is-one-of-the-best-designed-sites-on-the-web

The use of pre-package effects, such as those provided by jQuery UI,
are exactly like the $29.99 templates. They do an excellent job of
meeting the needs of a certain class of web site owner.

 

[Lawrence Krubner]

Am Sun, 12 Apr 2009 14:06:40 -0700 schrieb Lawrence Krubner:

[snip]

Why don't you just publish your scripts as a library then?

Yawn... The usual implied "if you can't do better, stop critizing". Apart
from that you *can* downloadMark'sscripts. But then: Are you capable of
assessing the code quality?

I'd never argue that Mark should stop criticizing anyone. I'm arguing
that, if his scripts are freely available, and no one uses them, then
perhaps they are not as useful as he thinks they are.

Your use of the word "quality" suggests that there is a single
dimension by which we can measure code. Your implication is that we
can use some official standard of code quality. Perhaps you're imaging
a standard such as "How well does this code conform to well known,
agreed upon principles of software design?"

However, there are many other, equally valid, dimensions by which code
can be measured. For instance:

1.) How useful do people find this code?

2.) How easy to use do people find this code?

If people find code un-useful, or if they find it hard to work with,
then I'd argue it is worth very little, regardless of its conformance
to some well known standards of software design.

 

[Lawrence Krubner]

I guess.  I also guess that programmers, not designers will end up
doing the maintenance on most of these sites (that is, if the site
does anything besides look pretty).  I think a lot of companies who
follow the pack fail to understand what the "big boys" are really
doing.  They are not hiring designers to code the front end.  They
hire designers to design the front end and programmers to code it.  If
production of web sites was truly designer driven then what you say
might be true but all you need to do is look at the sites linked to by
Smashing magazine to see a certain low-level of functionality common
to most (though I personally really like looking at them).

Those of us who fear having to maintain sites coded with jQuery have
more to fear from back end javascript generators like Rails
(prototype) and Microsoft MVC (jQuery).  Those systems spit out
unreadable javascript at an alarming rate.

Work on websites should be lead by the designers for the reasons I
outlined here:

http://www.teamlalala.com/blog/2009/03/01/the-problem-with-php-frameworks/

In general, designers have a better grasp of what customers, and what
the actual users of the websites, want. Computer programmers spend all
day thinking about how machines think, but designers spend all day
thinking about humans think. Web sites developed with a design lead
process tend to be more intuitive and usable than the sites where
programmers have control over the process. Web sites developed in
shops where the programmers dominate tend to deliver the requested
features, but in ways that damage the user experience.

 

[Lawrence Krubner]

My favorite is "Why don't you write all of your sites in
assembler?!!!"  This is usually parroted by people who have no idea
what assembly language is (they just thought it sounded like a geek-
chic thing to say.)




Lots of them, but fewer now than three months back.

Ah, yes. Because of your courageous willingness to stand against the
conventional wisdom, the world is coming around to your way of seeing
things. The millions of people who carefully read comp.lang.javascript
everyday have been dazzled by the brilliance of your arguments. That
respected publishing houses like O'Reilly have published books saying
positive things about jQuery is of no matter. They have learned the
errors of their ways. Surely any day now you'll be receiving a
personal letter of apology from O'Reilly himself, asking forgiveness
for the damage he may have caused by publishing books that expressed
opinions you disagree with. That popular magazines and popular
designers are recommending libraries like jQuery is a point we can,
and should, ignore. All that matters is how daring you've been, and
how you've won over all of society with the strength of your
arguments.

 

[Garrett Smith]

David, you don't seem to understand your own argument. When a
programmer writes code, they can do one of two things:

1.) Reuse old code, that is, use a library.

2.) Write new code from scratch.

It seems that in (1), code reuse implies using a library. I have to
disagree with that. Strongly.

For a search of "code reuse", you might stumble on the first hit:-

http://en.wikipedia.org/wiki/Code_reuse

For a more formal education on effective code reuse, I recommend the
book "Agile Software Development" (that is not in the FAQ).

Garrett

 

[Garrett Smith]

The standard I'd use is "How can we meet the customer's needs, at the
lowest possible cost, for a given level of quality?" That doesn't mean
that things should be low quality or low cost, but rather, that they
should be the lowest cost per whatever quality the client needs.

This statement:-

Some

clients need very high levels of quality, and some only need very low
levels of quality.

is a disturbing representation of what I see in the state of the art in
front end engineering.

I do take pride in my work and do not produce unprofessional quality code.

Garrett

 

[Lawrence Krubner]

I think that a collection of ostensible jQuery experts put their heads
together to solve a trivial browser scripting problem with their
favorite tool and turned it into a Chinese fire drill. The solution
that was ultimately recommended was a ridiculous end-around for a
script that is obviously just getting in the way. Did you see all of
those attr calls?

So much for the large and active developer community argument. These
discussions are taking place a week *after* I spelled out their
glaring, ten years too late oversight regarding the attr method. This
is one of many examples posted recently indicating that jQuery over-
complicates and even outright prevents the simplest of operations due
to abject incompetence. If that wasn't enough, the misconceptions are
ever-shifting, so it is as I once heard another disastrous API
(Windows) described, like stapling Jello.




Your mind's gone. We aren't talking about anything close to
idealism. We are talking outright failures, maddening misconceptions
and near-constant upgrades of a script that is now almost completely
superfluous (they lopped off too many supported browsers for their own
good.)


Who conducted that study?

I have. At the various web design firms that I've worked at, I've had
to work closely with designers. Over the last 10 years, I've gotten to
know what they need and what they don't need. I've also had long
conversations with clients, what they want, what goals they are trying
to acheive.

I've also had countless friends come up to me and say "I'd like to
learn how to build web sites." I've taught several. The experience has
helped me see what concepts they find easy to grasp, and which
concepts they find difficult to grasp.

Given those experiences, I understand why jQuery is gaining in
popularity. It answers a real need.

Unless they are blind, spastic, use mobile devices, hate Javascript,
use older browsers, use new browsers, etc., etc.

But I am willing to stipulate that such a trivial vanity page may be
the only justification for such a script. It's like using AOL's
builders to create a home page.

You are expressing contempt for the software AOL makes available so
that people can build a simple web page. And, really, your entire
argument is based on this straight-forward elitism. Take away the
elitism, and you have no argument at all. Once a person realizes that
AOL's simple web page builder answers a real market need, then the
person also understands how other efforts to make the web simple
answers real market needs.