Christian Boos wrote:
> Of course if someone comes with a convincing need for this, we could
> always switch to that solution at a later point.

Hi Christian!

What follows is not a criticism in any way, so please don't think it
is. Trac's architecture is solid, modular, maintainable, terse in code,
and scalable, so whatever you guys have in mind you have to continue
doing it. But several JavaScript-related developments introduce mild
discomfort in my personal feeling about Trac. First JQuery was used to
generate header links, now macros are required to use client-side JS to
add stylesheets. Nothing wrong with that, but I'm used to a more
conservative attitude towards JavaScript, such as that of Bugzilla
project team for example. Their motto used to be (and I think still is)
that Bugzilla must be functional without JS. Not "fully" functional of
course, but good enough to get work done. I believe that it's a good
idea to achieve maximum functionality on the server side, as that's the
side Trac controls. JS may be off, buggy, slow, or not available in a
browser. So, I as a user would feel better if Trac team were more
conservative about use of JavaScript, that's all.
At the same time, there's been a great deal of innovation coming from
you guys, and you all are experienced Web developers, so I trust that
you'll do what's best, be it adopting JS on a large scale or abandoning
it completely :-).
Thank you,

Sergey.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/trac-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to