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!

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

[Jim Ley]

On Wed, 19 May 2004 22:48:10 -0500, "Matt Kruse"
<ne********@mat tkruse.com> wrote:

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.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Randy Webb]

Matt Kruse wrote:

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

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Matt Kruse]

Randy Webb wrote:

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
?

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

[Jim Ley]

On Thu, 20 May 2004 13:44:49 -0500, "Matt Kruse"
<ne********@mat tkruse.com> wrote:

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.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Andrew Thompson]

On Thu, 20 May 2004 13:44:49 -0500, Matt Kruse wrote:

..This saved
me considerable time and effort. Why re-invent the wheel, to save a few
kilobytes of download?

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.

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.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

[Matt Kruse]

Jim Ley wrote:

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. :)

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!

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?

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

[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]

Andrew Thompson wrote:

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
Javascript Toolbox: http://www.mattkruse.com/javascript/

[Matt Kruse]

Lee wrote:

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. :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/