name spaces, dependencies, etc., but well-written, object-oriented
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
- in a Firefox extension
- in a IE plugin
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
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
> > 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
> > 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,
> > I'm wrong?
> I agree, but mostly because I'm concerned with the differing ECMAScript
> 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.
> 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
> 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
> 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
> 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.
> 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: