Re: "The Good Enough Revolution" - As it applies to js

On Aug 31, 12:06 pm, Pherdnut <erik.rep...@xxxxxxxxx> 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.

--
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 *** 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
.

Loading