JavaScript as a language has a number of severe limitations regarding
name spaces, dependencies, etc., but well-written, object-oriented
JavaScript as that you'd produce when you build an application using a
library such as prototype actually isn't too bad and (I believe)
provides reasonably good solutions to a good subset of your concerns.
To give you another data point: using an appropriate environment
layer, we're able to run the same JavaScript in LibX in 4
environments:
- in a Firefox extension
- in a IE plugin
- in client-side JavaScript (FF, IE, Safari)
- in server-side JavaScript (via Rhino)
That said: for the largest AJAX application we've build so far (LibX
edition builder at libx.org/editionbuilder ) - we went with a fully
server-centric AJAX solution (ZK from www.zkoss.org ), so no
JavaScript coding here for us....
- Godmar
On Mon, Mar 17, 2008 at 2:44 PM, Joe Hourcle
<[log in to unmask]> 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
>
|