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
