"The Good Enough Revolution" - As it applies to js
Matt Kruse
http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough?currentPage=all
And had a thought about javascript libraries like jQuery, et al.
I believe this is the point that many library-users try to make that
js "experts" seem to miss. jQuery (as the popular example) is "good
enough". It trades power, perhaps some speed, and certainly some
compatibility for flexibility, convenience, and simplicity. This is a
trade that most js developers are willing to make.
Although the js "purists" will always argue that libraries are _not_
"good enough" because they are never perfect, this is the same
argument that camera purists may make about cheap point-and-shoot
cameras that do not have the quality of the more advances models. Or
any purists in any field who argues against the "good enough"
technology.
But for most people, these purists are missing the point. "Good
Enough" really is Just Fine.
Just a thought.
Matt Kruse
Stevo
I completely agree. The makers of libraries like jQuery and prototype.js
are just trying to re-use code and that's a good aim to have. They start
out small and simple (and probably clean and well organized) and then
the new requirements come in by the bucketload and it just gets out of
control. Anyone who then comes along and takes a look just sees the mess
it's become and completely disregards the good intentions that were
there at the beginning.
Your point-and-shoot camera is a perfect analogy. It's not a $20,000 top
of the range Nikon which the purists demand, but it fits in the pocket,
takes near-zero knowledge to use and gets a basic job done.
The same should apply to the JS libs but generally doesn't. It's a
losing battle of wanting to be so flexible in their API that it becomes
very complex to make something simple like putting a DIV on a page and
moving it across the screen. That sounds simple, and if you were writing
your own function it would be, but the function in a super-flexible lib
would need to offer dozens of options for that simple display and
animate function that it becomes difficult. Of course, if they didn't
offer all those options, then people would complain it's no good for
them. Catch 22.
I've never used any of the often criticized libs, but I respect the
people that made them enough not to talk trash about them.
Jorge
> I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
>
> And had a thought about javascript libraries like jQuery, et al.
>
> I believe this is the point that many library-users try to make that
> js "experts" seem to miss. jQuery (as the popular example) is "good
> enough". It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity. This is a
> trade that most js developers are willing to make.
The more complex a page becomes the sooner they'll start to appreciate
libraries like JQuery.
There are many people here in cljs still worried that javascript might
be disabled. That just proves that they're still living in the past,
when pages were just pages and not (web) applications.
> Although the js "purists" will always argue that libraries are _not_
> "good enough" because they are never perfect, this is the same
> argument that camera purists may make about cheap point-and-shoot
> cameras that do not have the quality of the more advances models. Or
> any purists in any field who argues against the "good enough"
> technology.
>
> But for most people, these purists are missing the point. "Good
> Enough" really is Just Fine.
>
> Just a thought.
>
> Matt Kruse
Libraries are, and have ever been, pieces of code that perform a/some
function(s) to use when you don't want to write (for whatever reason)
your own piece of code to perform that/those function(s). There's
nothing wrong with this, and, often, those libraries were written by
people with more experience than you in the problem at hand.
--
Jorge.
Eric Bednarz
> Although the js "purists" will always argue that libraries are _not_
> "good enough" because they are never perfect, this is the same
> argument that camera purists may make about cheap point-and-shoot
> cameras that do not have the quality of the more advances models.
Analogies are like … oh, wait.
(I recommend becoming a graphic designer and trying to smuggle your good
enough point-and-shoot material past the art director without getting
cat o’ nine tailed)
Pherdnut
can spend colossal amounts of time making things faster, better,
stronger, more flexible and we rarely get the time needed just to
satisfy our own pride as developers but the reality of the situation
is that we're getting paid to produce and the time we'd like rarely
agrees with the time considered 'acceptable.' Some people skip the
pride part and never work longer than 40 hours a week if they're not
asked to. They'll just poop it out and move to the next deadline.
Sadly those are the ones who tend to end up managing and determining
what is an acceptable time frame. A well-written, well-maintained
framework that focuses on the basics of what makes dealing with the
DOM and cross-browser issues tedious and time-consuming is not about
mediocrity for me. It's about buying more time to do it as right as I
can with the time allotted plus the ten to twenty extra hours I put in
a week making it 'good enough' to fit my standards.
Garrett Smith
> I found this article interesting:
> http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough?currentPage=all
>
> And had a thought about javascript libraries like jQuery, et al.
>
> I believe this is the point that many library-users try to make that
> js "experts" seem to miss. jQuery (as the popular example) is "good
> enough". It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity.
Nope. It's a poorly designed library.
This is a
> trade that most js developers are willing to make.
>
Nope. jQuery has the classic signs of religion. I learned in the first
grade that you can't argue with religion. My classmate taught me that,
imploring me to prove that god did not exist.
> Although the js "purists" will always argue that libraries are _not_
> "good enough" because they are never perfect,
JS purist? What is that? Sounds like trying to put a label on someone
who tries hard.
Things not being perfect does not provide a good reason for doing them
half-assed.
this is the same
> argument that camera purists may make about cheap point-and-shoot
> cameras that do not have the quality of the more advances models. Or
> any purists in any field who argues against the "good enough"
> technology.
>
> But for most people, these purists are missing the point. "Good
> Enough" really is Just Fine.
>
That speaks of a low standard of personal achievement. I find this to be
a widespread problem in the USA.
> Just a thought.
Didn't like it. The part of "good enough" is uninspiring and depressing.
The generalization and labeling goes to the extreme. It's not just being
lazy and making excuses, it's making a scape goat out of those who try
hard. That makes me angry.
I did like this:-
Don't ship shit.
http://www.artima.com/weblogs/viewpost.jsp?thread=7588
- along with mostly everything he's written, but in particular, "Agile
Software Development, Principles, Patterns, and Practices."
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
Garrett Smith
> On Aug 29, 11:30 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>> I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
>>
>> And had a thought about javascript libraries like jQuery, et al.
>>
>> I believe this is the point that many library-users try to make that
>> js "experts" seem to miss. jQuery (as the popular example) is "good
>> enough". It trades power, perhaps some speed, and certainly some
>> compatibility for flexibility, convenience, and simplicity. This is a
>> trade that most js developers are willing to make.
>
> The more complex a page becomes the sooner they'll start to appreciate
> libraries like JQuery.
>
I hope this silly jQuery craze is not going to last much longer.
> There are many people here in cljs still worried that javascript might
> be disabled. That just proves that they're still living in the past,
> when pages were just pages and not (web) applications.
>
Sounds more like you want a reason to understand why javascript might be
disabled, and so you've made one up.
Plenty of awful sites misusing javascript to be "web 2.0". PubMed and
Yelp are good examples of such abuse.
Doug Gunnoe
> There are many people here in cljs still worried that javascript might
> be disabled. That just proves that they're still living in the past,
> when pages were just pages and not (web) applications.
My blackberry came with javascript disabled.
Gregor Kofler
> I found this article interesting:
> http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough?currentPage=all
>
> And had a thought about javascript libraries like jQuery, et al.
>
> I believe this is the point that many library-users try to make that
> js "experts" seem to miss. jQuery (as the popular example) is "good
> enough". It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity.
That depends of course on the definition of those latter terms...
> This is a
> trade that most js developers are willing to make.
What now? Are you talking about "JS developers" or "library-users" (in
the sense of "script kiddies").
> Although the js "purists" will always argue that libraries are _not_
> "good enough" because they are never perfect, this is the same
> argument that camera purists may make about cheap point-and-shoot
> cameras that do not have the quality of the more advances models. Or
> any purists in any field who argues against the "good enough"
> technology.
Interestingly enough, I hardly ever see professional photographers
(those who get paid for taking photos) with a point-and-shoot camera.
> But for most people, these purists are missing the point. "Good
> Enough" really is Just Fine.
> Just a thought.
True. We never had this "discussion" before...
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Stefan Weiss
> On Aug 29, 11:30 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>> I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
Yeah, I read that article too. It has a few good points, but I'm not
sure if you can really apply it as a general principle. If you aim for
"good enough" instead of "excellent", you run the risk of landing in the
"mediocre" or "barely acceptable" segments. Much of Apple's software
appears to be built around the "good enough" principle; it's shiny, easy
to use, and even my dad would know where to click, because there's only
one button. The downside is... there's only one button. If you want to
do something else, you're out of luck - but hey, 95% of the time, one
button is "good enough".
Personally, I try for excellence. Then, when I run out of time (which is
the inevitable downside of my approach), I have to cut corners, and what
gets shipped is "good enough".
> The more complex a page becomes the sooner they'll start to appreciate
> libraries like JQuery.
Actually, the more complex a page is, the more I'd refuse to use JQuery.
It's fine if you want to add a slide show to your blog, but as soon as
you have to support unusual clients or unusual requirements, JQuery is
more hindrance than help. In the context of Matt's posting, yes, JQuery
is good enough for many uses. Like a Swiss army knife is good enough for
many tasks, but professionals will still bring their own tools.
> There are many people here in cljs still worried that javascript might
> be disabled. That just proves that they're still living in the past,
> when pages were just pages and not (web) applications.
That's rich. How do you keep your pages (or applications) accessible, if
you require JavaScript? For many web sites, accessibility for
handicapped visitors is not an optional feature. I'm not sure how that's
handled in Spain, but if I remember correctly, there's even an EU
regulation about this for publically funded sites (correct me if I'm
wrong). If ignoring people with screen readers is the future, then I'll
keep living in the past, as you say. Maybe I'll even set up a Gopher
server to prove my point ;)
Summary: if you like JQuery, good for you, but don't expect the "purists
in cljs" to suddenly see the light, because there's nothing new to see
in JQuery. It's not the holy grail, and it's not the worst tool you
could choose either, it's just a very popular library, that's all.
cheers,
stefan
Jorge
> (...) Much of Apple's software
> appears to be built around the "good enough" principle; it's shiny, easy
> to use, and even my dad would know where to click, because there's only
> one button. The downside is... there's only one button. If you want to
> do something else, you're out of luck - but hey, 95% of the time, one
LOL, software quality is directly proportional to the number of
buttons... ?
--
Jorge
Jorge
> you require JavaScript?
So, do you still buy -nowadays- that a web app should run 100% server-
side, and serve just pure html and as few unobtrusive javascript as
possible ?
I'd bet you $10 that this (bs) isn't going to last for much longer...
A browser without javascript *enabled* is going to end up being as
useful and desirable as a PC without an internet connection...
> Summary: if you like JQuery, good for you, but don't expect the "purists
> in cljs" to suddenly see the light, because there's nothing new to see
> in JQuery. It's not the holy grail, and it's not the worst tool you
> could choose either, it's just a very popular library, that's all.
JQuery is one of them. More are yet to come. Sooner or later you'll
find the one that you like, and you'll use it. Because the need is
there. Because the API the browsers provide is a pitiful mess and the
need for a better-thought higher-level one exists. The desire is
inside you too already, although you may not have noticed it yet :-)
--
Jorge.
Jorge
>
> My blackberry came with javascript disabled.
Is it still disabled ?
--
Jorge.
Jorge
> (...)
> Plenty of awful sites misusing javascript to be "web 2.0". PubMed and
> Yelp are good examples of such abuse.
And plenty of awful sites too, built around the tired old <form> comes
<form> goes model, completely ignoring the (client-side) browser's
scripting true capabilities.
--
Jorge.
paolochiodi
work with the dom, working out browser incompatibility specially when
doin simpla action in a traditional web site;
But they became quite unusefull when building big applications.
Some times (mobile, embedded) the trade off speed is significant.
Paolo
David Mark
> I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
Okay.
>
> And had a thought about javascript libraries like jQuery, et al.
Of course. I'm sure you see justification everywhere.
>
> I believe this is the point that many library-users try to make that
> js "experts" seem to miss.
*PLONK* Should have done that years ago. :)
John G Harris
wrote:
>I found this article interesting:
>http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough
>?currentPage=all
>
>And had a thought about javascript libraries like jQuery, et al.
>
>I believe this is the point that many library-users try to make that
>js "experts" seem to miss. jQuery (as the popular example) is "good
>enough". It trades power, perhaps some speed, and certainly some
>compatibility for flexibility, convenience, and simplicity. This is a
>trade that most js developers are willing to make.
The article mentions the 80/20 principle. 80% of the work of a JQuery
web page is done by the 20% that is HTML+CSS. Let's be good enough and
get rid of the other 80%.
John
--
John Harris
Garrett Smith
I received report the older blackberry had CSS disabled.
BTW, which version of blackberry support postMessage?
Garrett
Lasse Reichstein Nielsen
> I found this article interesting:
> http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough?currentPage=all
It is :)
As my signature might suggest, I generally agree with the idea.
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
Pherdnut
I regularly reduce old code on the sites I work on by more than half
using JQ and I'm being conservative. It's probably been used to knock
out megabytes worth of crap-code on our sites in just the last couple
months. That's worth a one-time cache of 15K for the user. If you had
say... 3-5 static page sites that just needed some form validation in
mind, I could see your point.
RobG
> I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
I don't think "good enough" is a revolution, the concept has been
around ever since humans have been selling products. It's one of the
reasons Windows killed OS/2.
> And had a thought about javascript libraries like jQuery, et al.
The difference though is that the users in this case are developers
who don't use the product they make. The users of the product have no
say in the matter - the result might be different if they did. How
many sites offer alternative versions to see which "product" users
like better?
> I believe this is the point that many library-users try to make that
> js "experts" seem to miss. jQuery (as the popular example) is "good
> enough". It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity. This is a
> trade that most js developers are willing to make.
But are the end users aware the developer choices are forcing upgrade
costs onto them? Many sites now require the use of a recently released
browser, end users aren't aware that it was a developer who decided
not to support their otherwise perfectly functional browser, not the
owner of the site.
I recently re-installed Windows 2000 Pro. As soon as it was installed,
I ran Windows update, which refused to work unless I upgraded to IE
6. Microsoft's download site refused to work with IE 5.5 - so how was
I supposed to upgrade? A great catch-22.
Unsurprisingly, the Firefox download site worked fine so I installed
Firefox and Googled for IE 6 downloads.
A classic example of developers simply not bothering to support their
user base. Or perhaps it's a deliberate strategy to make life
difficult for Win2k users - either way, the effect is that because
their site depends on users having the latest and greatest browser,
anyone else is left out in the cold.
> Although the js "purists" will always argue that libraries are _not_
> "good enough" because they are never perfect, this is the same
> argument that camera purists may make about cheap point-and-shoot
> cameras that do not have the quality of the more advances models. Or
> any purists in any field who argues against the "good enough"
> technology.
I don't think it has anything to do with being a "purist", but much
more to do with valuing quality. It is very easy to use technology to
unwittingly discriminate against users who don't have the latest and
greatest PC or browser. Placing arbitrary constraints on the use of
the web purely because a developer's ignorance disenfranchises a class
of users is the antithesis of the fundamental reasons for the World
Wide Web and the internet as a whole.
The use of libraries can also lead to so very poor development choices
with shockingly inefficient code - again, this forces users to
consider upgrades because their otherwise perfectly functional PCs
become more and more sluggish.
> But for most people,
Where "most people" means inexperienced developers.
> these purists are missing the point. "Good
> Enough" really is Just Fine.
No, it isn't. Those who promote libraries, refuse to listen to valid
criticism and don't see that they aren't "just fine" are the ones
missing the point.
The argument against libraries is not just related to javascript, but
is of general interest for most programming languages. The site I am
working at has developed a number of VB applications over the years
using MS development tools. Recently, they have been forced to
upgrade certain parts of their technology stack, and now half of those
VB programs must be re-written because the current libraries don't
support things that were use in previous versions.
So while at the time they might have been seen as "good enough", they
certainly aren't now.
--
Rob
Pherdnut
> is of general interest for most programming languages. The site I am
> working at has developed a number of VB applications over the years
> using MS development tools. Recently, they have been forced to
> upgrade certain parts of their technology stack, and now half of those
> VB programs must be re-written because the current libraries don't
> support things that were use in previous versions.
>
> So while at the time they might have been seen as "good enough", they
> certainly aren't now.
>
> --
> Rob
What is the general argument against libraries? You provided yet
another example of either MS sucking or your team letting too many
versions go by before upgrading. At some point things do have to
change or go stale. I expect JQ to be well-maintained but even if it
wasn't there's no future-proofing against MS's refusal to conform to
standards. I'm new to this newsgroup so I've been trying to read up on
past debates and I keep seeing this recurring idea that a good library
should somehow anticipate the quirks of a new browser.
How is such a thing possible? In ten years, MS has barely made any
real movement in conforming to the W3C DOM. At this point, I'm almost
more worried about how much of a pain in the butt it's going to be
when/if they finally start actually trying now that we've really
nailed down some solid methodology for catering to their garbage.
Let's imagine I did write my own custom library with nothing but
exactly what we needed for the team of 23 front end developers I work
with and it was even a good 20% faster than JQ by some meaningless
standard. Odds are perfectly reasonable I'm not going to be at that
company when IE 9 rolls around. What's better for the team, my code,
or a popular framework supported by a crew who will be anticipating
changes that need to be made from the first day the beta of IE 9 is
made available.
Also, I think the fact that we have to write for a number of
conflicting interpretations of the very language we're writing with
and the object models it follows, makes the library question a very
different one where JS is concerned.
Malcolm Dew-Jones
: On Aug 30, 7:30 am, Matt Kruse <m...@thekrusefamily.com> wrote:
: > I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
: I don't think "good enough" is a revolution, the concept has been
: around ever since humans have been selling products. It's one of the
: reasons Windows killed OS/2.
Windows was "good enough", OS/2 was not good enough.
RobG
> On Aug 30, 12:39 pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>
>
>
> > On Sat, 29 Aug 2009 at 14:30:51, in comp.lang.javascript, Matt Kruse
> > wrote:>I found this article interesting:
> > >http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough
> > >?currentPage=all
>
> > >And had a thought about javascript libraries like jQuery, et al.
>
> > >I believe this is the point that many library-users try to make that
> > >js "experts" seem to miss. jQuery (as the popular example) is "good
> > >enough". It trades power, perhaps some speed, and certainly some
> > >compatibility for flexibility, convenience, and simplicity. This is a
> > >trade that most js developers are willing to make.
>
> > <snip>
>
> > The article mentions the 80/20 principle. 80% of the work of a JQuery
> > web page is done by the 20% that is HTML+CSS. Let's be good enough and
> > get rid of the other 80%.
>
> > John
> > --
> > John Harris
>
> I regularly reduce old code on the sites I work on by more than half
> using JQ and I'm being conservative.
Reducing the number of lines of code is, of itself, pointless. If that
is the sole beneift of the exercise, you've likely wasted your time
(and the money of your employer).
> It's probably been used to knock
> out megabytes worth of crap-code on our sites in just the last couple
> months. That's worth a one-time cache of 15K for the user.
Then the "crap code" would also be cached, so what's been saved? Your
example might have some meaning if you could produce a business case
for doing it.
> If you had
> say... 3-5 static page sites that just needed some form validation in
> mind, I could see your point.
That is a common scenario where a library with validation plugins is
added to a site - the "developers" justify it on the basis that it
isn't worth writing bespoke code for such a trivial excercise and that
using a library is "good enough".
Use snowballs from there, so that the library is used for all sorts of
things that it shouldn't; soon enough the site is dependent up it and
technology choices are foisted on unsuspecting users.
--
Rob
Erik Reppen
Formerly Pherdnut btw. Same account. e-mail always revealed my name.
By 'knock out' I meant 'eliminated/replaced.' By crap code I mean
JavaScript written by people who supposedly know Java and can barely
handle HTML. I've seen tables dynamically built for every row of a
table, markup in our database, and one gem of a for loop with
something like 215 compound conditional statements for the purpose of
building and spitting out a dozen lines of HTML for search results.
Granted, just vaguely competent POJS and real back end devs would
drastically reduce the code but being able to rebuild quickly is very
helpful and ultimately given the sheer volume of behavior covered
there is a massive savings in the amount of script loaded sitewide.
There is no aspect of core JQ I haven't touched on working on our
stuff and yes a few lines can save you hundreds of lines of cross-
browser and convoluted DOM API junk.
That some people misuse libraries does not detract from my experience
with them when they are built properly and used well. I have no
interest in JQ outside of its core, which primarily covers
crossbrowser issues you have to deal with near-constantly in JS. I
don't want somebody to come up with the solution to the problem for
me. I'm actually quite good at that. I just don't want to waste time
redoing the same code-branching solutions to the same dippy little
problems over and over again. I had my own set of functions for that
before that I was reasonably pleased with and I like what this set
offers even better.
RobG
> > The argument against libraries is not just related to javascript, but
> > is of general interest for most programming languages. The site I am
> > working at has developed a number of VB applications over the years
> > using MS development tools. Recently, they have been forced to
> > upgrade certain parts of their technology stack, and now half of those
> > VB programs must be re-written because the current libraries don't
> > support things that were use in previous versions.
>
> > So while at the time they might have been seen as "good enough", they
> > certainly aren't now.
>
> > --
> > Rob
>
> What is the general argument against libraries? You provided yet
> another example of either MS sucking or your team letting too many
> versions go by before upgrading.
Thanks, you just proved my point - using a library creates additional
dependancies. Whether those dependancies are acceptable or not
requires analysis of the particular circumstances (a business case).
Therefore, rather than simply saying "libraries are good", make a
sound business case and maybe you'll get it accepted. Or not.
> At some point things do have to
> change or go stale.
Change for the sake of change? Get that past any reasonably competent
project board. Forced upgrades may be a great strategy for a software
vendor to get you to buy new versions of their products, not so great
when your client finds out what's going on though.
> I expect JQ to be well-maintained but even if it
> wasn't there's no future-proofing against MS's refusal to conform to
> standards.
I don't think MS needs to be singled out for poor support of web
standards.
You've clearly missed previous discussions about feature testing here.
jQuery has belated decided it is a good idea, so it's better prepared
than it was before. It's not that hard to "future proof" web sites
and applications, more relevant is making them tolerant of new,
unknown browsers and until its adoption of feature testing, jQuery was
particularly bad at that. Tolerance is becoming more important with
each new browser-enabled mobile device, as is efficient, concise code.
jQuery sucks at that.
> I'm new to this newsgroup so I've been trying to read up on
> past debates and I keep seeing this recurring idea that a good library
> should somehow anticipate the quirks of a new browser.
All that needs to be anticipated is that a browser may not support any
features required by the scripts being used. It goes beyond "a good
library" to a sound development strategy.
The old bug-bear of "this site doesn't support your browser" has been
replaced by "our script library doesn't support your browser". Guess
that's progress.
> How is such a thing possible?
It isn't necessary.
> In ten years, MS has barely made any
> real movement in conforming to the W3C DOM. At this point, I'm almost
> more worried about how much of a pain in the butt it's going to be
> when/if they finally start actually trying now that we've really
> nailed down some solid methodology for catering to their garbage.
The only sites that would fail would be those dependent upon browser
sniffing. You might be aware that there are still developers who think
it's a viable "good enough" strategy. It isn't and never was.
> Let's imagine I did write my own custom library with nothing but
> exactly what we needed for the team of 23 front end developers I work
> with and it was even a good 20% faster than JQ by some meaningless
> standard. Odds are perfectly reasonable I'm not going to be at that
> company when IE 9 rolls around. What's better for the team, my code,
> or a popular framework supported by a crew who will be anticipating
> changes that need to be made from the first day the beta of IE 9 is
> made available.
Presumably "your" library would belong to the employer and the IT
section should have a methodology for maintenance and support of the
code. The use of jQuery does nothing to help in that case, there will
still be a significant amount of "library" code written on top of it.
All of that code needs to be tested and updated every time a new
version of jQuery is implemented in addition to every time a new
"supported" browser appears. So what have you saved? Oh, that's right
- if it's not a supported browser, you don't do anything and just let
it break.
> Also, I think the fact that we have to write for a number of
> conflicting interpretations of the very language we're writing with
You mean ECMA-262 implemenations? What conflicting interpreations?
> and the object models it follows
The javascript object model? or the DOM? I don't see how either of
those makes a library like jQuery a no-brainer. Quite the contrary -
jQuery wraps just about every available DOM method to support its
chaining strategy - developers end up writing jQuery, not javascript.
How will jQuery deal with HTML 5 or ECMA-262 version 5?
>, makes the library question a very
> different one where JS is concerned.
Presumably that is a reference to providing cross-browser support. If
you look at the very limited number of jQuery supported browsers, that
wouldn't be very difficult anyway.
Let's be clear - I'm not saying never user a library. But their over-
use has consequences that reflect on web development as a whole, such
as driving technology decisions (such as browser upgrades) that
otherwise need not have been made, or pushing users toward particular
software vendors or platforms. Those negative aspects should be
avoided as much as possible on the web, where the underlying philosphy
is to make information available as widely as possible with the
minimum of restrictions.
And certainly a "good enough" philosophy should be challenged at every
opportunity. At the least, the goal should be the best quality
possible within the project's constraints (where quality is judged on
functional performance, not things like crappy UI effects).
--
Rob
David Mark
wrote:> >http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
>
> It is :)
>
> As my signature might suggest, I generally agree with the idea.
The idea that a script written six years after IE6, proposing to make
cross-browser scripting easier, still fumbles IE quirks mode, ActiveX
and simple things like attributes *to this day* is some sort of
revolutionary breakthrough because such a thing is clearly "good
enough" if lots of people use it?
Still makes progressive enhancement impossible as well. I just don't
see it. I think something like that might be a disruption (in a
positive way) some day. If only...
David Mark
> On Aug 30, 12:39 pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>
>
>
> > On Sat, 29 Aug 2009 at 14:30:51, in comp.lang.javascript, Matt Kruse
> > wrote:>I found this article interesting:
> > >http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough
> > >?currentPage=all
>
> > >And had a thought about javascript libraries like jQuery, et al.
>
> > >I believe this is the point that many library-users try to make that
> > >js "experts" seem to miss. jQuery (as the popular example) is "good
> > >enough". It trades power, perhaps some speed, and certainly some
> > >compatibility for flexibility, convenience, and simplicity. This is a
> > >trade that most js developers are willing to make.
>
> > <snip>
>
> > The article mentions the 80/20 principle. 80% of the work of a JQuery
> > web page is done by the 20% that is HTML+CSS. Let's be good enough and
> > get rid of the other 80%.
>
> > John
> > --
> > John Harris
>
> I regularly reduce old code on the sites I work on by more than half
> using JQ and I'm being conservative.
Interesting you should mention that. I often reduce sites by 80% by
throwing out such scripts (among other things). Makes them far more
compatible and reliable as well. I'm sure disabled users appreciate
the changes as well.
And jQuery is not 15K. It's about 50K in the form that is comparable
to other assets (and most sites use a tiny bit of that). The
possibility of compression shouldn't enter into such comparisons.
Think about it.
Matt Kruse
> I don't think it has anything to do with being a "purist", but much
> more to do with valuing quality.
But that is the point of the article - that "quality" is not
necessarily the only or best judge of value. People will often
sacrifice quality in exchange for convenience, cost, aesthetics,
familiarity, etc.
The reason I saw a parallel to the common library discussions here is
because many js experts have a myopic view that since code quality is
most important to them, it should be the most important thing to
everyone. And they fail to understand or relate to the masses of
developers who choose the option that is "good enough".
> No, it isn't. Those who promote libraries, refuse to listen to valid
> criticism and don't see that they aren't "just fine" are the ones
> missing the point.
This always sounds to me like the professional photographer who can't
comprehend why anyone would choose not to buy an SLR with multiple
lenses and flashes for taking pictures. Clearly it results in higher-
quality photos. Clearly those who choose cheap point-and-shoot cameras
are missing the point! Don't they see the reduction in resolution? The
increase in noise? The desaturation in colors?! Why would they settle
for that?! They are missing the point!
While people may point out flaws, incompatibilities, or performance
problems with libraries, this need not be an argument for not using
them. Because when you factor in development time, convenience,
support, ease of learning, the number of problems that they _do_
solve, and resulting code quality as compared to what might have been
written otherwise, then they can often be seen as the clear winner.
While not perfect, certainly "good enough".
If that were not the case, then they certainly would have died out by
now. Argue all you want against it, but the "free market" of
technology seems to be going in the opposite direction.
Matt Kruse
Matt Kruse
> And certainly a "good enough" philosophy should be challenged at every
> opportunity. At the least, the goal should be the best quality
> possible within the project's constraints (where quality is judged on
> functional performance, not things like crappy UI effects).
Functional performance may be your judge of quality, but to someone
else UI effects may in fact be their measure of quality.
A typical barrier in these kinds of discussions, IMO, is that the
'experts' here don't seem to be able to imagine the world through
someone else's eyes and experience. Things look very different to
different people, and if they choose a different path it's not
necessarily because they are stupid or uninformed. Perhaps you just
can't see the world how they do and don't have to deal with the same
challenges, so you can't relate.
I am fascinated by "pop culture" and trying to understand the
"consensus" decisions that emerge from the swarm of people that all
act independently. Clearly, many javascript experts/purists have
strong arguments against libraries and point out their shortcomings.
Yet it seems like the majority of people out there writing javascript
have decided differently, and they are headed in the library
direction. I have no interest in persuading either side that the other
is correct. I am interested in understanding the merits of each view
so that I can better relate to the development environment that people
find themselves in, and I find myself in sometimes.
Understanding why people apparently choose an option that is of "lower
quality" than another available option can only make us better at what
we do. And as someone who works with many aspects of web technology
(not just js), I want to make sure I know where things are headed and
why. To use an analogy, I want to make sure I have a VHS deck and know
how to use it, even if I think Beta is obviously superior. In the end,
it may not matter what I think is best because it's the consensus of
the mob that will decide where things go. If you refuse to understand
or even acknowledge the advantages of the other way of doing things,
you may close yourself off to new ideas and opportunities. You may be
the guy who still trumpets the superiority of OS/2 and proclaims how
much Windows sucks and how stupid its users are, but finds himself
without a job ;)
Matt Kruse
Michael Wojcik
> On Aug 30, 9:54 am, Stefan Weiss <krewech...@gmail.com> wrote:
>> That's rich. How do you keep your pages (or applications) accessible, if
>> you require JavaScript?
>
> So, do you still buy -nowadays- that a web app should run 100% server-
> side, and serve just pure html and as few unobtrusive javascript as
> possible ?
Yes, many of them should. Client-side scripting often provides little
or no useful additional functionality. The most popular web
application, search, works just fine without client-side scripting.
> I'd bet you $10 that this (bs) isn't going to last for much longer...
What isn't going to last, and for how much longer? If you mean whether
web applications without client-side scripting will continue to be
useful for years to come, I'd take that bet.
People are always predicting the demise of this or that technology or
approach. They're nearly always wrong.
> A browser without javascript *enabled* is going to end up being as
> useful and desirable as a PC without an internet connection...
Almost 54 million downloads of NoScript say you're wrong.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Erik Reppen
> opportunity. At the least, the goal should be the best quality
> possible within the project's constraints (where quality is judged on
> functional performance, not things like crappy UI effects).
>
> --
> Rob
My experience is that I have not ended up writing JQuery instead of
JavaScript. It's a really fancy object that takes a lot of the time
and tedium out of the DOM API and uneven support for it. It gets heavy
use but not exclusive use. There's a kind of an absolutist philosophy
here on things. Yes, it uses browser sniffing for some things. I don't
know where yet, but I've read enough of Resig's stuff to trust he's a
good enough dev to avoid it when possible, but sometimes what we're
anticipating is more than just whether a given method or property
exists. How do you test for whether the box model is completely hosed,
for instance? There is more to the unique quirks of a browser that
could be relevant to a library than just the JavaScript methods and
properties supported and I'm a strong believer that coding for the web
requires a strong understanding of the relationship between the JS and
the other languages it's typically intermingled with. Too many would-
be JS rockstars don't know jack about CSS or the finer points of HTML
and their code suffers for it.
On your final point, I agree. I don't think I need to justify the use
of a library as a 'good enough' policy. If a library helps me do
better work in the time allotted, it doesn't murder performance, and
seems perfectly stable to me, I'm going to call that a major win, not
a compromise. There's nothing about extending the element object with
a whole bunch of methods using prototype in a way that doesn't
interfere with the core language that isn't JavaScript. That sort of
flexibility is one of the things that makes JS a beautiful language to
work with.
There is nothing we can do about people who don't want to learn the
craft properly. They are going to produce crappy code regardless of
whether they're pulling it from an ugly library, Dynamic Drive, .NET,
or writing 800-hose hosebeasts all by themselves. Bloat is inevitable
with standards as low as they are to people who don't know better and
good devs tend to eschew management in favor of continuing to actively
write code so that's not likely to improve. If the amateurs do
horrible things with JQuery, let them, or help them along however you
can. Just be happy that there's enough of them out there to keep
anybody with more than mediocre skills in demand. The more they fail,
the stronger arguments for doing it right become. And the more people
who belong there are relegated to Craigslist Computer Services section
offering web services 'any way u want it.'
Ivan Marsh
> I found this article interesting:
>
http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenough?currentPage=all
>
> And had a thought about javascript libraries like jQuery, et al.
>
> I believe this is the point that many library-users try to make that
> js "experts" seem to miss. jQuery (as the popular example) is "good
> enough". It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity. This is a
> trade that most js developers are willing to make.
>
> Although the js "purists" will always argue that libraries are _not_
> "good enough" because they are never perfect, this is the same
> argument that camera purists may make about cheap point-and-shoot
> cameras that do not have the quality of the more advances models. Or
> any purists in any field who argues against the "good enough"
> technology.
>
> But for most people, these purists are missing the point. "Good
> Enough" really is Just Fine.
The point being missed is that with JS all the code has to be downloaded to
the browser whether it's being used or not.
There is a major difference between a library used in a compiled language
and JS.
In this case I'd say "good enough" it what is being said by people that
don't understand the technology they're using and calling people "purists"
as if it's a cult and not professional programmers with a solid grasp of
overhead and bandwitch concerns.
--
"All right, all right, if it will make you happy, I will overthrow society."
- Philip J. Fry
Ivan Marsh
> On Aug 30, 7:30 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>> I found this article
>>
interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
>
> I don't think "good enough" is a revolution, the concept has been
> around ever since humans have been selling products. It's one of the
> reasons Windows killed OS/2.
IBM killed OS/2. Windows had little to do with it.
Richard Cornford
>I found this article interesting:
> http://www.wired.com/gadgets/miscellaneous/magazine/17-
>
> And had a thought about javascript libraries like jQuery, et al.
>
> I believe this is the point that many library-users try to make
> that js "experts" seem to miss.
Are you using the disingenuous characterisation of "experts" (and later
"purists") because if you named names you might be hard pressed to cite
statements of theirs that support your generalisations?
You have often enough made the point yourself that 'popular' libraries
allow people with little or no understanding or knowledge of browser
scripting or javascript to achieve (at least superficially) 'flashy'
results in exchange for very little effort. That is self-evidently true
(and has been true for the entire history of browser scripting (with
something or other standing in the place of "popular library").
A consequence of this simple truth is that there are (very) large number
of people doing a job (and seemingly producing viable product) who have
little or no understanding or knowledge of browser scripting or
javascript. Which isn't to say that the 'popular' libraries are
responsible for this situation, rather they have become the tools that
make its continuation practical; web developers being employed to
perform tasks for which they are nowhere near qualified could (and
certainly has) happened independently.
However, judging something to be "good enough" is a (software, in
context) design decision. It is a decision that should be made on a
(well) informed basis and encompass a consideration of alternatives and
their consequences. So, if the judgement applied turns out to be "it is
good enough because it 'works'[1] and I don't know any other way of
achieving it", then you have something that is "good enough", in the
judgement of its creator. On the other hand, if the design question is
"does this best maximise the potential for the outcome to satisfy the
desired goals of the client (the person paying for it), given the
applicable practical contracts (money, time, etc.)?" then the developer
who cannot even perceive alternatives cannot answer that question;
cannot make an informed design decision. An outcome being judged "good
enough" is not that informative without some knowledge of who is making
that decision, and what criteria are being applied in making that
judgment. If you know that the 'popular library' effect is going to be
to allow ever more of the unqualified/under-qualified into decision
making positions then you have to expect that the decisions made will be
increasingly poor.
[1] This would be 'works'given (usually) minimal testing (simple and
predictable sets of expected actions, performed on expected/'correct'
data) in a limited set of browsers, usually in there default
configurations, with 'default' plug-ins installed and enabled, on a
limited set of OSs, with a single form of client-server
communication/configuration, etc, etc. Observe, for example, that
(disregarding the quality of the advice/answers actually given there)
more than 25% of questions asked on the JQuery Google group/mailing list
(<URL: http://groups.google.com/group/jquery-en >) receive no response
at all. This is a 'community' that considers itself helpful and
friendly, but clearly is very limited in its capabilities, to the extent
that a quarter of the things that people are interested in doing with
JQuery result in unanswerable questions.
> jQuery (as the popular example) is "good enough".
But "good enough" for what (or, perhaps, who)?
> It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity.
That latter is a list of very subjective terms. I would not accept any
of them as accurate absolute labels for JQuery, and if they are supposed
to be relative to something else then it is necessary to see what that
something else is.
> This is a trade that most js developers are willing to
> make.
So that would be "good enough" for "most js developers". But aren't
"most" js developers more or less completely inept? After all you need
do no more than set IE's error dialog to pop-up each time an unhanded
exception is thrown and then browse the Internet for half a day to
observe that a significant proportion of web site's scripts continuously
spit out errors; implying a worst case of developers who not only don't
understand what their own cod does, but aren't bothering to test it
(more than very superficially). Under those circumstances, what "most"
js developers are willing to do is not a lesson in good practices.
> Although the js "purists" will always argue that libraries
> are _not_ "good enough" because they are never perfect,
When has anyone (here) ever argued that? Nobody (rational) would take
such a position seriously ("perfect" being far too subjective to be
employed usefully in such an argument).
There have been many criticisms of the various 'popular' libraries here
over the years, ranging from questions of (overall and API)
architecture/design, through the 'cross-browser' techniques employed, to
details of javascript language use (or misuse). But the validity of
those comments is best answered by observing the ways in which the
libraries have changed (and are changing), which is usually from a state
of arrogant denial towards an acceptance of the validity of the
criticism accompanied by substantial re-writing of their code.
> this is the same argument that camera purists may make
> about cheap point-and-shoot cameras that do not have the
> quality of the more advances models.
Do camera purists argue that, and what would "quality" mean in that
context? Is 'quality' going to be build quality, picture quality (say,
pixel resolution), lenses quality, or some amalgamation of those and
other factors?
What you sacrifice with point-and-shoot is control over the image that
will be created. Factors such as aperture width (the 'F stops') leave
the (absolute) control of the operator. Adjusting the aperture width
influences depth of focus (the range before and after the point where
the camper's lanes is focused in which objects will be in focus), which
can be exploited in the composition of a photographic image.
Most people are not interested in "the composition of a photographic
image" (at least beyond perhaps checking that they are not giving the
impression that someone has a tree growing out of their head), but are
instead interested in creating a visual record of "this happened", and
so don't have any interest in (or time for) worrying about aperture
widths and the like. The "good enough" question is not answered until
you know what this thing is supposed to be "good enough" for.
> Or any purists in any field who argues against the
> "good enough" technology.
>
> But for most people, these purists are missing the point.
> "Good Enough" really is Just Fine.
Isn't that closer to, for most people "good enough" for their purposes
is not the same thing as "good enough" for the purposes of the people
you are trying to categorise as "purists"? That in the end the judgment
means nothing without context.
Richard.
Richard Cornford
> RobG wrote:
>> The argument against libraries is not just related to javascript,
>> but is of general interest for most programming languages. The
>> site I am working at has developed a number of VB applications
>> over the years using MS development tools. Recently, they have
>> been forced to upgrade certain parts of their technology stack,
>> and now half of those VB programs must be re-written because
>> the current libraries don't support things that were use in
>> previous versions.
>>
>> So while at the time they might have been seen as "good enough",
>> they certainly aren't now.
>
There isn't a general argument against libraries, not least because
'library' is too imprecise a term. Any collection of source code (and/or
source code fragments) might validly be labelled a "library", and so
only the (hypothetical loonies) who write every single character of
every line of code they create at the point of entering it don't already
use something that could be considered a library in one sense or
another.
<snip>
> I'm new to this newsgroup so I've been trying to read up on
> past debates and I keep seeing this recurring idea that a good
> library should somehow anticipate the quirks of a new browser.
No you don't. You will have seen the proposition that well designed code
does not fall over when it encounters the lack of quirks in a new
browser. That is, given that the manufacturer of any new browser is
trying to get it to behave in accordance with the behaviour of
pre-existing browsers (else it would look broken form day one), code
should not be failing due to its failure to identify (or correctly
identify) a browser that did not exist at the time of its authoring.
This is the 'feature detection' verses 'browser detection' argument.
You may also have seen propositions that certain approaches to the
architecture of javascript code (frameworks. 'libraries', etc) can
significantly mitigate the impact of any new 'quirks' that new browsers
may introduce.
But when you try to "read up" on past debates the success/usefulness of
that process will depend quite a lot on where (or rather when) you set
about looking for those debates. You have to bear in mind that there is
quite a lag in 'information distribution', with many of the subjects
that might be called 'of the day' in wider context, having played-out in
discussion on this group so long ago that there is really nothing more
that could be added, and reiteration be too dull for many to be
interested at all.
The 'feature detection' verses 'browser detection' debate illustrates
this. The actual debate happened here around the turn of the century,
and had pretty much played-out by the begging of 2003 (that is, the
theoretical 'this is better than that' had had its rationale and
reasoning examined, had been empirically tested, feature detection
applied in practice, and the hows and whys of the techniques/principles
employed discussed (more or less) formalised and pinned down.). So when
2008-2009 sees the authors of JQuery and Prototype.js finally seeing the
light and attempting to replace their browser detection with feature
detection we are witnessing contemporary script development (at least)
half a decade out of touch with what might be described as the 'cutting
edge' (at least if it wasn't such old news here that 'cutting edge'
starts to sound bizarre).
That outcomes was inevitable (as the libraries that are currently
sticking with browser detection will eventually illustrate) because the
logic of feature detection was sound, and could be widely applied in
practice, it is just a pity that the high level of script authoring
background noise made seeing the light takes so long.
My recollection has the best code architecture for optimised
re-use/flexibility (library design) debates here happening between 2003
and 2005. The conclusions are not as well defined as they were with
feature detection (too much diversion in personal styles and opinions)
but the issues are there, along with viable strategies for addressing
them.
It was entertaining to read one of the threads on the JQuery development
group last week where it is clear that some of the JQuery developers are
finally starting to perceive some of the issues that come with the
JQuery architecture for what they are. Give then another two years to
account for the rest of half-decade lag and they might have realised how
much better things could have been designed from the outset.
Unfortunately, bad architecture in a general-purpose library is
extremely difficult to fix at all, let alone in a way that is
back-compatible, so here seeing the light may not result in change for
the better.
<snip>
> Let's imagine I did write my own custom library with nothing
> but exactly what we needed for the team of 23 front end
> developers I work with and it was even a good 20% faster than
> JQ by some meaningless standard.
If you write an application specific framework, and do it properly, 20%
faster is a very log way short of what you could achieve.
> Odds are perfectly reasonable I'm not going to be at that
> company when IE 9 rolls around.
Your point being? I have written an application specific framework, and
at 200,000-odd lines of code not a small one. The total number of lines
of code that needed changing when IE 7 come out was zero, and zero again
when IE 8 came out, and zero for Chrome, and zero for Firefox 3.5, and
so on. What makes you think well written/designed scripts are going to
have problems with IE 9?
> What's better for the team, my code, or a popular framework
> supported by a crew who will be anticipating changes that
> need to be made from the first day the beta of IE 9 is made
> available.
The best outcome in those circumstances is going to be to perform a full
set of regression testing with IE 9, find that nothing needs changing
and then get on with their current work (and with a proper QA department
it would not be the developers doing that testing, so pretty easy for
them). A pretty bad outcome would be to be forced to use a library
upgrade that was not entirely back-compatible with the version currently
in use, implying a certain amount of re-writing, and possibly multiple
rounds of re-testing, followed by a rapid sequence of 'bug-fix' releases
of that library which, even if they are fully back-compatible with IE 9
release, imply another round of re-testing with each 'bug-fix' version.
Now look at JQuery; 1.3 was not back-compatible, and versions 1.3.1,
1.3.2 and 1.3.3 followed in very rapid succession in order to fix bugs
introduced in 1.3. If people have been keeping up, and applying proper
QA practices (which, realistically, is very rare in web development)
then without anything other than the impact of JQuery they have done 4
full rounds of regression testing on their applications already this
year (plus whatever re-writing followed from the non-back-compatible
aspects of the 1.3 releases).
> Also, I think the fact that we have to write for a number of
> conflicting interpretations of the very language we're writing
> with
What? You write to the ECMA spec and avoid things like named function
expressions and arguments/parameters linkage (the very few known issues
in implementations) and the result is one language that behaves the same
everywhere, so one code fits all.
Now people certainly do attempt to use implementation specific language
features (such as the 'getters' and 'setters' available in
JavaScript(tm)), but that is not necessary, and just acts to introduce
compatibility headaches that can be completely avoided by something as
simple as not using them.
> and the object models it follows, makes the library question
> a very different one where JS is concerned.
Browser object models always have varied, but current trends suggest
that large parts of those object models are converging. It is an under
appreciated fact that Firefox has more non-standard features in its
object model that any other browser that has ever existed, while still
exhibiting the most comprehensive implementation of the existing
standards. Even if/when everyone correctly and fully implements all the
existing/proposed standards there will still be considerable variation
between browser object models. That is the reality of browser scripting;
learn to live with it, others have and it is not going to change.
Richard.
RobG
wrote:
> Pherdnut wrote:
> > RobG wrote:
> >> The argument against libraries is not just related to javascript,
> >> but is of general interest for most programming languages. The
> >> site I am working at has developed a number of VB applications
> >> over the years using MS development tools. Recently, they have
> >> been forced to upgrade certain parts of their technology stack,
> >> and now half of those VB programs must be re-written because
> >> the current libraries don't support things that were use in
> >> previous versions.
>
> >> So while at the time they might have been seen as "good enough",
> >> they certainly aren't now.
>
> > What is the general argument against libraries?
>
> There isn't a general argument against libraries, not least because
> 'library' is too imprecise a term. Any collection of source code (and/or
> source code fragments) might validly be labelled a "library", and so
> only the (hypothetical loonies) who write every single character of
> every line of code they create at the point of entering it don't already
> use something that could be considered a library in one sense or
> another.
Yes, I was trying to point out that there are downsides to 3rd party
libraries in that they can force upgrades and re-work for no other
reason than a new version is not backward compatible with a previous
version.
--
Rob
RobG
> On Aug 31, 2:18 am, RobG <robg...@gmail.com> wrote:
>
> > And certainly a "good enough" philosophy should be challenged at every
> > opportunity. At the least, the goal should be the best quality
> > possible within the project's constraints (where quality is judged on
> > functional performance, not things like crappy UI effects).
>
> Functional performance may be your judge of quality, but to someone
> else UI effects may in fact be their measure of quality.
>
> A typical barrier in these kinds of discussions, IMO, is that the
> 'experts' here don't seem to be able to imagine the world through
> someone else's eyes and experience.
I am not, nor have ever professed to be, an expert on javascript.
People engaged in a discussion shouldn't be instantly categorised as
stridently for or against a particular proposition just because they
offer a point of view.
> Things look very different to
> different people, and if they choose a different path it's not
> necessarily because they are stupid or uninformed.
Did I say that people are stupid or uninformed because they use a
library? No, not ever.
> Perhaps you just
> can't see the world how they do and don't have to deal with the same
> challenges, so you can't relate.
You like pigeon-holing people. Of course I can see the benefits of
libraries, I've even pointed people to them when I think it's
appropriate, but there are arguments for and against. I also get very
tired of arguments that something can't be done because of poor
technology choices, or refusal to admit to weaknesses in a development
strategy. 3rd party libraries have downsides, if you want to be seen
as credible, present both sides of the argument.
> I am fascinated by "pop culture" and trying to understand the
> "consensus" decisions that emerge from the swarm of people that all
> act independently. Clearly, many javascript experts/purists have
> strong arguments against libraries and point out their shortcomings.
The fact that "experts/purists" point out the shortcomings of
particular libraries doesn't mean they are fundamentally opposed to
libraries. It should be seen as constructive criticism.
Let's name names. David Mark has been strident in his criticism of
jQuery (and other libraries), yet published his own library (as an
exercise to show aspects of library development) and has apparently
decided to assist in the development of Dojo. Is he one of the
"experts/purists" you're referring to?
Richard Cornford has consistently argued that most 3rd party libraries
are poor quality, yet supports the development of code libraries for
re-use.
Garrett Smith has published his APE library.
So get the chip off your shoulder, accept criticism and move on.
> Yet it seems like the majority of people out there writing javascript
> have decided differently, and they are headed in the library
> direction.
Terrific. And they will never be in a position to determine whether
their library of choice is any good or not because they lack the
skills to find out. By the time they do, they've published bucket
loads of library-specific code that can only be salvaged by a re-
write. Great for developers, but take the client's perspective for a
moment.
If this discussion does nothing more than make one person more
thoroughly investigate their choice of js library to the extent that
they can present a balanced case for and against it, then it has been
worth it.
> I have no interest in persuading either side that the other
> is correct.
Then why post a link to an article about "good enough" development and
use it to support the use of a particular library? Seems like an
argument for mediocrity.
[...]
> You may be
> the guy who still trumpets the superiority of OS/2 and proclaims how
> much Windows sucks and how stupid its users are, but finds himself
> without a job ;)
Good grief, more verballing. Windows vs OS/2 was just an example of an
IT "good enough" story that predated the article you linked to. I am
certainly not, never have been, nor ever will be, an evangelist for OS/
2.
--
Rob
Erik Reppen
> Browser object models always have varied, but current trends suggest
> that large parts of those object models are converging. It is an under
> appreciated fact that Firefox has more non-standard features in its
> object model that any other browser that has ever existed, while still
> exhibiting the most comprehensive implementation of the existing
> standards. Even if/when everyone correctly and fully implements all the
> existing/proposed standards there will still be considerable variation
> between browser object models. That is the reality of browser scripting;
> learn to live with it, others have and it is not going to change.
>
> Richard.
So you 'won' this argument in 2003 but the rest of us are just too
slow to pick up on it. With all due respect, I'm sure everybody here
could teach me a few things I don't know, but it's 2009 and that's
just a little bit silly and perhaps a touch pompous. I don't believe
anybody was doing anything advanced enough with the DOM before IE 7
came out for varying layout or positioning discrepancies and other
concerns to ever be a real issue for your code. I defer to your
achievement given the browsers you worked around at the time because I
certainly don't miss IE 5, and was never blessed with having to deal
with IE 4 but I can't help but wonder if you have a realistic basis
for judging the merits of a modern framework.
There are concerns here other than whether a framework ever has bugs.
That's great that your code never does, but how does it help me if it
doesn't do anything for me that I wasn't already doing for myself.
Yes, I was quite capable of dealing with crossbrowser issues in
regards to the DOM before I ever touched a framework. I know where to
find quirksmode and I've read plenty of Crockford's stuff. But at the
end of the day, it's Dean Edwards' work that I'm really intrigued by
and I'm not sure I would expect any of you guys to understand why at
this point.
jeanph01
to help in the community that I don't see why I would not use it. Ok I
don't program for the IPhone or blackberry or whatever. My clients
have powerful workstations with plenty of bandwidth, lots of Ram but
also with IE6 (ouch!). When I include the library and plugins, I get a
lot of things I will never need or use. So what ? My job is done, i
deliver, and I don't care to continue to work or think about my code
when I go to bed. I love what I do and I like what I create. Am I a
guru in js ? Not at all. So what ? I have fun and I think, this is the
most important thing. And for me Jquery is not good enough, it's the
best choice. My user base like what I do, even if they do have that 50
ms response time that some better programmer could give them.
Garrett Smith
You know, I've gotten that attitude from other jQuery developers. I've
been asked: "Which library do you use?" I've also been told "We are
using jQuery." And when I reply: "For what/What are you trying to do?"
This is the type of answer that is the most insulting to the religious
fanatic. IT's like, not only do I not follow their sect, I don't even
believe in the fundamentalist ideas.
JQuery is promoted as "magic". I think it invites cult-like following.
Of course I can see the benefits of
> libraries, I've even pointed people to them when I think it's
> appropriate, but there are arguments for and against. I also get very
> tired of arguments that something can't be done because of poor
> technology choices, or refusal to admit to weaknesses in a development
> strategy. 3rd party libraries have downsides, if you want to be seen
> as credible, present both sides of the argument.
>
>
>> I am fascinated by "pop culture" and trying to understand the
jQuery is an abstract set of ideas, values, or experiences developed as
part of a cultural matrix.
(comes right from Wikipedia's "Religion" page).
>> "consensus" decisions that emerge from the swarm of people that all
>> act independently. Clearly, many javascript experts/purists have
>> strong arguments against libraries and point out their shortcomings.
>
> The fact that "experts/purists" point out the shortcomings of
> particular libraries doesn't mean they are fundamentally opposed to
> libraries. It should be seen as constructive criticism.
>
> Let's name names. David Mark has been strident in his criticism of
> jQuery (and other libraries), yet published his own library (as an
> exercise to show aspects of library development) and has apparently
> decided to assist in the development of Dojo.
Good place for him :-).
Is he one of the
> "experts/purists" you're referring to?
>
> Richard Cornford has consistently argued that most 3rd party libraries
> are poor quality, yet supports the development of code libraries for
> re-use.
>
> Garrett Smith has published his APE library.
>
Thanks, but that does not make me an expert.
(AFL 3.0 is not suitable for commercial use)
The social aspect of Github is great. For example, anyone with an
account can leave criticism for "commits" where it says "comment".
Coincidentally, Github is using jQuery and very slow, have you noticed?
In a recent thread on the "Github" google group, a user reported "slow
script" dialog box in Safari 3. The Github support suggested that a user
upgrade from Safari 3 to Safari 4 because Safari 4 is faster. While that
may be true, I do not accept that Safari 3 is not fast enough.
So, Github answered Richard's "good enough for what" question. jquery is
not good enough for Safari 3.
Thomas 'PointedEars' Lahn
> For me, Jquery is great. Period. There is so much passion and desire
Blind leading the blind, that's why. You missed or deliberately ignore the
"25% not answered" part in Richard's posting as well. And you did not quote
any of which what you are replying to. You are a loser finding lame excuses
for your incompetence while blinding yourself to the facts at hand, in the
hope nobody will notice. Like a kid playing "if I can't see them, they
can't see me." Only this time the repercussions of your decisions, and
ultimately and inescapably, your mistakes, affect the lives of a great many
other people. But you don't care about them, do you? Your job is "done"
(it is not) and you have "delivered" (you have not).
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Bart Lateur
>Coincidentally, Github is using jQuery and very slow, have you noticed?
>In a recent thread on the "Github" google group, a user reported "slow
>script" dialog box in Safari 3. The Github support suggested that a user
>upgrade from Safari 3 to Safari 4 because Safari 4 is faster. While that
>may be true, I do not accept that Safari 3 is not fast enough.
Does Reddit (http://reddit.com) use jQuery? Ah, yeah, apparently it
does.
Occasionally I use an ancient PC to browse the web (600MHz, 256MB RAM),
on reddit.com I consistently get warnings that some Javascript is taking
forever... 3 times on every page load.
It's about the only website where I have this kind of problem.
--
Bart.
Gregor Kofler
> I don't believe
> anybody was doing anything advanced enough with the DOM before IE 7
> came out for varying layout or positioning discrepancies and other
> concerns to ever be a real issue for your code.
jQuery was first published in February 2006, IE 7 appeared in October
2006. Go figure.
A - if not _the_ - goal of jQuery is and was to even out the various
pecularities of browsers (or rather browser DOMs). Perhaps it would be a
smart thing to think about intelligent "browser detection" then. And
browser sniffing is not an intelligent way to do so. As it was proven in
2003, 3 yrs before jQuery saw the light of day.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Gregor Kofler
> When I include the library and plugins, I get a
> lot of things I will never need or use. So what ? My job is done, i
> deliver, and I don't care to continue to work or think about my code
> when I go to bed.
You forgot: We are talking about a *professional* attitude towards
client side scripting (and our work) here.
jeanph01
I'm professionnal but what you consider important for your code is
maybe not important for my user.
Gregor Kofler
Professional in a way, that you make money with that.
Please don't quote signatures.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Andy Dingley
> But for most people, these purists are missing the point. "Good
> Enough" really is Just Fine.
What does "Good Enough" mean? In terms of features, then yes. The
article you cite is about simple cameras with limited capabilities,
not badly made cameras that break. It doesn't many any reduction in
product quality, where quality is measured as "ability to do what it
ought" rather than "how much it claims to do".
"Just Good Enough" is indeed making a (maybe minor) revolution in
software. Agile approaches, Scrum and LEAN in particular, are moving
this way. It's driven by finally making a comparison between the well-
known observations that "engineering for the future" has a benefit,
but also that a great many features implented (at cost) are never used
in practice, the surprising outcome being that the wasted features do
indeed outweigh the cost of re-engineering when it turns out to be
necessary.
What "Just Good Enough" doesn't do is to compromise _quality_. In
Scrum terms, don't cook up a squirrelburger (search for it). Your
"Just Good Enough" library needs to keep itself simple and not attempt
things that aren't needed, but that's no excuse to permit memory leaks
and the like.
jeanph01
detection instead of feature detection. And that he find that this is
bad because somewhere some people found that feature detection was the
way to go. But JQ use feature detection a lot, so... He says that JQ
1.3.x is not backward compatible with previous version but there is
numerous thread talking about the painless migration to JQ new
version, so... He's talking about his library that had no problem with
ie8... fine... good for him... now lets make it open source and see
how it behave on every client that JQ is supporting. Is he willing to
submit it to the test swarm (testswarm.com)? He's talking about
performance. But JQ has not been created to be faster than core JS. I
think that it's also one of the slowest lib out there. But like I
said, the programmer that is using it can deliver code fast, he can
benefit from the help of the community and not be bashed out for not
being that elitist religious coding guru that knows it all. And like
I said for the iphone or the blackberry, JQ is not your tool, at least
for now, that's it. Take a look at this stat :
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
With 0.58% to the "other" share, there is not that many blackberry out
there. Finally, programming to the browser is a pain in the s, JQ help
alleviate that pain. I can still use document.getElementsByTagName but
I find $('tag') less burdensome .
And for the rest of your really gentle comment, well, have a nice
day !
> -- Richard Cornford, cljs, <f806at$ail$1$8300d...@news.demon.co.uk>
David Mark
You bet! Imagine you'll be around as soon as you stop aping my last
project.
David Mark
> For me, Jquery is great. Period. There is so much passion and desire
> to help in the community that I don't see why I would not use it.
So you are charitable with your development time? They likely want to
help really badly, but...
> Ok I
> don't program for the IPhone or blackberry or whatever.
You typically don't program for any specific device(s). Of course, if
you use jQuery, you pretty much exclude devices such as these (unless
you want to really irritate your mobile users).
> My clients
> have powerful workstations with plenty of bandwidth, lots of Ram but
> also with IE6 (ouch!).
There's your biggest reason not to use it. That's the worst one for
them (just ask them!)
> When I include the library and plugins, I get a
> lot of things I will never need or use.
And pass those along to users who don't need or want them, leading to
a bogged down browsing experience.
> So what ? My job is done, i
> deliver, and I don't care to continue to work or think about my code
> when I go to bed.
Nothing further. :)
[...]
David Mark
> Erik Reppen meinte:
>
> > I don't believe
> > anybody was doing anything advanced enough with the DOM before IE 7
> > came out for varying layout or positioning discrepancies and other
> > concerns to ever be a real issue for your code.
>
> jQuery was first published in February 2006, IE 7 appeared in October
> 2006. Go figure.
>
> A - if not _the_ - goal of jQuery is and was to even out the various
> pecularities of browsers (or rather browser DOMs). Perhaps it would be a
> smart thing to think about intelligent "browser detection" then. And
> browser sniffing is not an intelligent way to do so. As it was proven in
> 2003, 3 yrs before jQuery saw the light of day.
And six years before they saw the light. ;)
David Mark
> For what I see the argument of Richard is Jquery is using browser
> detection instead of feature detection.
That's part of it.
> And that he find that this is
> bad because somewhere some people found that feature detection was the
> way to go.
Anyone paying attention for the last decade or so.
> But JQ use feature detection a lot, so... He says that JQ
No, it really doesn't. It thinks it does, but...
> 1.3.x is not backward compatible with previous version but there is
> numerous thread talking about the painless migration to JQ new
> version, so...
People talk about lots of things. Take this thread...
> He's talking about his library that had no problem with
> ie8... fine... good for him... now lets make it open source and see
> how it behave on every client that JQ is supporting.
It's been done (publicly) by others. Do some research...
> Is he willing to
> submit it to the test swarm (testswarm.com)?
LOL. Search the archive for that.
> He's talking about
> performance. But JQ has not been created to be faster than core JS.
It's not faster than anything from what I have seen. Certainly it's
much slower than its peers. Google for "TaskSpeed".
> I
> think that it's also one of the slowest lib out there.
Oh, so you know.
> But like I
> said, the programmer that is using it can deliver code fast, he can
> benefit from the help of the community and not be bashed out for not
> being that elitist religious coding guru that knows it all.
He can deliver code that doesn't work fast? And see the previous
comments about the community. Religion doesn't enter into any of
this.
> And like
> I said for the iphone or the blackberry, JQ is not your tool, at least
> for now, that's it.
Of course, Web pages are browsed with these devices, so...
> Take a look at this stat :http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
> With 0.58% to the "other" share, there is not that many blackberry out
> there.
Statistics like that are virtually worthless. Many agents imitate IE.
> Finally, programming to the browser is a pain in the s, JQ help
> alleviate that pain.
No, it really doesn't. It provides that illusion for the uninitiated
(typically those who see cross-browser scripting as impossible to
begin with).
> I can still use document.getElementsByTagName but
> I find $('tag') less burdensome .
That's a terrible strategy. The former is almost bullet-proof (avoid
"*" of course). The latter is a mysterious black box.
>
> And for the rest of your really gentle comment, well, have a nice
> day !
And yes, people were getting around quirks mode (and other IE issues)
long before jQuery came out. Same for ActiveX, attributes, opacity,
etc. That project really did botch everything for the first few years
and there is no reasonable explanation given that the script came out
6 years after IE6. That's 6 *years* and then another three to argue
about it and finally, a decade later... very little progress. And IE
is the biggest problem you have, so who do you want to solve it for
you?
[...]
Bruno Desthuilliers
> On 30/08/09 00:33, Jorge wrote:
(snip)
>> There are many people here in cljs still worried that javascript might
>> be disabled. That just proves that they're still living in the past,
>> when pages were just pages and not (web) applications.
>
> That's rich. How do you keep your pages (or applications) accessible, if
> handicapped visitors is not an optional feature. I'm not sure how that's
> handled in Spain, but if I remember correctly, there's even an EU
> regulation about this for publically funded sites (correct me if I'm
> wrong).
Nope, you're right. And FWIW, accessibilty would also be one of my first
concerns for a e-commerce website - people with certain disabilities
tend to do their shopping online whenever possible.
> If ignoring people with screen readers is the future, then I'll
> keep living in the past, as you say. Maybe I'll even set up a Gopher
> server to prove my point ;)
Lol. But yes, it's always good (and not necessarily that hard) to design
your web apps so they first work without javascript. I sometimes have to
work in text-mode only (oops, system update failed, no more
X-server...), and that's when you really start understanding what
accessibility is about.
Gregor Kofler
[snip]
> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
[IE6 25+% & the most popular browser]
Now this one:
http://gs.statcounter.com/
August:
IE6 < 18%; rank 3
but I have customers mainly in Europe, one says...
IE6 approx. 8.5%...
IOW: Forget those statistics. BTW they use browser-sniffing for those
statistics. Shows how reliable that works.
> And for the rest of your really gentle comment, well, have a nice
> day !
Same to you for such nice top-postings.
Thomas 'PointedEars' Lahn
> jeanph01 meinte:
>> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
>
> [IE6 25+% & the most popular browser]
>
> Now this one:
> http://gs.statcounter.com/
>
> August:
> IE6 < 18%; rank 3
> but I have customers mainly in Europe, one says...
> IE6 approx. 8.5%...
>
> IOW: Forget those statistics. BTW they use browser-sniffing for those
> statistics. Shows how reliable that works.
I think Net Application's figures are more realistic than others, though,
based on their statements: <http://marketshare.hitslink.com/>, "About Our
Market Share Statistics"
(And hey, 23% for Gecko-based UAs world-wide is really not bad!)
However, even if they showed IE (which is probably mostly MSHTML-based
browsers) to have 90% or more, that would not mean anything. In commercial
terms, even 10% spending visitors can generate more profit than 90% which
just look around and leave without spending.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Peter Michaux
> I found this article interesting:http://www.wired.com/gadgets/miscellaneous/magazine/17-09/ff_goodenou...
>
> And had a thought about javascript libraries like jQuery, et al.
>
> I believe this is the point that many library-users try to make that
> enough". It trades power, perhaps some speed, and certainly some
> compatibility for flexibility, convenience, and simplicity. This is a
> trade that most js developers are willing to make.
>
> argument that camera purists may make about cheap point-and-shoot
> any purists in any field who argues against the "good enough"
> technology.
>
> Enough" really is Just Fine.
Yes. Many people like to get on with things and finish projects so
good enough libraries are fine for them.
I think this post discounts the roles the purists play. Without the
purists who have criticized these "good enough" libraries with
behavior ranging from respectful criticism to hissy fits, these
libraries would still be "barely good enough." (Yes some would argue
they still are barely good enough or not good enough at all.) As much
as I would like to live in a civilized world with rational people, the
hissy fits may have had the most impact. Not long ago (~2 years) John
Resig was giving a Google tech talk where he was saying things like
"trust me, browser sniffing is fine." Had people only said "excuse me
John, there are better ways but what you're doing sort of works," do
you think jQuery would have removed as much sniffing as it apparently
has? He seemed to need a brick to the head on this issue. Why he
didn't see the value in feature testing articles on the web,
particularly by Richard Cornford, boggles my mind. What is sad is that
it is not even a big deal to write a base JavaScript library that does
all the main things people want and avoids worst practices like user-
agent sniffing. It has been understood for a long time. A couple
thousand lines of code is probably all that is required. With basic
browser scripting it is possible to have the functionality of these
good enough libraries *and* have them well written technically.
Peter
Bart Lateur
>> I can still use document.getElementsByTagName but
>> I find $('tag') less burdensome .
>
>That's a terrible strategy. The former is almost bullet-proof (avoid
>"*" of course). The latter is a mysterious black box.
Uh, what?? $() is intended as a shortcut for document.getElementById...
IMHO.
WTF. $(tag) works too. *shudder*.
This is terrible design. What if I have an id that is also usable as a
html tag? How will it know which one to return, the element with that
id, or all those tags?
--
Bart.
Gregor Kofler
> Gregor Kofler wrote:
>> jeanph01 meinte:
>>> http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0.
>> [IE6 25+% & the most popular browser]
>>
>> Now this one:
>> http://gs.statcounter.com/
>>
>> August:
>> IE6 < 18%; rank 3
>> but I have customers mainly in Europe, one says...
>> IE6 approx. 8.5%...
>>
>> IOW: Forget those statistics. BTW they use browser-sniffing for those
>> statistics. Shows how reliable that works.
>
> I think Net Application's figures are more realistic than others, though,
> based on their statements: <http://marketshare.hitslink.com/>, "About Our
> Market Share Statistics"
Yes, that's what they claim, and what is widely believed. (And their
methodology *sounds* pretty "sophisticatd".) However, those statistics
suffer from the same shortcomings as browser-sniffing libraries...
> (And hey, 23% for Gecko-based UAs world-wide is really not bad!)
Hey, *this* is web developer's heaven:
http://gs.statcounter.com/#browser-an-monthly-200808-200909
And this one (if it might be somewhat off) comes close:
http://gs.statcounter.com/#browser-DE-monthly-200808-200909
> However, even if they showed IE (which is probably mostly MSHTML-based
> browsers) to have 90% or more, that would not mean anything. In commercial
> terms, even 10% spending visitors can generate more profit than 90% which
> just look around and leave without spending.
Could be wealthy Apple users, who might run any browser except IE. ;-)
Jonathan
$() is only a shortcut for gEBId in prototype.js, in jQuery it's a
shortcut to their CSS selector engine (sizzle i believe)
So an ID would use $('#id') vs $('div') for a tag
kangax
Not quite.
In Prototype.js, `$` does a "little more" than just delegate to
`document.getElementById`. First of all, `$` is a variadic function.
This is rather unfortunate, since mere occurrence of `arguments` usually
prevents some of the optimizations in modern implementations. These
optimizations might not look significant but this is a very low-level
function we are talking about. Function that has to be as fast as
possible. If not for god damn backwards compatibility, we would remove
that wart long time ago. Nobody seems to use these days anyway.
Another thing `$` does (and is, in fact, another wart) is directly
extending an element with some of the Prototype specific methods. One of
the implications of doing so is rather noticeable performance hit in
clients that don't support host objects' prototypes' extensions.
--
kangax
Thomas 'PointedEars' Lahn
> What if I have an id that is also usable as a html tag?
Given that an HTML tag has the form `<...>', what you describe is not going
to happen.
<http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Richard Cornford
> <snip>
>> Browser object models always have varied, but current trends
>> suggest that large parts of those object models are converging.
>> It is an under appreciated fact that Firefox has more
>> non-standard features in its object model that any other
>> browser that has ever existed, while still exhibiting the
>> most comprehensive implementation of the existing standards.
>> Even if/when everyone correctly and fully implements all the
>> existing/proposed standards there will still be considerable
>> variation between browser object models. That is the reality
>> of browser scripting; learn to live with it, others have and
>> it is not going to change.
> So you 'won' this argument in 2003
No, as I said, the argument was happening around the turn of the century
(which was prior to my having anything to do with javascript). 2003 was
about when the process of working out how the theory should be applied
in practice came to an end. I did take part in that latter stage.
> but the rest of us are just too slow to pick up on it.
Possibly too slow, or too lazy, or too influenced by poor advice or poor
information, or just unable to see the information through the noise, or
any of any number of other reasons/excuses. It doesn't really matter why
it takes so long for people to see how very superior feature detection
is to the alternatives, only that given enough experience (and wit) they
do eventually see it. Prototype.js and JQuery haven't been switching
from browser sniffing to feature detection in order to impress me, they
have been doing it because it is the right thing to do in the context
browser scripting. It is just a pity that neither group managed to see
that before they wrote the initial browser sniffing versions of there
libraries (thus avoiding the need for change it later, and the back
compatibility issues that come with that), given that feature detection
was we well understood and out in the public domain well before they
started.
> With all due respect, I'm sure everybody here could teach me
> a few things I don't know, but it's 2009 and that's
> just a little bit silly and perhaps a touch pompous.
What? The suggestion that everything anyone needed to know in order to
avoid going off down the browser sniffing dead end was well know long
before numerous 'popular' libraries set off in that direction?
And what has its being 2009 got to do with anything? In browser
scripting terms the main difference between 2009 and 2003 is that the
number of browsers in common use has markedly increased and the rate of
new/updated browser releases has increased.
> I don't believe anybody was doing anything advanced enough
> with the DOM before IE 7 came out
LOL, that makes your "teach me a few things" look like quite an
understatement. Still, would you like to expand on what it is exactly
you consider "advance"?
> for varying layout or positioning discrepancies and other
> concerns to ever be a real issue for your code.
You are probably going to have to render that a lot more concrete before
it reaches that point of actually saying something.
> I defer to your achievement given the browsers you worked
> around at the time because I certainly don't miss IE 5, and
> was never blessed with having to deal with IE 4 but I can't
> help but wonder if you have a realistic basis for judging the
> merits of a modern framework.
The public record answers that question well enough; when I have made
the effort to examine, and criticise, any specifics of 'popular' library
code in the past the code in question has usually been gone from the
next released version of the library. That would not happen if my
comments were not correct (even if it actually happens by coincidence),
and it would not be necessary if I did not understand the code being
written better than its authors do (else there would be no substantial
criticisms to be made).
> There are concerns here other than whether a framework ever
> has bugs.
Relatively minor in comparison to other concerns. Bugs are bound to
happen (humans make mistakes) but some of the sillier stuff really
should never have happened. For example, navigate a browser to:-
<URL: http://www.google.com/codesearch >
- and enter the search phrase:-
typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript
- into the box there and see how many of the 'popular' libraries are
performing a comparison between the result of a - typeof - operation and
the string 'array', despite the fact that no native object could produce
'array' from a - typeof - operation, and no host objects have ever been
reported as producing that result. The whole thing is a nonsense, but a
very prevalent nonsense despite that (at 2000 odd hits).
> That's great that your code never does,
I didn't say my code has no bugs, I said I was not having to make any
modification in order to cope with new browser releases. The implication
being that my application of cross-browser scripting theory is effective
in practice and does contribute towards low (or lower) ongoing
maintenance/testing costs.
> but how does it help me if it doesn't do anything for me that
> I wasn't already doing for myself.
You are the one anticipating problems arising from new browser releases.
That implies that there is something that I am doing (or, maybe,
avoiding doing) that you are not doing (or doing) that you should be (or
should not be).
> Yes, I was quite capable of dealing with crossbrowser issues
> in regards to the DOM before I ever touched a framework. I know
> where to find quirksmode
quirksmode?
> and I've read plenty of Crockford's stuff.
You don't look to Crockford for cross browser scripting, his interests
are much more concentrated in the language.
> But at the end of the day, it's Dean Edwards' work that I'm
> really intrigued by and I'm not sure I would expect any of
> you guys to understand why at this point.
Yes, your shouldn't expect me to understand why.
Richard.
Eric Bednarz
> […] With all due respect,
Like missing attribution for the quotation?
> I don't believe
> anybody was doing anything advanced enough with the DOM before IE 7
> came out for varying layout or positioning discrepancies and other
> concerns to ever be a real issue for your code.
http://www.google.nl/search?q=%22you+must+be+new+here%22
(There are public archives, no reason to get pathetic; a lot of stuff
that is supposed to be very > 2007 has been discussed here in the early
2000’s; I wasn’t here either back then, so you are not excused.)
> […] it's Dean Edwards' work that I'm really intrigued by
> and I'm not sure I would expect any of you guys to understand why at
> this point.
If I were you, I wouldn’t expect anyone here to understand that at any
future point either. You might question whose problem that is, though.
Garrett Smith
Not necessarily positive impact.
Some individuals point out shortcomings in jq. Others parrot those
points, obnoxiously.
jQuery changes.
Crediting an obnoxious parroter for changes in jq could be a post-hoc
fallacy. In fact, some small problems have gone unfixed (change
string.match -> pattern.test, in many places, to improve perf). Who do
you blame for that?
Regardless, the few small changes in jq don't change the inherent design
of it much.
It's still based on an unneeded query selector which seems to be at the
core of the "magic".
The "event registry" (if it can be so called) still uses attachEvent or
addEventListener.
There's the - attr - which still deals with property/attribute
ambiguously, and that can cause more divergence between browsers than it
solves.
It still mostly uses unqualified - document - references, so can't
generally work in frames in a lot of cases.
The animation is baked into the core of the library. Most of the time,
animation is not needed. What good is it then? When trying to debug
something it could be a distraction, being alongside code that may be
the actual source of the problem. It also takes up a small amount of
memory and download time.
When animation is used, the animation should use a single - setInterval
- not several. jQuery animation library uses multiple setInterval, and
is severely limited in its design. FWICT, it does not seem to handle
color animation and opacity is designed as one-off in the "fade" effects
only.
A well designed animation library would be like a well designed
anything: focused on one thing, extensible, and have absolutely nothing
to do with "attachEvent", "form serialization" or the mishmash things in
jquery core, few (if any) of which have anything to do with animation.
Matt Kruse
> I am not, nor have ever professed to be, an expert on javascript.
Just for reference, I'm no referring to you personally. Although I do
think you fall into the group of very knowledgeable and experienced js
developers in this group.
> > Things look very different to
> > different people, and if they choose a different path it's not
> > necessarily because they are stupid or uninformed.
> Did I say that people are stupid or uninformed because they use a
> library? No, not ever.
Many have. I'm referring to those attitudes.
> 3rd party libraries have downsides, if you want to be seen
> as credible, present both sides of the argument.
Oh, most certainly. I think I've been fair to both sides.
> The fact that "experts/purists" point out the shortcomings of
> particular libraries doesn't mean they are fundamentally opposed to
> libraries. It should be seen as constructive criticism.
In this group, the entire concept of "general-purpose" libraries has
been repeatedly bashed by many. It's not just criticisms of specific
libraries, but the concept as a whole.
> Let's name names.
I don't have time to look up old threads, but I'm sure a person could
go back and easily find references from the people to mention as to
why general-purpose libraries are a bad idea in general.
> So get the chip off your shoulder, accept criticism and move on.
There might be some miscommunication, but I don't think I have a chip
on my shoulder at all. I find the discussion interesting. It helps me
evolve my own ideas and how I choose to put them into practice. I have
no stake in jQuery or any other library. I use several in some places,
none in others.
> > I have no interest in persuading either side that the other
> > is correct.
> Then why post a link to an article about "good enough" development and
> use it to support the use of a particular library? Seems like an
> argument for mediocrity.
I use jQuery as an example only because it is by far the most popular
one out there and the one that gets the most criticism here. I hoped
that by introducing a different way of looking at things, perhaps some
new ideas would emerge in a thread here. 65 posts later, I'm not sure
what has come out of it but a lot of defensiveness and arguing. Not
sure why.
> > You may be
> > the guy who still trumpets the superiority of OS/2 and proclaims how
> > much Windows sucks and how stupid its users are, but finds himself
> > without a job ;)
> Good grief, more verballing. Windows vs OS/2 was just an example of an
> IT "good enough" story that predated the article you linked to. I am
> certainly not, never have been, nor ever will be, an evangelist for OS/
> 2.
Again, not referring to you specifically. Just throwing out an
example.
Matt Kruse
Matt Kruse
wrote:
> Possibly too slow, or too lazy, or too influenced by poor advice or poor
> information, or just unable to see the information through the noise, or
> any of any number of other reasons/excuses. It doesn't really matter why
> it takes so long for people to see how very superior feature detection
> is to the alternatives, only that given enough experience (and wit) they
> do eventually see it. Prototype.js and JQuery haven't been switching
> from browser sniffing to feature detection in order to impress me, they
> have been doing it because it is the right thing to do in the context
> browser scripting. It is just a pity that neither group managed to see
> that before they wrote the initial browser sniffing versions of there
> libraries (thus avoiding the need for change it later, and the back
> compatibility issues that come with that), given that feature detection
> was we well understood and out in the public domain well before they
> started.
It is also a shame that those on the edge of js development realized
too late the importance of general-purpose scripting libraries.
Someone could argue that the need for a public general-purpose library
existed around the turn of the century or before, but it took quite a
few years before the js "experts" realized this and either constructed
their own libraries or began volunteering their time to help existing
ones.
Of COURSE some of the popular libraries were slow in adopting some
general good practices. Of COURSE they started out with some bad ideas
and questionable practices. Because their focus was on solving the
problem of how to write, distribute, debug, support, and maintain a
general-purpose library for the masses. Only later did they catch up
to the importance of best practices and better coding style.
For those people whose focus all along was best practices and better
coding style, they only later realized the importance of writing,
distributing, debugging, supporting, and maintaining a public general-
purpose library. Are they not just as to blame for missing the boat?
In 2009 we are seeing the real merging of the two views, and I think
everyone is going to benefit from it as it's sorted out in the near
future. Enough of looking back and trying to figure out who is right
or which stupid bugs existed in version X of popular library Y. Look
forward. Good things are happening.
Matt Kruse
Garrett Smith
They who? The authors? Their focus was on providing support?
The authors provided themselves with a career by impressing less
knowledgeable badly designed code.
The only reason jQuery can exist today is because browsers are as
compatible as they are. It is not because the "experts" were unable to
realize it was necessary. Not only was jquery never necessary, jQuery,
as designed, would be an impossibility back in those days.
Even if the browser compatibility issues were addressed, the sheer size
of jquery, coupled with the fickle support of gzip, and slower
connection speeds.
Trying to run jQuery on a PII or Mac G3 running Mozilla 097 or IE 5.5
would be a disaster. Even if it were patched to be made somewhat
compatible to those browsers.
Did you not notice where I pointed out that the Github tech support said
Safari 3 was too slow for their site (Github using jQuery). Safari 3.
Now Safari 2 was faster than Safari 1 and Safari 1 was much faster than
Mozilla when it came out.
The libraries that existed back then were Dan Steinman's Dynamic Duo,
Bindows, and soon after Dojo, which is still an awful disaster.
> For those people whose focus all along was best practices and better
> coding style, they only later realized the importance of writing,
> distributing, debugging, supporting, and maintaining a public general-
> purpose library.
I don't know what is the perceived benefit of "importance of
supporting". While there are plenty of things that are interesting to
consider in API design, they have not been mentioned in this thread, FWICS.
Regards,
Tim Down
> Crediting an obnoxious parroter for changes in jq could be a post-hoc
> fallacy. In fact, some small problems have gone unfixed (change
> string.match -> pattern.test, in many places, to improve perf). Who do
> you blame for that?
>
> Regardless, the few small changes in jq don't change the inherent design
> of it much.
[snip]
> The "event registry" (if it can be so called) still uses attachEvent or
> addEventListener.
Have I missed something? Is there another way to register multiple
event listeners for a single event on a single object?
Tim
Tim Down
... or is your point that jQuery should be using event delegation?
Tim
Thomas 'PointedEars' Lahn
Yes and yes.
> .... or is your point that jQuery should be using event delegation?
His point is probably that those two approaches are not equivalent:
<http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html>
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
beegee
>
> I regularly reduce old code on the sites I work on by more than half
> using JQ and I'm being conservative. It's probably been used to knock
> out megabytes worth of crap-code on our sites in just the last couple
> months. That's worth a one-time cache of 15K for the user. If you had
> say... 3-5 static page sites that just needed some form validation in
> mind, I could see your point.
I regularly reduce maintainable, easy to read code on the sites I work
on by more than half using JQ and I'm being fanatic. It's probably
been used to knock out megabytes of readable code on our sites in the
just the last couple months. That's worth a one-time cache of 15k for
the user who will never know the difference. Here's some more words.
There, fixed it for ya.
Bob
Tim Down
wrote:
> >>> The "event registry" (if it can be so called) still uses attachEvent or
> >>> addEventListener.
> >> Have I missed something? Is there another way to register multiple
> >> event listeners for a single event on a single object?
>
> Yes and yes.
>
> > .... or is your point that jQuery should be using event delegation?
>
> His point is probably that those two approaches are not equivalent:
>
> <http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html>
OK. All this I know. I haven't delved into the innards of jQuery's
event handling code, so I don't know if there's faulty logic to be
found. What I was trying to get at was whether there is something
wrong with the use of attachEvent and addEventListener in all cases. I
certainly don't think so.
Tim
Bart Lateur
>Bart Lateur wrote:
>> What if I have an id that is also usable as a html tag?
>
>Given that an HTML tag has the form `<...>', what you describe is not going
>to happen.
Um, $('a') works in jQuery, it returns an array of all links as
elements.
"a" is perfectly usable as an ID.
--
Bart.
Eric Bednarz
> Thomas 'PointedEars' Lahn wrote:
>
>>Bart Lateur wrote:
>>> What if I have an id that is also usable as a html tag?
>>
>>Given that an HTML tag has the form `<...>', what you describe is not going
>>to happen.
>
> Um, $('a') works in jQuery,
You are using the *generic indentifier* ‘a’, not a *tag* (e.g. a HTML
start-tag of an A element might look like ‘<a>’, ‘<a/’, ‘<a’, ‘<>’, and
have a attribute specification, of course).
Of course the DOM has misnomers like tagName and getElementsByTagName(NS),
and incidentally, in Dutch ‘dom’ means stupid. :-)
--
λ
Garrett Smith
> On Sep 2, 1:19 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
>>>>> The "event registry" (if it can be so called) still uses attachEvent or
>>>>> addEventListener.
>>>> Have I missed something? Is there another way to register multiple
>>>> event listeners for a single event on a single object?
>> Yes and yes.
>>
>>> .... or is your point that jQuery should be using event delegation?
>> His point is probably that those two approaches are not equivalent:
>>
>> <http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html>
>
The links in to footer of that article have some incorrect advice,
particularly the advice to replace a method assignment in a loop with
assignment to an anonymous function.
Good because it explains things from a beginners perspective, confused
because it fails to explain context, and bad because it has a bug where
he loses context for replacing the event handler and calling - old - in
the wrong context. Question what you read.
He shows in one of the linked "Documentation you should know by heart":
http://www.quirksmode.org/js/events_tradmod.html
| var old = (element.onclick) ? element.onclick : function () {};
| element.onclick = function () {old(); spyOnUser()};
The problem is that in - element.onclick - , function - old - is called
in global context, so when - old - executes, its - this - is the global
object where originally it would have been - element -.
| for (var i=0;i<x.length;i++) {
| x[i].onmouseover = over;
| x[i].onmouseout = out;
| }
|
Which is OK. It would be much more efficient to use bubbling and have
one handler for those, but what is worse is what he says next:-
| This code will work, no problem. But since the functions over() and
| out() are so simple, it is much more elegant to register them as
| anonymous functions:
|
| for (var i=0;i<x.length;i++) {
| x[i].onmouseover = function() {this.style.backgroundColor='#cc0000'}
| x[i].onmouseout = function () {this.style.backgroundColor='#ffffff'}
| }
Besides missing semicolon, the code in the second example results in the
creation if (x.length * 2) functions, where the code in the first
example results in the creation of just 2 functions. So the example that
he says is "much more elegant" is less efficient (that should be fairly
obvious).
> OK. All this I know. I haven't delved into the innards of jQuery's
> event handling code, so I don't know if there's faulty logic to be
> found. What I was trying to get at was whether there is something
> wrong with the use of attachEvent and addEventListener in all cases. I
> certainly don't think so.
Please see lines 2433-2796 where - jQuery.event - is defined.
With attachEvent, the callback functions are called in random order,
immediately after the object's event handler is called. The - this -
argument will be the global object, and - window.event - might not be
the same window/frame that the event occured in.
With addEventListener, callbacks fire in order they were registered in.
This is also a problem with Mootools:
https://mootools.lighthouseapp.com/projects/2706/tickets/35-ie-s-attachevent-ff-s-addeventlistener-and-event-fire-order
A program should not rely on callbacks firing in a particular order but
using a registry that is known to be inconsistent in contrast to one
that is seems unreasonable. That DOM 0 Event registration is much more
consistent.
// More consistent.
elem.onclick = callback;
An event registry that is designed and intended to do register and
remove callbacks should not be concerning itself with the name of the
event, whether there is a potentially absent - srcElement - property, or
any of the plethora of oddities that may or may not occur in any given
situation or browser configuration.
An event registry that concerns itself with specific details of browser
bugs or peculiarities will ultimately fail to miss some of those
peculiarities and in its attempt, will add complexity and bloat.
Taken to the extreme, it becomes either A) Afrightening mess that is not
extensible or B) magic (depends on your perspective). Adding expando
properties to the objects in the registry is risky. Errors caused by
setting pageY/X on an event in Gecko are well-known to this group's
regulars and such attempts also fail in Safari 2. It was recently
mentioned how the - delete - operator in MSIE results in error when used
on a certain Host object, and so relying on the delete operator to
remove an expando property from a Host object is not a safe bet.
In contrast, an event registry that does not concern itself with such
issues is going to be a lot simpler. It will be more extensible and can
possibly even be extended via prototype inheritance so that any
user-defined "ADT" or "class" could itself be an Event Publisher, should
such design be deemed desirable.
Where it is likely that multiple callbacks need to be registered, a
callback system that uses only properties for events (as DOM 0 does) can
work very well.
The strategy for using events-as-properties to keep an array of callbacks.
elem[eventType] = callback;
- where - callback - calls an array of functions. The concept can be
abstracted so that - elem - and - eventType - are variable.
When using attachEvent/addEventListener, one must keep the differences
in mind when using that strategy. Libraries do not remove the need for
testing.
RobG
> Thomas 'PointedEars' Lahn wrote:
> >Bart Lateur wrote:
> >> What if I have an id that is also usable as a html tag?
>
> >Given that an HTML tag has the form `<...>', what you describe is not going
> >to happen.
>
> Um, $('a') works in jQuery, it returns an array of all links as
> elements.
I would expect it to return a jQuery object that has an array of
references to all a *elements*, none of which may be links. If you
want a reference to links (none of which might be a elements), there
is already document.links:
< URL: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-7068919 >
--
Rob
Michael Wojcik
>
> A typical barrier in these kinds of discussions, IMO, is that the
> 'experts' here don't seem to be able to imagine the world through
> someone else's eyes and experience. Things look very different to
> different people, and if they choose a different path it's not
> necessarily because they are stupid or uninformed.
No doubt at least a few of the people who post here have some
experience with the fields of usability, user interaction studies,
human-computer interaction studies, etc.
In any case, I suspect it is not terribly useful to restate the basic
tenet of usability theory in a discussion like this. Your
interlocutors are either already familiar with the principle, or
disinclined to hear it. It would be difficult to participate in the
industry for long without encountering the idea in one form or another.
> I am fascinated by "pop culture" and trying to understand the
> "consensus" decisions that emerge from the swarm of people that all
> act independently.
Surely *this* ground has by now been tiresomely mined over and over
again by casual observers who have never done a methodologically-sound
human-subjects study, so they can post their trite and redundant
insights to their blogs and suchlike. As an argument in this context I
can't see how it carries any weight - certainly not without a much
more substantial thesis and solid supporting evidence.
(Personally, I am fascinated that anyone would think that large groups
of people, in their participation in popular culture, act
independently. But perhaps I have an overly-cynical view of human agency.)
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
>
> Of COURSE some of the popular libraries were slow in adopting some
> general good practices. Of COURSE they started out with some bad ideas
> and questionable practices. Because their focus was on solving the
> problem of how to write, distribute, debug, support, and maintain a
> general-purpose library for the masses.
This argument might be more persuasive if good practices were
independent from writing, debugging, supporting, and so forth. They
are not, so this does nothing to excuse a failure to attend to them.
Experienced practitioners should know that good practices reduce
development and maintenance costs.
Jorge
42.desthuilli...@websiteburo.invalid> wrote:
> Stefan Weiss a écrit :
>
> > On 30/08/09 00:33, Jorge wrote:
> (snip)
> >> There are many people here in cljs still worried that javascript might
> >> be disabled. That just proves that they're still living in the past,
> >> when pages were just pages and not (web) applications.
>
> > That's rich. How do you keep your pages (or applications) accessible, if
> > you require JavaScript? For many web sites, accessibility for
> > handicapped visitors is not an optional feature. I'm not sure how that's
> > handled in Spain, but if I remember correctly, there's even an EU
> > regulation about this for publically funded sites (correct me if I'm
> > wrong).
>
> Nope, you're right. And FWIW, accessibilty would also be one of my first
> concerns for a e-commerce website - people with certain disabilities
> tend to do their shopping online whenever possible.
>
> > If ignoring people with screen readers is the future, then I'll
> > keep living in the past, as you say. Maybe I'll even set up a Gopher
> > server to prove my point ;)
>
> Lol. But yes, it's always good (and not necessarily that hard) to design
> your web apps so they first work without javascript. I sometimes have to
> work in text-mode only (oops, system update failed, no more
> X-server...), and that's when you really start understanding what
> accessibility is about.
The future handicapped due to the handicappeds ? Hmm, no no.
Could you tell me how would your javascript-less theory help in
turning this site (below) accessibility-able ?
http://research.sun.com/projects/lively/
http://research.sun.com/projects/lively/index.xhtml
--
Jorge.
David Mark
> On Aug 30, 5:27 pm, Pherdnut <erik.rep...@gmail.com> wrote:
>
>
>
> > I regularly reduce old code on the sites I work on by more than half
> > using JQ and I'm being conservative. It's probably been used to knock
> > out megabytes worth of crap-code on our sites in just the last couple
> > months. That's worth a one-time cache of 15K for the user. If you had
> > say... 3-5 static page sites that just needed some form validation in
> > mind, I could see your point.
>
> I regularly reduce maintainable, easy to read code on the sites I work
> on by more than half using JQ and I'm being fanatic.
And replace it with illegible code?
> It's probably
> been used to knock out megabytes of readable code on our sites in the
> just the last couple months. That's worth a one-time cache of 15k for
> the user who will never know the difference. Here's some more words.
For the last time (I hope). It is not 15K. It's silly to quote
compressed sizes as compression is not a constant. It sure isn't 15K
on the server or the user end, so why get hung up on the perceived
weight in transit? And it is hardly a one-time cache, even if it was
not patched and re-released constantly.
>
> There, fixed it for ya.
Until it breaks (or is exposed as broken in environments you didn't
test) and the client must download a new jQuery (or sit on their hands
for years waiting for one that fixes the problem).
I wonder if you understand what you are doing. Do you use the attr
method? If so, you are in for a shock as your "easy to read" code is
a cipher that even the authors of jQuery can't unravel. That's one.
If you want more, they are plenty in the archive (and discussed all
over the place at this point).
You made a bad choice. Every day until you realize this fact will be
spent digging a deeper hole for your clients (and really fouling up
their Web properties). You can observe fouled-up Web sites
everywhere. This is how they got fouled up.
It's not because it is a general-purpose and publicly available
script. There were lots of those before jQuery. It's because it is
(and always has been) a very bad script. So bad that it must be
reevaluated and rewritten constantly. That's contrary to its stated
goal of making thing easier for Web developers. Perhaps people just
skip testing and figure zero times anything is zero.
Not hard to see how this happened. Just imagine looking at browser
scripting through the eyes of developers who are several years
behind. I'd estimate jQuery has arrived in 2003 by now. Should catch
up long after it is irrelevant to do so (assuming technology moves on
from silly scripts that can't do anything properly to... anything at
all). Just because a lot of people have bought into it doesn't make
it a good idea. What you see is not the beginning of a movement, but
the (bitter) end. Hard to believe anyone would argue differently at
this point. The decade is almost over. ;)
Stefan Weiss
> On Sep 1, 4:10 pm, Bruno Desthuilliers <bruno.
> 42.desthuilli...@websiteburo.invalid> wrote:
>> Stefan Weiss a écrit :
>> > keep living in the past, as you say. Maybe I'll even set up a Gopher
>> > server to prove my point ;)
>>
>> Lol. But yes, it's always good (and not necessarily that hard) to design
>> your web apps so they first work without javascript. I sometimes have to
>> work in text-mode only (oops, system update failed, no more
>> X-server...), and that's when you really start understanding what
>> accessibility is about.
>
> The future handicapped due to the handicappeds ? Hmm, no no.
>
> Could you tell me how would your javascript-less theory help in
> turning this site (below) accessibility-able ?
>
> http://research.sun.com/projects/lively/
> http://research.sun.com/projects/lively/index.xhtml
| We have tested our system on Windows XP and MacOS using the following
| browsers:
|
| * Safari 3 (recommended for best performance and quality of
| experience)
| * Firefox 3 (still some bugs left)
| * Firefox 2 (still some bugs left)
| * Chrome (still some bugs left)
What a wonderfully accessible project! I stand corrected.
(FWIW, I couldn't even get it to run on FF2/Linux with JS enabled, and a
Braille terminal will only show "Sun Labs Lively Kernel".)
Mind you, I wasn't saying that JS-only applications don't have their
place. I was responding to this statement from you:
| There are many people here in cljs still worried that javascript might
| be disabled. That just proves that they're still living in the past,
| when pages were just pages and not (web) applications.
If you haven't seen any visitors who had JS disabled, you're lacking
experience. I know I've got one of them sitting right there in the room
next to mine, for example.
(and no, he's not handicapped, he is paranoid ;-)
cheers,
stefan
RobG
> Matt Kruse wrote:
[...]
> > I am fascinated by "pop culture" and trying to understand the
> > "consensus" decisions that emerge from the swarm of people that all
> > act independently.
>
> Surely *this* ground has by now been tiresomely mined over and over
> again by casual observers who have never done a methodologically-sound
> human-subjects study, so they can post their trite and redundant
> insights to their blogs and suchlike. As an argument in this context I
> can't see how it carries any weight - certainly not without a much
> more substantial thesis and solid supporting evidence.
>
> (Personally, I am fascinated that anyone would think that large groups
> of people, in their participation in popular culture, act
> independently. But perhaps I have an overly-cynical view of human agency.)
Cue the scene from The Life of Brian, where the masses chant in unison
"We're all individuals" and a lone voice cries "I'm mot".
<URL: http://www.youtube.com/watch?v=LQqq3e03EBQ >
--
Rob
Gregor Kofler
[snip]
> Could you tell me how would your javascript-less theory help in
> turning this site (below) accessibility-able ?
>
> http://research.sun.com/projects/lively/
> http://research.sun.com/projects/lively/index.xhtml
Well, it loads 619kB of scripts and leaves a blank screen then.
I could do that with a simple "<html></html>" (throw in a few more tags
to make it standards compliant). On some subsequent reloads it showed me
a 25% fraction of the "desktop". It put a 25% load on my cpu (i.e.
blocking a complete core), for just sitting there. And there is no
Safari for my OS...
What's this example gonna prove? With _the_ (not _a_) right browser, I
can see some glorious example of how to burn cpu performance for
virtually nothing. But it uses prototype.js - should that prove something?