A
ashore
Guys, I see a fair bit of negativity around re subject package. Can
someone share your views, either way?
Thanks,
AS
someone share your views, either way?
Thanks,
AS
D
David Mark
Prototype - very bad.
It relies on browser sniffing in lieu of proper feature detection and
testing.
It works (sort of) in a limited set of modern browsers.
It is too large and the design isn't modular.
It is horribly inefficient. Even the lowest level code is tangled up
in syntactic sugar.
It augments host objects, most notably in the (unfortunately named) $
function.
It fails to leverage the inherent power of the JS language, instead
trying to force it to work like a class-based language.
Search the group for more details. Alternatively, read the comments
in the Rails Trac or related blogs.
D
dhtml
What goes on behind the scenes in Prototype? Some of the syntactic
sugaring is inefficient. It also makes code that uses prototype
require all of prototype, which is now a lot of code. Object Oriented
and non-modular.
The $super approach caused problems with compressors:
http://www5.sys-con.com/read/464826.htm
In fact, YUI compressor has apparently some logic to account for this.
(according to the README).
What do YOU think?
D
David Mark
From what I have read of it, nothing good. Like other (currently)
popular libraries, much of its decision-making is based on browser
sniffing and particularly susceptible to the myriad IE imitators out
there. Treating a non-IE agent as IE is clearly a recipe for
disaster. The authors of such libraries live in a dream world where
such agents don't exist.
I recently stumbled across the change log for the event handling code
and was amused to see that it cannot handle mousewheel events for the
handful of browsers it claims to support without several sniff-and-
branch operations. Such profound incompetence is on display
throughout the code. The accompanying comments to the seemingly
constant changes indicate that the developers haven't got a clue what
they are doing. How long until the maze of browser sniffing logic
outweighs the code that does actual work?
Exactly. It is all-or-nothing. Developers are advised to choose
nothing.
I wasn't aware of that one. One of the benefits of not using
Prototype (or the like) is that you don't have to keep up with the bug
reports.
I highly recommend the YUI "compressor" (misnomer), but certainly not
YUI itself. It is a better script than Prototype, but shares many of
the same problems (e.g. browser sniffing, too much sugar, etc.) Then
there is that ridiculous "namespace."
ME? I think I have made that abundantly clear. The only thing worse
than Prototype is jQuery. YUI is slightly better, but still well
south of competent. Using any of these libraries (or God forbid
combinations of them) is a bad idea. The average Web developer can
achieve lousy results on their own, so what is the benefit of adding
100K of third-party incompetence to the mix?
D
David Mark
It sometimes seems like "everybody" is doing it. What I can't
understand is why huge corporations would put their faith in trash
like Prototripe/Craptaculous (typically to add a few nifty fade
effects.) Can't they afford to pay competent developers? On the
server side, most appear to believe that .NET is the answer. If so,
what was the question?
From what I have read about IE8 (specifically the new versioning meta
tag), all of the libraries that rely on IE-sniffing are in for a rude
awakening. Will the authors finally see the folly of their ways or
will they add more branching based on the content of the meta tag?
P
Peter Michaux
<FAQENTRY>
Shouldn't something about Prototype be in the FAQ? It comes up very
frequently.
Peter
D
David Mark
I propose a two word entry: mostly harmful.
And for jQuery: completely worthless.
D
dhtml
Me too. But why 'misnomer'? It reduces the file size pretty well.
It is a better script than Prototype, but shares many of
Namespacing seemed stupid to me, at first. I mean, these aren't
"packages", they're just objects.
In fact, it confused the junior devs. Check out this example:
YAHOO.namespace("YAHOO.mst.scheduler");
YAHOO.mst.scheduler = function() { ... }
It's entirely possible to do this; to reassing a "package" to a
function (or any value, or delete it). It's not safe. But neither are
prototypes.
extend(Sub, Super);
Sub.prototype = { }; // <- Developer Mistake, just reassinged
prototype.
extend(Sub, Super, mixin); // <- corrected.
On the other hand, enforcing namespacing has made my code more
modular. Keeping the global namespace clean is just a small benefit.
If I didn't use packages and a build system, unit testing would be a
lot harder.
Writing a library is a lot of work. I want to write a better one. This
includes:
modular desing.
minimal framework.
building things as simple as possible, but not any simpler.
unit testing.
code review.
Now that last one, I could probably use a lot of help on.
That was meant for the OP. I'm not sure why this thread was brought up
even. If s/he's really considering Prototype, he could have done a web
search, or searched this group. (but I can't search Groups in FF
again; it's only FF now).
You have.
The only thing worse
Most of the F/E jobs here in the bay area want someone who has one of
the following:
Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that (of
fake it good enough), you can make decent money.
R
Richard Cornford
<snip>Randy said:
To be fair, I did not write that as a criticism of Prototype.js as such. I
wrote it as a comment on the worth of taking the advice of people who use
Prototype.js (advice which is usually that others should also use
Prototype.js).
Of course the comment was justified, and I certainly demonstrated technical
justification of my "by people who don't know javascript" in the thread with
the subject "Why should I eschew prototype.js?" (which started with
Message-ID: < (e-mail address removed) >).
Richard.
R
Richard Cornford
Javascript is a dynamic language where it is possible to write code that
will 'mess up' pretty much any other code. Nothing is "safe", there are just
varying degrees to which it is easy for programmer to break an existing
system. In the end it is the programmer's responsibility not to be doing
things wrongly, and that is going to be best achieved by understanding the
task in hand, the system it is to be done in/with and the environment(s) in
which it will operate.
If 'namespacing' were the only way of making code modular then that would
act as a justification for them, but they are not. Which leaves the only
relevant namspace-modularity relationship being a demonstration that they
may be either 'the best method' for achieving modularity or a 'good' method
in some sense or under some circumstances.
Remember to decide what precisely your library if for before even starting
to design it. Browser scripting has many contexts of application and trying
to create something that attempts to be all things to all people is pretty
much guaranteed to have a result that falls short of all.
It is still probably the easiest because all you have to do is post code
here in a readable/understandable form (along with an explanation of what it
is for) and its shortcomings will be pointed out.
My thoughts on the majority of current libraries is that they have been
bought into existence while their authors were experiencing the first flush
of superficial success in browser scripting (the stage where you start to be
able to create things that will work on more than two browsers and then gain
the false impression that you have the problem cracked) and then rushed
before a public hungry for such things. This has the effect of pretty much
freezing the libraries API (and its approach and the implied code authoring
style). The problem being that the authors don't see (because they don't
have the experience to see) that they have made fundamentally flawed design
decisions, and then the freezing of the API that follows from its being used
in the wider world removes any future hope of the overall design being
corrected (even if the authors are willing/ capable of recognising their
mistakes (and the current set seems to include many who have personalities
that are extremely resistant to the very idea that they may have done
anything wrong)).
Generally people who can recognise and learn from their mistakes will do
things better a second time and better yet a third.
This is also the trend in job advertisements in the UK, but not for the jobs
with the "decent money" (though our perceptions of "decent money" may
differ). It probably should not be taken too seriously, as the people doing
the recruiting don't tend to know what they need but have to write
something. It is like all the web development jobs where knowing Dreamweaver
was part of the requirement, regardless of the fact that the odds would be
that someone who knew Dreamweaver well would then not have any actual
technical understanding of web development at all.
Richard.
D
dhtml
Thread coming.
Well there;s plenty of mistakes to learn from, then.
This has the effect of pretty much
That's what I see with YAHOO. They can't change some broken core parts
of the library, like YAHOO.hasOwnProperty, augmentObject, et c.
With so many dependencies, how can they change?
The problem being that the authors don't see (because they don't
It's not just recruiters. Not many javascript experts out there.
One case is the company adopts a library. Often, they're B/E devs (or
tech leads w/o F/E experience). They want a library that's easy to
understand and does what they need.
Another case is a F/E dev will promote the library he likes to his
company, or the team will pick a library. As the team grows, they hire
other developers who know the same tools.
Hype can be a big influence.
Contract jobs such as these vay in pay range, depending on desparation
(Urgent: Must get 'Ajax' guru). They pay from USD 40-90+/hr. or 70-150k
+/yr. (in the Bay area).
Garrett
T
timothytoe
Until a clj Nazi codes a "correct" library with the capabilities of
jQuery or Prototype or YUI, those libraries will be continue to be
used to make websites. And probably to an acccelerating degree.
I agree that browser-sniffing is about as appealing as anus-sniffing,
but programmers in the real-world sometimes need to actually get
things done. A smart programmer (as opposed to a perfection-seeking
zealot} will go with the flow and be able to throw together a website
quickly as a result. Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way for programmers
to ensure future work.
If my site is cobbled together in jQuery, guess what I'm going to look
for on a FE resume. I need another guy who knows jQuery, so he can
read and debug the crappy code I wrote, and create new crappy code
that I can read and debug. I want someone who knows the jQuery plug-
ins, not some guy that'll come in and write a bunch of new untested
tab systems, tablesorters, Canvas charting systems, modal dialogs, and
tool-tips. If my new programmer quits because he hates the music I
play, or because we have a dangerous-looking homeless guy outside who
regularly threatens his life and throws half-eaten mayonnaise-and-
cheese sandwiches at him every time he walks to his car at night, I'm
going to look for <i>another</i> jQuery programmer to replace him.
And don't underestimate the impact of these libraries on the makers of
browsers. As jQuery shows up in more and more sites, will Microsoft
really want to be seen as releasing an IE8 that is "broken" and
"sucks?" I predict that Microsoft will endeavor to not break jQuery,
Prototype, and YUI sites. Already, people are starting to base their
ideas of "browser speed" on the CSS and XPath selector timings from
various libraries, and upon Javascript performance. It's not just the
speed of layout that counts now. I bet Microsoft will actually
accommodate these libraries so that IE has a little bit less
embarrassing showing in the benchmarks. Do you think it's coincidence
that Microsoft is trying to pass acid tests?
By all means, point out the flaws in the libraries. But if you know
how to write a better library, perhaps spend some of your time
building a better mousetrap and a little less time flapping your
mouthtrap.
It's all changed out from under you. The libraries are THE major force
in Web 2.0 development now. jQuery is in (I believe) Rails now, and
Drupal, and AIR. You may have disdain for them, but it's a quixotic
(and mildly pathetically humorous) jihad you wage against them.
I'm not saying there is not a place for a by-the-books JS programmer
out there--there certainly is. But I think there are already more
places for a library-slinger and every month will bring more. It's
more helpful to council people of how to deal with the libraries than
avoid them.
jQuery or Prototype or YUI, those libraries will be continue to be
used to make websites. And probably to an acccelerating degree.
I agree that browser-sniffing is about as appealing as anus-sniffing,
but programmers in the real-world sometimes need to actually get
things done. A smart programmer (as opposed to a perfection-seeking
zealot} will go with the flow and be able to throw together a website
quickly as a result. Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way for programmers
to ensure future work.
If my site is cobbled together in jQuery, guess what I'm going to look
for on a FE resume. I need another guy who knows jQuery, so he can
read and debug the crappy code I wrote, and create new crappy code
that I can read and debug. I want someone who knows the jQuery plug-
ins, not some guy that'll come in and write a bunch of new untested
tab systems, tablesorters, Canvas charting systems, modal dialogs, and
tool-tips. If my new programmer quits because he hates the music I
play, or because we have a dangerous-looking homeless guy outside who
regularly threatens his life and throws half-eaten mayonnaise-and-
cheese sandwiches at him every time he walks to his car at night, I'm
going to look for <i>another</i> jQuery programmer to replace him.
And don't underestimate the impact of these libraries on the makers of
browsers. As jQuery shows up in more and more sites, will Microsoft
really want to be seen as releasing an IE8 that is "broken" and
"sucks?" I predict that Microsoft will endeavor to not break jQuery,
Prototype, and YUI sites. Already, people are starting to base their
ideas of "browser speed" on the CSS and XPath selector timings from
various libraries, and upon Javascript performance. It's not just the
speed of layout that counts now. I bet Microsoft will actually
accommodate these libraries so that IE has a little bit less
embarrassing showing in the benchmarks. Do you think it's coincidence
that Microsoft is trying to pass acid tests?
By all means, point out the flaws in the libraries. But if you know
how to write a better library, perhaps spend some of your time
building a better mousetrap and a little less time flapping your
mouthtrap.
It's all changed out from under you. The libraries are THE major force
in Web 2.0 development now. jQuery is in (I believe) Rails now, and
Drupal, and AIR. You may have disdain for them, but it's a quixotic
(and mildly pathetically humorous) jihad you wage against them.
I'm not saying there is not a place for a by-the-books JS programmer
out there--there certainly is. But I think there are already more
places for a library-slinger and every month will bring more. It's
more helpful to council people of how to deal with the libraries than
avoid them.
L
Lasse Reichstein Nielsen
timothytoe said:
It's expected behavior. DHTML+AJAX is a disruptive technology, and so
are the libraries that enable its use to mortals. The responses to it
fall neatly into the two expected categories: worship and disgust.
Sure, the libraries are not perfect, but they "get the job done" -
delivering results that are "good enough", and that get better with
every iteration.
Personally I would rather use GWT, but I like statically typed
languages
/L
T
timothytoe
It's expected behavior. DHTML+AJAX is a disruptive technology, and so are the libraries that enable its use to mortals. The responses to it fall neatly into the two expected categories: worship and disgust.
I see three: worship, disgust, and pragmatism.
I fall into the third category. I just can't bring myself to be either
worshipful of or disgusted by a tool that people use to get things
done. I reserve my worship for Jimi Hendrix and Picasso and my disgust
for tubgirl and goatse.
I see three: worship, disgust, and pragmatism.
I fall into the third category. I just can't bring myself to be either
worshipful of or disgusted by a tool that people use to get things
done. I reserve my worship for Jimi Hendrix and Picasso and my disgust
for tubgirl and goatse.
P
Peter Michaux
I think the worshipers are the people who are glad to have someone
else worry about browser bugs. Then they can defer responsibility when
the boss questions about the support complaints.
But why do they get better so slowly when so many people are using
them and apparently reading the code? Browser scripting topics like
feature detection have been known for a long time and there are many
well known tests; however, the mainstream libraries opt for
navigator.userAgent frequently.
Peter
T
timothytoe
But why do they get better so slowly when so many people are using
You'd have to hunt one of them down and make them answer to know, but
my assumption is not yours. You appear to assume that they are simply
sniffing to detect features. I assume they are sniffing to get around
browser JS or CSS bugs, or perhaps in some cases to improve
performance or to reduce the size of their often-transmitted
functions. In other words, they probably have reasons that have to do
with real-world trade-offs.
You'd have to hunt one of them down and make them answer to know, but
my assumption is not yours. You appear to assume that they are simply
sniffing to detect features. I assume they are sniffing to get around
browser JS or CSS bugs, or perhaps in some cases to improve
performance or to reduce the size of their often-transmitted
functions. In other words, they probably have reasons that have to do
with real-world trade-offs.
D
dhtml
There shuold be an article about javascript API design. It should
ideally include an interview or forward by Brendan (long or brief).
This could be discussed by library authors and users of libraries.
An FAQ Entry should be unbiased and informative. There could be a link
to some Prototype JS forums. This topic does come up a lot.
T
timothytoe
An FAQ Entry should be unbiased and informative...
Now that's a provocative idea!
Now that's a provocative idea!
D
dhtml
They do damage. They do this by relying on browser bugs, sniffing the
userAgent, and then patching it with a hack. What happens if the
browser is to fix the bug? Chris Wilson takes about IE trying to "not
break the web".
<snip blah>
P
Peter Michaux
That right there is the most solid argument I've seen against hacking.
That is worth having in your sig line.
Peter