Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
From: Matěj Cepl on 22 Jun 2010 05:05
Dne 22.6.2010 10:49, Johannes Baagoe napsal(a):
> Weird. On mine, both Opera 10.01 and Firefox 3.6.3 take a few seconds
> not to complete, but simply to display the first snapshot - that is
> 1 % of completion. Chromium 5.0.375.70 completes in about 20 seconds.

RHEL 6beta, chromium-6.0.417.0-1.20100526svn48276.el6.x86_64
and firefox-3.6.4-7.el6.x86_64 ... firefox is slower (like 2 or 3 times
slower, not worse) but finishes in all dignity.

Matěj

--
A woman without a man is like a fish without a bicycle.
Therefore, a man without a woman is like a bicycle without
a fish.
From: Garrett Smith on 23 Jun 2010 20:23
On 2010-06-21 01:43 PM, Matt Kruse wrote:
> On Jun 18, 10:24 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote:
>> It seems like you believe that there are technical problems that ccan be
>> fixed and do not agree that the problems with jQuery come from the
>> initial API design. That's what my other post was getting at.
>
> There are multiple problems of different types, including:
>
> 1. Algorthm: Some problems are simply solved in the wrong manner,
> giving incorrect or inconsistent results
>

Well yeah, starting with queries are broken. That's like the core of it.
Fixing the query engine requires defining what it should do in the first
place, which brings up the subject of attributes.

> 2. API: Overloaded functions should be split into multiple functions,
> or in many cases just trashed. Complicated API should be simplified.
>
> 3. Design: Some of the goals of the core lib are too lofty and cannot
> be adequately accomplished, and should be trashed.
>

I've read where you previously wrote that the issues could be fixed and
improved while still maintaining the same API. That's what they've gone
after, it seems.

> 4. Syntax: The source is unnecessarily obfuscated and could be much
> more readable.
>

I agree with all of that.

>>>> Documentation for the selectors are a good starting point.
>>> Sure, that would be fine. If I were to re-write jQuery, I would keep
>>> Sizzle as-is, even with bugs, and just document the things that won't
>>> work correctly. They are fairly minor, IMO.
>> How much have you looked into it?
>
> Quite a bit. Nearly as much as DM, I suppose.
>

Keeping Sizzle as-is sounds like a really bad idea to me.

>> What good is a large user base?
>
> A large user base is helpful because it brings out many situations and
> conditions that could not be predicted or found by a small development
> group. Even the best, most experienced js developers can't keep track
> of all the browser quirks and bugs out there. If the goal of a js
> library is to work well in many environments and situations, it's
> great to be exposed to thousands of different contexts that you may
> have never thought of. It will make the code more robust.
>

That sounds right. More people using it in different contexts will find
bugs.

Then again, why's jQuery like it is? jQuery has thousands of users. Look
at the query selector for five seconds. Well, you did, so OK, 10 seconds.

> I know that in many things I've built, I thought it worked fine until
> a small portion of users complained about something. Then I learned of
> a whole new way of thinking, or a whole new context, and I could
> further generalize my code.
>

I see your point. Code reviews help. Using the abstraction more helps.

I can see the motivation to improve on jQuery, I mean, if you can help a
company avoid some of the problems they're having, that's great, right?

As attractive as that might sound at this point, there are design
decisions that should have been avoided from the start. The design of
the query engine, for starters. Some of the fundamental problems, in
particular, the selector engine, cannot very well be fixed.

I see that YUI has copied some of these problems and has added to that
its own problems, sometimes blowing up, other times returning every
element in the document. What sort of low-level abstraction is that?
Does it solve cross browser issues or does it cause them?

Javascript library authors tend to publish things as solutions to "other
peoples'" problems, as sort of "crowd pleasers," rather than creating
abstractions that solve real problems. There is a certain fundamental
joy in publishing something that everybody likes and that's great, but
it can result in a public API and if it's got problems, you're stuck
with them.

Garrett
From: David Mark on 15 Jul 2010 00:38
On Jun 21, 2:40 pm, "S.T." <a...(a)anon.com> wrote:
> On 6/18/2010 7:18 PM, Andrew Poulos wrote:
>
> >> The fact that most CLJ regulars (the vocal ones, at least) can't
> >> comprehend why there's such demand for libraries is the same reason
> >> their critiques of libraries are technically accurate yet largely
> >> ignored. They can't see in context, nor anything less rigid than a
> >> true/false view.
>
> > There's only a demand because people take on javascript projects that
> > are beyond their skill level.
>
> This is always what I suspected a portion of the animosity was based on.
> A fear that opening up DOM manipulation and AJAX to the masses cheapens
> a particular skill set.
>
> >>> Even when someone like DM comes along and writes "His Library", he's
> >>> missing the point. He may get the technical aspects more correct, but
> >>> he lacks the vision and social grace required to make the library
> >>> actually useful to most developers. It's like he's created a better
> >>> mousetrap, but completely drops the ball on manufacturing, marketing,
> >>> and distribution. Whereas something like jQuery suffers from poor
> >>> quality, but gets the other stuff right.
>
> >> DM's script may be solid but the project as a whole is a train wreck. It
> >> wasn't a project developed to solve a problem, rather was a script
> >> written in an attempt to mock other libraries. It was DOA before it saw
> >> daylight.
>
> > DM's library has had little objective criticism and to call it DOA when
> > its usage is clearly growing shows how much you know about it.
>
> Huh? What indicators show its "clearly growing"?

The fact that since I started promoting it (about six months ago),
people have started using it.

> Aside from David's 14
> posts, mostly replying to himself, the "support group" shows five posts
> from two authors so far this month.

It's not a "support group", but a general discussion group. Some
months it is busy, some months it isn't. Perhaps the recent lack of
posts indicates users are content with the offering as it is.

And "replying to myself" indicates adding additional thoughts to a
previous announcement (e.g. IE 9 fixing a bug).

> Not exactly a booming community.

And you are not exactly making sense. What makes you think that
everyone who downloads the script(s) posts messages to the discussion
group?

>
> I've never actually *seen* 'My Library' in use on a live site.

So what?

> Have you?

Yes.

> Tough to gauge growth rates when the benchmarks hold steady at zero.

Tour observations are not benchmarks.

>
> Until something suggests otherwise I'll stand by my conclusion the
> project is dead, and always was dead, as the result of largely
> non-technical factors.

It is certainly not dead. I'm the only one who can declare such a
state. As for "always was dead", I've said for years that you
shouldn't need to use any GP library (including mine). Recently I
have decided to do (very limited) promotion as I am tired of seeing
far inferior libraries plastered all over the Web. Clearly the masses
are going to use something and it shouldn't be jQuery, Prototype, etc.

And I shouldn't have to sell you code (a la John Resig) anyway. Your
"arguments" are centered on the idea that my code is superior but you
won't use it because I refuse to produce flashy informercials to ram
it down your throat. Your ADHD is not my problem.

>
> > Why don't you just admit that you have stopped trying to discredit DM as
> > a person and are now trying to discredit his library both of which you
> > apparently know little about.
>
> I know David Mark's online persona is that of an asshat.

That's your idiotic "opinion". The fact is that lots of GP library
authors are pissed off at me because I have pointed out numerous
shortcomings in their efforts over the course of several years. You
are simply parroting them from the cozy confines of an anonymous
posting account. In other words, you have no persona at all.

> That's about
> all I know about DM.

Which is absolutely nothing.

> Maybe he's a stand-up rational guy in the real
> world. I have no idea.

Exactly. No ideas, but plenty of free time to speculate about things
you know nothing about.

>
> If you think there's something more involved here, like I'm in the midst
> of a several-year mission to discredit a javascript library and it's
> author, running to various online forums constantly posting the same
> arguments over and over and over... well, those sorts of actions would
> border on lunacy.

I have no idea what you are doing (or where you are doing it). You
don't even have a name. Your initials do seem to repeat the same
"arguments" here though. Any time I point out flaws in "major"
libraries, I know serial apologists like Matt Kruse and yourself will
pop up out of nowhere to cluck about how I "don't get it". Rest
assured, I get it. What I don't understand is why you try so hard to
obscure the real issues and confuse those who truly don't get it.
From: David Mark on 15 Jul 2010 00:58
On Jun 18, 11:06 am, Johannes Baagoe <baa...(a)baagoe.com> wrote:
> Thomas 'PointedEars' Lahn :
>
> > Matt is still not getting that (JS) libraries as a concept are not the
> > issue, but the people writing them.
>
> That, exactly, is what bothers me in those discussions : the issue seems
> to be *the people* writing those libraries. Technical objections alone
> would hardly justify personal smears.
>

When choosing a script, the relative proficiency of the author(s) is
certainly relevant.
From: David Mark on 15 Jul 2010 02:34
On Jun 18, 10:57 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> "S.T." wrote:
> > [in response to Matt Kruse]
> > You are in a small subset of developers that use jQuery by choice, yet
> > are also highly critical of it. In fact you might be the only person
> > I've read that shares those characteristics. Not that there's anything
> > wrong with that, just a somewhat unique view.
>
> You can put me in that category as well.

The category of those who abdicate responsibility for cross-browser
scripting to the jQuery authors (of all people), despite being told
repeatedly of their collective incompetence?

> I find that JQuery often
> simplifies my development, but I recognize many flaws in it and would
> love to see something more solid come along to take it's place.

It only allow creates the illusion of simplifying your development.
Odd that you can't see that after all of the related discussions.

And why do you need something to take its place? It's a 70K QSA
wrapper. As we've been over repeatedly, CSS selector queries are
highly ill-advised and there aren't many "supported" browsers left
that lack QSA anyway. What's left to replace? A ham-fisted API that
is completely inappropriate for browser scripting?

> But
> those need to be libraries that I would feel comfortable handing off
> to a client to continue with, which leaves out, for instance, My
> Library.

That makes no sense at all. You'd feel comfortable handing off a
script that you know is full of holes? And unlike jQuery, the code in
My Library is relatively easy to follow. So what's your point? If
the client Googles the name they won't find tons of gushing blog posts
and bad examples?

>
> At the moment, JQuery seems the best of a fairly bad bunch.

And what seems to indicate that? Like the rest, it calls QSA (with
very little in the way of feature testing) and hands off to a proven
mess of unfinished nonsense in the event of an error.

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

But, of course, you've already seen that. IIRC, your position was
that the demonstrably execrable results were somehow my fault for
"trying to break it". :(

> But I
> really don't want to skip a library altogether.

Why? Cross-browser scripting is relatively easy these days, making
jQuery and the like antiquated notions. By far, they create more
problems than they solve.

> Yes, I trust my own
> skills enough to believe I could do everything that's done in those
> libraries, but I really don't want to spend the time.

And therein lies the problem. If you would stop and think about it,
you would realize that you don't need most of what is in those
libraries, not to mention the fact that those libraries have failed
miserably (over the course several years) at their shared goal. They
are selling both problems and (very bad) solutions. Using them over
and over leaves you with no solutions of your own, which is your own
fault.

> And I don't
> think it's *that* bad.
>

Software either works or it doesn't. Software authors have talent or
they don't. Some apologists like to point to Windows as a product
that is not "that bad", but still pervasive. Of course, the
difference between a completely transparent 70K script and an OS
should be apparent.

What has jQuery done for you, other than leave you short of time and
code and therefore perpetually dependent on it? And what will you do
when new browsers shed more light on its appalling inferences? Go
back and "upgrade" all of your clients to a new jQuery and hope that
it all works out? Seems like a hard way to go, particularly in light
of the ongoing education of the script's authors and their penchant
for breaking compatibility (with browsers as well as their own
scripts). Assuming the applications don't fall apart (something that
will take new rounds of QA testing to determine), do your clients then
need to post disclaimers about the new jQuery breaking anything
released since last year? And will the end-users even know what to
make of such a disclaimer?

In stark contrast, I didn't have to alter a single line to accommodate
IE 8, FF 3, Safari 4, Chrome, Opera 9.5, Opera 10, Opera 10.5, etc.
And I recently tried out the Build Test page in the IE 9 "preview" and
everything worked in both HTML and XHTML DOM's. Furthermore, my users
(as well as participants in this group) have tried it in all sorts of
mobile devices (from brand new to ancient), game consoles, etc.
without issue.

That doesn't mean it is perfect (it isn't), just demonstrably superior
to the "major" libraries, each of which has required frantic efforts
to "keep up" with just the latest versions of a handful of modern
desktop browsers (in their default configurations) and left a trail of
broken browsers behind them (e.g. Opera 9.x, FF2, etc.) To this date,
none of them have come close to "solving" IE 6 and 7, which are
largely the same and by far the most used browsers of the last
decade. Recently, they've taken to calling for a "ban" on those
browsers (despite the obvious futility and IE7's persistence in IE8)
as a substitute "solution".

I have recently fixed bugs for ancient browsers that the other
libraries couldn't support if they wanted to and that gives me
confidence that the script will run in browsers that I haven't heard
of or have never tested (including those that haven't been invented
yet). None of the fixes involved browser-specific code and most were
trivial (e.g. one line to fix an FF1.0 issue, two lines to fix NN4,
another line to fix Opera 6, etc.) I had never bothered to look at
such browsers and clearly didn't write perfect feature detection/
testing for every conceivable environment. But plugging the holes
didn't have the slightest effect on the code's size, performance or
the compatibility with the more recent browsers.

Why should such a contrast exist? Because, relatively speaking, the
authors of jQuery, Prototype, YUI, Dojo, Qooxdoo, SproutCore,
Cappucinno, Closure, etc. haven't got the slightest idea what they are
doing. Over the years, overwhelming evidence has been published (here
and elsewhere) to prove this fact beyond any reasonable doubt. The
only people who fail to grasp this are those who lack a basic
understanding of the subject and those who are completely out to lunch
(e.g. VK). Even the authors of some of these libraries have woken up
of late and decided to scrap their previous efforts and start over
(e.g. Prototype). And to address a previous "point" made earlier in
this interminable thread, stating such is not a "personal smear". I
mean, would you buy an English-language book by an author with a
demonstrably shaky grasp of the English language? By the same token,
you shouldn't abdicate responsibility for browser scripting to
author(s) with a demonstrably shaky grasp of Javascript and its
interaction with browsers.

Unsurprisingly, I have clients who have been using custom builds of My
Library for years without issue. Still more use context-specific
scripts that continue to perform properly, despite the lack of any
sort of GP library. Others simply write (or IM) when they find
themselves stuck (and perhaps leaning towards using a bad script) and
invariably I talk them down by suggesting a solution that avoids the
problem. That's how professional browser scripting is supposed to
work. It requires experience, thinking and yes, actually writing code
rather than piggy-backing on top of popular junk found on the Web. On
the other hand, selling lifetime subscriptions to dubious open source
projects is about as unprofessional as it gets. In many cases it is
downright fraudulent.
First  |  Prev  |  Next  |  Last
Pages: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)