On 28/07/10 07.59, David Mark wrote:
Oh, I didn't mean "pro" as in professional, I meant as "a point in favor
of"
Sorry, I see I misread.
Yes, in this case, the problem is hard. Hopefully with the course they
will get at least some degree of knowledge and experience.
At leasthttp://forkjavascript.org/still"works"
I imagine so. It's pretty thin (which is a good thing).
Yes, this is will be an important point. The problem is that getting a
GP library is easy, dropping it in your page is easy; not doing that
takes more work (either you do write part of it from scratch, or you
find a number of good reusable modules suitable for your context).
Or you hire a competent professional.
And, getting a number of reusable modules for the particular context
isn't that easy - i.e. there is no good-reusable-js-modules.org.
See previous.
More often than not most people go for the "easy" solution. The problem
being that it appears to work on all the browsers you have installed
(yes, in their default configuration
.
Yes, they get all puffed up and think they can do it themselves. Of
course...
Another point is that of widgets: with a GP library there is always the
chance that it comes with (almost) just that widget you want, or someone
has written that widget as a "plugin". Again it appears to work just
fine (in all the browsers you have installed, yes, in their default
configuration) - you may not consider "accessibility" (or usability, Rob
, use of keyboard.
Or the fact that people who build castles in swamps are likely
inexperienced with castle building.
In this case, the alternative often is writing it from scratch...
Still looking for quality-js-widgets.org
There's no such thing. You either start small and learn a little at a
time. Or you hire a professional. As we've discussed, abdicating
responsibility to B team-ers who are still laboring under
misconceptions about browser sniffing (among other things) is not a
viable option.
Anyway, I want to convey the message that using a GP library is not an
automatic default: it comes with a cost. Sometimes that cost is too high.
If you aren't writing a prototype, it's invariably too high.
Thanks
At least this should not be "the blind leading the blind", as
you say.
No, on the contrary, it sounds like you will teach a good course.
I may not see all that well, but at least I can steer away from the abyss...
Yes, tell them not to follow lemmings!
[snip]
Furthermore, it's not always true that there is a single point of
contact. Many of these efforts get fragmented over the years (see
Dojo and Ext JS), even so much as to break their Google search results
by changing domain names (Ext JS and Dojo each did that *twice* at
least).
While I agree that it is not always true, usually it is a single (ora
few) points of contact. I think I will keep this bullet.
Yes, but more importantly, who are they contacting? Programmers or
pattern arrangers?
And one glance at the Dojo or jQuery or whatever "support" forums
should tell you in an instant what sort you will be relying on. After
all, experienced developers would never use such things.
[snip]
- Monolithic/non-modular libraries will inevitably contain many features
that you won't use
And must be "upgraded" in one go, requiring a reboot of regression
testing. It's a nightmare in practice (again Dojo, Ext JS and the
like are the most extreme examples).
Do you mean as opposed to a modular library where you would be able to
upgrade a particular module, keeping other modules in an older version?
That is a good point.
Yes. And it is important to realize that they all claim to be
modular, but (particularly in the case of Dojo and Ext JS) it's
usually all smoke due to interdependencies. For example, Dojo's XHR
module requires its (highly dubious) query module. What does XHR have
to do with CSS selector queries?
Yes, part of the course is actually teaching the client the basics of
Ext JS which is used to build "app-in-a-page" things on their intranet
(where they use only IE7+ and FF3+ on windows).
OMG. The developers of Ext JS are so green they could easily be
mistaken for martians (and having talked to a few recently, I'm not
convinced they aren't).
Seriously. Search the archive for "Sencha" (their new alias).
I tried to use the Ext JS "builder" to create a version of the library
that only included the parts we were using: it included almost
everything
so much for modularity...
Exactly. 700K+ minified.
[snip]
I guess extensibility and customization is only relevant for "widget"
libraries.
Yes, it's more relevant for those. And note that the "widget"
frameworks are often castles built on top of swamps. In other words,
they are the results of developers getting way ahead of themselves. I
can't name one such framework that is not completely execrable. Dojo,
YUI, Ext JS, Cappuccino, SproutCore, qooxdoo, etc. are all ill-advised
and unsuccessful attempts to make every control look the same in every
browser and chop off the browser's built-in layout mechanisms to be
replaced slowly and painfully with single-threaded scripts that fail
miserably (when compared with what they sought to replace) even in
their "supported" browsers.
But I still have hopes that it will be possible to build those castles
on a better foundation, some day. The client wants castles in browsers.
The client needs to hire professional (and experienced) castle-
builders.
You are speaking about Ext JS again, aren't you?
Not specifically. Dojo, qooxdoo, YUI, Cappuccino, GoogClosure,
Sproutcore, etc. They are all the same sorts of failures. You don't
rip out the browser's free and built-in layout mechanism and attempt
to replace it with dubious single-threaded scripts.
Yes, HTML5 would remove the need for many, but probably not all, of
those "widgets". And I guess canvas would help too.
HTML5 controls are trivial to implement with progressive enhancement.
I'll be adding an example add-on to My Library soon. I heard recently
that Kangax has written a Canvas library. So there's a good
foundation to build your own widgets, learning useful and marketable
skills as you go. OTOH, constant reliance on canned "widget
libraries" is like being strung out on hard drugs. You end up with
nothing as you spend all of your time in search of the next "fix".
Yes, I meant the other implication: a good design would imply at least
some degree of customization.
Yes.
Thanks. Looking forward to it.
NP. I hope this follow-up helps. I've been too busy today to
organize my additional thoughts. Perhaps I will have time tomorrow.
One area I wanted to touch on is widgets and extensibility. Virtually
all of the "widget libraries" out there present developers with thick
stacks of objects, ostensibly allowing for myriad customization
options. Of course, no matter how much they are augmented,
overridden, "sub-classed", etc., at their core they are still the
library developer's vision of encapsulation.
These piles of prototypes result in objects that are relatively slow
and memory-intensive. Furthermore, upon close inspection, many of the
built-in methods abstract features that would have been better left to
CSS (which is inherently extensible). Others are related to layout
and should also be left to the browsers, which excel at such tasks and
offer more flexibility than could ever be needed.
A recurring theme in My Library is doing the exact opposite of the
"major" libraries and frameworks. Over the years, many library
devotees have decried the "verbose" (readable) nature of its API,
often overlooking that there are OO interfaces included, which sit
atop the API (rather than in it). This is as it should be.
The "wrapper object" constructors are kept in a separate module with
no dependencies other than the DOM and Query modules. The latter of
those dependencies represents a hasty and lazy design on my part that
should be corrected as only the Q wrapper uses queries. Of course,
those objects can be used in full without making use of a single
query, which is a big plus, but also demonstrates a somewhat slap-dash
design on my part. It wouldn't take much to correct these
shortcomings of the builder, but then most of my users prefer the API
anyway, electing to wrap its functions in OO designs that suit their
needs.
As asides, there has also been periodic criticism of the constructor
names (e.g. E for Element, Q for Query, D for Document) as somehow
more prone to collisions than names like "$" and "$F" and obviously
the former is laughable as jQuery, Prototype and countless other
efforts crashed into each other at that point in the
"namespace" (meaning the range of all possible variable names) years
before I published my library. There has also been a "point" made
that perhaps it would be better to abstract elements, documents,
queries (one or more elements) with a single, awkward and ham-fisted
abstraction (a la jQuery). Something about Web developers being
unable to keep track of more than one (which may be a valid
point).
As for widgets, to this point, they are all created with simple API
functions. This was a conscious decision on my part as I did not want
to box developers in to my vision of an OO widget interface. This is
the ultimate in extensibility as developers can design their own OO
widget interfaces that call the API functions, thereby concentrating
on widget design and leaving the much-feared browser differences to
the underlying library. If a developer wants a thin wrapper, they can
do that; or, if they prefer dozens of layer of inheritance, they can
go that route.
Furthermore, the strategy results in faster and less memory-intensive
widgets. This is important in browser scripting as widgets must
respond to user input and, of course, run in browsers (some of which
may be lacking in resources). I think the recent surge in popularity
of browsing through slow and relatively limited battery-powered
devices bears this out. Notice that most frameworks are now starting
anew on parallel sets of "lightweight" widgets, which they envision
downloading dynamically after some sort of futile attempt to detect
the type of browser in use.
Another thing to notice about my widgets (and other add-ons) is how
tiny they are and how little of the library they need to function.
Seemingly in contradiction to this is the fact that they are highly
readable (unlike "concise" code written with other libraries). The
thing is that the API functions are not methods. They don't care what
the - this - object refers to, so developers can create local
references to them, using verbose variable names (typically matching
the API names) and then let the minifier take the air out of the
code. Also, calling the functions this way is invariably faster than
constantly referencing properties of a global "namespace" object.
On that last point, the entire library uses such strategies
internally, which is why it compresses to such a small size. Of
something like 340K (full build with white space and light comments),
minification cuts out approximately 200K.
And, though I hate mentioning compressed sizes as compression is not a
constant on the Web (and most resources are not sitting around in a
compressed state for ready comparison), GZIP lops off another 100K or
so, making the "final" size in the 40-50K range. That's for
everything: Ajax, Flash, DirectX, audio, special effects, scrolling,
queries, drag and drop, all with support for frames and even XHTML,
all compatible with virtually any browser and about as future-proof as
you could ask for.
I literally slept right through the release of IE8 as I wasn't
actively working on the library at the time and wasn't particularly
surprised to see it come through unscathed. IE9, which is even more
of a dramatic change looks to be the same story. I recently tried my
Build Test page in both of its preview's DOM's (HTML and XHTML) and
was quite pleased with the results.
Interestingly enough, jQuery, which only advertises a compressed size
and a full-blown "development" version (leaving out the middle figure,
which is the best measure) is in the 30K range, despite being little
more than a query engine that has trouble coping with four or five of
the latest browsers in their default configurations, despite constant
efforts on the part of their developers to figure out where it is
going wrong. It's voodoo programming trying to realize a design that
is so far beyond their reach that they are in a constant state of
toppling over (and somehow they feel the need to continually add more
complexity). Prototype and MooTools and other "lightweights" are the
same way, the former of which recently gave up and decided to start
over (which doesn't help the thousands of sites that are sitting on
old abandoned versions).
The larger libraries are *much* heavier and even less compatible. The
recently ballyhooed "mobile framework" called Sencha Touch (Ext JS
combined with JQTouch basically) weighs in at a whopping 80K after
GZIP (228K before) and what little it does is only "supported" in two
Mobile Webkit-based devices. That's the smallest of the bunch. At
the other extreme is the parallel (and largely incompatible) desktop
version of Ext JS, which weighs in at around 400K after GZIP (700K+
before) and is largely inorganic (as you have seen) so cannot be
easily broken down.
Building any sort of desktop-like application with any of these (Dojo,
YUI, SproutCore, qooxdoo etc.) creates massive documents that often
push the unthinkable 1MB boundary, which is why none of them have
really taken off on the Web (inflicting their misery almost
exclusively on Intranet developers).
They will all try to reinvent themselves with HTML5 and CSS3 (or the
"HTML5 family" as some have taken to calling it), but that poses a
question: what good are brand names in this context? Do they indicate
the same programmers are behind them? If so, that would seem to be a
huge minus due their well-documented Sisyphus-like struggles of the
last half-decade. I predict they will make just as big a mockery of
the new technology as the old. You don't have to be a seer to see
that.
HTH
