My general philosophy is still always to put as _little_ Javascript as
possible. Thus my way-too-clever idea to have some javascript which
actually sends the Google (or similar) API response back to my server
via AJAX for _real_ processing. :)
But if you DO want or need to do javascript-heavy stuff, I _highly_
encourage you to take a look at some of the various Javascript client
libraries that are out there, like Prototype. Such libraries can
provides support for easy 'inheritance' in Javascript (implemented
through behind the scenes fakery), as well as ways to see what
versions/functions of javascript are supported in the browser.
But if you are trying to make things available without client javascript
at all... if a given API like Google _requires_ it, well, then there's
no way to have Google results used by the interface in a non-javascript
client. That's obviously just a syllogism. [It's interesting to know
though that, contrary to popular belief, recent versions of JAWS _do_
support javascript. But only some kinds of javascript done in certain
ways. Doing javascript that will work for JAWS is yet another layer of
complexity, yet another headache. Added headaches and layers of
complexity is why I try to minimize my javascript altogether. And JAWS
is just one kind of 'accessibilty'. And the rules you have to follow
whether you like it or not for 'accessibility' may or may not actually
be rationally related to actual accessible use cases, like it or not.]
Joe Hourcle wrote:
On Mon, 17 Mar 2008, Jonathan Rochkind wrote:
Of course, all these things _can_ be done with only client-side
javascript API. To my perspective, it is quite a bit more complex to do
it that way. And complexity is the enemy of maintainability, especially
in my limited staff resources library environment.
But perhaps my perspective is not sufficiently "2.0" (or "3.0"); I've
been a software developer for a long time, but doing client side
javascript stuff for less. Maybe I'm wrong. I dunno. To me, it looks
quite a bit more complex to try and provide these services with the same
level of control and customization in a "don't repeat yourself" modular
way accross all my various display systems that need this functionality,
using client side javascript services. Other developers, do you think
I'm wrong?
I agree, but mostly because I'm concerned with the differing ECMAScript
implementations out there (JavaScript, JScript, different versions,
etc.),
and the lack of the ability to test for the existance of a function ...
you can test for what version the client thinks it can run, but that
doesn't given you fine control. (and as try/catch wasn't included 'til
1.3, I had to go through elaborate hoops to try to verify that the code
would run cleanly)
... then there's the issue that I need to support Section 508
requirements, and our normal procedure is to make sure that whatever
features we have don't require client-side support -- they can be
_enhanced_ by client-side scripting, but even without scripting turned
on,
the applications are at least usable.
I'm also not a fan of how '<NOSCRIPT>' is handled in web browsers. Say
for instance, that I actually know which spec I'm coding to, and I have
some functionality that requires 1.0, and some that requires 1.3. I'd
want the <NOSCRIPT> to be directly tied to the <SCRIPT> tag, so I can
give
appropriate messages when they have scripting completely turned off and
both don't load, vs. when they're running a 1.2 spec, and can't load the
1.3 code.
http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.1
Now, in the HTML spec, they describe that the original intent was for
people to embed other languages ... but they don't ever say how you'd
handle the case where the browser loaded javascript, but not tcl. Of
course, they've also deprecated the 'language' attribute, so it's more
difficult to handle the code based on the version of the language that's
supported.
...
It may be that I was stung by trying to move over to client-side
scripting
too early (10 years ago?), and I've used it in small amounts through the
years, but I'm currently working on my first 'real' JavaScript
application, where it's going to require significant amounts of
processing
to render output ... but I have no idea how much memory is safe to
use, or
if my text machines are representative of our user base ... and I've
already found that the render time is more than doubled in FireFox
compared to Safari or IE.
... okay, this is slowly getting into a rant -- but yes, I agree -- I
have
less control, more worries about security implications, issues with
debugging, etc. I think the only reason I've gone along with the change
is because it's giving me a chance to clean up some of the UI code and I
can get a better separation between it and the back-end logic.
...
oh -- and the inability to inherit code from within JavaScript is a major
step backwards -- I have to have whatever HTML file (or whatever
generates
the HTML) know what the full chain of dependancies are for each script I
load. JSAN looked promising when it was announced, but it doesn't
seem to
have taken root:
http://openjsan.org/doc/c/cw/cwest/JSAN/0.10/lib/JSAN.html
-Joe
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
