/usr/lib/info -- hacker/librarian haven
Front Page · News · Features
Software · Events · Standards
Ask Anything · Opinion · Diaries
Reviews . MLP . Everything
Server-Side Fascism & the JavaScript Resistance

By art, Section Ask Anything
Posted on Wed May 14th, 2003 at 07:00:30 PM EST
Is it ever ok to use JavaScript? Most of us go to great lengths to keep all web processes on the server so that the widest range of browsers can be accommodated, which is clearly a worthwhile goal for libraries. With appropriate caching engines, I think you can even argue that there’s some efficiency to be gained in performing a lot of rendering tasks on the server rather than on the client browser. But what if you want to augment an existing web page, especially when it is for a resource from another organization? We are hoping to roll out our LibraryLookup Helper App for the summer semester and are dealing with the dilemma of depending on JavaScript to supply a service.


Now, there are proxy/co-browsing methods of re-routing pages through an intermediate process, so the JavaScript can be avoided, but this is messy at best, and there are definitely times when it would mean some serious backtracking for the user in order to get cookies and authentication in sync. We have recently achieved access to Mac OS/X and I am revamping the code required to make the same JavaScript work on Mac IE that works on Mozilla, Internet Explorer (on windows and older versions of the Mac OS), Phoenix (my favourite browser), and Opera. In some ways, this points to the root of one of the biggest problems with JavaScript; it is so inconsistent between platforms that it makes it hard to use browser scripting for doing much of anything.

The sad part is that JavaScript is a decent language, although considered a toy by some web developers you can do some truly neat things with it. Netscape probably pushed the browser to its loftiest heights when it bundled CORBA libraries and attempted to make the browser a sort of universal object container, but by then Microsoft started to wake up and any further steps to extend the browser paradigm would be hard to achieve. Again, our aim is to augment an existing resource, automatically bringing up the Amazon page for a title in the OPAC, for example, arguably makes the web less of a static viewing experience but more an intersection of local and remote resources. The “hooks” to make this happen are very flimsy, mostly looking for numeric patterns that might qualify as ISBNs/ISSNs, but I would love to see some level of “acceptable use” guidelines in client-side capabilities and processing since XML could eventually open the door to all sorts of exciting client-side combinations. What if you could rely on a tag like ISBN instead of using free-form searching on HTML text? The availability of resource identifiers and specific metadata tags could allow the browser to be the main enabler in a process of extending library services throughout a user’s web travels.

I still think there is great value in the notion of a library-specific toolbar, but there may be an opportunity to use existing browser capabilities for pushing the library’s availability into every part of web space. The way this works now is using this to go to this. Or, if you are in the catalogue, going from this to this. Thanks to an unnamed organization and an emerging web service, we can handle variations in ISBNs by doing some server-side work, and server-side processing remains an essential part of maximizing the benefits of client-side tools. But are we expecting too much from client-side processing by using JavaScript at all? Server-side fascism is not necessarily a bad thing, but I wonder if the browser wars have negated the allure of client-side tools to the point that the web desktop is fated to remain a place with massive amounts of unused plumbing.

< Koha and the Trophees du Libre (3 comments) | RSS, catalogs, Koha, and more (4 comments) >

· submit story
· create account
· faq
· search
· recommended reading
· editorial guide
· masthead

Make a new account

Do you use JavaScript in your web pages?
· Yes 25%
· No 0%
· Sometimes 75%
· Never 0%

Votes: 4
Results | Other Polls

Related Links
· LibraryLookup
· Helper App
· library-specific toolbar
· this
· More on
· Also by art

View: Display: Sort:
Server-Side Fascism & the JavaScript Resistance | 7 comments (7 topical, 0 editorial, 0 pending) | Post A Comment
XUL (none / 0) (#1)
by inkdroid on Thu May 15th, 2003 at 08:30:36 AM EST
(User Info) http://www.inkdroid.org

Javascript is a much maligned language...only because of the unstable platform it runs on. I think developing a browser tooklkit for libraries is definitely useful. The great thing about libraries is that you often have the browser market under your control. You have workstations, and can define the OS and web browser that will run on them. If you like Phoenix, then heck, you can create your own library browser with XUL that has all these Javascript goodies built in! My rule for developing web pages for a large audience is that core functionality must work with Javascript off...but extra stuff can rely on Javascript as long as the core is still there. I'm not an expert, but that's the rule I use.

[ Reply to This ]

yes, if... (none / 0) (#2)
by ksclarke (ksclarke @ stanford no spam dot edu) on Thu May 15th, 2003 at 10:49:58 AM EST
(User Info) http://www.stanford.edu/~ksclarke

I'd say it is okay to use it 1) if the result is purely cosmetic (and it doesn't interfere with the access of people who do not use it), 2) it is functional but you also provide a server-side way to do it, or 3) you have a limited audience that you can require JS support from (like a cataloging client only intended to be used by your library's staff).

When you start providing services to patrons that require JS (with no server side alternative) I think you begin to walk on shaky ground.  It is a nice language though...


Out, out brief candle!
... it is a tale told by an idiot, full of sound and fury,
Signifying nothing.
[ Reply to This ]

Server-side Fascist (none / 0) (#3)
by roy on Thu May 15th, 2003 at 08:26:11 PM EST
(User Info) http://escholarship.cdlib.org/rtennant/

I'll admit to being a server-side Fascist on this score. I think hanging user services on something so breakable is a bad idea in general. Having said that, if the service is not "core" and could be considered "merely" and enhancement to core service, then I'm less of a Nazi. I would stil want the Javascript to work well in most browsers (i.e., most recent versions of MSIE and Netscape/Mozilla), but if it isn't an essential function I'd be willing to give up the fringe browsers (e.g., Netscape 4.7, etc.), especially if they would see nothing at all (as opposed to seeing something that simply didn't work).

[ Reply to This ]

UI convenience and the meaning of librarianship? (none / 0) (#4)
by dchud on Thu May 15th, 2003 at 09:15:09 PM EST
(User Info) http://curtis.med.yale.edu/dchud

Wow, Art, as is your wont, you've managed to pack an teasingly simple lead question into a wide-ranging essay on some of the deepest issues in our field. :) Answering only the lead question (sheepishly, but sleepily as well), and having recently written here about a javascript-dependent app I'm working on, yes, of course, it is okay to use javascript.

Well, a-hem, to hedge that a little bit, I should admit that except for some brief dalliances to see what it was all about, I'd never really used js for any real application, and had a definite affinity for the attitude expoused in the three earlier comments, albeit leaning heavily toward the "not if I can really help it" camp. This attitude lasted until about three months ago.

Now that I'm a big SVG fan, the power of javascript as a simple event handler and DOM-manipulator is really looking potent. This is especially true since the tool in question is currently focused on a controlled user group who will receive specific training, and the necessary environment requires a standard configuration, so for now I don't have to deal with the incompatible implementation problem (a situation deemed appropriate by ksclarke above).

So for now, I'm using it, and I can't help but imagine how nice it would be to add some client-side bits into other apps I'm working on, but envisioning the concomitant maintenance headaches likely to ensue I'd probably pass on those.


[ Reply to This ]

Compromises and Trade-offs (none / 0) (#6)
by art on Fri May 16th, 2003 at 07:50:17 AM EST
(User Info) http://www.uwindsor.ca/library/leddy/people/art

Well I don't know about depth but I am re-kindling a long interest in quantum physics for an upcoming event and it's territory that makes everything seem wide and interconnected somehow. Dan, you put your finger on what I think I want from the browser, a sanctioned method of using an event handler and DOM-manipulator. Your SVG application is a perfect example of why there are times when treating the web as a global mainframe is very limiting. Still, the minefields waiting for JS solutions are enough to drive you crazy. By far the most devious variation seems to be IE on Mac OS/X, so far I have discovered that: a) remote scripts need to be called differently than any other platform (including IE on every other Mac OS but X), b) regular expressions have methods that just silently fail without error messages or anything else, c) image attributes are handled differently when called from a web server dynamically, a killer "gotcha" for me because I was using an attribute as the flag for whether an item is in the library collection.

I think what I will settle for is offering two bookmarks. One that does an "in-page" status (I can get around the Mac issues with a hidden iframe) and another that goes to the server for non-JS users. The server process will look at where the browser is coming from, at which point it will retrieve that page and re-edit it to add status information where there are ISBNs/ISSNs. This doesn't shut out text-based browsers and strange browser versions, while at the same time will work for what will probably be the most common use, and that is browsing titles in a site like Amazon. I think most book vendors have URLs that can be used to navigate directly to a title so getting the required linking information is likely not a big deal in this case. But I think that there's a lot of possible instances where it could be incredibly useful to be able to see what the user is seeing so that the information there can be the entry point to other applications.

These aren't great examples, but what if you wanted a Topic Map of all the subject headings in a bib record, or a quick way for grabbing the date information on when a title was being returned to the library so that it could be plugged directly into your personal calendar. Even if we reach XML nirvana, I suspect there will always be applications that no one will foresee and the browser might be a potent development platform for putting them together. I remember a Computer Science professor once saying to our class that "your users will always have more interesting uses for your application than you will ever think of". JavaScript can be an empowerment tool, it's too bad it has been so misused over the years.

[ Reply to This ]

Here is good website (none / 0) (#7)
by Anonymous Hero on Wed Feb 23rd, 2005 at 12:11:57 AM EST

Here is good website I will introduce it to my friends website imiquimod pic bbs Article links sitemap sitemap2 links add Health links all Article hpv net freewebpage1 seocn googlecn aakkfree healthcn hpvcn szseo stds ccctvxxyyzz aaccoo xbcnorg aakkorg google aakkorglink 1 2 3 4 5 6 7 8 9 10

[ Reply to This ]

Server-Side Fascism & the JavaScript Resistance | 7 comments (7 topical, 0 editorial, 0 pending) | Post A Comment
View: Display: Sort:

Powered by Scoop
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest © 2002 The Management

front page | submit story | create account | faq | search