n00b questions for javascript!

[David Mark]

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

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/


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]

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]

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

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]

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]

PointedEars

 

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

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




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?

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]

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

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.

 

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

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

 

[Kenny]

So that's a million families in the UK you don't know.





Q: Why does Google's home page load so quickly ?

A: Because it's so easy to switch to another search engine.

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]

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]

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

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]

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?

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

 

[David Mark]

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?

 

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

 

[Thomas 'PointedEars' Lahn]

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