Please help us Oh Great Masters

[Randy Webb]

Matt Kruse said the following on 9/14/2006 12:33 AM:

Since my name is mentioned in the same paragraph as this I thought I'd point
out that *my* rather robust, general-purpose date
parsing/formatting/manipulating lib is < 8k.. Just FYI

Fair enough. To be honest, I wasn't referring to the Date library but I
hadn't looked to see what size it was.

But your point is valid - including a 50k library just to use a single
function is not efficient. I've seen people use _only_ $() from
prototype.js, but include the whole lib. That is some serious over-kill!

Precisely

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Wed, 13 Sep 2006
23:33:17 remote, seen in Matt Kruse

Since my name is mentioned in the same paragraph as this I thought I'd point
out that *my* rather robust, general-purpose date
parsing/formatting/manipulating lib is < 8k.. Just FYI

That's 40% of the size of the average *.htm file in my master root
directory. Ignoring those under 3000 bytes, which are mostly re-
directors, it's over 33%.

I/O handling of standard-format dates, independently of OS settings, can
probably be done in under 1K.

It's a good idea to read the newsgroup and its FAQ.

 

[Matt Kruse]

That's 40% of the size of the average *.htm file in my master root
directory.

So? Your pages aren't exactly typical. They are plain and boring with very
little css, javascript, or images. Many _images_ are more than 8k, and they
most likely provide provide less value than javascript functionality. Plus,
8k of cached javascript that can be reused on multiple pages is not bad at
all.

I/O handling of standard-format dates, independently of OS settings,
can probably be done in under 1K.

If you just want to handle standard-format dates, you're probably right. But
that's not the point of my library. The point of my library is to be
flexible, so the same cached 8k of javascript can be used on many pages
which may even have different date-handling needs, and be reused in
different sites or applications where the specific need differs but the same
code with the same interface can still do the job.

 

[Tom Cole]

I am by no means a JavaScript "elite", but I really love the book
Professional JavaScript for Web Developers:

http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764579088.html

It clears up a lot of confusion for me--the chapter on OO is really
great.

That's where I probably get the most confused with Javascript and where
I use the least of it's capabilities. I'm a Java developer, it's what
I've done since '95. But the prototyping style of OO used in javascript
just hasn't sunk in for me yet. I'm still use to the way natively OO
oriented systems to it.

I remember slightly dabbling in something similar with a version of
Pascal that taunted some OO capabilities way back in late 80's (I think
it was Borland TurboPascal 7.0.) which were really more of a custom
datatype than they were objects.

Maybe I'll check this book out as well. Anyone out there know how well
the Definitive Guide covers the OO aspects of Javascript?

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Thu, 14 Sep 2006
21:21:04 remote, seen in Matt Kruse

So? Your pages aren't exactly typical. They are plain and boring with very
little css, javascript, or images. Many _images_ are more than 8k, and they
most likely provide provide less value than javascript functionality.

But I was referring to *.htm files, which do not contain images. Images
are in separate files (I have some elsewhere; but, except for js-
anclk.htm, the only ones in js-*.htm are digits). The existence of one
form of bloat does not justify the use of another.

Plus,
8k of cached javascript that can be reused on multiple pages is not bad at
all.

But not as good as 1K. Readers may not want to read multiple pages if
they are only interested in one topic.

If you just want to handle standard-format dates, you're probably right. But
that's not the point of my library. The point of my library is to be
flexible, so the same cached 8k of javascript can be used on many pages
which may even have different date-handling needs, and be reused in
different sites or applications where the specific need differs but the same
code with the same interface can still do the job.

A date is a date. Only one form is needed for input (unless terminators
are omitted, or ordinal date or week number is used) and likewise, plus
day-of-week, for output. A little more if Easter is to be calculated.


Americans love standards - that's why they have so many local ones.
Ideally, every citizen would have his/her own.

 

[Matt Kruse]

But not as good as 1K.

I disagree. The difference between an 8k include file and a 1k include file
is negligible. At a certain point, differences in file sizes become
irrelevant.

A date is a date. Only one form is needed for input (unless
terminators are omitted, or ordinal date or week number is used) and
likewise, plus day-of-week, for output.

Not true. If a site or webapp allows the user to select their favored date
format, the javascript must adapt if you are to check for valid dates,
insert calculated date values, etc. Rather than writing different code that
gets delivered depending on the selected format of the user, using a single
library to which the date format can be passed as an argument is certainly
preferred.

Americans love standards

and kittens.

 

[Ray]

That's where I probably get the most confused with Javascript and where
I use the least of it's capabilities. I'm a Java developer, it's what
I've done since '95. But the prototyping style of OO used in javascript
just hasn't sunk in for me yet. I'm still use to the way natively OO
oriented systems to it.

Ah, then definitely I'd recommend the book above. The author cleared up
everything for you, and explained step-by-step what's the big deal
about prototype, why one style and not another, and so on. I felt so
enlightened after reading that chapter ("oh, so *that* was the whole
thing about this prototype thing...")

I remember slightly dabbling in something similar with a version of
Pascal that taunted some OO capabilities way back in late 80's (I think
it was Borland TurboPascal 7.0.) which were really more of a custom
datatype than they were objects.

Yeah, same here

Maybe I'll check this book out as well. Anyone out there know how well
the Definitive Guide covers the OO aspects of Javascript?

I wanted to buy the Definitive Guide when I got thrown into programming
JS a few months back, however the latest edition hadn't come out yet so
I bought the book I recommended. I'd say it's good enough for my job
(I'm still mainly a Java developer, just that in my new job I gotta do
everything from DB table design all the way to JS and CSS for the
pages, so...)

 

[Tom Cole]

Ah, then definitely I'd recommend the book above. The author cleared up
everything for you, and explained step-by-step what's the big deal
about prototype, why one style and not another, and so on. I felt so
enlightened after reading that chapter ("oh, so *that* was the whole
thing about this prototype thing...")


Yeah, same here


I wanted to buy the Definitive Guide when I got thrown into programming
JS a few months back, however the latest edition hadn't come out yet so
I bought the book I recommended. I'd say it's good enough for my job
(I'm still mainly a Java developer, just that in my new job I gotta do
everything from DB table design all the way to JS and CSS for the
pages, so...)

Sounds like similar paths. I had written a few new sites with some
really great functionality for our customers, vendors and employees,
all using J2EE. After browsing around the internet I really liked the
more fluid response of Ajax empowered sites so I started making some
modifications of the pages to perform the lookups and sorting etc.
using XmlHttpRequest.

Since I've spent some time with it (javascript that is) I've decided to
start my own "toolkit" to simplify and standardize the way I use
javascript (kind of like the dozens of custom tag libraries I've
written for the J2EE stuff). So now I'm trying to improve it (the
javascript toolkit that is) as I learn more about the language.

I think I'll be getting both books (The Definitive Guide and
Professional JavaScript for Web Developers). Thanks a bunch.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Fri, 15 Sep 2006
21:08:15 remote, seen in Matt Kruse

Not true. If a site or webapp allows the user to select their favored date
format, the javascript must adapt if you are to check for valid dates,
insert calculated date values, etc.

Only one form is *needed*.

If you allow users to enter any form they like, what happens in a
Quebecois fireworks company that happens to employ a few Japanese and
Americans as well as indigenous staff, and sells into the UK for Bonfire
Night?

The locals will write, in the French manner, 05/11/06.
The Japanese will write, in a logical manner, 06/11/05.
The Americans will write, idiosyncratically, 11/05/06.

So you'll have to provide a selector for the format; and it may not be
correctly set.

More bloat - you must be paid by the yard of code.

 

[Matt Kruse]

Only one form is *needed*.

On a given page for a given user, perhaps. (Though not necessarily so)

If you allow users to enter any form they like, what happens in a
Quebecois fireworks company that happens to employ a few Japanese and
Americans as well as indigenous staff, and sells into the UK for
Bonfire Night?

What I was referring to was if the user has a "preferences" page, for
example, where they can choose their desired date format from a
pre-determined list. Let's say either yyyy-MM-dd or MM/dd/yyyy or
dd/MM/yyyy.

The preference would be used on the server-side to render dates in the
output, but should also be used to validate date input fields and to
populate input fields based on a calendar popup or some in-page
calculations. For this, the javascript used to parse, validate, and
manipulate dates must be sufficiently generic to handle multiple formats.
You could write code that only handles the specific formats presented as
options, but that would require re-writing the javascript if a new date
format is made available. Instead, a general-purpose library written from
the start to handle almost any date format would be preferrable, even if it
costs a few more k in code "bloat".

More bloat - you must be paid by the yard of code.

On the contrary, the concept is so fundamental that it's hard to believe
you've not encountered it in your own experience.

 

[George3]

OT: And probably borrowed from Louis Pasteur:
"In the fields of observation chance favors only the prepared mind."
Lecture, University of Lille (December 7, 1854)
http://en.wikiquote.org/wiki/Louis_Pasteur