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