Reusable Libraries: Good or Evil?

[Matt Kruse]

Since this topic has come up several times in other threads, I thought I'd
make a separate thread and gather opinions from (hopefully) a more varied
range of newsgroup participants.

What are your thoughts on the development and use of generalized, reusable
javascript libraries?

Discussion points:

1) Is the overhead of a 25k (for example) .js file too much for a typical
(public) web site? What if it's cached, and used on a number of pages? How
about if it's used on an Intranet? What if the library is 25k, but the user
only actually uses about 15k of the code? Is there a limit to acceptable
size of a reusable library?

2) Is it beneficial to create a generalized library that contains solutions
for a wide range of problems, and reuse that library on a number of pages?
Or should those pages only include the exact functions/code that it needs?

3) If a library can be created which will solve a complex problem in a way
that is reusable and can be implemented into a working page by users without
a lot of javascript knowledge, is this a valid and recommended thing to do?
Even if the library solves problems an individual user may never encounter
in their situation, causing the library to grow bigger than it needs to be
in the given situation?

4) What are the good points of developing reusable libraries? What are the
bad points? Which one outweighs the other, and in what situations might the
opposite be true?

I'm looking forward to hearing what others in this group think!

 

[Jim Ley]

1) Is the overhead of a 25k (for example) .js file too much for a typical
(public) web site? What if it's cached, and used on a number of pages? How
about if it's used on an Intranet? What if the library is 25k, but the user
only actually uses about 15k of the code? Is there a limit to acceptable
size of a reusable library?

It's expensive but who cares, I have more problems with the tendency
of such authors to spread it over 20 script files which impacts
download performance much more than a few extra k. 75k I'd start to
worry. The bigger question though is not in absolute size, but in
overhead it brings to your page, a 5% decrease in time for the user
probably doesn't matter, a 150% probably does.

2) Is it beneficial to create a generalized library that contains solutions
for a wide range of problems, and reuse that library on a number of pages?

This is a difficult problem, the difficulty comes in the need (that I
believe) to offer sensible degradation in this face of all behaviour,
this very rarely works well with libraries, and you end up with all
the degradation code seperate from the library anyway, making it all a
bit crufty and negating a lot of value in the library.

My experience of libraries is that they tend to increase the amount of
script by 10 or 20 times what a specific solution would do, for not a
whole lot of saved time on the final solution - People tend to spend
more time playing with features in their library that are never used
in production code, and the extra complications are rarely tested in
anger.

Jim.

 

[Randy Webb]

Since this topic has come up several times in other threads, I thought I'd
make a separate thread and gather opinions from (hopefully) a more varied
range of newsgroup participants.

What are your thoughts on the development and use of generalized, reusable
javascript libraries?

I don't care for them.

Not sure if it would qualify as a "library" (probably so), but if I ever
manage to finish my dynamic loading of .js files page, I will put it in
an external file for use on more than one page. Not for the use of a
"library" per se, but to ease maintenance.

Discussion points:

1) Is the overhead of a 25k (for example) .js file too much for a typical
(public) web site? What if it's cached, and used on a number of pages? How
about if it's used on an Intranet? What if the library is 25k, but the user
only actually uses about 15k of the code? Is there a limit to acceptable
size of a reusable library?

What if they only need 1K of it? 25K is a lot of code. The largest .html
file I personally possess that is of any use to the internet, is only a
tad under 10K, and thats the largest. And the majority of that page is
CSS declarations.

2) Is it beneficial to create a generalized library that contains solutions
for a wide range of problems, and reuse that library on a number of pages?
Or should those pages only include the exact functions/code that it needs?

Personally, I prefer a tailored approach to the page.

3) If a library can be created which will solve a complex problem in a way
that is reusable and can be implemented into a working page by users without
a lot of javascript knowledge, is this a valid and recommended thing to do?
Even if the library solves problems an individual user may never encounter
in their situation, causing the library to grow bigger than it needs to be
in the given situation?

That is part of my dislike for libraries. The never encountered/used
code and the lack of understanding of what the author is using. It also
cuts down on the "discussion" of the use of the code.

4) What are the good points of developing reusable libraries? What are the
bad points? Which one outweighs the other, and in what situations might the
opposite be true?

I don't know of any good points, based on my personal beliefs. Doesn't
make me right, doesn't make me wrong, just means I don't care for them.
To me, they fall into the category of the proverbial fish. Give a man a
fish, he eats for a day, teach a man to fish, he eats for life.

Give a man a library.......

 

[Matt Kruse]

What if they only need 1K of it? 25K is a lot of code. The largest
.html file I personally possess that is of any use to the internet,
is only a tad under 10K, and thats the largest.

I would say you're a rare exception to the general rule, then! Most sites on
the web have 50k of _graphics_ or more. I've had pages on internal
applications that have over 200k of content alone (yuck). I'm not sure that
25k of cached javascript - which adds functionality to a page, unlike
images - is "a lot".
With faster internet connections and faster computers being used by more and
more people, I don't know if such a focus on small page sizes and dense
content really pays off at all.

I don't know of any good points, based on my personal beliefs.

No good points at all?
What about in an environment where a web app is being developed by a team
of, say, 15 developers. Most have little javascript knowledge, yet they must
be able to perform basic javascript validation, implement dynamic select
lists, implement popup controls for selecting data, tooltips, etc? In that
case, developing a single library containing the most commonly-used
functions, with an explanation of how to integrate them into a screen, saves
considerable development/debugging/troubleshooting time, as well as time
spent fixing javascript written by people who don't really know how to do
things correctly. Not everyone can be a master of every technology.

To me, they fall into the category of the proverbial fish. Give
a man a fish, he eats for a day, teach a man to fish, he eats for
life.
Give a man a library.......

Is it fair to expect everyone who wishes to use javascript to fully
understand how it works, and have the skill and knowledge to implement
complex functionality?

Javascript is a tool. If the tool can be used in a "black box" manner,
allowing people to perform complex tasks with a minimal amount of effort,
isn't that a good thing? Look at Perl, even in a CGI environment where load
time and code bloat is a concern - the perl community lives and dies by
modules. The motto is, there's more than one way to do it, but why reinvent
something that someone else has already solved in an extremely robust way,
taking into consideration far more issues than you'll think of? Wouldn't the
same apply to javascript?

In fact, I used a library just yesterday for tooltips:
http://www.walterzorn.com/tooltip/tooltip_e.htm
I knew exactly what I wanted to do, and this did it. It has more
functionality than I needed, but I was able to implement it in under 15
minutes and have it work on a wide variety of browsers, and behave exactly
how I expect. I could have written my own from scratch, but why? This saved
me considerable time and effort. Why re-invent the wheel, to save a few
kilobytes of download?

Is it fair to say that your main objections come down to:
1) too much extra code included that isn't necessary, increasing page size
and
2) Hiding implementation details from developers doesn't allow them to learn
how to do it themselves
?

 

[Jim Ley]

Randy Webb wrote:
I would say you're a rare exception to the general rule, then! Most sites on
the web have 50k of _graphics_ or more.

Sure, so the javascript enlarges the site 100 when it could only 2% -
of course a preprocessor can help with this (at the expense of cross
page cacheability/reusability.

With faster internet connections and faster computers being used by more and
more people, I don't know if such a focus on small page sizes and dense
content really pays off at all.

Except we're now paying more for bandwidth than we were 5 years ago -
10 UKP/mb.

What about in an environment where a web app is being developed by a team
of, say, 15 developers. Most have little javascript knowledge, yet they must
be able to perform basic javascript validation, implement dynamic select
lists, implement popup controls for selecting data, tooltips, etc?

I don't think anyone is arguing that re-using code across pages is
valuable, and providing code that can be integrated by other people in
the team is good. But that is not quite the same as always using a
library. In any case - could you please point me to a product that is
in the situation you describe, I've never seen one.

Javascript is a tool. If the tool can be used in a "black box" manner,
allowing people to perform complex tasks with a minimal amount of effort,
isn't that a good thing?

the problem is it can't! it only does half the job, and in an
environment where you're executing code on unknown systems it's
dangerous to do that!

Look at Perl, even in a CGI environment where load
time and code bloat is a concern - the perl community lives and dies by
modules. The motto is, there's more than one way to do it, but why reinvent
something that someone else has already solved in an extremely robust way,
taking into consideration far more issues than you'll think of? Wouldn't the
same apply to javascript?

Perl is a known execution environment, javascript is not, that's the
key difference libraries start to break when you cannot know what
you're doing.

Is it fair to say that your main objections come down to:
1) too much extra code included that isn't necessary, increasing page size

no, that's a minor detail, and one that can be mostly overcome with
simple code-coverage preprocessors.

2) Hiding implementation details from developers doesn't allow them to learn
how to do it themselves

No, that's the wrong thought of the problem it's hiding the pitfalls
of your script from those developers so they are not able to correctly
cope with the script failing.

Jim.

 

[Matt Kruse]

Except we're now paying more for bandwidth than we were 5 years ago -
10 UKP/mb.

I don't pay for bandwidth, so I can't relate

I don't think anyone is arguing that re-using code across pages is
valuable, and providing code that can be integrated by other people in
the team is good. But that is not quite the same as always using a
library.

How is it not?
By library, I'm talking about a set of reusable functions which provide
known functionality.
Even if you tell your developers, "here's 25 validation functions like
isBlank(), isInteger(), isCurrency(), etc. Use them to validate your input
fields, rather than writing your own validations from scratch. It's all in
this js file." That kind of library is very valuable, IMO.

In any case - could you please point me to a product that is
in the situation you describe, I've never seen one.

I've worked on several in the last few years for one of the biggest banking
institutions in the world. Sorry, can't point you to them. But they do
exist.

the problem is it can't! it only does half the job, and in an
environment where you're executing code on unknown systems it's
dangerous to do that!

Why do you say it only does half the job?
For example, my dhtml tree, which is similar to some others:
http://www.mattkruse.com/javascript/mktree/

To use this, the page author needs to do very little. It degrades nicely,
and they don't have to worry about browsers without javascript enabled or
older browsers, etc. Would you say it only does "half the job"? Why?

Further, developers aren't always executing code on unknown systems. If
someone is developing for an Intranet for a company that only has IE6 on its
desktops, the developer can be very sure of the environment. In that case,
they don't even have to worry about supporting the unknown, and even an
IE6-specific library could work very well for them and supply them with
impressive functionality with very little cost.

Perl is a known execution environment, javascript is not, that's the
key difference libraries start to break when you cannot know what
you're doing.

That's not true - Perl can run on almost any OS, and the modules need to be
smart enough to take that into account. A module can't simply call a unix
command to do something - it needs to do detection to determine where it is
running, what commands are available, how to call them, etc. Similar to
Javascript. Yet in Perl, relying on 10 modules in your script, which each
rely on their own modules, is very common. In fact, encouraged.

And I don't see why libraries need to "start to break" in an unknown
environment. Shouldn't they degrade nicely?

No, that's the wrong thought of the problem it's hiding the pitfalls
of your script from those developers so they are not able to correctly
cope with the script failing.

I can see how this might apply in some situations, but I don't think it
applies to all.

For example, if you have a dhtml date picker to select a date for a form
field. If the user has javascript disabled and clicked on the "select date"
link, nothing will happen. No problem. If javascript is enabled, the library
is smart enough to figure out what the browser is capable, and use the
available features to generate the date selector in a way which will work.
The person using the script in the page doesn't need to worry at all about
the script failing, if it's written correctly. If the page _depends_ on the
javascript functionality, then yeah, the author should know how to handle
failure cases. But, if the javascript is just adding extra functionality to
make it easier, then the page author shouldn't care if the browser doesn't
support it - their page will work anyway.

Are you arguing against the general concept of libraries, or more about how
_most_ libraries are written and implemented?

If a reusable javascript library can be written that performs function X,
and does so correctly on all browsers that support the required features,
and simply doesn't do anything on browsers which don't have the required
features, why is that bad?

And are all your concerns still valid for an internal, intranet web
application where the environment is known and faster/easier/better
development is the priority rather than supporting 87 different browsers? Do
you think libraries add value in those situations?

 

[Lee]

Matt Kruse said:

Since this topic has come up several times in other threads, I thought I'd
make a separate thread and gather opinions from (hopefully) a more varied
range of newsgroup participants.

What are your thoughts on the development and use of generalized, reusable
javascript libraries?

Discussion points:

1) Is the overhead of a 25k (for example) .js file too much for a typical
(public) web site? What if it's cached, and used on a number of pages? How
about if it's used on an Intranet? What if the library is 25k, but the user
only actually uses about 15k of the code? Is there a limit to acceptable
size of a reusable library?

The size probably isn't limited by bandwidth so much as by
the namespace. I would worry about a user declaring variable
isBlank, and wiping out not only that library function, but
several others that rely on it.

There are solutions for that, of course, but I think I would
prefer to offer a library of smaller .js "packages" for your
inexperienced developers to choose from as needed to provide
validation, tree structures, etc. Each should define few enough
globals to allow them to become reasonably familiar with them.

Demanding that they know enough to choose the packages that
they need doesn't seem unreasonable, to me.

 

[Matt Kruse]

One person saved three hours(?) on a single
web design problem, as opposed to 10's
of thousands of visitors (not) saving a
few kilobytes on each uncached fetch
over a period of years...
Think your math is a bit awry their Matt.

You think? Wow, some of you guys are _really_ concerned about downloading a
few extra kilobytes. Why?
Do you download with images and css turned off too, to save all that
download time?
I don't think most of the web-browsing world has the same concerns.
Especially considering the weight of many pages these days. Clearly, users
prefer a nicer look and extended functionality over minimalist design to
save bandwidth. I think the bandwidth concerns are completely unwarranted.

Quick'n'Dirty (so to speak) might be fine
for some applications with a small user base
and/or limited lifespan, but there has to
come a point when minimal bandwidth and
high efficiency take precedence over the
'off the shelf/plug-in' solution.

In theory, I agree. But I don't think that "point" is anywhere close to
being a realistic situation.

It's like the people who will work for hours to improve the efficiency of
their code, gaining milliseconds here or milliseconds there. It's a fine
exercise, but not nearly as important as creating something _useful_. All
the good programming and efficiency in the world won't matter at all unless
you can build something that people want to use.

You can build a minimalist website that is only 10k in weight and has lots
of good content, but if your customers all go to your competitors site
because it has better navigation, dhtml widgets to help them out, and
enhanced functionality, have you gained anything?

 

[Matt Kruse]

The size probably isn't limited by bandwidth so much as by
the namespace. I would worry about a user declaring variable
isBlank, and wiping out not only that library function, but
several others that rely on it.

True, namespace issues are important. I've seen libraries crash because they
rely on a global variable "i" or something. But that's bad design, not a
problem with the concept of libraries.
I always prepend my global variables and methods with unique text
qualifiers, so something like "isBlank" becomes "XX_isBlank". I typically
try to expose only the constructor and possible a couple global variables to
keep track of the objects of the type with common names. Every other
function name is something no one else would ever use.

There are solutions for that, of course, but I think I would
prefer to offer a library of smaller .js "packages" for your
inexperienced developers to choose from as needed to provide
validation, tree structures, etc.

Are we just playing a semantics game?
How would "packages" differ from "libraries"?

When I say "library" I don't refer to these big 100k behemoth libraries
which hide all internals of, say, dhtml events and positioning, and replace
them with their own custom methods.
I'm referring to small, tight, compact files which provide very specific
reusable functionality.
How is that different from your idea of a "package"?

Demanding that they know enough to choose the packages that
they need doesn't seem unreasonable, to me.

How many projects of over 10 developers have you worked on?
I find that javascript knowledge is hard to come by in circles of really
good C/Java developers.

 

[Lasse Reichstein Nielsen]

Wow, some of you guys are _really_ concerned about downloading a few
extra kilobytes. Why?

Because users care.
<URL:http://www.useit.com/alertbox/sizelimits.html>

/L

 

[Matt Kruse]

Because users care.
<URL:http://www.useit.com/alertbox/sizelimits.html>

That article is 7 years old!

Users today aren't usually browsing on 14.4k modems. Cable modems are
everywhere, and most dial-ups are at 56k. I suppose if you want to continue
catering to _every_ possible user who might be behind on technology by 7
years, you could create pages that are 2k.

But, software continues to develop, and people do need to catch up. If you
have ancient technology, then you can expect ancient performance. New
off-the-shelf software today isn't written for Pentium60's with 8MB RAM, so
why should we develop on the web for technology of the same era?

It's difficult to keep a good grasp on where users are, but I have no doubt
that 14.4k modems and 2k page sizes are _not_ the type of stuff we should be
worrying about. IMO.

 

[Lee]

Matt Kruse said:

Lee wrote:

Are we just playing a semantics game?
How would "packages" differ from "libraries"?

When I say "library" I don't refer to these big 100k behemoth libraries
which hide all internals of, say, dhtml events and positioning, and replace
them with their own custom methods.
I'm referring to small, tight, compact files which provide very specific
reusable functionality.
How is that different from your idea of a "package"?

That's what I mean.
Your first post gave the impression that you were putting
all of your functionality into one large file.

How many projects of over 10 developers have you worked on?
I find that javascript knowledge is hard to come by in circles of really
good C/Java developers.

But if they can program in any language, they should
be able to choose which package (ie, small library)
they need to include. I don't think we disagree there.

 

[Matt Kruse]

That's what I mean.
Your first post gave the impression that you were putting
all of your functionality into one large file.

Ah, certainly not. Perhaps that did cause some confusion.
By using 'libraries' I mean that if the developer wants form validation,
they include validations.js. If they want a tree, they include tree.js. If
they want to do tooltips, they include tooltips.js. Each library has its own
function and is stand-alone.

The only problem I have with this is that if each library has some similar
core code, that core functionality is duplicated in the page. I've overcome
this in the past by having dependencies defined, and a server-side script
which parses dependencies on the page and only includes those core functions
once when delivering the .js files. It worked very well.

But if they can program in any language, they should
be able to choose which package (ie, small library)
they need to include. I don't think we disagree there.

I agree.
But one of my primary reasons for writing and encouraging library use is
that so much _really_ bad javascript is out there.

Debate about certain techniques all you want, but if you find code that is
filled with evals and document.all and all that mess, and you know it's bad,
it becomes really beneficial to write stuff well once, and just tell
everyone else to use it

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

That article is 7 years old!

Maybe, but it links to this page:
<URL:http://www.useit.com/alertbox/9703a.html>
which was updated four months ago. More people have fast connections,
but the majority are still using modems. The conclusion stands.

Users today aren't usually browsing on 14.4k modems.

The page assumes 33.6k modems. Todays modem users probably use 56.6k
modems. So, you can, perhaps, double the size.

But, software continues to develop, and people do need to catch up. If you
have ancient technology, then you can expect ancient performance.

If the majority has ancient technology, then you should design for it,
if your pages are to be used commercially.

/L

 

[Jim Ley]

Even if you tell your developers, "here's 25 validation functions like
isBlank(), isInteger(), isCurrency(), etc. Use them to validate your input
fields, rather than writing your own validations from scratch. It's all in
this js file." That kind of library is very valuable, IMO.

What, isCurrency, isBlank is valuable?- you're expecting someone who
doesn't even know how to check a form field is blank or not be able to
integrate a library with the code? That sounds way too low a level,
code snippets for combining can be given more efficiently and anyone
integrating it will then be able to ensure that it degrades
appropriately - remember part of the argument about libraries is that
fail because they can't do the job, it's not just that they're
inefficient.

I've worked on several in the last few years for one of the biggest banking
institutions in the world. Sorry, can't point you to them. But they do
exist.

C'mon any site which has say 4 man years of forms on them, without a
CMS at the backend (remember we had 15 developers all of who'm were
doing the javascript library from the 1 expert) I work on large
complicated systems with larger teams, but I've never seen a site with
that amount of forms - I'd suggest there was a product management or
something system - any site with that sort of weight of generic form
validation would be fine.

Why do you say it only does half the job?
For example, my dhtml tree, which is similar to some others:
http://www.mattkruse.com/javascript/mktree/

Ah, we have very different ideas on what's a library, that's a code
snippet that can be re-used whenever you need a list - it's a few k,
(not 25, not 50, but pretty much all the code you realistically need
to do the job) It does no more than a tree, for example the last tree
I created, I needed drag drop functionality like windows explorer, now
I could've taken a library tree code, and extended the library so that
it could support drag and drop updating, but that would've made the
library bloated when we don't need that functionality.

Further, developers aren't always executing code on unknown systems. If
someone is developing for an Intranet for a company that only has IE6 on its
desktops, the developer can be very sure of the environment.

Oops that old chestnut, Yeah, I've done a lot of work when I've gone
in to fix the systems that broke when there was a browser upgrade or a
security patch, the known system turned out not to be quite so known -
of course not so much recently as we've not a new IE6 for some time -
IE6sp2 will be interesting I'm sure though - I plan to be travelling.

And I don't see why libraries need to "start to break" in an unknown
environment. Shouldn't they degrade nicely?

but that degrading is difficult to manage - how does a drag'n'drop
tree degrade if you don't have gEBI? (select boxes maybe, nothing at
all maybe it's optional - maybe just the up down form buttons, maybe
with server round trips) Of course some functionality you can degrade
okay - if you don't have RegExp's you can just return true in the
regexp validation and submit the form, but more complicated things -
and I see virtually no value at all in the simple - the degrade path
depends on context.

Are you arguing against the general concept of libraries, or more about how
_most_ libraries are written and implemented?

I'm arguing against the cost of the library making it not economic to
code - it'll be slower to implement initially, pretty slow to
integrate later, more expensive to download, and slower to execute,
and more complicated to add in new features when they're needed.

It will almost always be better to put together specific scripts from
code snippet stores than to use a library function.

And are all your concerns still valid for an internal, intranet web
application where the environment is known and faster/easier/better
development is the priority rather than supporting 87 different browsers? Do
you think libraries add value in those situations?

Nope as they change, browsers get upgraded etc. they'd only add value
if the liftetime of the project was short enough that there'd be no
chance of environment changing? IME maintenance is expensive even on
the intranet and libraries don't help this, as you generally don't get
the author doing the debugging, unless you're paying them a lot in
maintenance, and then you've lost the cost efficiency arguments.

For me code snippets are the way to go. (which is in a way a library,
but it's a library of code that you need to build into the solution
rather than a script which you add and use the specific objects
provided by it to do what you want.)

Jim.

 

[Jim Ley]

Lasse Reichstein Nielsen wrote:
Users today aren't usually browsing on 14.4k modems. Cable modems are
everywhere, and most dial-ups are at 56k.

Are they, I'd've thought there were more 9.6k and 46k modems in the
world than 56k ones...

It's difficult to keep a good grasp on where users are, but I have no doubt
that 14.4k modems and 2k page sizes are _not_ the type of stuff we should be
worrying about. IMO.

We have mobile devices!

Jim.

 

[Jim Ley]

How many projects of over 10 developers have you worked on?
I find that javascript knowledge is hard to come by in circles of really
good C/Java developers.

True, but at the same time I've never seen a project that needed the
amounts of javascript you're talking about. For example at the moment
I'm basically doing a window manager in JScript, the team has 12
developers, there's a couple who can do the non HTML related JS and me
who can do all the UI stuff, the ratio's working fine, and this is
wholly dependant on javascript.

Jim.

 

[Matt Kruse]

If the majority has ancient technology, then you should design for it,
if your pages are to be used commercially.

Not necessarily. There's no rule that says a commercial product or web site
needs to cater to everyone.
Software is released every day which has minimum requirements greater than
the average user's PC.
Sure, that limits their market, but no product needs 100% penetration to be
profitable.

Losing a very small percentage of users who don't have adequate browsers in
order to please the vast majority who do isn't necessarily a bad trade-off.
Certainly not one everyone would or could make, but such a decision
shouldn't be thrown out as irrational.

 

[Matt Kruse]

What, isCurrency, isBlank is valuable?- you're expecting someone who
doesn't even know how to check a form field is blank or not be able to
integrate a library with the code?

Definitely!
Telling if a form field is blank isn't as straight-forward as it should be.
You have to use different methods depending on if the field is a text input,
select box, multi-select box, radio button, or checkbox. And even more code
if it's a collection of inputs with the same name. Or hell, what if there
are 2 checkboxes, 2 input boxes, and 2 select boxes of the same name?

For a java developer, for example, who is just trying to insert some
client-side form validation, it's very easy for them to understand:

function beforeSubmit()
requiredField("name","The name field is required!");
}

If that's all they have to code to do form validation, they can do it
without any troubles at all.
But if they're left to discover every annoying little detail about how to
access form field values of various types, that's wasted development time.
Haven't we all seen the question a million times - why doesn't
document.forms[0].selectname.value work as I expect it to?

There is great value in hiding the guts, and giving non-javascript
programmers a simple interface and tools to perform the logical tests they
know they need to do.

Ah, we have very different ideas on what's a library, that's a code
snippet

Hmm... semantics

I could've taken a library tree code, and extended the library so that
it could support drag and drop updating, but that would've made the
library bloated when we don't need that functionality.

Sounds like a perfect situation to develop a tree code library, and another
drag-n-drop tree code library which extends the first. Then you can use the
plain tree when it's needed, or the drag-n-drop version when it's needed,
without code duplication and without unnecessary code bloat.

but that degrading is difficult to manage - how does a drag'n'drop
tree degrade if you don't have gEBI?

Depends, but I would say, if the site functionality depends on drag n drop,
then you simply can't use it without the right browser support. If it's a
requirement that all users be able to perform the functionality, then you
implement it in a plain html server-side manner.

For me code snippets are the way to go. (which is in a way a library,
but it's a library of code that you need to build into the solution
rather than a script which you add and use the specific objects
provided by it to do what you want.)

I'm still not quite understanding how you differentiate between "code
snippets" and "library".

 

[Lasse Reichstein Nielsen]

Not necessarily. There's no rule that says a commercial product or web site
needs to cater to everyone. ....
Losing a very small percentage of users who don't have adequate browsers in
order to please the vast majority who do isn't necessarily a bad trade-off.

I was talking about the *majority*. I agree about a minority, although
there is no reason to lose any potential customers if it can be
avoided. Remember, on the internet, 10% of all users is an awful lot
of people (and is also about the percentage of people who is reported
to browse without Javascript)

/L