Matt said:
It makes sense that if you favor an approach to development,
that you would have something to offer which takes that
approach.
"Something to offer" is a bit of a loaded term.
Much the same way that you 'promote' closures and offer
documentation and example scripts using the approach.
I do not "offer" anything. I have written and published explanations of
closures and example of their application. I have also written
extensively on my approach to browser scripting, and published numerous
specific examples. If you have not seen them then that is probably
because you have not been looking.
Few would argue in favor of 'monolithic' generalised
libraries.
Few here would, but they are argued in favour of.
Libs with a specific purpose and just a little extra
'code bloat' as some might call it is a different story
entirely.
What you characterise as a "little extra" code bloat is not necessarily
that little. Every time one of your libraries satisfies a demand for a
less common facility you increase the download for everyone who has no
use or interest in that facility. Every time you need to do something
you must do it in the most general way available, while many actual
applications may preclude much of what the general code must take into
account. Allowing simpler, faster, more specific code to be used in its
place, if that general approach was not lost in the depths of an
interdependent library file. And every time more than one library is
used the odds are good that entire chunks of more or less identical
functionality are being reproduced in each one.
So they are not entirely different stories. Your strategy is a reduction
of a significant problem that is present in monolithic generalised
libraries, but only a small reduction offering diminishing returns as
more of your libraries are used together.
A layered approach to code re-use where systems are built upon many low
level components providing small sets of facilities to all the higher
layers in the system allows the minimisation of redundant code in any
application, and allows the choosing of components that provide those
facilities in a way that closely matches the context in which they are
used, removing the overheads of being general in the face of the
specific. Thus providing the benefits of code re-use for efficient
software authoring but avoiding the bloat and overheads inherent in high
level self-contained general libraries.
You often confuse the two.
The two are not sufficiently different to justify the distinction in
many cases. If you propose that the reduction in code bloat achieved by
moving form monolithic generalised libraries to task specific libraries
is an important difference then the fact that the remaining inherent
code bloat can largely be removed by adopting a third strategy makes
drawing a distinction between the two less effective strategies
superfluous.
The two goals are not mutually exclusive.
But short-term expedience is not a justification for a particular
practice as a "Best Practice".
A developer may need a short-term solution, yet be interested
in learning to do things the 'right' way long-term.
Or, more likely, recognise a best practice but see expedience as a
reason for not employing it in a specific context.
Ridiculous statement.
I've used many 3rd-party Java libraries which I
certainly would not be able to develop on my own.
And Java is a language where the use of libraries is fundamental to the
language's design.
Yet I benefitted by being able to deliver more
advanced functionality in a shorter timeline.
And the relevance of Java authoring to browser scripting is?
You seem to argue in favor of writing everything of scratch,
You know that I don't.
As it would be, if true.
You surely don't follow that reasoning yourself. You just
define it differently to suit your needs.
I do not 'promote' my libraries.
Oh yes you do. Look at the domain names you have purchased and tell me
you are not in the business of promoting your scripts.
I offer them as solutions to specific cases in this group
where my already-developed solution matches exactly what
the poster needs.
If that was actually true your activities would not have attracted any
comment. You frequently propose the use of your scripts without any
indication that the OP is working in the restricted contexts in which
many of them are appropriate, or any indication that the OP is capable
of doing the extra work necessary to deploy them in a reliable way in
the default Internet context (and given the attitude towards "average
web developers" expressed below it appears that your assumption would be
that they were incapable of undertaking that extra work).
There is no financial motivation. There may be some
financial reward, but it is certainly not a motivating
factor.
Ira Baxter also maintains that it is not the financial return that
leaves her promoting her obfuscator in the face of the reasoned
arguments for its futility. It looks like behaviour that can only be
explained by a vested interest or mental illness.
Without a vested interest my expectation would be that individuals would
be interested in identifying the best possible approaches towards
achieving their goals. And willing to engage in, and be swayed by,
reasoned debate about the possible approaches, even to experiment with
the possibilities to better assess their relative merits. So
encountering persistent intransigence suggests questioning its
motivation.
This is a valid thought, and I had considered adding a
"Why?" link which would open up a pre-hidden DIV explaining
in a little more detail the rationale behind the
recommendation.
That seems a needlessly complicated approach to presenting necessary
information, but let us know when it is done as it is the rational
behind a recommendation that is necessary in assessing its worth.
As is any recommendation. Having a detailed justification
doesn't make it any more 'correct', and readers are still
open to disagree with the justification.
The point of providing a justification for any recommendation is
precisely so that the reader can disagree with the recommendation. Any
proposed "Best Practice" that has a flawed or hollow justification is
unlikely to actually be a "Best Practice". You need to know why
something is being proposed in order to see what it is that makes it a
"Best Practice". And is something really is a "Best Practice" there
should be a really good reason for that being the case.
Any 'truth' is only as good as your faith in
the person telling it to you.
Truth is based entirely on an appeal to authority? You cannot really
believe that?
But philosophy is not really on topic...
Epistemology is entirely relevant to the question of identifying "Best
Practice" form a set of proposed "Best Practices".
For any developer who doesn't know enough to decide for
themselves to do differently,
A "developer who doesn't know enough to decide for themselves" which
type of property accessor to use in any given context? A vision of web
development as a bunch of headless chickens careering about in the dark
continuously bumping into each other and bouncing off walls. The pity is
that that does appear to describe the reality in some organisations, but
it does no good to be pandering to the notion that this would be an
acceptable situation.
I think it is the 'safest' recommendation.
So your are proposing that bracket notation should be used to the
exclusion of dot notation (and proposing it as a "best practice")? Such
a proposal is insane. Bracket notation is slower than dot notation
because of the additional requirement to evaluate the expression within
the brackets and type-convert the result to a string. It should be the
less used property accessor, with bracket notation being used where it
is necessary, and possibly where it contributes to source code clarity
(such as in differentiating between names originating in the HTML and
the javascript).
It will certainly lead to fewer problems and less
confusion for the average web developer.
Only if the "average web developer" really is a headless chicken. The
very worst web developers may well be that incapable of understanding
what they are doing, but for the majority the real solution to not
knowing enough to "decide for themselves" is to provide the explanation
that would facilitate informed decision making.
On the contrary, I've received great feedback so far from
many others who said they immediately benefitted from it.
Marvellous, you demonstrate utter contempt for the intellectual
potential of the "average web developer" and then cite their opinion as
in some way significant to an assessment of your page.
Javascript is a mystery to many. A short, concise, easy
to understand document such as thing can be very valuable
to those who may be experienced programmers but just want
a push in the right direction when it comes to javascript.
And a short concise easy to understand document can also do significant
harm, depending on its contents. Being short is not of itself a good
thing, when the result can be too superficial to promote understanding.
But then if you start form the presupposition that the average web
developer is incapable of achieving a technical understanding of what
they are doing omitting all technical explanation may seem more
justified than its inclusion.
The FAQ is great, but it's too big, too long, and too
bloated to be scanned quickly in a lunch break by
someone who wants to avoid typical day-to-day JS problems.
This group's FAQ is quite big, and all the pressure is to make it
bigger. It never was designed to be read in a lunch break. But then you
cannot learn javascript in a lunch break, or 24 hours, or a couple of
weeks, and expecting to be able to do so is totally unrealistic.
For one who criticizes so much, I would expect to see your
alternative 'Best Practices' document offered on the web
somewhere. It is conspicuously absent.
You see a superficial document as appropriate in addressing the question
of "Best Practice", I don't. Late last year I was involved in the
process of creating a javascript authoring standards document for the
software house for which I work. The intention was to lay down formal
rules and "Best Practices" to be followed by our sub-contractors in
creating javascript (but inevitably, once formalised, those same rules
would also have to be followed internally). The resulting document is 50
sides of A4 and does no more than lay down rules that will be followed.
The criteria for choosing those rules, the reasoning behind them, the
arguments about them and the decision making that resolved those
arguments are not part of that document. They were the subject of
discussion in various meetings and extensive e-mail conversations, and
then only when a specific "Best Practice" was subject to disagreement
(as most were adopted without opposition or debate).
I think that a document about "best Practices" should be about best
practices, rather than a list of practices that one individual believes
to be "best Practices". So such a document has to include the
explanations/justifications that allow the reader to understand why a
practice is being proposed, what benefits are expected to follow from
its adoption, and how its adoption is likely to impact upon other
aspects of the scripting task. And for me such a document should include
practices that are argued as best practices but with which I personally
disagree, along with their justifications. The result should be a
document that allowed reader to cherry-pick the set of "best practices"
that best suited their authoring context, and do so on the basis of
informed decision making.
The result is not a screen full of text, it is probably about the size
of a largish chapter in a book. So is it surprising that I have not
created such a document, given the amount of work involved?
That is a fundamental difference between us. I will not be satisfied to
publish anything less than a document that allows its readers to make
informed decisions about the adoption of best practices (and so also
make informed decisions about when it might be expedient to disregarded
them), and you see your best interests in pandering to a flock of
headless chickens.
Richard.
