n00b questions for javascript!
disappearedng
I came from Java so there's somethings that I would like to clear up:
1) What's the purpose of var? Since JS has no "forced types" (i don't
know if I am using the right term), why do we bother to declare a
variable like
var a;
a = 1;
when we can simply just do this?
a = 1; (without implicitly declaring var a before hand?)
2) When do we use new? In Java, we use new when we are constructing a
new class that has a constructor. But in Javascript, I don't think I
have come across the concept of "classes".
For example,
//constructor, (still a function)
function Jar(param){
this.member = param;
}
why is it such that I have to use the following:
var myJar = new Jar('abc'); //Note that this requires "new" here
in order to declare this?
Note that var myJar = Jar('abc') doesn't work.
3) This question actually refers to a particular writer's JS
If you have time please look at this.
function Container(param) {
function dec() {
if (secret > 0) {
secret -= 1;
return true;
} else {
return false;
}
}
this.member = param;
var secret = 3;
var that = this;
}
According to the author,
"The private method dec examines the secret instance variable. If it
is greater than zero, it decrements secret and returns true. Otherwise
it returns false. It can be used to make this object limited to three
uses."
My question is: How do you access dec()?
I tried using
var myContainer = new Container('abc');
myContainer.dec() doesn't work!
Thx man
Gregor Kofler
> 1) What's the purpose of var? Since JS has no "forced types" (i don't
> know if I am using the right term), why do we bother to declare a
> variable like
> var a;
> a = 1;
> when we can simply just do this?
> a = 1; (without implicitly declaring var a before hand?)
var defines a variable as local.
> 2) When do we use new? In Java, we use new when we are constructing a
> new class that has a constructor. But in Javascript, I don't think I
> have come across the concept of "classes".
Pretty good. Some JavaScript experts still do have problems with that.
> For example,
> //constructor, (still a function)
> function Jar(param){
> this.member = param;
> }
The meaning of "this" changes. It's replaced by the new object.
> why is it such that I have to use the following:
> var myJar = new Jar('abc'); //Note that this requires "new" here
> in order to declare this?
> Note that var myJar = Jar('abc') doesn't work.
Because "this" in Jar() still points to wherever it pointed before
invoking the function().
Take a look at
http://javascript.crockford.com/survey.html
This should make everything clear.
> 3) This question actually refers to a particular writer's JS
> If you have time please look at this.
>
> function Container(param) {
>
> function dec() {
> if (secret > 0) {
> secret -= 1;
> return true;
> } else {
> return false;
> }
> }
>
> this.member = param;
> var secret = 3;
> var that = this;
> }
>
> According to the author,
> "The private method dec examines the secret instance variable. If it
> is greater than zero, it decrements secret and returns true. Otherwise
> it returns false. It can be used to make this object limited to three
> uses."
>
> My question is: How do you access dec()?
> I tried using
> var myContainer = new Container('abc');
> myContainer.dec() doesn't work!
No. dec() can only be called within Container(). It's a private function.
Add
this.dec = dec;
to Container, and you can access it as a (public) method of Container.
Gregor
Martin Rinehart
function foo( args ) {
i = 5;
...
}
You'd expect 'i' to be local in foo(). It's not. It's scope is global.
function bar( args ) {
var i = 5;
...
}
That 'i' is local in bar().
Martin Rinehart
Java, not so very JavaScript.
var person = new Person( 'Fred', 'Latham' ); // JavaLand style
var person = { firstName:'Fred', lastName:'Latham' }; // JavaScript,
or
var person = {} // object, no attrs
person.firstName = 'Fred';
person.lastName = 'Latham';
var another = {};
another.prototype = person; // another now shares person's attrs and
their values
another.occupation = 'JavaScripter'; // another now extends the object
// method shared by both:
person.prototype.wholeName = function() { return this.firstName + ' '
+ this.lastName; }
You probably want to buy Crockford's book to get going in the right
direction.
Henry
> Hi everyone
> I came from Java so there's somethings that I would like to
> clear up:
>
> 1) What's the purpose of var?
To declare a variable. Java is block scoped, javascript is not, and
its scoping units are functions. A variable declared inside a function
body is only visible to code inside (lexically inside) the same
function (the code of the function's body, including any nested
functions).
> Since JS has no "forced types"
> (i don't know if I am using the right term), why
> do we bother to declare a variable like
> var a;
> a = 1;
Given that code, "we" would write - var a = 1; - as there is little
point in splitting it up there.
> when we can simply just do this?
> a = 1; (without implicitly declaring var a before hand?)
Assignments to undeclared Identifiers result in the creation of
properties of the global object. These may, in most relevant senses,
act as global variables (properties of the global object added by
executing code can be deleted, while real global variables cannot
(people don't tend to attempt to delete global variables so the
practicalities of deleting don't have much impact)).
There is a general programming axiom that things should never be given
more scope than they need, so creating what are effectively global
variables where function local variables could be used would be a bad
idea. And certainly introduces considerable additional potential for
naming conflicts. Consider, for example, a loop counter which in java
would traditionally be named "i", and a loop that included a call to a
function that also executed a loop with a counter named "i". If the
two "i"s were global then the loop counter for the first loop would be
being modified by the loop code in the function it called.
It may then be argued that global variables do not need to be
declared. There are two reasons for not doing that: the first is code
maintainability/understandably; you encounter - a = 1; - in function
body code and wonder if the intention is to assign to a global
variable or whether this is an example of failing to declare - a - as
a function local variable. If you find a global - var a; - declaration
then you know the intention, otherwise you have to look for other uses
of/references to a global - a - (and if there are none that implies
looking at all the code before that can be determined).
The second reason for declaring all global variables is a peculiarity
of IE browsers. If an Element in the DOM is given an ID attribute, say
- ID="a", and there is no declaration of a correspondingly named
global variable, then IE creates a property of the global/window
object with a name that corresponds to the ID attribute's value.
Having created this, effectively, global variable to refer to the DOM
Element it then throws exceptions if you attempt to assign to that
variable. So, in this example, - a = 1; - would result in an exception
being thrown. If you declare - var a; - globally IE does not assign
the Element reference to that variable, and does not throw exceptions
if you assign to it.
Apart from being quite difficult to track down, this IE issues makes
javascript code vulnerable to modifications in HTML. If you are using
a non-declared global variable and someone else modifies the HTML
(which is not unknown in collaborative projects) such that they
introduce an element with an ID attribute that happens to coincide
with that global variables then the script suddenly breaks, but only
in IE.
> 2) When do we use new? In Java, we use new when we are
> constructing a new class that has a constructor. But in
> Javascript, I don't think I have come across the concept of
> "classes".
Not as part of the language. The concept of 'class' can be employed in
(OO) code design.
> For example,
> //constructor, (still a function)
> function Jar(param){
> this.member = param;
>
> }
>
> why is it such that I have to use the following:
> var myJar = new Jar('abc'); //Note that this
> requires "new" here
> in order to declare this?
Applying the - new - operator to a function causes a new object to be
created, the (current) value of the function's - prototype - property
to be assigned to the new object's internal [[Prototype]] property
(for use as the start of its prototype chain), and then for that
function's body to be executed with the - this - value assigned a
reference to the new object (and if the function's body does not
return any other object reference then the result of the - new -
expression is a reference to that newly created object). The reason
for using the - new - operator is that you want these things to
happen, and you use it when you want these things to happen.
> Note that var myJar = Jar('abc') doesn't work.
Well, it does work, it just doesn't do anything expected/useful. In
that case the - this - value for the execution of the function is a
reference to the global object (so a "member" property is added to the
global object) and as the function has no return statement the result
of the call expression is the undefined value.
> 3) This question actually refers to a particular writer's
> JS If you have time please look at this.
>
> function Container(param) {
>
> function dec() {
> if (secret > 0) {
> secret -= 1;
> return true;
> } else {
> return false;
> }
> }
>
> this.member = param;
> var secret = 3;
> var that = this;
>
> }
>
> According to the author,
> "The private method dec examines the secret instance
> variable. If it is greater than zero, it decrements
> secret and returns true. Otherwise it returns false.
> It can be used to make this object limited to three
> uses."
>
> My question is: How do you access dec()?
In that code you cannot access it. Indeed, the function object
resulting form the function declaration for - dec - will be garbage
collected (probably soon) after the constructor finishes execution.
> I tried using
> var myContainer = new Container('abc');
> myContainer.dec() doesn't work!
No, it wouldn't. Given only the code above the object that results
form the - new - expression will have no "dec" property, and so
attempting to call - myContainer.dec - will error.
Kenny
compressed and I am still building. And lots of lame code out there,
they cannot even follow the simplest HIG principles.
Trying to talk the boss into letting me just do HTML/CSS/JS and start
enjoying programming again.
Thx for priming the pump, anyway.
cheers, kenny
John G Harris
wrote:
<snip>
>2) When do we use new? In Java, we use new when we are constructing a
>new class that has a constructor. But in Javascript, I don't think I
>have come across the concept of "classes".
You use 'new' to create an object, not a class. This is just as true in
Java as in javascript.
In general, a class is the collection of all possible objects that have
something particular in common. In Java you have class definitions,
source text that starts with the keyword 'class', that says what the
objects have in common. The definition can also supply additional
information such as a name for the class.
Javascript is less helpful. You often have to program yourself things
that are done by the compiler in other languages. If you want a class
definition you have to write it yourself in the form of a constructor
function (maybe more than one) and have enough self-discipline to avoid
building a horrible mess.
If you don't need all the facilities that a constructor function can
provide then you may be able to use an object literal instead.
>For example,
>//constructor, (still a function)
>function Jar(param){
> this.member = param;
>}
>
>why is it such that I have to use the following:
> var myJar = new Jar('abc'); //Note that this requires "new" here
>in order to declare this?
In Java, myJar holds a pointer to an area in memory that holds the
object's data, etc. 'new' allocates a fresh memory area and arranges for
the constructor to act on that area. From then on you can write myJar
when you really mean thing-pointed-to-by-myJar. The same is true in
javascript.
>Note that var myJar = Jar('abc') doesn't work.
<snip>
This doesn't work in Java either. Constructors don't have return type
and so can't be used to assign a value to a variable.
John
--
John Harris
Checkraise
> I came from Java so there's somethings that I would like to clear up:
Browse to http://developer.yahoo.com/yui/theater/,
find the 4 videos in 'Douglas Crockford ? "The JavaScript Programming
Language"' and watch those. It's a good start. And there are more vids
on that site.
--
The first time you'll get a Microsoft product, that doesn't suck,
will be the day they start producing vacuum cleaners. (unknown)
Kenny
> These JS frameworks are death by a thousand cuts. Dojo is 300k
> compressed and I am still building. And lots of lame code out there,
> they cannot even follow the simplest HIG principles.
>
> Trying to talk the boss into letting me just do HTML/CSS/JS and start
> enjoying programming again.
Nope, qooxdoo is the answer. Hides HTML and CSS, very fast,
well-documented, adds a bit of an OO model atop JS's...overall, very
sophisticated.
hth, kenny
Joost Diepenmaat
> Kenny wrote:
> Nope, qooxdoo is the answer. Hides HTML and CSS, very fast,
> well-documented, adds a bit of an OO model atop JS's...overall, very
> sophisticated.
I'm looking at it, and it's pretty interesting. Not so sure about the
API or the actual implementation (need to look at both some more). It
doesn't seem THAT fast, though.
Cheers,
J.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
David Mark
> Kenny wrote:
> > These JS frameworks are death by a thousand cuts. Dojo is 300k
> > compressed and I am still building. And lots of lame code out there,
> > they cannot even follow the simplest HIG principles.
>
> > Trying to talk the boss into letting me just do HTML/CSS/JS and start
> > enjoying programming again.
>
> Nope, qooxdoo is the answer. Hides HTML and CSS, very fast,
Then, what is the question?
Kenny
I have graduated from asking to informing.
hth,kxo
David Mark
Okay. What is the question? (Inform away.)
David Mark
Never mind. I see that the question is "name another monstrous blob
of ill-advised browser scripting rubbish."
/**
* Whether the first element contains the second one
*
* Uses native non-standard contains() in Internet Explorer,
* Opera and Webkit (supported since Safari 3.0 beta)
*
* @signature function(element, target)
* @param element {Element} Parent element
* @param target {Node} Child node
* @return {Boolean}
*/
contains : qx.core.Variant.select("qx.client",
{
"webkit|mshtml|opera" : function(element, target)
So if some baseless series of characters contains these strings
(assumes some variant of Safari, IE or Opera), take this fork.
{
if (qx.dom.Node.isDocument(element))
Passing a document to this would seem a waste for most applications.
And who knows what sort of mysticism is used in this "isDocument"
method? Designs that require differentiating between host object
types are doomed to fail (see jQuery.)
{
var doc = qx.dom.Node.getDocument(target);
return element && doc == element;
} else if (qx.dom.Node.isDocument(target))
{
return false;
Waste of code.
}
else
{
return element.contains(target);
Assumes a non-standard method exists. Blows up in anything that looks
remotely like IE, Safari or Opera, but does not implement a "contains"
method on elements.
}
},
// http://developer.mozilla.org/en/docs/DOM:Node.compareDocumentPosition
"gecko" : function(element, target) {
Sure, anything that calls itself "Gecko" must...
return !!(element.compareDocumentPosition(target) & 16);
support compareDocumentPosition!
},
[snip]
Didn't this thing die out years ago? Certainly it should have. It is
the same sort of generalized, over-the-top incompetent rubbish that
has plagued Web applications during this initial craze over Ajax.
Gregor Kofler
> Never mind. I see that the question is "name another monstrous blob
> of ill-advised browser scripting rubbish."
> Didn't this thing die out years ago? Certainly it should have. It is
> the same sort of generalized, over-the-top incompetent rubbish that
> has plagued Web applications during this initial craze over Ajax.
Well, you have to credit them that they created a lean 17MB(!) SDK
package... From a brief look, it seems to be a monster in the "extJS"
vein - anyway, JS now has classes. Makes you wonder what Kenny was
babbling about when he stated:
"These JS frameworks are death by a thousand cuts. Dojo is 300k
compressed and I am still building. And lots of lame code out there,
they cannot even follow the simplest HIG principles. "
But then he moved from asking nOOb questions to dishing out advice in
just 8 days.
Gregor
Kenny
> [snip]
>
> Didn't this thing die out years ago? Certainly it should have. It is
> the same sort of generalized, over-the-top incompetent rubbish that
> has plagued Web applications during this initial craze over Ajax.
Hey, thanks for taking a look at it, I'll keep my eyes open. Right now
my app runs on Chrome, Safari, and FireFox but not IE.
kt
David Mark
> David Mark meinte:
>
> > Never mind. I see that the question is "name another monstrous blob
> > of ill-advised browser scripting rubbish."
> > Didn't this thing die out years ago? Certainly it should have. It is
> > the same sort of generalized, over-the-top incompetent rubbish that
> > has plagued Web applications during this initial craze over Ajax.
>
> Well, you have to credit them that they created a lean 17MB(!) SDK
> package... From a brief look, it seems to be a monster in the "extJS"
It makes you wonder why people would set out to write these bloated
general-purpose "frameworks" when they are so obviously ill-suited for
browser scripting. Though, it is no wonder that the average Web
developer who wants an "Ajax site" sees them as gold.
> vein - anyway, JS now has classes. Makes you wonder what Kenny was
> babbling about when he stated:
>
> "These JS frameworks are death by a thousand cuts. Dojo is 300k
> compressed and I am still building. And lots of lame code out there,
> they cannot even follow the simplest HIG principles. "
No telling.
>
> But then he moved from asking nOOb questions to dishing out advice in
> just 8 days.
That's what happens. Download a lousy script, try it in a handful of
browsers, talk to previously indoctrinated ignoramuses, conclude that
this is how browser scripting is done and embark on a career as an
"Ajax expert" with [fill in the framework name] experience. It can be
quite lucrative due to ignorance at the management level and the
constant maintenance that is required to keep one of their "solutions"
working in three browsers.
Kenny
> Kenny <kent...@gmail.com> writes:
>
>
>>Kenny wrote:
>>Nope, qooxdoo is the answer. Hides HTML and CSS, very fast,
>>well-documented, adds a bit of an OO model atop JS's...overall, very
>>sophisticated.
>
>
> I'm looking at it, and it's pretty interesting. Not so sure about the
> API or the actual implementation (need to look at both some more). It
> doesn't seem THAT fast, though.
I'll keep you posted. It just seems a lot zippier on handling a grid
than I experienced under Dojo or YUI or jQuery.
Right now I am trying to figure out why AllegroServe cannot keep web
sessions straight in anything other than FFox (after doing fine a couple
of hours ago <sigh>).
It does mean writing JS where jquery and Dojo supported the declarative
markup model better, I plan eventually to have the declarative thing
going on the Lisp side so its kinda better (but less portable to other
frameworks) to leave the whacky world of html/css behind.
Meanwhile I see these hardcores here want me doing html and css -- I bet
they were the last to let go of assembler, too.
:)
kt
Kenny
> David Mark meinte:
>
>> Never mind. I see that the question is "name another monstrous blob
>> of ill-advised browser scripting rubbish."
>
>
>> Didn't this thing die out years ago? Certainly it should have. It is
>> the same sort of generalized, over-the-top incompetent rubbish that
>> has plagued Web applications during this initial craze over Ajax.
>
>
> Well, you have to credit them that they created a lean 17MB(!) SDK
> package... From a brief look, it seems to be a monster in the "extJS"
> vein - anyway, JS now has classes.
Working out pretty well, too, for what classes do best: divide up huge
wodges of code and even maybe make reuse a little easier.
> Makes you wonder what Kenny was
> babbling about when he stated:
>
> "These JS frameworks are death by a thousand cuts.
qooxdoo Just Works. If I work for two hours I produce two hours of
application. It has been a while since I experienced that playing with
dojo and yui.
> Dojo is 300k
> compressed and I am still building.
I gotta confess, a build of my qooxdoo app is now bigger than that!
> And lots of lame code out there,
> they cannot even follow the simplest HIG principles. "
I am talking about click vs shift-click vs control-click -- the simplest
thing in the world and qooxdoo is the first I have seen that got it right.
>
> But then he moved from asking nOOb questions to dishing out advice in
> just 8 days.
I been at this a while, I know quality when I see it. Little things like
the build process, the runtime errors (amazing detail), the slick layout
(nothing else comes close -- well, I did not try them all).
And I like to shoot from the hip. :)
I will come back and confess if it does not work out for us.
cheers, ken
David Mark
[snip]
>
> Meanwhile I see these hardcores here want me doing html and css -- I bet
That makes no sense. Poorly written "framework" scripts are hardly a
substitute for HTML and CSS.
> they were the last to let go of assembler, too.
You still don't get it. People who actually write browser scripts
accumulate repositories of re-usable code. That's what they use to
build Web applications. Those who do not, download other people's
repositories and pray that the authors knew what they were doing (and
will always be there to help them.) The impetus to stick with them is
so strong (anything to remain blissfully ignorant to the rigors of
browser scripting) that some communities "flourish" even after their
leaders have been exposed as clueless windbags (e.g. John Resig.)
Good luck with that. See you back here in a few months with lots of
impossibly complex problems.
Kenny
> I been at this a while, I know quality when I see it. Little things like
> the build process, the runtime errors (amazing detail),
[Exception... "'Error: Error in property asynchronous of class
qx.io.remote.Request in method setAsynchronous with incoming value
'undefined': Undefined value is not allowed!' when calling method:
[nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no]
Doh! Missed off a new parameter from the call site. Instant debugging
thx to thorough work by the qooxers.
kt
David Mark
> Gregor Kofler wrote:
> > David Mark meinte:
>
> >> Never mind. I see that the question is "name another monstrous blob
> >> of ill-advised browser scripting rubbish."
>
> >> Didn't this thing die out years ago? Certainly it should have. It is
> >> the same sort of generalized, over-the-top incompetent rubbish that
> >> has plagued Web applications during this initial craze over Ajax.
>
> > Well, you have to credit them that they created a lean 17MB(!) SDK
> > package... From a brief look, it seems to be a monster in the "extJS"
> > vein - anyway, JS now has classes.
>
> Working out pretty well, too, for what classes do best: divide up huge
> wodges of code and even maybe make reuse a little easier.
Working out pretty well? I already showed you a sample that will
clearly cause problems. It was a pretty low-level function too, so
God only knows how many things call it. So what are you judging by?
Pretty graphics on the demo pages?
>
> > Makes you wonder what Kenny was
> > babbling about when he stated:
>
> > "These JS frameworks are death by a thousand cuts.
>
> qooxdoo Just Works. If I work for two hours I produce two hours of
> application. It has been a while since I experienced that playing with
> dojo and yui.
But your "application" will only "work" in a handful of browsers in
their default configurations and it will be huge. How is that useful?
>
> > Dojo is 300k
> > compressed and I am still building.
>
> I gotta confess, a build of my qooxdoo app is now bigger than that!
No kidding.
>
> > And lots of lame code out there,
> > they cannot even follow the simplest HIG principles. "
>
> I am talking about click vs shift-click vs control-click -- the simplest
> thing in the world and qooxdoo is the first I have seen that got it right.
LOL. That accounts for about two lines of code. I wonder if they
used browser sniffing there too? How do you justify the other 300K of
rubbish to your client? Oh sorry, did I say I knew browser
scripting? I lied. After ten minutes of arduous research, I
concluded that 300K+ of rubbish called "qooxdoo" (sp?) would
compensate for my inabilities. It didn't "Just Work" as I first
thought. Sorry for any inconvenience.
>
>
>
> > But then he moved from asking nOOb questions to dishing out advice in
> > just 8 days.
>
> I been at this a while, I know quality when I see it. Little things like
No you don't.
> the build process, the runtime errors (amazing detail), the slick layout
Oh yes, the "runtime errors." I saw that they throw exceptions on
invalid arguments in lots of functions. That is an ignorant thing to
do and accounts for much of the bloat.
> (nothing else comes close -- well, I did not try them all).
You could have saved time by not typing that.
>
> And I like to shoot from the hip. :)
>
> I will come back and confess if it does not work out for us.
>
That's already been predicted.
Kenny
> On Nov 21, 8:28 pm, Kenny <kentil...@gmail.com> wrote:
>
> [snip]
>
>
>>Meanwhile I see these hardcores here want me doing html and css -- I bet
>
>
> That makes no sense. Poorly written "framework" scripts are hardly a
> substitute for HTML and CSS.
qooxdoo means to hide html and css completely. they are still there,
just as there are native instuctions behind my Lisp code, but I am not
supposed to have to think about them.
Have they succeeded? I dunno, so far, no HTML, no CSS, and she looks
nice and works. except on IE. :)
>
>
>>they were the last to let go of assembler, too.
>
>
> You still don't get it. People who actually write browser scripts
> accumulate repositories of re-usable code. That's what they use to
> build Web applications.
Great! I would love a pointer to the most highly recommended open source
repositories. (Google shows one last updated in 1996 -- is that it?) In
fact, it may not be too late -- I'd love not to use a library, esp. one
like qooxdoo that makes me write JS (nice language, but it's no Lisp) --
but I just found out I have till after Thanksgiving to produce or I go
the way of all turkeys, so make it fast!
Those who do not, download other people's
> repositories and pray that the authors knew what they were doing (and
> will always be there to help them.) The impetus to stick with them is
> so strong (anything to remain blissfully ignorant to the rigors of
> browser scripting)
You know, all you are describing is every use of technology to get ahead
without reinventing the wheel. Of course people use libraries.
Do many libraries suck, js or not? Yep. Are many great. yep. Are any JS
libraries great? qooxdoo is my last gasp. Will JS always suck? Nope.
that some communities "flourish" even after their
> leaders have been exposed as clueless windbags (e.g. John Resig.)
> Good luck with that. See you back here in a few months with lots of
> impossibly complex problems.
I'll lose the contrat in two weeks if you are right, I'll come back so
you can all gloat.
The important point is that no one here has offered any alternatives
other than a ten year apprenticeship. And that is not an alternative.
kt
David Mark
> David Mark wrote:
> > On Nov 21, 8:28 pm, Kenny <kentil...@gmail.com> wrote:
>
> > [snip]
>
> >>Meanwhile I see these hardcores here want me doing html and css -- I bet
>
> > That makes no sense. Poorly written "framework" scripts are hardly a
> > substitute for HTML and CSS.
>
> qooxdoo means to hide html and css completely. they are still there,
That makes zero sense when describing a browser scripting framework.
> just as there are native instuctions behind my Lisp code, but I am not
> supposed to have to think about them.
What does that mean in this context?
>
> Have they succeeded? I dunno, so far, no HTML, no CSS, and she looks
No HTML or CSS? What are you serving?
> nice and works. except on IE. :)
"Works" on everything but the most used browser. Great.
>
>
>
> >>they were the last to let go of assembler, too.
>
> > You still don't get it. People who actually write browser scripts
> > accumulate repositories of re-usable code. That's what they use to
> > build Web applications.
>
> Great! I would love a pointer to the most highly recommended open source
> repositories. (Google shows one last updated in 1996 -- is that it?) In
Who said anything about an open source repository? And the
repositories of the late 90's have been replaced by libraries that are
stocked with similarly incompetent code.
> fact, it may not be too late -- I'd love not to use a library, esp. one
> like qooxdoo that makes me write JS (nice language, but it's no Lisp) --
What does that mean?
> but I just found out I have till after Thanksgiving to produce or I go
> the way of all turkeys, so make it fast!
So, you are willing to throw anything at the client to avoid
termination.
I just read an interesting quote from an equally clueless blogger
(which was resoundingly approved by lots of oddly named people at the
bottom of the page.) I think it applies here.
"A JavaScript framework may not make you a better programmer, but it
will make you more efficient."
More efficient at doing what? Writing inefficient code? So the
programmer "saves time" (quotes indicate that it is all borrowed
against the inevitable future rewrites) by saddling the users with
needless delays.
It goes on to say:
"That alone should be reason enough to choose a JavaScript framework,
or library if you prefer."
Really?! So you can churn out trash faster and then throw your hands
up when things inevitably go to hell (call the jQuery guy!)
>
> Those who do not, download other people's
>
> > repositories and pray that the authors knew what they were doing (and
> > will always be there to help them.) The impetus to stick with them is
> > so strong (anything to remain blissfully ignorant to the rigors of
> > browser scripting)
>
> You know, all you are describing is every use of technology to get ahead
> without reinventing the wheel. Of course people use libraries.
What you fail to understand is that none of the general-purpose
libraries out there were good ideas in the first place. Why re-invent
them? Yes, lots of people have tried. I even wrote a similar library
(in my defense, it is at least modular.) Do I use it? No, I
inevitably make a build of the features I need for a project and then
chip away everything that is unneeded in that context. Typically I
save the stripped down versions of each function for future use.
It is just plain stupid for a Web application to serve unneeded code
(even stupider if that code is incompetently written.) Stupidest of
all is to serve lots of obviously incompetent and unneeded code, and
that perfectly describes the average browser scripting library.
For a concrete example, I have been working in my spare time on a
sequel to "My Library", which is tentatively titled "My Page." It is
an HTML template (probably won't bother with XHTML this time around),
assorted alternate style sheets (themes in library-speak) and a script
that is essentially a stripped-down version of my library. It is
intended as a starting point for those who wish to publish accessible,
semantic documents on the Web, without sacrificing "cool" features
like removable (or re-arrangable) navigation, special effects, themes,
persistence, etc. The effects, drag and drop, etc. are easily more
impressive (and infinitely more compatible) than anything built with
one of those 300K monstrosities. Last I checked, after I had added a
few bells and whistles that will likely be made optional in the
builder, the script was 11K (minified but uncompressed.) This is
because I only had to design for certain DOM structures and styles
(and doesn't that describe any Website development?)
In short, the first three rules of browser scripting are context,
context, context.
>
> Do many libraries suck, js or not? Yep. Are many great. yep. Are any JS
What makes you qualified to judge the "greatness" of code written in a
language you don't understand. Perhaps you should instead listen to
those who do understand it?
> libraries great? qooxdoo is my last gasp. Will JS always suck? Nope.
Then you are about to suffocate. You can't say you weren't warned.
>
> that some communities "flourish" even after their
>
> > leaders have been exposed as clueless windbags (e.g. John Resig.)
> > Good luck with that. See you back here in a few months with lots of
> > impossibly complex problems.
>
> I'll lose the contrat in two weeks if you are right, I'll come back so
> you can all gloat.
Whether you lose the "contrat" is a matter for management. You may be
in luck there as most managers know nothing about browser scripting
(you are supposed to be the expert.)
>
> The important point is that no one here has offered any alternatives
> other than a ten year apprenticeship. And that is not an alternative.
I offered no such apprenticeship. And if you are a LISP programmer,
then you should be able to pick up browser scripting in something less
than ten years.
Another alternative would be to do something else with your life.
Kenny
Hmmm, not sure but I think a lurker just filed a bug report over on
qooxdoo related to this. If not it is coincidentally *very* close, and
certainly in the same spirit of faulty browser detection.
Speaking of spirit, the above nicely makes the whole point of libraries:
they constitute a way of collecting in one place tech wisdom (in re
things like isolating browser variability) and effort (when fancy
datagrids can be had off the shelf).
Not sure why this is such a threat to you all that you have to speak so
disparagingly of those who take the trouble to build them and noobs like
us who try to use them.
Worrying about bloat is ok, but doesn't that yield eventually to
optimizers that can prune the unneeded? (Answer:yes, but watch out for
dynamic code). Similarly, people whine about it being impossible to
build an 8k exe in Lisp, as if 8k exes are a widespread target. ie, You
are impressing no one but your self.
A web application is not launched to check the weather or respond to a
google ad, it is launched for at least five minutes of work and launches
faster than any of my desktop apps. That sound you just heard was the
"game over" sound from Pac Man.
Why don't you all lose the grumpy old men in the balcony of The Muppets
act and start an Anti-Framework project? I'd use it, I like lean and
mean, truth be told.
Oh, and start watching late night comedy, you seriously need to grow a
sense of humor.
hth, kt
Matt Kruse
> It is just plain stupid for a Web application to serve unneeded code
That's not a convincing argument. If my browser gets 10k of code that
isn't needed on page X, but caches it and has in on hand for when page
Y needs it, then that isn't so bad. It might be bad to serve 500k of
unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
the line is up for debate.
> an HTML template (probably won't bother with XHTML this time around),
Obvious choice, since XHTML is a bad choice to begin with.
> This is
> because I only had to design for certain DOM structures and styles
> (and doesn't that describe any Website development?)
Not at all. What about, for example, an open source tool that is used
by many sites and allows the users to create their own themes and
layout? If the tool is to have any scripting features, it needs to
create them in as generalized a way as possible, to consider as many
different DOM structures as it possibly can. The tool authors don't
get the chance to go back and selectively choose the code module that
will work in a given layout. It has to be generalized. What approach
to you recommend they take?
What about writing a "widget" for a webapp that can be inserted on any
page by the app admin? The widget should be self-contained, yet it
can't know anything about it's container until it runs.
What about when a site owner decides to change structure and layout of
their site by modifying their page template, but doesn't want to go
back and re-write javascript code? Wouldn't a more generalized
solution that still works in any design he chooses be the better
choice?
> In short, the first three rules of browser scripting are context,
> context, context.
And when the context is unknown to you until the time your code runs,
then what? What's plan B?
> > The important point is that no one here has offered any alternatives
> > other than a ten year apprenticeship. And that is not an alternative.
> I offered no such apprenticeship.
A common argument is that the best alternative to a library is to grow
your own expert in js coding, who creates his own reusable functions
over time and uses them when required.
This works great in some situations, but is not possible for everyone.
People like you rarely offer an alternative other than "well, you
shouldn't be writing javascript, then" which is not helpful or
realistic. At least library authors offer something helpful, even if
you think it's not ideal.
Matt Kruse
David Mark
> On Nov 21, 10:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > It is just plain stupid for a Web application to serve unneeded code
>
> That's not a convincing argument. If my browser gets 10k of code that
> isn't needed on page X, but caches it and has in on hand for when page
> Y needs it, then that isn't so bad. It might be bad to serve 500k of
> unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
> the line is up for debate.
Far South of these ridiculous general-purpose libraries for virtually
any Web site or application.
>
> > an HTML template (probably won't bother with XHTML this time around),
>
> Obvious choice, since XHTML is a bad choice to begin with.
As opposed to *both* half-wit.
>
> > This is
> > because I only had to design for certain DOM structures and styles
> > (and doesn't that describe any Website development?)
>
> Not at all. What about, for example, an open source tool that is used
> by many sites and allows the users to create their own themes and
> layout? If the tool is to have any scripting features, it needs to
> create them in as generalized a way as possible, to consider as many
> different DOM structures as it possibly can. The tool authors don't
> get the chance to go back and selectively choose the code module that
> will work in a given layout. It has to be generalized. What approach
> to you recommend they take?
I want the last 20 seconds of my life back. Why would you bother to
write such a thing?
>
> What about writing a "widget" for a webapp that can be inserted on any
And this.
> page by the app admin? The widget should be self-contained, yet it
> can't know anything about it's container until it runs.
You clearly didn't understand what I said. Perhaps one day you will.
>
> What about when a site owner decides to change structure and layout of
> their site by modifying their page template, but doesn't want to go
> back and re-write javascript code? Wouldn't a more generalized
> solution that still works in any design he chooses be the better
> choice?
Again, you don't get it.
>
> > In short, the first three rules of browser scripting are context,
> > context, context.
>
> And when the context is unknown to you until the time your code runs,
> then what? What's plan B?
That's the whole point. Optimally, you design script for a specific
context (e.g. a certain set of documents.) If the context of your
site is unknown to you, then you have much bigger problems.
>
> > > The important point is that no one here has offered any alternatives
> > > other than a ten year apprenticeship. And that is not an alternative.
> > I offered no such apprenticeship.
>
> A common argument is that the best alternative to a library is to grow
> your own expert in js coding, who creates his own reusable functions
> over time and uses them when required.
Right.
>
> This works great in some situations, but is not possible for everyone.
Are you kidding? That is why *everyone* should not be posing as
programmers, especially not in browser scripting. (!) That's another
point you refuse to see after all these months of "debate" on this
subject.
> People like you rarely offer an alternative other than "well, you
You have either lost your memory or your mind. And stop trying to be
the Voice of the Delusional Poser.
Kenny
Perhaps a middle ground would be an Anti-Framework Project
(Unframework?) that just took care of the hard stuff and simply offered
examples of things folks need to do, leaving adaptation to specific
requirements to developers who at least get a headstart from a good
working example. Truth be told, off-the-shelf stuff can be a bear to
understand and live with, so no loss there.
But it occurs to me that qooxdoo offers a core primitives library that
provides the low-level wiring and lets us do the rest:
http://qooxdoo.org/documentation/0.8/setup_a_low-level_application
Nice design, eh?
:)
kt
David Mark
> > "gecko" : function(element, target) {
>
> > Sure, anything that calls itself "Gecko" must...
>
> > return !!(element.compareDocumentPosition(target) & 16);
>
> > support compareDocumentPosition!
>
> > },
>
> Hmmm, not sure but I think a lurker just filed a bug report over on
Good for them. Too bad it is a dead project.
> qooxdoo related to this. If not it is coincidentally *very* close, and
> certainly in the same spirit of faulty browser detection.
What does that mean?
>
> Speaking of spirit, the above nicely makes the whole point of libraries:
> they constitute a way of collecting in one place tech wisdom (in re
> things like isolating browser variability) and effort (when fancy
> datagrids can be had off the shelf).
And the place to collect such "wisdom" (more like idiocy in most
cases) is on users' hard drives?
>
> Not sure why this is such a threat to you all that you have to speak so
Oh Christ. LOL. There is not a single library jockey (or code monkey
if you prefer) that is even a remote threat to *me*. However they are
a major *irritation* to anyone who has to use the Web on a regular
basis (especially users of off-brand browsers, mobile devices, screen
readers, etc.) Get it?
> disparagingly of those who take the trouble to build them and noobs like
> us who try to use them.
What did I tell you? Don't use them. Why *you* would argue is a
mystery as you are admittedly clueless on the subject. And I will
speak disparagingly about anyone who pollutes the Web with trash
(especially Javascript trash.)
>
> Worrying about bloat is ok, but doesn't that yield eventually to
Thanks for that.
> optimizers that can prune the unneeded? (Answer:yes, but watch out for
No. More wild speculation from somebody who admittedly knows nothing.
> dynamic code). Similarly, people whine about it being impossible to
> build an 8k exe in Lisp, as if 8k exes are a widespread target. ie, You
> are impressing no one but your self.
Will you stop talking about LISP?
>
> A web application is not launched to check the weather or respond to a
No?
> google ad, it is launched for at least five minutes of work and launches
Where do you come up with this stuff? And who is talking exclusively
of Web applications. Most code monkeys do not build Web applications
as they are incapable of implementing even the simplest enhancements
without forcing the user to download 300K of incompetently written
code.
> faster than any of my desktop apps. That sound you just heard was the
> "game over" sound from Pac Man.
Yep. Looks like you will lose the "contrat." Why did you waste all
of this time babbling in here?
>
> Why don't you all lose the grumpy old men in the balcony of The Muppets
> act and start an Anti-Framework project? I'd use it, I like lean and
> mean, truth be told.
Is that supposed to be a joke?
[snip]
dm...@cinsoft.net
[snip]
Do you really think I am going to review more of their code? It
didn't take more than a minute to find the first major blunder. I
threw it away after that. You should do the same.
Thomas 'PointedEars' Lahn
> On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>> On Nov 21, 10:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> In short, the first three rules of browser scripting are context,
>>> context, context.
>> And when the context is unknown to you until the time your code runs,
>> then what? What's plan B?
>
> That's the whole point. Optimally, you design script for a specific
> context (e.g. a certain set of documents.) If the context of your
> site is unknown to you, then you have much bigger problems.
Yes, *optimally*. However, when you write a *library*, it stands to reason
that you can't always know the context of its application when you write it.
This is no excuse for unnecessarily bloated code, of course, but it is a
good reason for writing more general code in a library because that is what
a library is and should be about, like it or not.
ISTM that you don't see that there can be (at least) two approaches to
writing a library: One, to start with generalizing for one context and
refine the library every time you encounter a new context; two, to try to
write it as general as possible (and reasonable) in the first place so that
it can be used later without much adaption by its user.
Both approaches are taken in their own right. Some people like to develop
libraries, e.g. to provide efficient algorithms for daily tasks to other
developers, and nothing else. That a large number of libraries out there
is badly written, or simply junk, e.g. because the approach taken has been
too general (I'm thinking of jQuery wanting to handle a method check on DOM
nodes) or the author is a half-wit programmer is a /different/ story.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
David Mark
wrote:
> David Mark wrote:
> > On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> >> On Nov 21, 10:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>> In short, the first three rules of browser scripting are context,
> >>> context, context.
> >> And when the context is unknown to you until the time your code runs,
> >> then what? What's plan B?
>
> > That's the whole point. Optimally, you design script for a specific
> > context (e.g. a certain set of documents.) If the context of your
> > site is unknown to you, then you have much bigger problems.
>
> Yes, *optimally*. However, when you write a *library*, it stands to reason
> that you can't always know the context of its application when you write it.
Presumably you mean a library for use by others.
>
> This is no excuse for unnecessarily bloated code, of course, but it is a
> good reason for writing more general code in a library because that is what
> a library is and should be about, like it or not.
Exactly. That's why writing a *general-purpose* browser scripting
library is silly.
>
> ISTM that you don't see that there can be (at least) two approaches to
> writing a library: One, to start with generalizing for one context and
> refine the library every time you encounter a new context; two, to try to
> write it as general as possible (and reasonable) in the first place so that
> it can be used later without much adaption by its user.
We are talking about a specific type (e.g. third-party, generalized,
do-everything-for-everybody libraries.) They are a terrible idea for
the reasons listed. That doesn't mean you shouldn't organize your own
code for the types of projects that you work on.
>
> Both approaches are taken in their own right. Some people like to develop
> libraries, e.g. to provide efficient algorithms for daily tasks to other
> developers, and nothing else. That a large number of libraries out there
If they are specific enough tasks and the code is well written and
documented then great. But that's not what we are talking about. The
whole thread has degenerated into an attempt to justify poorly written
(and generalized) junk like jQuery and qx00D00 (sp?)
> is badly written, or simply junk, e.g. because the approach taken has been
> too general (I'm thinking of jQuery wanting to handle a method check on DOM
There you go.
> nodes) or the author is a half-wit programmer is a /different/ story.
But it is a related story (at least in this thread.) If all of the gp
libraries are junk (which they certainly are), then that is another
reason to ignore them.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>> On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>>>> On Nov 21, 10:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>> In short, the first three rules of browser scripting are context,
>>>>> context, context.
>>>> And when the context is unknown to you until the time your code runs,
>>>> then what? What's plan B?
>>> That's the whole point. Optimally, you design script for a specific
>>> context (e.g. a certain set of documents.) If the context of your
>>> site is unknown to you, then you have much bigger problems.
>> Yes, *optimally*. However, when you write a *library*, it stands to reason
>> that you can't always know the context of its application when you write it.
>
> Presumably you mean a library for use by others.
Not only, no.
>> This is no excuse for unnecessarily bloated code, of course, but it is a
>> good reason for writing more general code in a library because that is what
>> a library is and should be about, like it or not.
>
> Exactly. That's why writing a *general-purpose* browser scripting
> library is silly.
I don't think you got my meaning right. No, it is _not_ silly to write more
general code. But maybe I misunderstand how you define "general-purpose".
>> [that] the author is a half-wit programmer is a /different/ story.
>
> But it is a related story (at least in this thread.) If all of the gp
> libraries are junk (which they certainly are), then that is another
> reason to ignore them.
Yes, *iff*.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> David Mark wrote:
> >>> On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> >>>> On Nov 21, 10:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>>> In short, the first three rules of browser scripting are context,
> >>>>> context, context.
> >>>> And when the context is unknown to you until the time your code runs,
> >>>> then what? What's plan B?
> >>> That's the whole point. Optimally, you design script for a specific
> >>> context (e.g. a certain set of documents.) If the context of your
> >>> site is unknown to you, then you have much bigger problems.
> >> Yes, *optimally*. However, when you write a *library*, it stands to reason
> >> that you can't always know the context of its application when you write it.
>
> > Presumably you mean a library for use by others.
>
> Not only, no.
Well, third-party libraries and blind faith are the subjects at hand.
>
> >> This is no excuse for unnecessarily bloated code, of course, but it is a
> >> good reason for writing more general code in a library because that is what
> >> a library is and should be about, like it or not.
>
> > Exactly. That's why writing a *general-purpose* browser scripting
> > library is silly.
>
> I don't think you got my meaning right. No, it is _not_ silly to write more
> general code. But maybe I misunderstand how you define "general-purpose".
It is silly to write general-purpose browser scripting libraries as
there are too many variables involved to be reasonably efficient (and
often these variables are filled in by browser sniffing, but that is
another story.) It is and has always been folly to attempt such a
thing.
>
> >> [that] the author is a half-wit programmer is a /different/ story.
>
> > But it is a related story (at least in this thread.) If all of the gp
> > libraries are junk (which they certainly are), then that is another
> > reason to ignore them.
>
> Yes, *iff*.
No. Even if a general-purpose library is perfectly designed and
written, it will still fall short of most context-specific solutions
in terms of efficiency (and performance of course.) As Richard has
stated repeatedly, a repository of lightweight and interchangeable
functions is the best option. Having written solutions both ways, I
can tell you that he is correct.
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> David Mark wrote:
> >>> On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> >>>> On Nov 21, 10:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>>> In short, the first three rules of browser scripting are context,
> >>>>> context, context.
> >>>> And when the context is unknown to you until the time your code runs,
> >>>> then what? What's plan B?
> >>> That's the whole point. Optimally, you design script for a specific
> >>> context (e.g. a certain set of documents.) If the context of your
> >>> site is unknown to you, then you have much bigger problems.
> >> Yes, *optimally*. However, when you write a *library*, it stands to reason
> >> that you can't always know the context of its application when you write it.
>
> > Presumably you mean a library for use by others.
>
> Not only, no.
>
Also, lets take a concrete example of a module you might write for
yourself. Lets say you are charged with writing a script to determine
the offset position of an element. With no context, I can tell you
from experience that the function(s) involved will be relatively large
and complex. But if you knew that the documents in the project have a
relatively positioned body, you can crop out a large chunk of the
code. If you know something about the types of elements involved
(e.g. perhaps none of their containers have borders), you can lose
more of the bloat and complexity. Smaller and simpler is good thing
in browser scripting.
Clearly if you write scripts for every page, they are optimal for
none. There are trade-offs of course. It would be wonderful if you
never had to change scripts due to markup and/or changes but that is
not always possible (at least not practical.) However, if you have
thought through your design carefully, taking into account future
needs, it isn't likely to be a problem. I use more or less the same
basic HTML template for everything, which can be presented and
scripted in so many ways that it works just as well for basic
documents as Web applications. YMMV.
Matt Kruse
> On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> > That's not a convincing argument. If my browser gets 10k of code that
> > isn't needed on page X, but caches it and has in on hand for when page
> > Y needs it, then that isn't so bad. It might be bad to serve 500k of
> > unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
> > the line is up for debate.
> Far South of these ridiculous general-purpose libraries for virtually
> any Web site or application.
That's not helpful to anyone. Care to explain how you would arrive at
a good limit to the amount of code that should be delivered to the
client?
You're right up there with the "I can't define obscenity, but I know
it when I see it" argument.
> > Not at all. What about, for example, an open source tool that is used
> > by many sites and allows the users to create their own themes and
> > layout? If the tool is to have any scripting features, it needs to
> > create them in as generalized a way as possible, to consider as many
> > different DOM structures as it possibly can. The tool authors don't
> > get the chance to go back and selectively choose the code module that
> > will work in a given layout. It has to be generalized. What approach
> > to you recommend they take?
> I want the last 20 seconds of my life back. Why would you bother to
> write such a thing?
Because it's a real-world problem that many people face, and you have
no solution for it. You just choose to ignore situations that don't
fit well within your pre-defined box of solutions.
The trouble is, many people are not working within your model, yet you
still think you have something useful to say to them. You do not.
> > What about writing a "widget" for a webapp that can be inserted on any
> And this.
Have you never done such a thing? You should try it, you may benefit
from a different perspective.
> > page by the app admin? The widget should be self-contained, yet it
> > can't know anything about it's container until it runs.
> You clearly didn't understand what I said. Perhaps one day you will.
Only if you begin to write clearly and make actual statements.
> > What about when a site owner decides to change structure and layout of
> > their site by modifying their page template, but doesn't want to go
> > back and re-write javascript code? Wouldn't a more generalized
> > solution that still works in any design he chooses be the better
> > choice?
> Again, you don't get it.
Ditto.
> > And when the context is unknown to you until the time your code runs,
> > then what? What's plan B?
> That's the whole point. Optimally, you design script for a specific
> context (e.g. a certain set of documents.) If the context of your
> site is unknown to you, then you have much bigger problems.
Not really bigger problems. Just different problems. And ones you
don't know how to address (or choose to ignore).
Of course you would criticize such a situation when you don't have a
solution that is helpful.
You have a hammer, therefore only nails should exist. You wouldn't
know what to do if you saw a screw.
It's easy to think your solution is best when you ignore situations
where your solution doesn't work.
> > A common argument is that the best alternative to a library is to grow
> > your own expert in js coding, who creates his own reusable functions
> > over time and uses them when required.
> Right.
> > This works great in some situations, but is not possible for everyone.
> Are you kidding?
Not at all. But you can ignore the real-world situation again if you
wish.
> That is why *everyone* should not be posing as
> programmers, especially not in browser scripting. (!) That's another
> point you refuse to see after all these months of "debate" on this
> subject.
Nicely dodged again. Just because you don't think a situation is ideal
and should therefore not exist, doesn't make it so.
I'm reminded of a story:
Climber #1: "Help! I'm hanging off the side of this cliff! I'm going
to die! Help me!"
Climber #2: "You shouldn't fall off cliffs to begin with."
Climber #1: "Yes, but I already did, and I'm here. What should I do?"
Climber #2: "Well, you're an idiot for falling off the cliff. The only
sensible solution is to not fall off cliffs."
Climber #1: "That doesn't help me!
Climber #2: "You got yourself into this. Obviously I'm right. You
shouldn't fall off cliffs."
Climber #3: "Here, use this rope!"
Climber #2: "#3, you are an idiot. That rope won't work if there are
sharp rocks, or if the wind is too high, or if climber #1 is not
strong. Just because it may work in some situations doesn't mean it
will work in all. It's foolish to suggest such a solution. He would be
better served if he just didn't fall off cliffs to begin with."
Climber #1: "Ah, thanks #3, that did the trick this time. Maybe I
should reconsider my climbing strategy, but I'll use this rope for
now. #2, you're an idiot."
Wow, great story!
Matt Kruse
Matt Kruse
> > I don't think you got my meaning right. No, it is _not_ silly to write more
> > general code. But maybe I misunderstand how you define "general-purpose".
> It is silly to write general-purpose browser scripting libraries as
> there are too many variables involved to be reasonably efficient (and
> often these variables are filled in by browser sniffing, but that is
> another story.) It is and has always been folly to attempt such a
> thing.
Why? Because you say so? What are your arguments against it?
Just because existing libraries don't live up to your standards is
_not_ an argument against the concept. Just because some libraries use
browser sniffing is _not_ a reason to dismiss them all.
In fact, it seems almost like you are arguing in _favor_ of
generalized libraries, just in a different form than what exists
today. Great! Then we agree!
> No. Even if a general-purpose library is perfectly designed and
> written, it will still fall short of most context-specific solutions
> in terms of efficiency (and performance of course.)
There are different ways to measure efficiency.
To you, performance and code bloat may be the best measures of
efficiency.
To someone else, the least development effort required to provide an
acceptable solution may be the best measure of efficiency.
Computers are fast. Just because there is extra unneeded code or
because a routine is not as optimized as it could be for a given
context doesn't mean that it isn't acceptable. There is always a trade-
off.
I may choose to save 10 hours of development time (a lot of $$$) by
using a library, yet sacrifice 500ms of performance in some operations
and deliver an extra 40k of unneeded code. Who are you to say that is
absolutely the wrong decision? Are you really so narrow-minded? If I
can't afford the 10 hours of development, and the performance hit is
not bothersome to me, isn't it really the best solution to use an
"inefficient" general-purpose library?
And just because my general-purpose library of choice won't get the
right element position if I start using a positioned body, is that
really an argument against it if I _don't have_ such a case? Who cares
if the library can't do X right if I have no intention of doing X? If
it does Y right, and I only want to do Y, then why is it bad?
I would love to hear about a time when you had to write a widget or
component that would be plugged into a bigger system that you had no
control over. Or a time when you had to write script for a site that
may change layouts frequently or even with every request, depending on
user's preferences. Or a time when you designed functionality before
the layout and structure of a site was decided for certain, and you
didn't have the ability to go back and change it later.
If you haven't found yourself in such situations, then you lack a
perspective that is required to intelligently talk about generalized
solutions and libraries, IMO.
Matt Kruse
David Mark
> On Nov 22, 12:10 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Nov 22, 9:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> > > That's not a convincing argument. If my browser gets 10k of code that
> > > isn't needed on page X, but caches it and has in on hand for when page
> > > Y needs it, then that isn't so bad. It might be bad to serve 500k of
> > > unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
> > > the line is up for debate.
> > Far South of these ridiculous general-purpose libraries for virtually
> > any Web site or application.
>
> That's not helpful to anyone. Care to explain how you would arrive at
> a good limit to the amount of code that should be delivered to the
> client?
Depends on the context doesn't it?
> You're right up there with the "I can't define obscenity, but I know
> it when I see it" argument.
Irrelevant babbling.
>
> > > Not at all. What about, for example, an open source tool that is used
> > > by many sites and allows the users to create their own themes and
> > > layout? If the tool is to have any scripting features, it needs to
> > > create them in as generalized a way as possible, to consider as many
> > > different DOM structures as it possibly can. The tool authors don't
> > > get the chance to go back and selectively choose the code module that
> > > will work in a given layout. It has to be generalized. What approach
> > > to you recommend they take?
> > I want the last 20 seconds of my life back. Why would you bother to
> > write such a thing?
>
> Because it's a real-world problem that many people face, and you have
> no solution for it. You just choose to ignore situations that don't
> fit well within your pre-defined box of solutions.
No. Why would you write such a paragraph? Do you not understand the
term "context?" Hint: all you have done is name a context where
scripts would be relatively more generalized. Doesn't really add
anything does it?
>
> The trouble is, many people are not working within your model, yet you
> still think you have something useful to say to them. You do not.
Oh brother. This from you?
>
> > > What about writing a "widget" for a webapp that can be inserted on any
> > And this.
>
> Have you never done such a thing? You should try it, you may
Groan. You know I have.
> benefit from a different perspective.
You know much better than that.
[snip]
>
> I'm reminded of a story:
>
I'm reminded of what an idiot you are.
Brian Adkins
> No. Even if a general-purpose library is perfectly designed and
> written, it will still fall short of most context-specific solutions
> in terms of efficiency (and performance of course.) As Richard has
> stated repeatedly, a repository of lightweight and interchangeable
> functions is the best option. Having written solutions both ways, I
> can tell you that he is correct.
It's possible that when some folks are requesting information on
"JavaScript libraries", you hear "general purpose framework", when in
fact they simply mean JavaScript code that may be reused such as
"lightweight and interchangeable functions". If so, communication may
be difficult.
David Mark
> David Mark <dmark.cins...@gmail.com> writes:
> > No. Even if a general-purpose library is perfectly designed and
> > written, it will still fall short of most context-specific solutions
> > in terms of efficiency (and performance of course.) As Richard has
> > stated repeatedly, a repository of lightweight and interchangeable
> > functions is the best option. Having written solutions both ways, I
> > can tell you that he is correct.
>
> It's possible that when some folks are requesting information on
> "JavaScript libraries", you hear "general purpose framework", when in
Not likely as a context is rarely specified (as in the case of this
thread.)
David Mark
Just to clear up any further confusion, the unqualified term
"Javascript library" has no real meaning, other than it is a blob of
Javascript. Qualify it with "general purpose" and the connotation is
that it abstracts basic browser scripting tasks (e.g. DOM
manipulation, event handling.) Add "third-party" to it (which is what
we normally discuss here) and it becomes synonymous with garbage.
Frameworks are just libraries with lots of added bloat (so they are
even less appropriate for scripting Web pages.)
Libraries are typically designed and tested as a unit and often cannot
be deconstructed to leverage their parts. One of the most egregious
3rd-party examples (which was inexplicably popular at one time) of
this is Prototype. Back when it came out, lots of sites added 150K
(or so) of tangled up and highly inefficient script to their sites to
leverage one special effect. No good.
Then there was this ridiculous race to "pave over" every known browser
quirk. Of course, this is asking scripts to do the impossible. Did
the authors stop to consider their foolishness? No, they resorted to
user agent based browser sniffing. This is obviously inappropriate
for Web pages.
Did you ever wonder why these libraries are written almost exclusively
by people new to the language? Big surprise, they didn't know what
they were doing. And now that lots of clueless Web developers have
parked these things on their sites, they can't tear them down and
rewrite them.
The alternative, as recommended here repeatedly, is to concentrate on
writing re-usable functions. For example, a wrapper for gEBI could be
anywhere from one to a dozen lines, depending on compatibility
requirements and the competence of those writing the markup (ideally
that is also the person writing the scripts.) So start with the
obvious one (one line that calls the host method) and build more
robust versions as needed. Then do gEBTN. At that point, you will
(hopefully) have learned something about the language, DOM, etc. and
will understand exactly when to use which versions of the functions
(and where to look if something goes wrong.)
The popular trend of dumping 50-100K (at least) of ridiculously
generalized CSS selector code from unreliable sources onto a site to
"simplify" the retrieval of DOM elements is the last resort of the
lost. Most pages should be under 50K as dial-up is still very much in
use. So, as a browser scripting professional, should you use up all
of that at the design stage, on a script that you don't even
understand? Furthermore, should you exclude users who use something
other than a handful of modern browsers in their default
configurations? Ask this of virtually any "library jockey" and they
will reply with something like "Jquery Rules dude!" Hell, I asked
similar questions of the jQuery author, including lots of pointers on
how to fix his mangled and ill-conceived code and the response was
similar.
Matt Kruse
> Most pages should be under 50K as dial-up is still very much in
> use.
No one I know uses dial-up. It's probably in the low single digits
percentage-wise. If they do, then they probably aren't interested in
anything I'm creating, nor do I really concern myself with their web
experience. They are surely used to a painfully slow and unusable web
already.
50k seems arbitrary, anyway.
> Furthermore, should you exclude users who use something
> other than a handful of modern browsers in their default
> configurations?
I'm tired of hearing this phrase. Feels like an stump speech repeated
100 times.
A "handful of modern browsers in their default configurations"
accounts for just less than 100% of all visitors to most web sites.
You could rephrase it as "should you exclude the 1% of people who use
browsers different than most others?"
Matt Kruse
David Mark
> On Nov 22, 8:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Most pages should be under 50K as dial-up is still very much in
> > use.
>
> No one I know uses dial-up.
Ah, the old "nobody I know" justification.
>It's probably in the low single digits
> percentage-wise. If they do, then they probably aren't interested in
Obviously depends on which country. And you might as well consider
phones as dial-up with serious weight restrictions to boot.
> anything I'm creating, nor do I really concern myself with their web
Who is asking about what you do? We are talking primarily about
Websites.
> experience. They are surely used to a painfully slow and unusable web
> already.
So why not make it completely impossible? Your clients will love it.
> 50k seems arbitrary, anyway.
http://www.websiteoptimization.com/services/analyze/
>
> > Furthermore, should you exclude users who use something
> > other than a handful of modern browsers in their default
> > configurations?
>
> I'm tired of hearing this phrase. Feels like an stump speech repeated
> 100 times.
I am sure it is unwelcome for any user of jQuery. It pretty much
deflates any of those "there are no other browsers that I care about"
arguments.
>
> A "handful of modern browsers in their default configurations"
> accounts for just less than 100% of all visitors to most web sites.
And you know this how? Even if it were true, define "just less" and
then try to justify excluding that percentage of umpteen billion
potential leads to a client. Explain that you arbitrarily excluded
all of them at the design stage due to some made-up statistic.
>
> You could rephrase it as "should you exclude the 1% of people who use
> browsers different than most others?"
Excluding anywhere near 1% is ridiculous. Excluding anyone due to
ignorance and/or incompetence is outrageous (but very much the norm
these days.)
Matt Kruse
> > A "handful of modern browsers in their default configurations"
> > accounts for just less than 100% of all visitors to most web sites.
> And you know this how? Even if it were true, define "just less" and
> then try to justify excluding that percentage of umpteen billion
> potential leads to a client.
"Bob, we typically use a common scripting library named X. We do so
because we've found that it decreases our development time by 50% and
decreases bugs by 50%. We can get your site up and running in less
time, but there is a chance that a very small portion of users will
encounter scripting problems because they are using old or uncommon
browsers. In our experience we've not yet encountered a situation
where this was actually a problem, but it could in theory happen. So
if you would like, we could add several thousand dollars to our
estimate to correctly handle the fraction of 1% of users who may
someday, in theory, encounter a problem. It's up to you."
Not that I would ever have that conversation myself, but it does
happen.
> Excluding anywhere near 1% is ridiculous.
Not really. It's a business decision. It happens all the time. In
fact, companies knowingly exclude much bigger chunks than 1%. Are you
not aware of that?
Matt Kruse
David Mark
> On Nov 22, 10:05 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > A "handful of modern browsers in their default configurations"
> > > accounts for just less than 100% of all visitors to most web sites.
> > And you know this how? Even if it were true, define "just less" and
> > then try to justify excluding that percentage of umpteen billion
> > potential leads to a client.
>
> "Bob, we typically use a common scripting library named X. We do so
Bob? What is this play acting?
> because we've found that it decreases our development time by 50% and
And increases load time for our users by 300%.
> decreases bugs by 50%. We can get your site up and running in less
Well, we don't really know how many bugs it has at any given moment.
It uses browser sniffing. Yeah, I know. What do you mean fired?!
> time, but there is a chance that a very small portion of users will
> encounter scripting problems because they are using old or uncommon
Or very new ones half-wit. Mobile devices with scriptable HTML
browsers are *everywhere*. Chances are somebody you know has one.
> browsers. In our experience we've not yet encountered a situation
Your experience with what? These things are silent killers (on the
Internet, there's nobody to hear you scream.) You couldn't mean the
old "haven't heard any complaints" argument. The disgruntled don't
bother and the excluded obviously can't contact you.
> where this was actually a problem, but it could in theory happen. So
> if you would like, we could add several thousand dollars to our
> estimate to correctly handle the fraction of 1% of users who may
Again with the 1%.
> someday, in theory, encounter a problem. It's up to you."
Or you can hire a *competent* developer.
>
> Not that I would ever have that conversation myself, but it does
> happen.
So the act was a work of fiction, much like most of your other posts.
I can tell you that if you ever had that conversation with me (or any
of my clients), you would be put out on your ass forthwith.
>
> > Excluding anywhere near 1% is ridiculous.
>
> Not really. It's a business decision. It happens all the time. In
Yes, indeed. It is a business decision. And businesses are informed
by supposed experts. Woe is the company that mistakes you for one.
Thomas 'PointedEars' Lahn
> On Nov 22, 8:02 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>> It's possible that when some folks are requesting information on
>> "JavaScript libraries", you hear "general purpose framework", when in
>> fact they simply mean JavaScript code that may be reused such as
>> "lightweight and interchangeable functions". If so, communication may
>> be difficult.
>
> Just to clear up any further confusion, the unqualified term
> "Javascript library" has no real meaning, other than it is a blob of
> Javascript.
You seem to have a strange understanding about the term "library" in general.
> [...]
> Libraries are typically designed and tested as a unit and often cannot
> be deconstructed to leverage their parts.
That does not necessarily apply to *script* libraries as a programming
concept, though.
> [ex falso quodlibet snipped]
Matt Kruse
> [blah blah blah]
I'm not sure why I get drawn into responding to your drivel, but I
quickly get reminded of what a waste of time it is to try to have any
kind of intelligent exchange with you. I'll stop.
Matt Kruse
Kenny
And in my case with an internal web application I did have the
conversation, I did lay out the alternatives, and the answer was, "It
works on Safari, Chrome, and FireFox? Fine, we'll use Safari."
They too have their eye on the prize and are not distracted by nonsense.
Not that I won't look for the problem on IE, just at the most rational time.
kt
Kenny
Club joined.
I may have to blog on this soon, "Solve the Right Problem". Mr. Mark
acknowledges lotsa folks are using frameworks, mainly because the Web is
way cool and folks want to offer stuff on it and they will do what it
takes to get it done /now/, not sign on for his ten-year apprenticeship.
But he is right, these things are a bear on start-up because of the big
initial downlaod.
So what is the right problem? That lotsa people want to program the web?
No. That they are using the wrong tool? No, none of the haters on this
group pointed to The Compleat Repository of Reusable Ajax Wonderfulness.
Oh, look, the only problem is big downloads. It is not an urgent problem
apparently, but it would be wonderful to eliminate cuz eevryone loves
fast esp. on the Web.
So as I said, the solution is something like a tree-shaking build
process that tosses everything I do not use. This is truly an exercise
for the same geniuses who gave us optimizing compilers.
Lars Rune Nøstdal
interested in the work of "competent developers".
I'd like to see or hear about an application of yours with a web UI (I
have clients who use both Windows and Mac; some even run this new Linux
thing!) where you have 100% coverage wrt. browsers.
It must be an actual interesting and/or _useful_ application. Something
that's used by or could be used by a business. It probably has a DB
backend and is highly dynamic "by nature". There are a lot of variables
the user would like to change and manipulate to do his work.
It should not redraw the entire UI each time the user picks a different
item in drop-down boxes etc., because we do not like to waste bandwidth
and we like fast response times. I guess this means one will have to use
something like AJAX.
It should maintain state if the user where to press the "Refresh" button
in his browser for some reason, and it should maintain browser history
(back/forward buttons).
We are not interested in deploying a custom application (Qi, Gtk+ etc.)
for this; it must be a web application or use a web UI. If you cannot
provide this, we will look elsewhere. That would be all. Kthnx.
PS: I'll be having the Links and Closure browsers ready for testing.
Lars Rune Nøstdal
> We are not interested in deploying a custom application (Qi, Gtk+
> etc.)
Make that Qt.
Kenny
> I'd like to see or hear about some of your work, David Mark. I'm
> interested in the work of "competent developers".
>
> I'd like to see or hear about an application of yours with a web UI (I
> have clients who use both Windows and Mac; some even run this new Linux
> thing!) where you have 100% coverage wrt. browsers.
>
> It must be an actual interesting and/or _useful_ application. Something
> that's used by or could be used by a business. It probably has a DB
> backend and is highly dynamic "by nature". There are a lot of variables
> the user would like to change and manipulate to do his work.
>
> It should not redraw the entire UI each time the user picks a different
> item in drop-down boxes etc., because we do not like to waste bandwidth
> and we like fast response times. I guess this means one will have to use
> something like AJAX.
>
> It should maintain state if the user where to press the "Refresh" button
> in his browser for some reason, and it should maintain browser history
> (back/forward buttons).
>
> We are not interested in deploying a custom application (Qi, Gtk+ etc.)
Careful, qooxdoo wants to blur the lines:
"Despite being a pure JavaScript framework, qooxdoo is quite on par with
GUI toolkits like Qt or SWT when it comes to advanced yet easy to
implement user interfaces." http://qooxdoo.org/about
I can confirm they have succeeded, tho of course I have not shipped yet
so we can keep alive another week Mr. Mark's dream of me losing my contrat.
This knocked me over: for some reason none of these frameworks wants to
mix a server-side paging data model with a treeview. I have a too-big
tree to serve all at once. Luckily, it is only 3+k nodes at the top. So
I loaded all 3+k and left the leaves behind for JIT serving. Super, nice
and zippy. Now <groan> I have to implement the JIT thing. Track down the
node open event, detect it is the first time, code up the separate load.
...searching for event...o. my. god. They have a dedicated event for
"open empty tree". Mr. Mark suggested I was not competent to judge
anything, the bad news is I have these handy shortcuts that do tell me
pretty reliably when a group of developers cares as much about code as I
do, and once I detect that I sleep pretty well.
Elsewhere I saw someone groaning about qooxie introducing OO to JS. The
thing is, if you are a good programmer you can get good mileage out of
OO. I am doing great with my OO-lite leverage of what they have done.
Getting back to qooxie poaching on Qt, yeah, that is where I am at. I am
now programming the Web with a *very* nice application framework. Mr.
Mark apparently does not know enough about programming to understand how
this is possible, but I simply am not thinking about HTML/CSS anymore,
even though that is what I am serving. Except:
Just for fun I took one bit where the server returned the HTML banner
for the search results "N things found in J places" and used the qooxdoo
"embed" widget that takes straight HTML.
My Web app is rapidly materializing even tho I do not even have the
pedal to the metal -- I am pretty wasted after three weeks of learning
first Dojo then YUI then qooxdoo. And the app is /slick/, giving the
user an experience Mr. Mark's users will never experience because he is
hunkered down with the assembly language of the Web worrying about 28k
modems.
I have a top-notch, compleat framework (qooxdoo) and I have Lisp. Stand
back, Argentina!
hth,kzo
John G Harris
wrote:
>On Nov 22, 8:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Most pages should be under 50K as dial-up is still very much in
>> use.
>
>No one I know uses dial-up.
So that's a million families in the UK you don't know.
>It's probably in the low single digits
>percentage-wise. If they do, then they probably aren't interested in
>anything I'm creating, nor do I really concern myself with their web
>experience. They are surely used to a painfully slow and unusable web
>already.
Q: Why does Google's home page load so quickly ?
A: Because it's so easy to switch to another search engine.
John
--
John Harris
Kenny
Agreed, one has to be rational. Our situation is an internal Web app
used for quite a while when used at all, probably just left open by
people in certain departments.
In a case like google, I'd just use the qooxdoo core, or one of the
minimalist libraries. Why? This is the group that keeps talking baout
browser variability--so now I need to learn them all?
See wheel. Re-invent?
kt
Matt Kruse
> Q: Why does Google's home page load so quickly ?
> A: Because it's so easy to switch to another search engine.
Design decisions depend on your goal and your audience.
Google wants to reach anyone and everyone. Simple works for them.
If I create a web site for my daughter's soccer team, I only care
about a small audience. I don't really care about loading time or
performance. Using a library that lets me create the site quickly and
easily for my audience of 25 people is _way_ more sensible than
writing custom javascript code to add some animations and interaction
that makes it fun and useful for everyone.
People like David and others tend to only focus on e-commerce sites or
other sites that are apparently trying to reach the whole world. The
vast majority of development on the web does not fall into this
category.
Matt Kruse
David Mark
wrote:
> David Mark wrote:
> > On Nov 22, 8:02 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> >> It's possible that when some folks are requesting information on
> >> "JavaScript libraries", you hear "general purpose framework", when in
> >> fact they simply mean JavaScript code that may be reused such as
> >> "lightweight and interchangeable functions". If so, communication may
> >> be difficult.
>
> > Just to clear up any further confusion, the unqualified term
> > "Javascript library" has no real meaning, other than it is a blob of
> > Javascript.
>
> You seem to have a strange understanding about the term "library" in general.
You seem to have a pedantic bent.
>
> > [...]
> > Libraries are typically designed and tested as a unit and often cannot
> > be deconstructed to leverage their parts.
>
> That does not necessarily apply to *script* libraries as a programming
> concept, though.
That's why I said "typically."
David Mark
> Matt Kruse wrote:
> > On Nov 22, 11:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >>[blah blah blah]
>
> > I'm not sure why I get drawn into responding to your drivel, but I
> > quickly get reminded of what a waste of time it is to try to have any
> > kind of intelligent exchange with you. I'll stop.
>
> Club joined.
Thank you. Your incessant blithering was getting tired.
>
> I may have to blog on this soon, "Solve the Right Problem". Mr. Mark
That should be good for a laugh.
> acknowledges lotsa folks are using frameworks, mainly because the Web is
> way cool and folks want to offer stuff on it and they will do what it
> takes to get it done /now/, not sign on for his ten-year apprenticeship.
You already explained that you are in way over your head (probably due
to some deception on your part) and will be sacked in two weeks if you
can't cobble some illusion of a solution together. The libraries are
perfect for you. Now your client...
>
> But he is right, these things are a bear on start-up because of the big
> initial downlaod.
Thanks for that, but it the problems run far deeper.
>
> So what is the right problem? That lotsa people want to program the web?
I don't know what that means. The right problem?
> No. That they are using the wrong tool? No, none of the haters on this
YES. They are using the wrong tool(s). And if there is one thing I
*hate* it is clueless newcomers who cop outrageous attitudes from jump
street (especially those without proper names.)
> group pointed to The Compleat Repository of Reusable Ajax Wonderfulness.
Your best bet is to forget you ever heard of Ajax.
> Oh, look, the only problem is big downloads. It is not an urgent problem
It is not the only problem, but it is a big one.
> apparently, but it would be wonderful to eliminate cuz eevryone loves
> fast esp. on the Web.
>
> So as I said, the solution is something like a tree-shaking build
> process that tosses everything I do not use. This is truly an exercise
> for the same geniuses who gave us optimizing compilers.
Could you possibly be more out of touch? Try Googling for: "browser
scripting" library builder. What is hit #2? Now read for a while
before your next post.
David Mark
> I'd like to see or hear about some of your work, David Mark. I'm
> interested in the work of "competent developers".
You've come to the right place.
>
> I'd like to see or hear about an application of yours with a web UI (I
> have clients who use both Windows and Mac; some even run this new Linux
> thing!) where you have 100% coverage wrt. browsers.
Would you?
>
> It must be an actual interesting and/or _useful_ application. Something
> that's used by or could be used by a business. It probably has a DB
> backend and is highly dynamic "by nature". There are a lot of variables
> the user would like to change and manipulate to do his work.
>
> It should not redraw the entire UI each time the user picks a different
> item in drop-down boxes etc., because we do not like to waste bandwidth
> and we like fast response times. I guess this means one will have to use
> something like AJAX.
Not necessarily.
>
> It should maintain state if the user where to press the "Refresh" button
Cookies?
> in his browser for some reason, and it should maintain browser history
> (back/forward buttons).
Yes, breaking history is an ignorant thing to do. And all you have to
do is not do it. Odd that most Ajax developers don't get that.
>
> We are not interested in deploying a custom application (Qi, Gtk+ etc.)
Whatever.
> for this; it must be a web application or use a web UI. If you cannot
> provide this, we will look elsewhere. That would be all. Kthnx.
Wherever you look, you will have to specify what you want. A "Web UI"
is pretty vague.
>
> PS: I'll be having the Links and Closure browsers ready for testing.
Lynx? Yes, my documents look (oddly enough) like text documents in
text-based browsers (and they are readable.) Never heard of Closure,
so thank heavens I don't use browser sniffing.
David Mark
Whatever.
David Mark
> Lars Rune Nøstdal wrote:
> > I'd like to see or hear about some of your work, David Mark. I'm
> > interested in the work of "competent developers".
>
> > I'd like to see or hear about an application of yours with a web UI (I
> > have clients who use both Windows and Mac; some even run this new Linux
> > thing!) where you have 100% coverage wrt. browsers.
>
> > It must be an actual interesting and/or _useful_ application. Something
> > that's used by or could be used by a business. It probably has a DB
> > backend and is highly dynamic "by nature". There are a lot of variables
> > the user would like to change and manipulate to do his work.
>
> > It should not redraw the entire UI each time the user picks a different
> > item in drop-down boxes etc., because we do not like to waste bandwidth
> > and we like fast response times. I guess this means one will have to use
> > something like AJAX.
>
> > It should maintain state if the user where to press the "Refresh" button
> > in his browser for some reason, and it should maintain browser history
> > (back/forward buttons).
>
> > We are not interested in deploying a custom application (Qi, Gtk+ etc.)
>
> Careful, qooxdoo wants to blur the lines:
You've been told why to avoid that, yet you are suddenly its #1 fan.
>
> "Despite being a pure JavaScript framework, qooxdoo is quite on par with
> GUI toolkits like Qt or SWT when it comes to advanced yet easy to
> implement user interfaces."http://qooxdoo.org/about
>
> I can confirm they have succeeded, tho of course I have not shipped yet
And I can confirm that "Kenny" hasn't the slightest clue what he is
talking about.
> so we can keep alive another week Mr. Mark's dream of me losing my contrat.
I've marked it on my calendar.
>
> This knocked me over: for some reason none of these frameworks wants to
> mix a server-side paging data model with a treeview. I have a too-big
> tree to serve all at once. Luckily, it is only 3+k nodes at the top. So
> I loaded all 3+k and left the leaves behind for JIT serving. Super, nice
> and zippy. Now <groan> I have to implement the JIT thing. Track down the
> node open event, detect it is the first time, code up the separate load.
LOL. Good luck with that!
>
> ...searching for event...o. my. god. They have a dedicated event for
> "open empty tree". Mr. Mark suggested I was not competent to judge
> anything, the bad news is I have these handy shortcuts that do tell me
> pretty reliably when a group of developers cares as much about code as I
> do, and once I detect that I sleep pretty well.
Seems you slept through this entire thread.
>
> Elsewhere I saw someone groaning about qooxie introducing OO to JS. The
> thing is, if you are a good programmer you can get good mileage out of
> OO. I am doing great with my OO-lite leverage of what they have done.
Great?
>
> Getting back to qooxie poaching on Qt, yeah, that is where I am at. I am
> now programming the Web with a *very* nice application framework. Mr.
> Mark apparently does not know enough about programming to understand how
> this is possible, but I simply am not thinking about HTML/CSS anymore,
> even though that is what I am serving. Except:
What an idiot.
>
> Just for fun I took one bit where the server returned the HTML banner
> for the search results "N things found in J places" and used the qooxdoo
> "embed" widget that takes straight HTML.
Sounds great!
>
> My Web app is rapidly materializing even tho I do not even have the
> pedal to the metal -- I am pretty wasted after three weeks of learning
> first Dojo then YUI then qooxdoo. And the app is /slick/, giving the
> user an experience Mr. Mark's users will never experience because he is
> hunkered down with the assembly language of the Web worrying about 28k
> modems.
Keep thinking that, slick.
>
> I have a top-notch, compleat framework (qooxdoo) and I have Lisp. Stand
> back, Argentina!
You are delusional.
David Mark
Don't program for all of them. Program for none of them.
>
> See wheel. Re-invent?
>
Can you possibly be any more ignorant (or blind?) Browser sniffing is
not a wheel (e.g. it is not useful.)
Lars Rune Nøstdal
David Mark
> On Nov 23, 11:45 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
> > Q: Why does Google's home page load so quickly ?
> > A: Because it's so easy to switch to another search engine.
>
> Design decisions depend on your goal and your audience.
Thanks professor.
>
> Google wants to reach anyone and everyone. Simple works for them.
Works for virtually anybody. But who is preaching simple? I am all
for scripted enhancements when they are done competently (virtually
never.)
>
> If I create a web site for my daughter's soccer team, I only care
> about a small audience. I don't really care about loading time or
> performance. Using a library that lets me create the site quickly and
You would do that to your kid's team? You are a monster. But
seriously, how is this latest fantasy relevant to the discussion?
> easily for my audience of 25 people is _way_ more sensible than
> writing custom javascript code to add some animations and interaction
> that makes it fun and useful for everyone.
See, if you actually wrote scripts (rather than rearrange the works of
others), you would be stocked up on animation code by now. And how
would animations be useful for a soccer team page?
>
> People like David and others tend to only focus on e-commerce sites or
People like me? You don't know me. And the characterization is
predictably false.
> other sites that are apparently trying to reach the whole world. The
> vast majority of development on the web does not fall into this
> category.
The vast majority of the *World* Wide Web is not intended for the
whole world? How very interesting. What about urban areas in the
US? Are they part of the world? Hint: dial-up is prevalent in those
areas.
You haven't got a clue have you?
Gregor Kofler
> Ok, you have nothing. Just as I thought. Neeeext!
Seems as if this group is currently flooded with first-class nitwits.
(And since you're not the brightest bulb on the tree - I'm not talking
about David.)
Gregor
Lars Rune Nøstdal
Ah, but let's see what you got then; something that does "the right
thing" and is useful.
Anything at all? Not much code yet you say? Thought so.
Gregor Kofler
> Anything at all? Not much code yet you say? Thought so.
Ok. You had your 15 minutes of fame. Neeeext!
Lars Rune Nøstdal
haha :)
no, really .. i'd like to be proven wrong
i googled your name; you have some nice stuff .. does it do "the right
thing"?
(..and wrt. david; does it support the last 1%? .. rofl; what a friggin
moron)
David Mark
What are you babbling about now?
Lars Rune Nøstdal
..you didn't get it the first time?
David Mark
Yes, I suspect this one is a shill for Q*XD00 (sp?) Every time I
trash one of these libraries, somebody shows up with the old "where's
your way-cool cross-browser scripting framework?" argument (as if that
was an argument!)
Google-challenged as usual. What planet do these people come from?
David Mark
Uh, no.
Kenny
I did google, because just as a developer I hate waiting 6-15 seconds
for a development iteration.
google says you are dreaming and doing nothing to help anyone except
your personal desire to piss all over people.
That you are helping great!
kxo
David Mark
> David Mark wrote:
> > On Nov 23, 4:30 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>
> >>Lars Rune Nøstdal meinte:
>
> >>>Ok, you have nothing. Just as I thought. Neeeext!
>
> >>Seems as if this group is currently flooded with first-class nitwits.
> >>(And since you're not the brightest bulb on the tree - I'm not talking
> >>about David.)
>
> > Yes, I suspect this one is a shill for Q*XD00 (sp?) Every time I
> > trash one of these libraries, somebody shows up with the old "where's
> > your way-cool cross-browser scripting framework?" argument (as if that
> > was an argument!)
>
> > Google-challenged as usual. What planet do these people come from?
>
> I did google, because just as a developer I hate waiting 6-15 seconds
> for a development iteration.
Huh?
>
> google says you are dreaming and doing nothing to help anyone except
> your personal desire to piss all over people.
LOL. Blind as a bat apparently.
[snip]
Kenny
> Lars Rune Nøstdal meinte:
>
>> Ok, you have nothing. Just as I thought. Neeeext!
>
>
> Seems as if this group is currently flooded with first-class nitwits.
If by "nitwit" you mean "people actually doing productive work under
deadline to help enterprises as best they can".......yes! Hi, Mom!
> (And since you're not the brightest bulb on the tree - I'm not talking
> about David.)
Sweet, This group seems not to actually know all that much (or we would
see useful information from the haters) and... well, what is it? What an
ugly group of pissantes you are! Zero redeeming technical value.
Is it that you have labored for years to master browser invariability
and now someone is sellinng solutions off the shelf, either turning your
investemnet into sawdust or depriving you of employment, whichever hurts
most? Yeah, dinosaurhood sucks, been there, done that. Any one need a
VAX/VMS genius? (not)
Friendly tip: you might want to find some other way to survive the
asteroid strike, this one aint workin. Try my idea: the anti-framework.
A 4k framework that solves 90% of the problem.
peace, kxo
David Mark
> Gregor Kofler wrote:
> > Lars Rune Nøstdal meinte:
>
> >> Ok, you have nothing. Just as I thought. Neeeext!
>
> > Seems as if this group is currently flooded with first-class nitwits.
>
> If by "nitwit" you mean "people actually doing productive work under
> deadline to help enterprises as best they can".......yes! Hi, Mom!
More along the lines of "people desperately trying to delude
themselves (and their clients) that they can do a job that they are
hopelessly unqualified to do." (and posting lots of less-than-lucid
rants in the process.) We've seen it over and over. Good luck with
that!
>
> > (And since you're not the brightest bulb on the tree - I'm not talking
> > about David.)
>
> Sweet, This group seems not to actually know all that much (or we would
> see useful information from the haters) and... well, what is it? What an
> ugly group of pissantes you are! Zero redeeming technical value.
To wit.
>
> Is it that you have labored for years to master browser invariability
> and now someone is sellinng solutions off the shelf, either turning your
Who is "selling solutions off the shelf?" Perhaps some are trying,
but I doubt they have many takers (other than desperate incompetents
like you.)
[snip rambling nonsense]
Kenny
> You already explained that you are in way over your head (probably due
> to some deception on your part) and will be sacked in two weeks if you
> can't cobble some illusion of a solution together. The libraries are
> perfect for you. Now your client...
David, you ignorant slut. The client approached me for this task because
they wanted a Lisp solution.* I warned them I would have to take a few
days to figure out if I could even help them. In fact, the invite was so
vague it was not clear they meant Web2 app building or I would have
turned it down out of hand.
Instead in five days I gave them a working protoype using nothing but
your cherished HTML/CSS. In a few weeks my screens were in the CEO's
office for an important demo.
You may now apologize and acknowledge your master.
kzo
* The one thing I do /not/ like about qooxology is the loss of the
declarative thing: it's gonna take a little Lisp macrology to get that
back.
Lars Rune Nøstdal
> On Nov 23, 4:30 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> > Lars Rune Nøstdal meinte:
> >
> > > Ok, you have nothing. Just as I thought. Neeeext!
> >
> > Seems as if this group is currently flooded with first-class nitwits.
> > (And since you're not the brightest bulb on the tree - I'm not talking
> > about David.)
> >
>
> Yes, I suspect this one is a shill for Q*XD00 (sp?) Every time I
> trash one of these libraries, somebody shows up with the old "where's
> your way-cool cross-browser scripting framework?" argument (as if that
> was an argument!)
I don't care either way tbh. I'm stuck using plain old HTML for simple
UI "widgets" at the moment.
This does work for now, but it would be great if there was something out
there (for later, when I really need it) that "did the right thing(?)"
and had some useful higher-level widgets at the same time.
> Google-challenged as usual. What planet do these people come from?
Yeah, let's try Google. I can do this .. .. I guess this is it:
http://www.cinsoft.net/mylib.html
Ok, this is a collection code that supposedly "does the right thing"?
Great!
(trac is down btw. .. but trac is always down)
I had to click around a bit to find (create?) some examples:
http://www.cinsoft.net/mylib-builder.asp
..then "Select All", then "Test HTML" -- and we have some widgets.
I like the Sidebars idea.
The window on "Handles and Initiation" has some problems on FF-3.0.3.
When I click the Size button and move the mouse a bit, the window
instantly "jumps" to a very large vertical size.
..but it's not like the, say, jQuery UI or qoxowhatever stuff has
problems too.
..what now?
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>>> On Nov 22, 8:02 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>>>> It's possible that when some folks are requesting information on
>>>> "JavaScript libraries", you hear "general purpose framework", when in
>>>> fact they simply mean JavaScript code that may be reused such as
>>>> "lightweight and interchangeable functions". If so, communication may
>>>> be difficult.
>>> Just to clear up any further confusion, the unqualified term
>>> "Javascript library" has no real meaning, other than it is a blob of
>>> Javascript.
>> You seem to have a strange understanding about the term "library" in general.
>
> You seem to have a pedantic bent.
I'm so glad we've finally talked about it, dude.
>>> [...]
>>> Libraries are typically designed and tested as a unit and often cannot
>>> be deconstructed to leverage their parts.
>> That does not necessarily apply to *script* libraries as a programming
>> concept, though.
>
> That's why I said "typically."
Asterisks are used in Usenet to emphasize words. Emphasis is a means to
point out the increased importance of a word or phrase in a statement.
HTH
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
David Mark
> On Sun, 2008-11-23 at 14:06 -0800, David Mark wrote:
> > On Nov 23, 4:30 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> > > Lars Rune Nøstdal meinte:
>
> > > > Ok, you have nothing. Just as I thought. Neeeext!
>
> > > Seems as if this group is currently flooded with first-class nitwits.
> > > (And since you're not the brightest bulb on the tree - I'm not talking
> > > about David.)
>
> > Yes, I suspect this one is a shill for Q*XD00 (sp?) Every time I
> > trash one of these libraries, somebody shows up with the old "where's
> > your way-cool cross-browser scripting framework?" argument (as if that
> > was an argument!)
>
> I don't care either way tbh. I'm stuck using plain old HTML for simple
> UI "widgets" at the moment.
>
> This does work for now, but it would be great if there was something out
> there (for later, when I really need it) that "did the right thing(?)"
> and had some useful higher-level widgets at the same time.
But what is the right thing for your project? Context is everything.
>
> > Google-challenged as usual. What planet do these people come from?
>
> Yeah, let's try Google. I can do this .. .. I guess this is it:
>
> http://www.cinsoft.net/mylib.html
Well spotted.
>
> Ok, this is a collection code that supposedly "does the right thing"?
> Great!
More or less. See the discussion group for a few bug reports and I am
not happy with some of the code (it is a year later of course.) I
haven't touched any of it since last March, so there could indeed be
issues with newer browsers (even feature testing requires a little
maintenance.) On projects, I make a build of the required features
and then trim it to the bare minimum needed for the context.
>
> (trac is down btw. .. but trac is always down)
No, the entire "Code Worth Recommending" site is down. That is
something else entirely. One of these days I will rewrite the page to
eliminate those references. Not a big priority at the moment. There
is no trac, just a builder. Whenever I update it, I will post the
specific changes to the discussion group.
>
> I had to click around a bit to find (create?) some examples:
>
> http://www.cinsoft.net/mylib-builder.asp
There is a link to that on every page.
>
> ..then "Select All", then "Test HTML" -- and we have some widgets.
Er. Sort of. The only widget per se is a faux alert box (on
steroids.)
>
> I like the Sidebars idea.
Thanks, me too. Of course, they really weren't my idea.
>
> The window on "Handles and Initiation" has some problems on FF-3.0.3.
Okay. I don't know that I have ever tested any of it with the latest
FF or Opera.
> When I click the Size button and move the mouse a bit, the window
> instantly "jumps" to a very large vertical size.
The expected behavior is something similar to clicking the "size" menu
item on a Windows control menu. Last I checked it was fine, but I
know there is another bug related to dragging a fixed position
"widget" with a relatively positioned caption. I blew that one
initially and have since fixed it on some projects, but never updated
the public version.
>
> ..but it's not like the, say, jQuery UI or qoxowhatever stuff has
> problems too.
Do they ever. The jQuery UI is saddled with a major birth defect
(jQuery), so it is doomed. I am pretty sure Q*D (I am tired of trying
to spell that one) is a dead issue.
>
> ..what now?
No idea.
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> David Mark wrote:
> >>> On Nov 22, 8:02 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> >>>> It's possible that when some folks are requesting information on
> >>>> "JavaScript libraries", you hear "general purpose framework", when in
> >>>> fact they simply mean JavaScript code that may be reused such as
> >>>> "lightweight and interchangeable functions". If so, communication may
> >>>> be difficult.
> >>> Just to clear up any further confusion, the unqualified term
> >>> "Javascript library" has no real meaning, other than it is a blob of
> >>> Javascript.
> >> You seem to have a strange understanding about the term "library" in general.
>
> > You seem to have a pedantic bent.
>
> I'm so glad we've finally talked about it, dude.
Yes, happy trails.
>
> >>> [...]
> >>> Libraries are typically designed and tested as a unit and often cannot
> >>> be deconstructed to leverage their parts.
> >> That does not necessarily apply to *script* libraries as a programming
> >> concept, though.
>
> > That's why I said "typically."
>
> Asterisks are used in Usenet to emphasize words. Emphasis is a means to
> point out the increased importance of a word or phrase in a statement.
Thanks for that.
Kenny
> On Sun, 2008-11-23 at 14:06 -0800, David Mark wrote:
>
>
>>Google-challenged as usual. What planet do these people come from?
>
>
> Yeah, let's try Google. I can do this .. .. I guess this is it:
>
> http://www.cinsoft.net/mylib.html
>
>
> Ok, this is a collection code that supposedly "does the right thing"?
> Great!
I think you forgot to notice the, um, interface. Kinda says it all.
kzo
David Mark
Um, what interface would that be? Perhaps you mean the front page has
no graphics or scripts. That is by design and clearly has nothing to
do with the code. Perhaps you would like to comment on the interface
for the builder, which I recently tested on a PS3 (please insert
memory card!)
Or perhaps you could just shut the hell up. Haven't you had enough
humiliation for one lifetime?
>
> kzo
Kenny
>>
>>>On Sun, 2008-11-23 at 14:06 -0800, David Mark wrote:
>>
>>>>Google-challenged as usual. What planet do these people come from?
>>
>>>Yeah, let's try Google. I can do this .. .. I guess this is it:
>>
>>> http://www.cinsoft.net/mylib.html
>>
>>>Ok, this is a collection code that supposedly "does the right thing"?
>>>Great!
>>
>>I think you forgot to notice the, um, interface. Kinda says it all.
>
>
> Um, what interface would that be? Perhaps you mean the front page has
> no graphics or scripts. That is by design and clearly has nothing to
> do with the code. Perhaps you would like to comment on the interface
> for the builder, which I recently tested on a PS3 (please insert
> memory card!)
The bad news is that I *was* talking about the builder.
>
> Or perhaps you could just shut the hell up. Haven't you had enough
> humiliation for one lifetime?
>
There is no humiliation or even disagreement, I think. I am completely
on your side in re preferring as small as possible, and your Code Worth
Recommending project, albeit pushing up daisies, is something I would
turn to if I were not doing a serious Web application where the one-time
cost of loading a lot of JS did not make up for having an application
framework to use in building said application.
The client took me out to dinner a few weeks ago and thanked me for the
nice Web app (built on just jQuery). They said corporate had noticed.
They asked how I got so good at UI design.
I told them, (a) I hate computers so I get tired of awkward interface
before anyone else and (b) with Lisp and jQuery it makes it easy/cheap
to do fancy things.
Your "checkboxes gone wild" interface is serviceable so you left it at
that because anything as slick as I do using a JS library would take
forever.
Not to date myself, but the Fractured Fairy Tales cartoon opening
credits showed Aesop torturously finishing off a hand chiseled "Aesop"
engraving in marble or granite or something when his kid comes out with
a jackhammer and adds "and Son" in about two seconds. Something like that.
And now I have exactly one week to finish this and save my contrat, so I
better file this bug report with qooxdoo and get back to work.
peace, kt
Kenny
> And now I have exactly one week to finish this and save my contrat, so I
> better file this bug report with qooxdoo and get back to work.
>
I am up to bug report #3, tho possibly I was just violating some
widget's protocol. A synchronous request seems to have saved my *ss this
time.
I figured someone should get some pleasure out of my impending doom. :)
peace,k
Dr J R Stockton
3g2000yqm.googlegroups.com>, Sun, 23 Nov 2008 11:04:39, Matt Kruse
<ma...@thekrusefamily.com> posted:
>
>People like David and others tend to only focus on e-commerce sites or
>vast majority of development on the web does not fall into this
>category.
Whether or not that is correct in detail, ISTM something that FAQ
section "2 Language Overview" might well refer to.
2.0 What is JavaScript used for? // or perhaps in Section 1.
JavaScript can be used to facilitate user input, by pre-validation,
organising options, etc.
JavaScript can be used to decorate a site.
JavaScript can be used to publish and demonstrate calculations and
algorithms.
JavaScript can ...
Some sites are for light use, some for intensive. Design considerations
vary accordingly.
Please bear these points in mind when posting to CLJ.
Also, ISTM that the content of FAQ "2.6 What does the future hold for
ECMAScript?" does not deserve a subsection, and could be put at the tail
of "2.1 What is ECMAScript?"
It's a good idea to read the newsgroup c.l.j and its FAQ. See below.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF2 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
David Mark
> David Mark wrote:
> > On Nov 24, 6:19 am, Kenny <kentil...@gmail.com> wrote:
>
>
> >>>On Sun, 2008-11-23 at 14:06 -0800, David Mark wrote:
>
> >>>>Google-challenged as usual. What planet do these people come from?
>
> >>>Yeah, let's try Google. I can do this .. .. I guess this is it:
>
> >>>http://www.cinsoft.net/mylib.html
>
> >>>Ok, this is a collection code that supposedly "does the right thing"?
> >>>Great!
>
> >>I think you forgot to notice the, um, interface. Kinda says it all.
>
> > Um, what interface would that be? Perhaps you mean the front page has
> > no graphics or scripts. That is by design and clearly has nothing to
> > do with the code. Perhaps you would like to comment on the interface
> > for the builder, which I recently tested on a PS3 (please insert
> > memory card!)
>
> The bad news is that I *was* talking about the builder.
It is bad news that you are such a poor judge of interfaces!
>
>
>
> > Or perhaps you could just shut the hell up. Haven't you had enough
> > humiliation for one lifetime?
>
> There is no humiliation or even disagreement, I think. I am completely
Perhaps I imagined this thread?
> on your side in re preferring as small as possible, and your Code Worth
> Recommending project, albeit pushing up daisies, is something I would
It was not *my* Code Worth Recommending Project (it was Peter's.) My
project is very much alive (as you have seen.)
> turn to if I were not doing a serious Web application where the one-time
You are incapable of writing a "serious Web application" (or
maintaining a train of thought apparently.)
> cost of loading a lot of JS did not make up for having an application
> framework to use in building said application.
Yes, as I have said, good luck with that.
>
> The client took me out to dinner a few weeks ago and thanked me for the
> nice Web app (built on just jQuery). They said corporate had noticed.
So you are basically a con man.
> They asked how I got so good at UI design.
You've got a live one!
>
> I told them, (a) I hate computers so I get tired of awkward interface
> before anyone else and (b) with Lisp and jQuery it makes it easy/cheap
> to do fancy things.
This sounds made up.
>
> Your "checkboxes gone wild" interface is serviceable so you left it at
> that because anything as slick as I do using a JS library would take
> forever.
So you are against checkboxes?
>
> Not to date myself, but the Fractured Fairy Tales cartoon opening
> credits showed Aesop torturously finishing off a hand chiseled "Aesop"
> engraving in marble or granite or something when his kid comes out with
> a jackhammer and adds "and Son" in about two seconds. Something like that.
And that means what exactly?
>
> And now I have exactly one week to finish this and save my contrat, so I
LOL. You are going to lose that "contrat" if you don't stop wasting
time!
> better file this bug report with qooxdoo and get back to work.
Good luck with that too.
David Mark
> Kenny wrote:
> > And now I have exactly one week to finish this and save my contrat, so I
> > better file this bug report with qooxdoo and get back to work.
>
> I am up to bug report #3, tho possibly I was just violating some
Thanks for the update!
> widget's protocol. A synchronous request seems to have saved my *ss this
> time.
No, you just threw the game away. Your "widget" can't use synchronous
requests.
>
> I figured someone should get some pleasure out of my impending doom. :)
Probably.
Kenny
Thx! They said they were going to be looking at that widget/data control
in the future. Look for me to have committer status in a week.
I'll put in a good word for you if you want to get involved, too.
:)
kzo
ps. None of those links to the code worked, or did I miss the one that
does? Or should I go ahead, make some choices, and say "make it so"?
Kenny
> On Nov 24, 4:59 pm, Kenny <kentil...@gmail.com> wrote:
>
>>Kenny wrote:
>>
>>widget's protocol. A synchronous request seems to have saved my *ss this
>>time.
>
> No, you just threw the game away. Your "widget" can't use synchronous
> requests.
Nonsense. I backed it out and am trying something else. I have a team of
monkeys trying things at random. I like their chances, but so far all I
keep getting are Shakespearean sonnits. Good ones, but still...
kxo
David Mark
> David Mark wrote:
> > On Nov 24, 2:18 pm, Kenny <kentil...@gmail.com> wrote:
>
> >>better file this bug report with qooxdoo and get back to work.
>
> > Good luck with that too.
>
> Thx! They said they were going to be looking at that widget/data control
> in the future. Look for me to have committer status in a week.
Pardon me if I don't look.
>
> I'll put in a good word for you if you want to get involved, too.
Don't put any word for in anywhere. I don't know you.
>
> :)
>
> kzo
>
> ps. None of those links to the code worked, or did I miss the one that
What links to what code?
David Mark
> David Mark wrote:
> > On Nov 24, 4:59 pm, Kenny <kentil...@gmail.com> wrote:
>
> >>Kenny wrote:
>
> >>widget's protocol. A synchronous request seems to have saved my *ss this
> >>time.
>
> > No, you just threw the game away. Your "widget" can't use synchronous
> > requests.
>
> Nonsense. I backed it out and am trying something else. I have a team of
So it wasn't nonsense.
Kenny
> On Nov 24, 9:57 pm, Kenny <kentil...@gmail.com> wrote:
>
>>David Mark wrote:
>>
>>>On Nov 24, 4:59 pm, Kenny <kentil...@gmail.com> wrote:
>>
>>>>Kenny wrote:
>>
>>>>widget's protocol. A synchronous request seems to have saved my *ss this
>>>>time.
>>
>>>No, you just threw the game away. Your "widget" can't use synchronous
>>>requests.
>>
>>Nonsense. I backed it out and am trying something else. I have a team of
>
>
> So it wasn't nonsense.
You said threw the game away. The correct metaphor would be "fumbled the
snap, recovered ball, loss of two". A little precision, please, in your
flaming. (Can we add that to the FAQ?)
Meanwhile, oops, they had:
<parse json> || null;
Clever way to coerce false to null. And zero. Doh!
Thank god for open source.
kxo
Kenny
> Clever way to coerce false to null.
Ah, probably "undefined to null"
Boy, Lisp sure got this one right. Surprised js blew it.
kt
Kenny
And a good community: my bug report/fix got fast-tracked into SVN.
Meanwhile, I was merely tinkering with my own subclass of their Remote
data model just trying to head off some thrashing (they acknowledged
needed fixing) before tackling the actual functional misbehavior and I
got lucky: when I had quiessed the thrashing the whole damn thing widget
grid and data model started performing flawlessly (well, all the issues
I knew about were gone).
Just sent that in, too.
Along the way of course I got a good look at the internals. This is top
notch stuff, kiddies.
All aboard the qooxdoo choo-choo?
:)
kzo
David Mark
[snip]
>
> Along the way of course I got a good look at the internals. This is top
> notch stuff, kiddies.
I pointed out some time back that the "internals" use browser
sniffing. So now you are convinced it is "top notch stuff?" Of
course, you haven't demonstrated the slightest ability to judge such
things.
>
> All aboard the qooxdoo choo-choo?
This is like watching a train wreck in slow motion.
[snip]
Kenny
> On Nov 25, 5:38 pm, Kenny <kentil...@gmail.com> wrote:
> [snip]
>
>>Along the way of course I got a good look at the internals. This is top
>>notch stuff, kiddies.
>
>
> I pointed out some time back that the "internals" use browser
> sniffing. So now you are convinced it is "top notch stuff?" Of
> course, you haven't demonstrated the slightest ability to judge such
> things.
Not mastering the subtleties you prize most does not mean they do not
design software well in general. Cuz they do.
>
>
>>All aboard the qooxdoo choo-choo?
>
>
> This is like watching a train wreck in slow motion.
>
Cool, my client contat/boss is a huge Bridge On the River Kwai fan.
Now help me with something: I define a utility function at the
top-level. Works fine loading everything torturously uncompressed. Now I
do their build process to get her down to a lean 700k and the browser
thinks the function is undefined.
I tried document.myFn and window.myFn, no luck.
Any ideas?
kt
David Mark
> David Mark wrote:
> > On Nov 25, 5:38 pm, Kenny <kentil...@gmail.com> wrote:
> > [snip]
>
> >>Along the way of course I got a good look at the internals. This is top
> >>notch stuff, kiddies.
>
> > I pointed out some time back that the "internals" use browser
> > sniffing. So now you are convinced it is "top notch stuff?" Of
> > course, you haven't demonstrated the slightest ability to judge such
> > things.
>
> Not mastering the subtleties you prize most does not mean they do not
> design software well in general. Cuz they do.
The source tells another story and that trumps anything you could ever
say about it. You are wasting your time and going to lose your
contrat (sic).
[snip]
>
> Now help me with something: I define a utility function at the
Why on earth would I help you with anything? I am simply here to
attempt to mitigate your ridiculous, confused and often misleading
posts, though it's probably not strictly necessary at this point (you
are clearly nuts.)
> top-level. Works fine loading everything torturously uncompressed. Now I
> do their build process to get her down to a lean 700k and the browser
> thinks the function is undefined.
All I saw was 700K. And since I don't believe anything you say at
this point, I won't comment further.
>
> I tried document.myFn and window.myFn, no luck.
What was the phase of the moon at the time?
>
> Any ideas?
>
Yes. Go away.
Kenny
I just threw in workarounds and now the page comes up in 5-seconds even
with some non-trivial interactions with the server and it just flies.
All kidding aside, qooxdoo seems to be the real deal. The others almost
killed me, but this one is a joy to live with.
peace,kzo
Kenny
> On Nov 25, 9:17 pm, Kenny <kentil...@gmail.com> wrote:
>
>>David Mark wrote:
>>
>>>On Nov 25, 5:38 pm, Kenny <kentil...@gmail.com> wrote:
>>>[snip]
>>
>>>>Along the way of course I got a good look at the internals. This is top
>>>>notch stuff, kiddies.
>>
>>>I pointed out some time back that the "internals" use browser
>>>sniffing. So now you are convinced it is "top notch stuff?" Of
>>>course, you haven't demonstrated the slightest ability to judge such
>>>things.
>>
>>Not mastering the subtleties you prize most does not mean they do not
>>design software well in general. Cuz they do.
>
>
> The source tells another story and that trumps anything you could ever
> say about it. You are wasting your time and going to lose your
> contrat (sic).
Nah, you just /looked/ at the source, I am working with it, debugging
it, resolving the thrashing problem, overriding the default behavior. I
also tried looking at YUI code. Ouch.
So I /know/. You just see what you want to see, because a good library
handling low-level stuff makes your skills as obsolete as the guy who
can winnow 24 bytes of machine code down to 10.
Me, my only concern is the client. I have first liked then become
disappointed by jQuery, Dojo, and YUI. I am moving the client to qooxdoo
because it is amazingly good in details small and large. Where the
others came up short when pressed into action revealing more and more
problems, qooxdoo looks better and better. If it had not I would have
told the client to hell with it, we're going with the nutjobs on c.l.js.
>>Now help me with something: I define a utility function at the
>
>
> Why on earth would I help you with anything?
Simple human decency?
What was going on was the build process scrunches identifiers and I
guess is not clever enough to look cross-file when building its symbol
table. I should file a bug report, that's daft. But by the time the
support came thru I had backed out the two/three globals and had the
monkeys hammer out something else.
> I am simply here to
> attempt to mitigate your ridiculous, confused and often misleading
> posts, though it's probably not strictly necessary at this point (you
> are clearly nuts.)
"The lady protests too much, methinks." - Bob Dylan
>
>
>>top-level. Works fine loading everything torturously uncompressed. Now I
>>do their build process to get her down to a lean 700k and the browser
>>thinks the function is undefined.
>
>
> All I saw was 700K. And since I don't believe anything you say at
> this point, I won't comment further.
Would you believe your code amounts to 300k? While offering nothing to
someone building a serious Web application other than, lessee, no
browser sniffing?
>
>
>>I tried document.myFn and window.myFn, no luck.
>
>
> What was the phase of the moon at the time?
I shouldn't take credit. One of the randomly typing monkeys also likes
to read doc, coulda swore he saw something somewhere.
>>Any ideas?
>>
>
>
> Yes. Go away.
Actually I plan to port my reactive programming hack called Cells to
Javascript:
http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html
You will then have to acknowledge I am your master.
Next I give my algebra software an interwebby frontend:
http://www.theoryyalgebra.com/
ei, I am here to stay. :)
kt
Brian Adkins
> Kenny wrote:
> [...]
> I just threw in workarounds and now the page comes up in 5-seconds
> even with some non-trivial interactions with the server and it just
> flies.
>
> All kidding aside, qooxdoo seems to be the real deal. The others
> almost killed me, but this one is a joy to live with.
Thanks for reporting on your experience with qooxdoo Kenny. It seems
worth a look regardless of browser sniffing :)