R
Randy Webb
Matt Kruse wrote:
Where do you want to start out? It sounds interesting...
Where do you want to start out? It sounds interesting...
M
Matt Kruse
Randy said:
I'd volunteer to create a mailing list.
Also, I'm creating a site and content for the URL in my sig (redirecting to
my personal site for now), and I think it would be a logical place to house
such a project. My plan for now is to put my stuff up there, but I would
certainly dedicate a portion of the site (if not the majority of it, and the
site's emphasis) to housing the collaborative efforts of a group of
javascript experts.
I envision a site which accomodates a number of different approaches to
script development. I like libraries which deliver a lot of different
functionality to end-users (developers) and are relatively easy to
implement. Others don't like this approach. But these libraries are
dependent on blocks of common functions, glued together to serve a purpose.
So others can stop at that level, and just build functions which perform
very specific tasks, but offer no functionality on their own. Even those
functions are dependent on low-level coding structures which can be made
very efficient. For the people who enjoy tighter loops and super-efficient
code, they can focus on streamlining the common functions.
I believe in doing something productive immediately, and getting immediate
results to get going. If things like this get bogged down in planning and
fighting over theories and ideals, they fail.
I would love to see a plan something like this:
1) Create a separate mailing list to communicate.
2) Get a core group of knowledgeable and experienced people on the list
3) Decide on some very basic assumptions and requirements for all code,
or at least an approach to separating solutions which offer similar
functionality but with different assumptions/requirements.
4) Build low-level functions for common functions which many
higher-level scripts are dependent on.
5) Create test cases for each function/snippet for future browser
testing of the core functionality
6) Publish the content as it gets completed for immediate peer review,
further testing, and use in real projects
Of course, this would rely on a number of talented people coming together,
cooperating, and putting egos aside. I think that's the biggest stumbling
block
R
Richard Cornford
Matt said:
It certainly can be, but without (at least some) common criteria there
is not much point in those people trying to talk to each other about
"value". Yesterday "value" was proportional to instances of script
deployment, I don't agree but at least that is concrete enough to be the
subject of rational consideration. Today it is entirely a matter of
individual opinion.
The general public (even just the Internet using portion of the general
public) are unlikely to have any well formed attitude towards browser
scripting. The majority will be totally unaware of browser scripting as
a distinct aspect of a web page/site, and script design should aim to
keep the role of scripting in a web page/site transparent to users.
You do love stating numbers without any apparent relationship to
anything.
If it is an informed decision appropriate to the context then that is
fine. Though when extremely questionable statistics start appearing in
the criteria you have to wonder how informed the decision could be.
From the list you appear to be looking upon this person exclusively as a
potential purchaser (acquirer) of pre-existing browser scripts. Rather
than, say, the commissioner of browser scripts for a particular task, or
the project manager of a team, including javascript authors, creating
commercial web applications in a software house, or any of the many
other people who might have a reason for weighting these and other
factors.
Implementation is a relatively vague term when used in this context. It
is common to talk of implementing a specification, but ease of
implementation in that context is a quality of the specification not of
the script that will be implemented from it. Ease of implementation
might also be a quality of a design, existing prior to any script that
represents the implementation.
Given the previous discussion I assume you mean ease of deployment,
employment or use in a web page/site. The ease of that is related to
various factors including the quality of the documentation (which is
independent of the script) and who is doing it.
The author of a script would usually find it trivial to deploy without
any documentation at all, while a complete newcomer might struggle even
with comprehensive and well-written documentation and a script designed
to be easy to deploy. Then there is quite a spectrum in between where
different factors contribute to ease of deployment/use, and factors
contributing to the significance of the javascript code to its ease of
deployment.
Take deployment through JSP tag libraries, for example, It would be
quite feasible to use a script implementation that was objectively
complex to set-up and initialise within a tag library because that task
would be done once by the specialist who created the tag library code.
All of the details would be completely concealed from whoever was
eventually using that tag library, allowing easy deployment of that
script by people who would be incapable of using actual javascript code
independently. But a script written with the intention that it be used
directly by those same people would do well to be as simple as a JSP tag
to employ.
So in the case of the code inside the tag library, effort put into
making the javascript easy to set-up and initialise has little reward as
it is only occasionally done, no matter how many times the corresponding
tags are used. That effort would be better directed at making the script
as well suited to its use within a tag library as possible. While effort
put in to reduce the set-up and initialisation complexity of the script
for direct deployment is very significant because that would be done
repeatedly, and by people who would not normally be expected to have
more than a minimal understanding of javascript.
I am not sure extensibility should be in here at all. It speaks of your
library mentality, where you want to be adding ever more and more
features. But that produces the code bloat problem that is one of the
main arguments against libraries as a concept in browser scripting.
Modularity should probably take the place of extensibility in this list.
Small, direct, re-usable components so that they can be mixed and
matched to suite the application.
The availability of features doesn't mean much if you don't intend using
them. Beyond the need for a script to have all of the features that are
wanted/needed (specified), features that are not used are just code
bloat (and maybe higher memory/resource consumption, slower execution
and download, etc.).
Price (or cost) certainly. Licensing and licensing restrictions are
closely related to the purchasing (acquiring) of software products.
Browser scripts themselves are not necessarily software products, they
may be, for example, created in-house and used as part of, say, a web
application product. They would still have an absolute cost (in
developer hours), and knock-on cost implications resulting from their
design. But licensing would not be a issue at all.
Again very much related to the extent to which a browser script is
itself seen as the product.
Speed of execution, speed of download, creation deadlines. A DHTML
animating script needs to be fast (generally), while form validation
execution speed probably doesn't matter at all (unless it is really
bad).
I have never said this. I have said that quality is an absolute
characteristic of code and so can be used in objectively comparing code
(rather than your rather flexible criteria of "value"), and I have said
that quality is more likely to be achieved by attempting to achieve it.
What I do consider more important than (almost) anything else is design.
Design that is appropriate for the application, specification and the
context, design that encompasses established software design principles,
applies recognised applicable best practices, facilitates effective
testing and eases implementation (and to some extent documentation).
The stress that I place on graceful degradation follows from the
realisation that it is necessitated in a script intended for use in a
web browser in an Internet context.
Much as the author of a web application that is to operate over HTTP
needs to recognise that HTTP has characteristics that need to understood
and handled at the design stage of that application, the author of an
Internet browser script needs to recognise that browsers also have
characteristics that need to be handled at the design stage. One of
those characteristics is that client-side scripting is optional, another
is that it is unreliable when it is available. Failing to recognise
those (and other) facts, and handle them, is failing to design/author an
Internet browser script.
Graceful degradation is nothing but one of a number of design
prerequisites in scripts intended to be used in web browsers over the
Internet.
Designing for another context, say an Intranet, where client-side
scripting is not optional (because someone has decided that it is not)
and scripting is not unreliable (because only a finite set of browsers
are intended to be used) removes those factors from the list of
prerequisites. The result of such a design will not be a script suited
for use in an Internet browser context.
Clean degradation offers the only practical way of handling the optional
client-side scripting and the variation in DOMs that results in
unreliability in scripts, and it is best handled at the design stage as
attempting to bolt it on afterwards impacts significantly on many other
significant aspects of any script (ease of deployment being a pertinent
example).
A combination of good design and skilled implementation will tend to
result in a quality script, but a combination of appropriate design and
knowledgeable implementation should be enough to produce a reliable and
functional script.
We are getting further away from any definition of "value" as time goes
by.
See what I mean?
That isn't what the archives would show (assuming we are actually
talking about ease of deployment again), I have actually written quite a
lot on designing for easy deployment. It should be a factor in a design.
Its significance is specific to the expected circumstances of
deployment.
As I said, features beyond what is needed (or specified) are potentially
negative.
All else aside, you promote scripts you have designed without clean
degradation as Internet browser scripts, and then come up with spurious
justifications for not considering normal browser characteristics in
your design. I am just not going to see that as good (or even
appropriate) design, and targeting them at people who don't know enough
to recognise the consequences, or making them easy to deploy for those
people, is not going to change that.
If you make a judgement on technical criteria then technical superiority
relates to "better", if you choose other criteria then they rank
"better". You chose "not technically ideal" and "follows all the
technical ideas" as the characteristics for comparison, which look like
technical criteria to me (nothing else is implied about the hypothetical
scripts under discussion).
WTF has that got to do with anything? We are talking about people who
purport to be professionals providing professional services to clients.
The question would be whether a professional should be
recommending/supplying software to a client because it was convenient
for them. An ethical professional should be doing what they thought was
best for their client. There are many valid reasons why that actually
may result in recommending a Windows OS over another. But they would
relate to the circumstances of the client not the convenience of the
"professional".
How do "technically stupid" and "adds convenience for users" get to
appear together in the same sentence? If something is technically stupid
it stands a very good chance of inconveniencing users. Or are you using
"users" to refer to someone other than the person sitting in front of
the browser again?
Isn't that what I have been saying from the outset; that the dependent
select list concept has the potential for clean degradation but the
degraded state is unsatisfactory as a user interface? Making a fully
server-side approach the easiest way of achieving the combination of
reliability and functionality in a task that is a fairly common
requirement, but usually pre-supposes the availability of server-side
scripting.
But in circumstances where my UI is being unsatisfactory yours is
non-functional.
^
There should have been a "not" in there.
I am yet to meet a businessman (or woman) who would turn down the
opportunity to make money when all else was equal.
One example from a browser that will build 10,000-odd objects for an
average web page, allow their error free use and facilitate feature
detection on all the rest of them and their properties. Appending child
nodes to attribute objects is something that does not need to be done at
all, so it is not a big deal to not be attempting it.
Feature detecting is not diminished in its practicality by locating one
or two fatal problems in arias of the DOM you would not normally be
going into.
Feature detection has grown out of a need that no other strategy came
close to satisfying. It is practical, it is implementable and it works.
And much as your assertions that it would be of no use in the case of
Opera 5.02 proved pessimistic, once you become familiar with the
techniques and the proper application of the strategy you will find that
it can handle everything you are likely to throw at it. (And it isn't as
if there is any contender as a viable alternative, short of the
acceptance of unreliability and uncontrolled failure.)
... . In fact, the first
result in a search I just did was
http://www.quirksmode.org/js/options.html which states "You cannot
create or delete options in Operate 5.02- on Windows". I guess I
wasn't the only one to reach such a conclusion
Jim wants me to put a link to quirksmode.org in the resources section of
the FAQ. I probably will but I am not so sure it is a good idea. Finding
them peddling old wives tails doesn't help.
And I didn't turn out to be alone in that opinion did I?
The date picker code is not exactly formatted for being read. The
commented development version would be easier to understand, but it is
too big a script to be practical to document as an example for learning
purposes.
Do you have any specific reasons for attributing that belief to me?
I have made suggestions; I suggested you design was fundamentally
ill-suited to the environment of its application. You don't believe me
so there is not a great deal more I can do.
<snip>
My experience of problem solving says: stage 1. Identify the problem.
And uses that to define what would qualify as a solution.
Richard.
M
Matt Kruse
Richard said:
In fact, I've done exactly this. Nothing polished yet, but you can see my
playing around here:
http://www.mattkruse.com/javascript/javascripttoolbox.zip
It is my goal to have most of my scripts packaged into jsp taglibs (some
most likely tied to struts, which is what I work with on a daily basis). It
works great. It just takes _more_ time, of which I don't have enough...
I typed them both without a [.!?] between them.
It's unlike the interface many users are used to, and it covers up the input
field. It also activates whether the user wants it to or not. Annoying for
keyboard-users who happen to have a capable browser.
Rather, I'd say that others came to the same erroneous conclusion I did,
based on not testing assumptions we assumed would always be true (that the
options collection would have a length). Testing for the obvious could add a
lot of bloat to scripts.
Nor am I alone in my opinion.
Magical powers of observation.
My libraries are made up of a lot of smaller functions which perform
specific tasks.
Even if you disagree with combining the functions into libraries, individual
functions could be critiqued for their ability to perform the specific task
for which they were written.
I have no idea how that relates to what I said.
R
Richard Cornford
Matt said:
Thinking about your "Available features" and "Extensibility". I was
wondering about the potential for having separate software assemble js
files from a pre-defined "library" based on only the specified required
features as a way of dealing with the code bloat problem, at least
partly.
Given a sufficiently modular design providing a number of utility
functions and a basic object with the minimal common functionality, and
then a series of augmentation methods; the software could understand the
relationships between the components and output a js file that included
any required utilities, the basic object and the augmentation methods
needed to achieve any combination of features required, but no more.
Leaving the person deploying the code using no more (or little more)
than just what was needed for the task, and so no code bloat.
That would leave you free to stuff as many features in as you wanted to
into the system because that would not impact on everyone using the
"library", beyond the extent that they actually wanted those features.
It would also allow features to be explicitly mutually exclusive in a
way that could not be achieved in a single file.
I lifted the design straight from a standard piece of windows software,
so its users will be familiar, it just wasn't Outlook. I really don't
think it would be that hard to work out anyway, a calendar is a
calendar. It is not that different form some of the permutations of
yours except visually, but a bit of CCS could change that.
When a positioning algorithm can hit an input field it can easily be
modified to avoid it, if that was a requirement. I lent towards the
opinion that the pop-up calendar represented an alternative means of
inputting the date, so the original field is not needed simultaneously.
It activates onmouseup on the input field, so only when the user is
traversing the form with a pointing device in their hand, thus likely to
appreciate a pointing device orientated means of quickly inputting the
date.
Keyboard users tend to tab between fields so they will not be seeing it
at all.
There are people who say "make *no* assumptions about browsers". There
are some things that I would be willing to assume, the existence of -
document -, some common global functions/objects, ECMA 262 2nd edition
specified global functions/objects, but that is about it. Everything
else needs verifying first, or handling in a way that is safe.
Very little seems obvious once you start looking into browser DOMs.
Suitable testing will increase the size of scripts, but isn't really
optional if the results are going to be reliable. Probably a more
significant impact follows form how that testing is implemented as the
wrong strategy can seriously burden the execution speed and efficiency
of code. The fact that extensive testing is necessary and that testing
increases the amount of code used just provides an additional reason for
not including code that is not used.
But you didn't find anyone who has demonstrated an understanding of
browser scripting to publicly express that opinion.
If I wrote code that I would have found understandable with the
knowledge that I had two years ago there would have been no point in
learning what I have learnt over the intervening period (it surprised me
that there was so much more to be learnt, but I don't regret making the
effort).
I have seen it argued, by Java programmes, that javascript should be
authored in an exclusively Java-like style. That would be possible, and
would produce code that was more comprehensible to Java programmers, but
they are not the same language and some of javascript's most powerful
features would become unavailable. And they are features that really
lend themselves well to the problems of browser scripting.
However, occasionally, when the subject of obfuscation of client-side
code has come up, I have suggested that code that fully exploits
javascript as a language doesn't really need obfuscation as anyone who
can understand how it works can write it for themselves and so doesn't
need to steal it.
But given a suitably modular and OO approach the techniques use to
implement something (however advanced they may be) don't represent a bar
to the use of that code by less skilled authors. With a properly
documented public interface the internal details of components don't
impact on their usability (so long as they work as advertised).
If you post code chances are that someone will critique it.
You want to create a "best possible solution". "Best" implies some sort
of ranking criteria that would differentiate between "possible
solutions". "Possible" implies realisable or achievable; a demonstrable
characteristic. And "solution" implies a problem. You won't create a
"best possible solution" until you know what the problem is that it is
going to solve.
Unless I am suffering from another of your overly flexible word
definitions and you mean something unexpected when you say "solution".
Richard.
M
Matt Kruse
Richard said:
I've done this, and it turned out to be more hassle then it's worth. Also,
it stops being a purely javascript solution. You need some server-side
processing to assemble and deliver the javascript.
I've concluded that IMO, some 'code bloat' is acceptable. I compact my
library source to remove whitespace and comments and all that, which reduces
the size by 50%, usually. If I removed 'extra' code that I might not use on
a page, then I could maybe remove 5k or 10k from a big library. That's not
enough to even worry about, IMO.
Building a dependency chain into javascript functions and objects is a royal
PITA. I've done it, and decided it's more work than it's worth.
Your 'solution' is very limited, though. Can it change date format? Can it
parse user-entered dates and popup the calendar with the correct day
highlighted? Can you make some days unselectable? Can you make the week
start on any given day? Can month/day names be easily changed for
internationalization? Can the calendar populate 3 separate d/m/y fields?
There are a lot of features that everyday users would find handy. Adding an
additional 5k of library code to have as many of those functions available,
tested, and working is a huge advantage to many developers, and definitely
adds 'value' to the script.
Hey, it's a fine way to implement it, just not a way that I find very
useable. It should hide when the user clicks off of it. It shouldn't hide
the field. It shouldn't popup without the user choosing to pop it up. All
IMO.
But, I'm not trying to be overly-picking about your date picker solution. It
looks like a fine script. I'm just explaining why I lean towards the
'library' approach, and building in functionality that many people find
useful, even if a number of people will never use that functionality.
R
Richard Cornford
Matt said:
Either that, or it is very specific.
That wasn't a specified requirement, but if it was it could be added.
Currently it defaults to whatever is defined/enterd in the HTML, or
today otherwise. The date defaulting code would not be difficult to
modify to accept information as function call parameters, or whatever.
The resolution of unavailable dates is to the Year boundary. It could
also be parameterised if there was a need for more control.
No more than I can turn back the tide
But if you mean the orderingof the day columns, yes of course I could, it would need a more complex
algorithm and more code (the current ordering is certainly the most
easily coded, and not that unexpected from a calendar).
They are both in isolated Arrays so they could be swapped for other
nation/language specific dynamically or otherwise, if that was required.
That is what it does now (the second two being select elements).
Is this user "users" or developer "users"?
You comments so far centre on the way my script is not configurable to
every permutation of possible deployment. You want me to write library
style software products for use by third parties as you do, else you
will consider the results inferior. I am not going to do that, my script
is *one* specific implementation of a date picker, a demonstration. I
could write others, and maybe re-use much of the existing code in doing
so. But I will not write an all singing and dancing, 100% configurable,
multi-UI, multi-national date picker until that is the specific
specification (so not in my spare time).
While I disagree with the concept of client-side javascript libraries it
cannot be reasonable to criticise my scripts for not exhibiting
characteristics that are only called for in client-side javascript
libraries. If my scripts did have those characteristics it would mean my
design was inappropriate for the context and they would represent ground
for criticism in themselves.
I notice that you assert that this additional flexibility can be
accommodated in 5K.
You want to be able to change the date format. How many date formats are
there world wide? How many unicode characters represent numbers and/or
digits? Can you really cope with all the possibilities in 5K?
You want to swap the language for the labels. How many languages are
there world wide? How much space will all of their month names and day
abbreviations take up? Plus the corresponding digit character mappings
for the calendar body.
You wonder if dates can be pre selected. What about color-highlighting
local holidays? Internationally? Other dates of interest/relevance? How
about highlighting week when hovering, or the day column, or both in
different colors?
You wonder if the column order can be changed. What about using rows
instead, ordered up or down (right to left) for different languages (if
that is normal for their calendars)?
You wonder how many fields it might populate. What would be the limit;
one to infinity? spread across multiple windows and frames? Different
types; input here, hidden there, the year to a select in another frame?
The first US slash separated date format in UTC, the second equivalent
local time in ISO format?
You want to have the position specifiable. Does it cover the input field
or not (or partly overlap with an offset)? If not is it going to be
above it, below it, to the left or right, offset by how much, offset at
an arbitrary angle, by pixels, em or cm? Or is it positioned relative to
any arbitrary element, or absolutely positioned. Is its position
adjusted so that it will be within the client area or might the user
have to scroll to get to all of it? Should it be dragable?
You think it should close onmousedown outside of the picker. What about
onmouseout, with a close button, onkeydown/press/up outside, onfoucs for
any other control/link? What happens if an event handler is already
assigned to any element that might be considered relevant? What if
someone wants opening onmouseover some other element?
How many other possibilities might suggest themselves? Scripting to a
specification can attempt to provide all of what *is* wanted, a library
cannot practically provide all of what *may* be wanted (even if
everything could be anticipated). A line must be drawn, and with only 5K
to play with that line is not going to be too far from where it is now.
So the library, no matter how feature packed and flexible, ultimately
defines the outcome. And the harder it tries to avoid that the more it
will become bloated with features that some may want but most will not.
As few as 8 lines of code will do that if the deployment context is
known not to include a document.onmousedown handler. For an unknown
context either much more code is needed or cross-browser support would
be restricted. Ultimately it is a matter of someone deciding that it is
something they want (and that implies the context of its use).
Why not? It is not as if you can do anything with the field while it is
showing (as you want the picker closed on any mousedown in the
document).
By implication clicking on the Date field is a request to be able to
enter a date, and the date picker being easy to use with the pointing
device implied by the method of activation might easily justify making
that facility available when date entering is requested. It is really
just a matter of UI style, if someone wanted it activated otherwise that
wouldn't be at all difficult to arrange.
Richard.
M
Matt Kruse
Richard said:
My comments point out common requirements for developers around the world
trying to implement a date-picker popup. Having had my date picker available
for qutie some time, and having received hundreds of suggestions and feature
requests, I'm fairly familiar with the requirements that most developers
have when looking for such a script. Surely no one can meet all requirements
that anyone might have. But solving the vast majority of typical
requirements is definitely possible.
My point in raising those questions was to show that your solution is very
specific to a single set of requirements, and therefore not very useful to
very many people. My solution - although more 'bloated' with code - is built
to meet a wide range of common requirements, and therefore it is very useful
to a lot of people. This is not to knock your solution - it may be _perfect_
for someone. The point is to examine what 'value' each of our aproaches
offers to potential developers who wish to implement a date picker.
If someone wishes to implement a date picker using your philosophy of
javascript development, they would need to download your code, fully
understand it (and it is unreadable to most people), then customize it to
add the required functionality. This could be very time-consuming.
Or, they could download my library, customize the display with a few lines
of code using built-in parameters and methods, and have their requirements
met in a few minutes. And have the date picker work on a wider range of
browsers. At the expense of an additional few kb of code 'bloat'.
If you were a non-expert developer wishing to add a date-picker popup to
your page, which solution do you think you would prefer? You may disagree,
but I think most people would clearly prefer the latter. You have offered a
solution which meets the requirements of very very few developers. I have
offered a solution which meets the requirements of thousands of developers.
And that is why I build libraries, and why I think the library concept is
superior for general use and distribution than your philosophy.
Your code is 23k, mine is 34k. So, I estimated wrong - an additional 11k is
required. But that also adds many more features than what I noted
R
Richard Cornford
Matt said:
What proportion have you fulfilled? Did you notice the post today form
someone who wants to drag select a range of dates? I wonder how that
would work for month/year spanning ranges but I can see it being a very
realistic requirement. For example, an Intranet application for booking
holidays where nobody would ever be entitled to more than, say, 8 weeks
off at a stretch, and so the interface would never have to span more
than 3 months of dragged selection.
Surly it is entirely possible to meet all requirements that anyone might
have (assuming that they are technically achievable) because no matter
what those requirements may be they will be specific and finite. Your
problem is that it is not practical to meet all possible requirements in
one piece of javascript all at the same time.
As it was designed to be.
As long as it is useful in the context for which it was created then it
is doing its job.
Someone using my "philosophy of javascript" would have no need to be
downloading my example. They would start by reading their specification,
then design their script, then they would write it themselves.
That would do nobody any harm, but it is not necessary.
It would almost certainly be more efficient (in terms of time to
implement and the resulting code) to design the script for the
requirements that apply to it than try to customise a script designed
with different requirements.
Trying to reverse engineer a script that you don't understand and then
get it to do something other than what it was designed to do would be
very time consuming. You will be hard pressed to find anyone
recommending that as a development strategy.
However, given a repertoire of well tried and tested low level
functions/components/objects, an understanding of the design issues and
a familiarity of common patterns in implementation, creating a specific
script for the context and specification doesn't have to be that time
consuming at all.
Assuming that there specification was achievable within the inevitably
limited features of your library. Otherwise they stand a very good
chance of not being able to find them implemented in any library and
either having to find an expert to implement it for them or wishing they
had learnt how to do it themselves.
As I said, amateurs can do as they like, they have no responsibility to
others. Professional and non-expert do not sit well together, though I
cannot deny that web development is full of people for whom "non-expert
developer" would be a very good title (but I doubt they would appreciate
it).
Server-scripting some years ago, a client decided that one of our web
applications needed a facelift beyond what could be accommodated in the
style sheets. They commissioned a firm of HTML designers to create
templates for all of the interface pages and then had us install the
server-side logic into the templates.
Not in itself a bad idea, but the HTML designers unfortunately fell into
a category that would deserve the title "non-expert". At the time I had
been playing with GIF files and their format, and had written a
loss-less batch GIF re-compressor. It did no more than identify which
colours where actually used in a GIF image and re-arranged to color
table and image to color table mappings so that the table was a size
that accommodated all of the colours used, but was no bigger,
re-encoding the image using that new color table. Running the images
directory that came with the HTML templates through my re-compressor
reduced the total size of that directory to (literally) 1/10 of the size
that it was originally (without changing the color of a single pixel in
any of the images within it). The originals had all been created with
256 item color tables (the maximum for GIF) regardless of the number of
colors used.
The images themselves had been created without any grasp of what was
appropriate for their application. A common background color carried
over from the HTML to the images, and expressible in the CSS as a
six-character hex color value, was reproduced in the images as a four
color random dither pattern. GIF colors are 24 bit, it could have been
one flat color instead of a pattern of four, and if it had been the GIF
compression algorithms would have packed those background regions down
to a tiny fraction of there actual size (and the color tables could have
been even smaller as well). Just in the images alone we were looking at
total bandwidth wastage of two orders of magnitude.
The HTML was no better; tables within tables within tables. Our project
manager looked at all this and said: "it is what the client has provided
and we are not being paid to fix it", so we did our jobs and delivered
to schedule. The client withdrew the site after a month and reverted to
the old one because they were fed up with fielding complaints from their
users that the new version was too slow to be useable (making the whole
exercise a total waste of money for them).
And that is what you get from professionals who turn out to be
"non-expert developers"; script bloat on top of image bloat on top of
HTML bloat. It doesn't do the users any good, and it doesn't do the
clients any good, no matter how convenient it may be for those
"professionals" never to have to learn the skills they purport to be
selling.
I have no interest in meeting the requirements of thousands of
developers. I have an interest in meeting the requirements of a
specification, and doing the best job of that I can of that.
Your code is 23k, mine is 34k. So, I estimated wrong - an additional
11k is required. But that also adds many more features than what I
noted
When I look at you calendar example page I find it importing a 58K JS
file. Because it has dependencies on - PopupWindow -, -date - and -
AnchorPosition - (oddly your dependency list for CalendarPopup doesn't
list - date - but uses its functions anyway). While examining my file
would reveal that my date picker code employs:-
InitializeMe
getElementWithId
associateObjWithEvent
getSimpleExtPxIn
HideCovered (needs getSimpleExtPxIn (or equivalent interface))
compatModeTest
getWindowState (needs compatModeTest)
- as independent low-level components that it is depended upon. As low
level components they stand a reasonable chance of also finding
themselves
being used by other non-date picker code in any actual deployment. In
much the same way as you might argue that - PopupWindow -, -date - and -
AnchorPosition - could. Though the lower the level of the component the
more likely it is to find use in other code.
But for purposes of comparison it would be more reasonable to compare
your 58K deployment code against my 23K, or your 35K date picker
specific code against my 15K date picker specific code. With those
numbers we see a difference exceeding the size of the smaller.
Although a more meaningful comparison would run both through a JS
minimiser of some sort and compare what come out to provide a measure of
unavoidable differences, as large blocks of comments don't really need
to be being sent to the user, and so impacting on bloat comparisons
(unless copyright restrictions require them to remain)). And the
minimiser would have to be a version that re-wrote identifiers so that
the differences in identifier naming styles was also removed from the
comparison.
But it remains the case that I can produce a date picker implementing
any specific features required, including any not already covered by
your library, and come up with something more or less the same size,
because different requirements would displace the code need for other
approaches. While if your library wants to cover new requirements it
needs additional features and you have no choice but make it bigger.
Richard.
M
Matt Kruse
Richard said:
I would say 80-90% of the requests I get are now covered by the library. I
only implement those features that might be useful to a number of people (or
myself). If there are unusual or unique requirements, I instruct the
developer where additional code could be plugged in.
Nope. That would be cool, though
But I'd still prefer a "start date" and "end date" interface.
It is practical to meet most of the possible requirements, and that's my
goal.
Of all the web developers out there, I would bet that only a small fraction
could implement a date picker resembling either one of our solutions. If
everyone wishing to have javascript functionality needed to write their code
from scratch (or pay someone to do so) then there wouldn't be much js out
there.
Expecting code to be designed and written from scratch is incredibly
unrealistic, IMO. Even if you think that is the way things should be, you
will _always_ be in the minority. If you wish to code for the minority, then
that's your approach. My approach is to give the greatest value to the
greatest number of people. There will always be a market for my approach.
Which is where we fundamentally differ. But while I say your approach is
fine - just not what I choose, you say that my approach is fundamentally
flawed. *shrugs*
I've found that distributing my code to thousands of users has a lot of
benefits:
1) It makes me consider situations and environments I otherwise might have
not thought of, making my solution more robust for my own future use
2) It encourages me to add features that I might otherwise have skipped, and
in turn give me a more powerful tool to use on my own. I've added features
to scripts before, thinking it was an odd requirement. Then later, realized
I did have a use for the same thing, and it was already coded.
3) It benefits me personally by bringing traffic to my site and even being
quite nice financially, via donations.
I enjoy building tools more than anything. Small nuggets which perform
specific tasks in the best way possible, which can be plugged into
applications. In and of itself, a date picker is useless. But it's a tool to
be used to achieve a higher goal, and that's what intrigues me.
Indeed, the example page currently links to the uncompressed version of the
code. Usually my examples link to the shortened version. For the calendar
popup, the condensed version is 34k.
It's optional, for date formatting. If the user wishes to use that features.
And that's exactly why they are separate libraries - because they serve
separate, independent functions. Inside of each of those libraries are other
smaller functions which are reusable, too.
As I do for all my code. I have "Original" which is fully commented,
"Compact" which is stripped of whitespace, etc, "Combined" which combines
all dependencies into one file, and "Combined & Compact" which does that and
also minimizes. For debugging, the original is preferred, and for production
the compact is preferred.
That's leaning more towards an obfuscator
I could also trim code out of the combined code which isn't required by the
calendar popup, and make it even smaller. But I'm not that worried about
size. [heh]
And that wouldn't bother me.
At some point, if the script gets too big, I'll probably offer a "simple"
version and a "fully-featured" version.
I've even toyed with the idea of a page where you select which features you
need, and it intelligently builds the script for you, based on smart
comments and dependency listings within the code. That would be cool, IMO.
All the benefits of a big full-featured library, but with the smaller
footprint of code written for a specific situation. I don't even think the
concept would be that difficult to implement. It just takes more time...
R
Richard Cornford
Matt said:Richard Cornford wrote:
Nope. That would be cool, though
But I'd still prefer a "start date" and "end date" interface.
You might prefer it, you might even explain that it would be easier to
understand, but if the client wants drag selection of date ranges and
cannot be persuaded otherwise then someone is going to have to implement
it. That makes it a good idea for anyone likely to be on the receiving
end of the requirement to be able to create it themselves, or be
prepared to find (and fund) someone who can.
Until you are in a position to identify *all* possible requirements it
is not possible to tell if any finite subset represents most of them. A
goal of implementing all of the common requirements makes sense, but it
makes exactly as much sense for any other date-picker library so
anything outside the common requirements stands a good chance of needing
a specific implementation.
Web developers cover a considerable range of skills. HTML/CSS
specialists, server-side scripting specialists, etc, largely could not
implement a javascript date-picker. It would make about as much sense
asking them to as it would to ask an HTML/CSS specialist to write an
EJB. But for people who know javascript and a bit of DHTML it isn't a
massive problem. It is basically putting the days of a given month into
appropriate positions in a grid, showing it to the users and doing
something when the user clicks on a number. The specification should
fill in any other interface requirements and that just leaves a number
of issues to be handled that may or may not become significant depending
on the context of use.
OK, there are not that many who could do it the way I did (and not all
of those would choose to), and there will be some who haven't got to
grips with basic javascript objects sufficiently to do it your way. But
a date picker could be implemented in a purely procedural way and do its
job adequately. There may be objectively better of worse ways of
designing a date picker scripts, and more or less skilled
implementations possible, but I am inclined to think that someone who
could not make one at all should not be working in a client-side
scripting related capacity on a web site (working in the sense of; in a
professional capacity).
When the vast bulk as the copy and paste javascript code that is out
there is somewhere between poor and actively harmful that wouldn't
necessarily be a bad thing.
Nobody but a complete beginner would write anything from scratch. The
process of acquiring any level of skill in javascript entails the
creation of numerous scripts of various sorts, and it doesn't take long
to start seeing recurring patterns and re-using existing functions
instead of re-writing them. How far that gets taken would depend on the
level of experience of the programmer and their grasp of applicable
programming design practices and the like.
Maybe, there is always considerably more potential for things to be done
badly than well.
Being in a minority is not the same as coding *for* a minority. How does
cross-browser coding aimed at achieving 100% reliability, combined with
exploiting the maximum of available script functionality from any
browser, qualify as coding for a minority? There are two groups that I
should be coding for, the users (of the browser) and the client
(individual or company). For the first group I am very patently coding
for the majority (in trying to accommodate all of them) and coding for
the second group is obviously coding for a minority as they are each an
distinct entity.
Yes, the fundamental flaw is that you want to place in the hands of
someone with negligible browser scripting skills a lump of functionality
wrapped up in a form that they will find easy to deploy, and then expect
that individual to asses the suitability of it for the context of its
use, comprehend the consequences of its design (the code bloat an so
on), recognise and mitigate any dependencies by implementing suitable
browser testing and clean degradation and basically sort out everything
pertinent to any application of the library in a specific context.
These are mutually exclusive anticipations, the people who the libraries
are targeted at don't have the skills to even recognise the consequences
of what they are doing let alone handle them. The consequences of
needless javascript dependencies, pop-up window use, restricted browser
support, etc. are going to carry right through deployment straight onto
public web sites, where they will start detracting from the usability of
those sites, and from there they will detract from the achievement of
the aims of whoever commissioned the site (be they commercial or
otherwise). The client may never notice this; they way be completely
happy with the outcome (only ever viewing their site on javascript
enabled IE 6 and anticipating that the rest of the world dose likewise),
but that doesn't mean that it didn't happen or that its impact isn't
negative.
So in the end all you might be doing is saying to someone who doesn't
know any better "here is something that you can use to give your client
(who doesn't know any better either) the impression that you have done
your job, without any knowledge or effort on your part". And yes, that
is going to be very appealing to probably many thousands of "non-expert
developers". But using the library alone doesn't mean they have done
their job.
There will inevitably also be circumstances where a completely competent
developer decides that your library entirely fits the context of its use
and deploys it in a way appropriate to that context. I suspect those
developers will also be in a minority.
Yet somehow you missed the possibility of browsers having javascript
switched off or not supporting it, their ability (and the need for)
scaling fonts, and the existence of entire categories of javascript
capable browser.
<snip>
There is nothing like a financial incentive. Didn't someone mention
cigarettes recently?
Richard.