jquery vs dojo vs yui etc

[David Mark]

[stuff]

After all these posts, I'm none the wiser: what is the problem these
libraries are trying to solve?

That's the problem. They are trying to solve everything for
everybody. Doesn't make sense for scripts that must be downloaded,
does it?

One big "issue" is cross-browser compatibility, which most "solve" by
peering at browsers endlessly and then adding browser sniffs to their
code. They then declare the scripts to be compatible with library X,
Y and Z (current versions only). When the next slew of major browsers
emerge, they go through it all again. That means more downloads for
the developers, more testing and ultimately more downloads (and forced
browser upgrades) for the hapless end-users.


None of it makes any sense, does it?

 

[David Mark]

You've pointed out some. I've discovered many things on my own (things
you would never encounter, since you don't actually use it).


The "free market" disagrees with you. At least for now.

Popularity does not indicate the quality of the tools. In fact, in
this case, the people choosing the tools have no clue how to judge
their quality. So it's even less meaningful a metric for JS
libraries, isn't it? Popularity is usually an indicator of lots of
shiny graphics and disingenuous marketing.

I know better than to waste my time arguing specifics with you.

That's sensible as you've been routed so thoroughly in the past.

There's no value in trying to convince you of anything.

What a lame argument that is. Worse than usual.

 

[David Mark]

Has left the station?  You know, it's odd; all of the "majors" have
botched basic attribute manipulation.  That's hardly trivia.  After
all, DOM stands for Document Object Model.  And what are documents
made of?  At the "atomic" level?  That's right.  The train crashed
right after it left.

http://www.cinsoft.net/attributes.html


And apparently none of the authors of the "major" libraries understand
it at all.


That makes no sense at all.  The code is transparent and often
obvious.  When I see code like:-

function removeAttr(el, name) {
  el.removeAttribute(el, name);

Oops, it's not quite that bad, is it?

el.removeAttribute(name);

Still botched beyond belief though. One freaking line of code (two if
by jQuery). Basic CRUD for documents broken by design (apparently
never to be fixed). You can't make this stuff up.

 

[VK]

[stuff]

After all these posts, I'm none the wiser: what is the problem these
libraries are trying to solve?

Ever since NN3/IE3 slash, so since it became important to care of more
than one specific platform, the JavaScript libraries are solving these
problem:

1) Provide a reusable subroutines/interfaces for universally frequent
tasks (client-side form pre-validation is the oldest one)
2) To cover with a top level interface different and traditionally
numerous native DOM interfaces discrepancies and bugs of different UA
producers (layer positioning and viewport size calculations among the
oldest one).
3) To add custom methods that was originally considered as non-needed
one by specs producers (getElementsByClassName for a sample).
4) To add a functionality that otherwise requires many ours of
developments and some particular knowledge not universally presented
even among experienced programmers (3D vector graphics and animated 3D
object matrix transformations for SVG/VML for a sample).
5) Rather new one and not so common: adjusting the top level
programming paradigm to emulate some non-JavaScript paradigm with is
more traditional for a given target audience (C/C++ class-like in
Prototype.js for a sample).

 

[Thomas 'PointedEars' Lahn]

Easily offended much?

I'm only pointing out that jQuery takes what is a classic C style syntax
that JavaScript offers and encapsulates it in a cryptic wrapper. When it
comes to cryptic commands you can't dispute that *nix has that going on
at a bash prompt. Seen a complex grep or ls command ? Same applies (as I
mentioned) to regexp commands. I don't like either.

But the lesson that John Resig hasn't learned from Unices is its paradigm
"one tool for one purpose". It is what makes the (POSIX/Unixoid) shell
maybe a little bit crpytic for newcomers (it isn't really once you've
grasped the basics), but very powerful, without adding needless complexity;
much in contrast to jQuery.


Pointed"f y cn rd ths y mst hv bn sng nx "Ears

 

[Jeremy J Starcher]

Pointed"f y cn rd ths y mst hv bn sng nx "Ears

If only it was that easy.

I can handle dropping all vowels, but I fear I'll never be able to spell
'umount' or 'creat' properly again.

 

[Jeremy J Starcher]

Pointed"f y cn rd ths y mst hv bn sng nx "Ears

If only it was that easy.

I can handle dropping all vowels, but I fear I'll never be able to spell
'umount' or 'creat' properly again.

 

[David Mark]

[stuff]

After all these posts, I'm none the wiser: what is the problem these
libraries are trying to solve?

Ever since NN3/IE3 slash, so since it became important to care of more
than one specific platform, the JavaScript libraries are solving these
problem:
Huh?


1) Provide a reusable subroutines/interfaces for universally frequent
tasks (client-side form pre-validation is the oldest one)

Virtually any blob of script is reusable and form validation is not
the primary focus of the "major" libraries.

2) To cover with a top level interface different and traditionally
numerous native DOM interfaces discrepancies and bugs of different UA
producers

And as the browser have converged, we are left with library
discrepancies and bugs of different library producers.

(layer positioning and viewport size calculations among the
oldest one).

LOL. They all botch viewport size.

http://www.cinsoft.net/viewport.asp

3) To add custom methods that was originally considered as non-needed
one by specs producers (getElementsByClassName for a sample).

You sure don't need a library for that function. If you can't write
(and optimize) such a function in five minutes, a library isn't going
to help you.

4) To add a functionality that otherwise requires many ours of
developments and some particular knowledge not universally presented
even among experienced programmers (3D vector graphics and animated 3D
object matrix transformations for SVG/VML for a sample).

Those are specialized "libraries", so off the current topic.

5) Rather new one and not so common: adjusting the top level
programming paradigm to emulate some non-JavaScript paradigm with is
more traditional for a given target audience (C/C++ class-like in
Prototype.js for a sample).

And those are ill-advised of course.

 

[John G Harris]

http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo-part-iii-why-
it-rocks.html

He says :

"How good is qooxdoo at layout? When I popped open the Firebug debugger
in FireFox, where by default it begins by seizing application window
real estate, the qooxdoo layout engine handled the downsizing
impeccably, right down to adjusting scroll bars to accurately reflect
the new dimensions."

My javascript library, (that's mine, not My), does that with exactly 0
bytes of javascript ! Gee willikins, I'm a genius !

That article is about a good library, but the first line has links to
assessments of the three you mentioned.

Not in my browser, not after telling it to ignore the JS errors.


John

 

[Matt Kruse]

After all these posts, I'm none the wiser: what is the problem these
libraries are trying to solve?

The goal of any library/framework/layer/abstraction is to simplify the
solution to one problem, so it can be used as a foundation for solving
a bigger problem.

Browser scripting can be complicated, marred by over a decade of
browser hacks, quirks, bugs, and non-compliant behavior. If a person
is required to understand, solve, and code for all these problems that
have been built up for years, they are unable to focus on bigger
problems.

Imagine if, every time we wanted to make an ajax call in js, we needed
to worry about browser threading, the OS we were on, the network
stack, handling tcp/ip correctly, handling dns, all the way down to
the ethernet layer. It would be an insurmountable problem. Thankfully,
all those layers have been abstracted away for us. We have just a few
concerns to deal with ajax, since we have to solve for a few different
browser conditions and quirks.

Along with all those layers of abstraction comes trade-offs.
Certainly, performance is reduced by each layer. There may be bugs and
quirks in each layer. Our ajax call may fail not because we coded the
js incorrectly, but because a DNS bug caused the lookup to fail. But
there is no way we would ever think of re-writing all these components
to be more technically correct. Even if we knew the faults and knew
how to code them better, it would not be practical. Accepting the
stack of layers under you - the good and the bad - allows you to focus
on higher-level problems.

Now, writing applications for the web has developed to a degree that
authors no longer want to deal with the lower-level problems of
javascript, browsers, the DOM, etc. They may want to just display an
in-page dialog that blocks the rest of the UI, for example. It seems
like a trivial task, but in reality it's a complex problem.

A library simplifies the problem, so instead of having to understand
and solve 100 scripting issues, they now just have to understand a few
API calls. And they can then afford to combine even more complicated
behavior together to create something that would have otherwise been
too complex to create.

Obviously, the library introduces a layer of complexity that comes
with its own problems. It may be less efficient, or may not work in
some browsers, or may have other issues. But these are the trade-offs
for having a large, unmanageable problem reduced to a smaller,
manageable one. Just as there are many trade-offs in the long stack of
abstractions between your js scripting environment and the bits in the
hardware that is driving it all.

Surely, it is up to the developer to decide whether a library is a
good layer of abstraction to introduce. If it solves a great number of
problems and allows them to focus on bigger issues, then that is good.
If it introduces new bugs or incompatibilities or problems, then it's
important for the user to be aware of exactly what they are
sacrificing, and to decide if it's worth it.

Some people are so attached to this specific technology - their ego so
caught up in understanding this layer better than anyone else - that
it's frustrating for them to see anyone "abstract away" their
knowledge. These people fear the day when the js layer is abstracted
away, because then their expertise is no longer needed. They can point
out the faults in specific libraries all day long, but they lack the
vision to see that _every_ layer eventually gets abstracted away. It's
how technology advances.

JS Libraries, as a way to abstract away the problems with browser
scripting, may not be the *best* solution. But it is one solution, and
it works very well for many people. I think it's great to argue for
different ways to abstract away the problem, and pick the option that
is best. But IMO, rejecting the abstraction altogether because of its
shortcomings is short-sighted. Web development will move on without
these detractors. Libraries will be used and improved, because people
don't want to have to deal with the whole nasty, confusing browser
scripting layer. They want it solved, at least to a degree that they
are comfortable with, and presented in a nicer, easier-to-use form.
That's what libraries like jQuery do, and that's why people so
overwhelmingly choose to use them.

Matt Kruse

 

[Jeremy J Starcher]

The js that I'm currently working with most is
http://BetterFacebook.net, which is a greasemonkey script/firefox add-on
(which also works in Chrome, Safari, and Opera, I've heard) that adds a
bunch of functionality to Facebook. It's a whole different kind of
challenge, and it's refreshing to not have to deal with IE at all.

IE7Pro adds a UserScript option to various versions of IE ... and I've
got a "compatibility" option that renders the differences mostly
transparent.

 

[Kenneth Tilton]

Thanks for the links. Somewhat wordy articles with way too much talk
about Lisp.

Oh, right, I forgot about that bit. But the choice being made was
between JS libraries and I think you'll find that info in there.

I thought Lisp went out of fashion in about 1959 (a year
after it came in).

No, it did quite well until the DOD gave up on it ever doing AI, which
was smart. DOD 1980-ish?

It's another one of those languages where I always
wonder what it's useful for.

It's a general purpose language like any other, so you can use it for
anything.

Back in college, I think Lisp was covered
in just one day and the conclusion was that you'd never have to worry
yourself about it, you won't likely see it again.

That was good albeit self-fulfilling advice.

Why do people hang
onto these obscure languages?

They offer things the popular languages do not.

Aren't you supposed to be shopping JS libraries? Have you looked at
ExtJS? But it's an offshoot of YUI, which is scary.

kt

 

[VK]

Virtually any blob of script is reusable and form validation is not
the primary focus of the "major" libraries.


And as the browser have converged, we are left with library
discrepancies and bugs of different library producers.


LOL.  They all botch viewport size.

http://www.cinsoft.net/viewport.asp


You sure don't need a library for that function.  If you can't write
(and optimize) such a function in five minutes, a library isn't going
to help you.


Those are specialized "libraries", so off the current topic.


And those are ill-advised of course.

These are what the libraries are (lesser some particular cases). I am
not clearly sure what point are you trying to make by your comments.
That libraries are not *necessary* for the programming to exist as
such? They are not necessary, it is a convenience tool in any
language.

 

[Joe Nine]

It's a general purpose language like any other, so you can use it for
anything.

Can I download a compiler and use it to create .exe[cutable] files to
run on Windows? Can I use it to build web plugins? Can I embed it into
web pages? Can I use it to write an abstraction layer to display 3D
graphics? I don't think it can do any of these things although I could
be wrong.

That was good albeit self-fulfilling advice.


They offer things the popular languages do not.

Things that people want to do ?

Aren't you supposed to be shopping JS libraries? Have you looked at
ExtJS? But it's an offshoot of YUI, which is scary.

Actually quite the opposite. I don't want any JS libraries. They always
offer bloat no matter how well they're written. They always want to do
more than I need. I prefer to write my own code and when appropriate
re-use things I've written before (or someone else has shared on the
web). When I recently had to do some Ajax stuff, I found it a lot easier
writing my own 10-line function than learning how to use something like
jQuery.

 

[Garrett Smith]

On 6/16/2010 6:29 PM, David Mark wrote:

On 6/16/2010 4:06 PM, David Mark wrote:

On 6/16/2010 2:35 PM, David Mark wrote:

Does anyone have any links to very convincing articles that eloquently
state the major flaws of these libraries? I'm not considering using any
of them, I've heard enough here to know how bad they are. I just want a
few article links to keep in my back pocket that I can fire back when
someone suggests we use one of them.

[...]

I've done all of the hard work. You yourself were just parroting some
of it recently.

That is untrue.

History says otherwise.

I've have never wanted to copy anything of yours.

Then I assume you've done so repeatedly at gunpoint.

Lets be very clear on this: There is nothing of yours that I have
copied. Ever.

Let's be very clear. You have. Perhaps, for whatever reason, you
don't even realize it.

If you believe otherwise, then it's time for you to get very specific
with an example.

Haven't we been over *that* enough times? Start with your recent
obsession with queries and attributes vis-a-vis jQuery.

So let me get this straight: I reviewed code from jQuery. This bothers
you because you believe that I copied you.

Did I get that right?

No, it's one of your usual purposeful oversimplifications. You copied

No?

You wrote that I copied you by having "obsession with queries and
attributes". What exactly did I do?

http://www.google.com/search?q="attributes+vs+properties"+jquery
http://www.developersdex.com/asp/message.asp?p=2978&r=6837513

I certainly am not going to copy any of the things you wrote there.

the one-off feature test from me too. See, I can generalize too!
IIRC, your comment at the time (as you did this here in public) was
that you were changing your whole library to use it as you previously
just had flags. Go ahead, deny it. I'll dig that one up for
sure.

One thing at a time. Back to your first point about jQuery.

Garrett

 

[Garrett Smith]

What's wrong with JsUnit?<http://www.jsunit.net/>

There aren't any JsUnit tests on cinsoft.net, so I assume you are asking
what I think of JsUnit in general.

From memory, last I used JsUnit (over 3 years), my complaints were:
* UI problems. Nested frame layout makes it hard to view source
* Doesn't scale well; large suites, such as those on w3.org, are a
runaway train that can't be stopped (the UI is really bad).
* poor stack trace functionality / reporting
* No dom abstraction layer for dispatching events
* No asynchronous testing features.

Garrett

 

[VK]

Maybe the most logical preliminary step would be to make an
informational (for now) RFC like "JavaScript Web oriented library
design principles"
http://en.wikipedia.org/wiki/Request_for_Comments
So first state on public what is considered good, what is considered
bad and why. Because many of frequent posters in here are having their
own strong opinions on good and bad. Plus the prevailing dream in here
- as I may conclude - of all more-or-less known libraries disappeared
at once with their authors going to the programming hell As
nothing of it will happen in any close perspective, it would be nice
to take some sufficiently respected document for the approach
principals. I would suggest the W3C letter that ended the 2nd Browser
Wars. It is a nice summary of reasons why W3C failed once again, so it
could be good to produce a RFC that would be of anyone interest
besides its clj authors.

HTML Design Principles
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/

The core point IMO would be:

Do not Reinvent the Wheel
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#do-not-reinvent-the-wheel

Evolution Not Revolution
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#evolution-not-revolution

Priority of Constituencies
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#priority-of-constituencies

As a side note: no, $ identifier will never be expelled again for that
mysterious "machine generated code only" usage - and any of existing
library in use will not be rewritten to accommodate that ECMA-262
suggestion. That could be as a flag to see people able to any
reasonable compromises at all.

 

[Gregor Kofler]

Am 2010-06-17 16:21, David Mark meinte:

On Jun 17, 9:21 am, Kenneth Tilton<[email protected]> wrote:

[qooxdoo rocks - as usual]

In short, it's a bad library.

Hmm, do I see your softer side here? ;-)

A library which replaces and rebuilds all kind of (form) elements with
custom lookalikes (but not behavealikes) is crap. Axiomatically - no
matter whether the code is of utmost quality.

Gregor

 

[Thomas 'PointedEars' Lahn]

There aren't any JsUnit tests on cinsoft.net, so I assume you are asking
what I think of JsUnit in general.

Yes, I misunderstood what you were aiming at.

From memory, last I used JsUnit (over 3 years), my complaints were:

The master branch at github was last updated 2010-02-18, the latest release
(2.2) was uploaded 2009-11-28. So it might be time for another review.

* UI problems. Nested frame layout makes it hard to view source

That hasn't changed, but I do not consider it a problem in itself. I have a
source code editor to view and edit the source if it turns out to be
erroneous. What I have a problem with is that the test site of JsUnit 2.2
is apparently not scrollable in Firefox (so I need full screen), but that
could be remedied.

* Doesn't scale well; large suites, such as those on w3.org, are a
runaway train that can't be stopped (the UI is really bad).

There is a Stop button, so that appears to have changed in the meanwhile.

* poor stack trace functionality / reporting

It can only be as good as what the ECMAScript implementation provides. I
think they are doing not bad there. I could even reuse their approach in
providing a stack trace along with my exceptions.

* No dom abstraction layer for dispatching events

That appears to have changed.

* No asynchronous testing features.

How do you propose that to be implemented?

Which alternatives to JsUnit are you recommending?


PointedEars

 

[Joe Nine]

Am 2010-06-17 16:21, David Mark meinte:

On Jun 17, 9:21 am, Kenneth Tilton<[email protected]> wrote:

[qooxdoo rocks - as usual]

In short, it's a bad library.

Hmm, do I see your softer side here? ;-)

A library which replaces and rebuilds all kind of (form) elements with
custom lookalikes (but not behavealikes) is crap. Axiomatically - no
matter whether the code is of utmost quality.

Admit it, you've been waiting for weeks for a thread where you can use
the word axiomatically