 |
 |
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 <!cript> 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